We are excited to announce the availability of Kubernetes version 1.29 for your clusters that are running in IBM Cloud Kubernetes Service (IKS). This marks our 24th release of Kubernetes and has been accessible since 14 February.

Our Kubernetes service ensures a straightforward upgrade experience by using the IBM Cloud console, sparing you the need for extensive Kubernetes expertise with just a few clicks! For more information and methods on upgrading your cluster, look here.

When you deploy new clusters, the default Kubernetes version remains at 1.28 (soon to be 1.29); however, you have the flexibility to opt for immediate deployment of version 1.29.

Kubernetes 1.29 highlights

In addition to all the great Kubernetes features provided in this release, IBM Cloud Kubernetes Service version 1.29 also includes numerous component updates that our community is excited about. Some of the highlights for the release include:

• Support for Key Management Service (KMS) v2 (#3299): KMS plays a critical role in securing sensitive data within Kubernetes clusters. With KMS v2, substantial improvements were made in performance, key rotation and observability – offering a more performant and secure experience.
  
  In KMS v1, a data encryption key (DEK) is generated to encrypt the secret and can be cached to decrease the number of KMS calls in future decryption. This feature is especially useful when trying to reduce network load, although a new DEK is generated for each encryption. Should a user opt for a more secure setup by not running in memory, they’d set the cachesize property to 0; however, this setup requires a call to the KMS.
  
  KMS v2 graduated to stable (or generally available). The overarching goal is to reduce the number of calls to KMS and the total number of generated DEKs, while still maintaining a strong security posture. The cachesize property is no longer supported. Instead, on API server startup, a DEK is created and cached with a time limit. Visit Graduated to stable to see the other enhancements that graduated.
  
  Note that with IBM Kubernetes Service, a custom plug-in already does the aforementioned, so we added support for KMS v2 to stay current. The community implementation is now similar to our custom implementation with all the aforementioned benefits.

• Improved Calico installation and operations by using the Tigera-operator: Calico has been used for a long time as the Container Networking Solution in IBM Cloud Kubernetes Service. The goal is to make the installation, upgrades and ongoing lifecycle management of Calico as simple and reliable as possible. Starting with version 1.29, Calico and its components are installed with a Kubernetes operator (tigera-operator). With this change, you can use new features like the Calico typha auto-scaler, which can scale the calico-typha deployment according to the cluster size. Tracking the status of the Calico components is also made easier. The following command can be used to show the state:

kubectl get tigerastatus calico -o yaml

The configuration can be checked with a single command:

kubectl get installation default –o yaml

With operator-based installation, the Calico components are moved. Instead of the kube-system namespace, Calico core components (calico-node, calico-typha, calico-kube-controllers) are running in the calico-system namespace. The operator runs in a new tigera-operator namespace. These namespace and component changes are reflected during the upgrade from Kubernetes 1.28 to 1.29. You can read more about the namespace migration in the release notes.

• Optimized resource requests for control and data plane system components: Cluster health and RBAC sync control plane components were added to our component management catalog for monitoring and patching resource requests. These additions work to improve the overall stability and performance of the Kubernetes cluster, ensuring smoother operation and better resource allocation for applications in the data plane.
  
  Furthermore, combining these components with improved initial resource request values for all control plane components, enhances the Kubernetes environment’s overall health, stability and security posture from the start.
  
  These positive effects ripple across to benefit the data plane, as a healthier control plane translates to a healthier data plane.

To see the full list of IBM and the community’s enhancements, visit Kubernetes v1.29: Mandala and IBM Cloud Kubernetes Service version 1.29 change log for more details.

Kubernetes version support updates

Now that IBM Cloud Kubernetes Service supports Kubernetes version 1.29, clusters running version 1.26 are deprecated with end of support that is tentatively scheduled for 24 April 2024. Clusters that run a deprecated Kubernetes version might not receive fixes for security vulnerabilities until they are updated to a supported version.

As a reminder, if your cluster runs a deprecated or unsupported Kubernetes version, review the potential impact of each Kubernetes version update, and update today. If your cluster runs an archived Kubernetes version, create a new cluster and deploy your apps to the new cluster. Here is the current support status for IBM Cloud Kubernetes Service clusters running an earlier Kubernetes version:

• Clusters running Kubernetes version 1.25 remain unsupported with end of support reached on 31 January 2024. Such clusters will not receive fixes for security vulnerabilities until they are updated to a deprecated or supported version.
• Clusters running Kubernetes version 1.24 or earlier remain archived. For security reasons, IBM reserves the right to shut down the control planes of such clusters.

For general questions, engage our team by using Slack by registering here and join the discussion in the #general channel on our public IBM Cloud Kubernetes Service Slack.