On-Demand ALB Update Feature on IBM Cloud Kubernetes Service

IBM Cloud Kubernetes Service ALB

IBM Cloud Kubernetes Service provides a managed Ingress controller (also referred to by its other name: IBM Cloud Kubernetes Service ALB) as an add-on. The IBM Cloud Kubernetes Service ALB is deployed using a Kubernetes Deployment that runs the ALB pods in the kube-system namespace. By default, there are two pods running in each availability zone on separate worker nodes. The Ingress controller pods are deployed automatically at cluster creation time (or when a new availability zone is added to an existing cluster). The deployment and images are maintained by IBM Cloud Kubernetes service.

Introducing on-demand updates and rollback

Effective immediately, IBM Cloud Kubernetes Service customers can gain control over when the IBM Cloud Kubernetes Service ALB pods are updated in their clusters.

The default setting for each newly created cluster remains—the Ingress controller will get updated automatically by IBM Cloud Kubernetes Service whenever a new version is available. With the newly introduced feature, customers have the option to opt-out from auto-updates and the ability to trigger manual updates of the IBM Cloud Kubernetes Service-managed ALBs per cluster to the latest version of the Ingress controller image at their convenience. Additionally, there is a rollback feature introduced in case the update needs to be reverted. For further information, please visit the official documentation about updates.

Suggested usage pattern

The auto-update opt-out feature is a cluster-level setting. Depending on your environment, your application, SLA targets, and personal choice, you can opt-out for your production and stage clusters while leaving auto-update on for your dev cluster, or opt-out everywhere. If you decide to opt-out, it is suggested that you do the following:

1. Check for updates on a regular basis. If there is a possible disruptive update, we will post to the change log. This way, it possible to take actions ahead of time to prevent outages.

2. If there is an update, go ahead and test the new version in your dev and stage clusters before applying it on your production cluster.

How do I do this?

You can check the currently running IBM Cloud Kubernetes Service-managed ALB version in your cluster and whether there is an available update:

$ ibmcloud ks albs --cluster mycluster

You can opt-out from IBM Cloud Kubernetes Service-managed ALB auto-updates with the following command:

$ ibmcloud ks alb-autoupdate-disable --cluster mycluster

You can check the status of IBM Cloud Kubernetes Service-managed ALB auto-updates with the following command:

$ ibmcloud ks alb-autoupdate-get --cluster mycluster

You can force a one-time update to the latest while staying in auto-update disabled state with the following command:

$ ibmcloud ks alb-update --cluster mycluster

Running this command will result in ALB deployments being updated with the latest stable build that IBM Cloud Kubernetes Service has available for mycluster.

If there are any issues after update to the latest image and you wish to rollback the update, you can do that with the following command:

$ ibmcloud ks alb-rollback --cluster mycluster

This will rollback the ALB pods to the previous build that was last running on the cluster. Please note: This is only a one-time rollback to the previous build and can’t be initiated multiple times.

Here is an example: My current IBM Cloud Kubernetes Service-managed ALB image version is 350. At the time of my intended upgrade, the latest available version is 385. When I trigger the upgrade with ibmcloud ks alb-update , I get version 380 deployed on my cluster. Now if I trigger ibmcloud ks alb-rollback, I will get back to version 350. I cannot get back to an earlier version prior to 350.

If you want to reenable auto-updates to your IBM Cloud Kubernetes Service-managed ALB, you can do that with the following command:

$ ibmcloud ks alb-autoupdate-enable --cluster mycluster

For further information, please visit the official documentation about updates.

FAQ answers and best practices

• It is generally a good idea to keep up-to-date with the latest IBM Cloud Kubernetes Service-managed ALB version because new releases come with security, performance, and feature enhancements.

• Three IBM Cloud Kubernetes Service-managed ALB versions are tested for backward compatibility.

• New clusters always come with the latest version of the IBM Cloud Kubernetes Service-managed ALB.

• Customers cannot pick the version of the IBM Cloud Kubernetes Service-managed ALB. They can only go to the latest version, remain at their current version, or roll back to the previous version after an update.

• If you initiate a rollback while auto-update is on, you get back the previous image before the update happened, and auto-update will be disabled for your cluster (equivalent to ibmcloud ks alb-autoupdate-disable).

• Zone-specific updates in a multi-zone cluster are not supported at this time. The pods will be updated with the update strategy included in the deployment (RollingUpdate) across all zones. The update will start at the same time in each zone, and one pod is updated at a time without downtime.

Contact us

If you have questions, engage our team via Slack by registering here and joining the discussion in the #general channel on our public IBM Cloud Kubernetes Service Slack.