Migrate to Confluent for Kubernetes
This topic describes how to migrate Operator 1.x to Confluent for Kubernetes (CFK) 2.0.1
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.
||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.yaml configuration 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
internalTLS is set to
- RBAC is enabled,
internalTLS is set to
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:
kafka: #component section
enabled: false --- 
name: kafka --- 
namespace: confluent --- 
release: kafka --- 
 Set to version
confluentinc/cp-init-container-operator:220.127.116.11 for all
 Required. Set to
true to 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
 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 \
helm repo update --namespace <namespace>
In the same namespace as you have Confluent Operator 1.x, deploy Confluent for Kubernetes
helm upgrade --install confluent-for-kubernetes \
--set licenseKey=<CFK license key> \
Verify that both are deployed and running:
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:
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
# 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 > \
Edit the secret file,
remove everything in the
metadata section except the
Once you’ve validated that all components have been migrated, uninstall Operator
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