.. _co-upgrading: Upgrading |co-long|, |cp|, and Helm ----------------------------------- .. _co-migrate-53to54: ----------------------------------------- Upgrading |cp| version 5.3.x to |version| ----------------------------------------- Complete the following procedures to upgrade your operating environment. .. important:: * :ref:`Migrate Helm 2 to Helm 3 `. Helm 3 is recommended for |co-long| and |cp| Kubernetes deployments. Review this information before migrating: `Helm 2 to Helm 3 changes `__. * Make sure that $PATH points to the Helm 3 binary. * |co| and |cp| components restart during the upgrade procedure. * You must complete the procedure for each namespace in your environment. * Extract the new |co-long| |version| bundle. Consider renaming any old extracted directories before starting the procedure. .. _co-upgrade-operator: Upgrade |co-long| ^^^^^^^^^^^^^^^^^ You start the migration and upgrade process by upgrading |co-long|. #. Download and extract the |co-long| |version| bundle. **Bundle download link:** `https://platform-ops-bin.s3-us-west-1.amazonaws.com/operator/confluent-operator-20200115-v0.142.1.tar.gz `__ #. Go to the ``helm`` directory where the files were extracted. #. Go to the **scripts > upgrade** directory. #. Run the ``disable_reconcile.sh`` script. .. important:: If you do not disable the reconcile operations before you run the upgrade, components will begin rolling restarts and some pods may go into ``CrashLoopBackOff`` status. The script disables reconcile operations so that |cp| components do not restart. Only |co| restarts during this upgrade. :: ./disable_reconcile.sh Your output should resemble the following: :: ./disable_reconcile.sh operator physicalstatefulcluster.operator.confluent.cloud/connectors annotated physicalstatefulcluster.operator.confluent.cloud/controlcenter annotated physicalstatefulcluster.operator.confluent.cloud/kafka annotated physicalstatefulcluster.operator.confluent.cloud/ksql annotated physicalstatefulcluster.operator.confluent.cloud/replicator annotated physicalstatefulcluster.operator.confluent.cloud/schemaregistry annotated physicalstatefulcluster.operator.confluent.cloud/zookeeper annotated #. Go to the base ``helm`` directory and enter the following command. :: helm upgrade --install -f \ --set operator.enabled=true \ --wait /helm/confluent-operator \ --namespace ```` is the **NAME** displayed when running the command ``helm ls``. :: NAME REVISION UPDATED STATUS CHART APP VERSION NAMESPACE operator 2 Mon Jan 6 DEPLOYED confluent-operator 1.0 operator Upgrade |zk| ^^^^^^^^^^^^ After |co| is upgraded, you can continue the upgrade for |zk|. .. important:: The cluster will roll during this procedure. #. Go to the ``helm`` directory where the files were extracted. #. Update the |zk| component image. Complete the steps in :ref:`co-update-image-version`. #. Go to the **scripts > upgrade** directory. #. Run the ``pre_upgrade_cp54_zookeeper.sh`` script: :: ./pre_upgrade_cp54_zookeeper.sh For example: :: ./pre_upgrade_cp54_zookeeper.sh operator CONFLUENT_VERSION=5.3.1 echo ==> running zookeeper cluster on namespace operator is part of CP 5.3 release..check if snapshot file exists.. ==> snapshot files already exist for a pod zookeeper-0 in namespace operator ==> copying snapshot.0 successful for a pod zookeeper-1 in namespace operator ==> copying snapshot.0 successful for a pod zookeeper-2 in namespace operator ==> zookeeper cluster is ready to upgrade to CP 5.4 version #. Enter the following command: :: ./enable_reconcile.sh For example: :: ./enable_reconcile.sh operator zookeeper Upgrade |ak| and other |cp| components ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Complete the following steps for the remaining components in the |cp| cluster. .. note:: The cluster will roll during this procedure. #. For non-Kafka components, specifically ksqlDB, |kconnect|, |crep|, |sr|, and |c3-short|, update the their clients running outside of Kubernetes with the changed load balancer ports. When upgrading to release 5.4, the port where the component is reachable via the load balancer is changed to the standard HTTPS (443) or HTTP (80) port, depending on whether TLS is enabled or not. This is a breaking change and requires the clients that were accessing the component via the load balancer to be updated to use the new port. If it is not feasible to update the clients to use the new port, set the ``.tls.port`` field to 8443 (which was the previous default value) or some other value of choice in your Helm values file. For more details, refer to :ref:`Load balancer ports in Confluent Operator `. #. For non-Kafka components, specifically ksqlDB, |kconnect|, |crep|, |sr|, and |c3-short|, update their clients running within Kubernetes with the changed component ports. When upgrading to release 5.4, the *external* and *internal* ports for the component containers and ClusterIP services change. Unlike the load balancer ports discussed in the previous step, these ports cannot be changed. When TLS is enabled for a component, the HTTPS listener is available on the container and ClusterIP service external port. When TLS is disabled for a component, the HTTP listener is available on the container and ClusterIP service internal port. Clients accessing the components from within the Kubernetes cluster must be reconfigured to use the newer ports, as listed in :ref:`Ports in Confluent Operator `. #. Update the remaining |cp| component releases by following the instructions in :ref:`co-update-image-version`. Complete these steps for each component release in the cluster. #. Go to the ``scripts > upgrade`` directory. #. Run the ``enable_reconcile.sh`` script: :: ./enable_reconcile.sh For example: :: ./enable_reconcile.sh operator kafka #. Complete the previous step for all remaining namespaces (if applicable). .. _co-update-image-version: --------------------------------- Updating a single component image --------------------------------- You can update a single |cp| component image version without affecting cluster performance. Special care is taken when upgrading |ak| brokers. The upgrade process verifies topic leader re-election and zero under-replicated partitions before beginning the upgrade process for the next |ak| broker. This ensures that the |ak| cluster continues to perform well while being upgraded. A component rolling upgrade begins after you run the ``helm upgrade`` command shown below, unless you have disabled reconciliation. (See the workflow :ref:`above ` on upgrading to 5.4 for an example where you might disable reconciliation): .. sourcecode:: bash helm upgrade \ -f ./providers/.yaml \ --set .enabled=true \ --set .image.tag= \ ./confluent-operator * Replace ```` with the provider platform for your cluster. * Replace ```` with the new image tag provided by Confluent. * Replace ```` with the component you are updating (for example, kafka, connect, etc.). .. _co-migrate-helm2tohelm3: ------------------------------- Migrating from Helm 2 to Helm 3 ------------------------------- * Review this information before migrating: `Helm 2 to Helm 3 changes `__. * Use the `Helm instructions `__ to migrate from Helm 2 to Helm 3. .. important:: Keep |co-long| and |cp| running during Helm version migration.