Migrate to Confluent for Kubernetes¶
This topic describes how to migrate Operator 1.x to Confluent for Kubernetes (CFK) 2.0.0 to manage your Confluent Platform deployment.
Migration is supported from the following software versions:
- Confluent Operator 1.6.x or 1.7.x
- Confluent Platform 6.0.x or 6.1.x
In any of the migration options presented below, there is no destructive change to the Confluent Platform deployment. No Confluent component pods, PersistentVolumeClaims or services are deleted in the migration process.
The following are the recommended migration options based on your current deployment state, referred as the Starting Point in the table.
|Starting Point||Recommended Migration Approach|
|No out-of-band changes  were made to Operator 1 Helm Chart templates||Automated in-place migration |
|Out-of-band changes were made to Operator 1 Helm Chart templates||Manual in-place migration|
|The legacy storage class created by Operator 1 Helm Chart is used||Deploy new cluster and replicate data|
-  Out-of-band changes refer to the changes you made to Operator 1 deployment
outside of the
values.yamlconfiguration file. These changes do not include the configuration changes you made in the
-  In the following configuration scenarios, even without any out-of-band
changes, an automated migration will not be possible. Contact Confluent
support for guidance as the scenario requires a manual migration.
- RBAC is enabled and
internalTLSis set to
- RBAC is enabled,
internalTLSis set to
interbrokerTLSis set to
- External access is configured using the Node Port service
- RBAC is enabled and
If Connect, ksqlDB, or Schema Registry has TLS enabled, ensure that the TLS
certificate have the correct hostnames for the inter-component communication
over the internal Kubernetes network in the certificate Subject Alternative
Name (SAN). This usually maps to the pod DNS name, for example,
Migration job CR¶
Confluent for Kubernetes provides the
MigrationJob custom resource definition (CRD) that
allows you to specify your current deployment state declaratively. You can
trigger a migration by creating a
MigrationJob custom resource (CR).
You can access the current state of the migration through the
sub-resource of the
An example for the Kafka section:
spec: initContainerImage: confluentinc/cp-init-container-operator:126.96.36.199 ---  kafka: #component section enabled: false ---  name: kafka ---  namespace: confluent ---  release: kafka --- 
 Set to version
confluentinc/cp-init-container-operator:188.8.131.52for all migrations.
 Required. Set to
trueto migrate the component with the the
 Required. Set it to the name of the Operator 1.x-deployed Helm Chart component. See where to find it in your Operator 1.x Helm
## Kafka Cluster ## kafka: name: <this-component-name>
 Required. Namespace to find the current component, and where the migrated resource will be created.
 Required. Set to the Helm release name specified with the following command when you deployed Operator 1.x:
helm install <release-name> -f myvalues.yaml ./chart
See an example migration job CR for configuring migration jobs for Confluent components.
Automated in-place migration¶
The automated in-place migration follows these steps:
- Deploy Confluent for Kubernetes 2.0 alongside Confluent Operator 1.x.
- Migrate Confluent Platform components one component at a time. See below for the order
- Execute the migration job for the component.
- Monitor the migration job progress.
- Validate that the migration job finished.
- Once all components are migrated, remove Confluent Operator 1.x.
For each component, once the migration job is kicked off (in step 2), the migration cannot be rolled back.
Migrate the components in the following order:
- Migrate ZooKeeper
- Migrate Kafka
- Migrate Schema Registry
- Migrate ksqlDB
- Migrate Connect
- Migrate Replicator
- Migrate Confluent Control Center
Step 1. Deploy Confluent for Kubernetes 2.0 along side Confluent Operator 1.x¶
Add the Helm repo:
helm repo add confluentinc https://packages.confluent.io/helm \ --namespace <namespace>
helm repo update --namespace <namespace>
In the same namespace as you have Confluent Operator 1.x, deploy Confluent for Kubernetes 2.0:
helm upgrade --install confluent-for-kubernetes \ confluentinc/confluent-for-kubernetes \ --set licenseKey=<CFK license key> \ --namespace <namespace>
Verify that both are deployed and running:
kubectl get pods
NAME READY STATUS RESTARTS AGE cc-operator-7dbc8fd598-bh8r7 1/1 Running 0 2d19h confluent-operator-5b99cdd9d9-bzmqr 1/1 Running 0 20h
Step 2. Execute the migration job one component at a time¶
Execute the migration job one component at a time.
Configure the migration CR as described in Migration job CR.
An example to migrate ZooKeeper:
spec: initContainerImage: confluentinc/cp-init-container-operator:184.108.40.206 zookeeper: enabled: true name: zookeeper namespace: confluent release: zookeeper kafka: enabled: false
Apply the migration CR. This will start the migration job for the component.
Step 3. Monitor the migration job execution progress¶
The migration job for a component executes the following steps:
- Create the CFK 2.0 CustomResource and corresponding Kubernetes objects.
- Roll the component pods to start being managed through the CFK 2.0 CR.
- Remove the Operator 1.x resources.
During migration, check the progress and status with the following commands.
<component> with one of ZooKeeper, Kafka, Schema Registry,
Confluent Control Center, ksqlDB, or Connect. Replace
<namespace> with your namespace
that Operator 1.x is deployed to.
# Check the status of current migration job kubectl get migration migration -oyaml -n <namespace> -w # Check that the migration job creates the CFK 2.0 CustomResource kubectl get <component> -n <namespace> # Check that the component pods are rolling kubectl get pods -n <namespace>
Step 4. Validate that the migration job finished¶
Verify that the migration job successfully finished:
# Validate that migrated components do not have a release helm list # Validate that migrated components do not have a PSC - an Operator 1.x object kubectl get psc -n <namespace> # Validate that all secrets are prefixed with v2 prefix kubectl get secrets -n <namespace>
Step 5. Remove Confluent Operator 1.x¶
When all components are successfully migrated, your Confluent Platform deployment should be in a healthy state.
CFK 2.0 uses the same image pull secret that Operator 1.x uses. If you use a custom Docker registry, ensure that you can re-apply this secret:
Copy the Docker registry secret to a file.
kubectl get secret <your docker registry secret> -oyaml > \ confluent-docker-registry-secret.yaml \ -n <namespace>
Edit the secret file,
confluent-docker-registry-secret.yaml, and remove everything in the
metadatasection except the
Once you’ve validated that all components have been migrated, uninstall Operator 1.x:
Uninstall Operator 1.x:
helm uninstall <operator 1.x helm release> -n <namespace>
Apply the Docker registry secret:
kubectl apply -f confluent-docker-registry-secret.yaml -n <namespace>
Manual in-place migration¶
If you have made changes to the Confluent Operator 1.x Helm Chart templates, contact Confluent Support to review your migration approach with the Confluent engineering team.