1.30 version information and update actions

Review information about version 1.30 of IBM Cloud® Kubernetes Service. For more information about Kubernetes project version 1.30, see the Kubernetes change log.

Figure 1. Kubernetes version 1.30 certification badge

IBM Cloud Kubernetes Service is a Certified Kubernetes product for version 1.30 under the CNCF Kubernetes Software Conformance Certification program. Kubernetes® is a registered trademark of The Linux Foundation in the United States and other countries, and is used pursuant to a license from The Linux Foundation.

Release timeline

The following table includes the expected release timeline for version 1.30 of IBM Cloud® Kubernetes Service. You can use this information for planning purposes, such as to estimate the general time that the version might become unsupported.

Dates that are marked with a dagger (†) are tentative and subject to change.

Release timeline for IBM Cloud Kubernetes Service version 1.30
Version	Supported?	Release date	Unsupported date
1.30	Yes	29 May 2024	13 August 2025 `†`

Preparing to update

This information summarizes updates that are likely to have an impact on deployed apps when you update a cluster to version 1.30. For a complete list of changes, review the community Kubernetes change log and IBM version change log for version 1.30. You can also review the Kubernetes helpful warnings.

VPC workers nodes provisioned at version 1.30 have the VPC Instance Metadata Service enabled. For more information, see About VPC Instance Metadata

Update before master

The following table shows the actions that you must take before you update the Kubernetes master.

Changes to make before you update the master to Kubernetes 1.30
Type	Description
Calico operator namespace migration	If your cluster was upgraded to version 1.29, it will have had a Calico operator namespace migration started. This migration must be completed before your cluster will be allowed to upgrade to version 1.30. If the following commands do not return any data then the migration is complete: `kubectl get nodes -l projectcalico.org/operator-node-migration --no-headers --ignore-not-found ; kubectl get deployment calico-typha -n kube-system -o name --ignore-not-found`.

Update after master

The following table shows the actions that you must take after you update the Kubernetes master.

Changes to make after you update the master to Kubernetes 1.30
Type	Description
Deprecated: Pod `container.apparmor.security.beta.kubernetes.io` annotations.	Pod `container.apparmor.security.beta.kubernetes.io` annotations are now deprecated. These annotations are replaced by the `securityContext.appArmorProfile` field for pods and containers. If your pods rely on these deprecated annotations, update them to use the `securityContext.appArmorProfile` field instead. For more information, see Restrict a Container's Access to Resources with AppArmor.
Unsupported: `kubectl apply` `--prune-whitelist` option	The deprecated `--prune-whitelist` option on `kubectl apply` has been removed and is replaced by the `--prune-allowlist` option. If your scripts rely on the previous behavior, update them.
`kubectl get cronjob` output	The `kubectl get cronjob` output has been changed to include a time zone column. If your scripts rely on the previous behavior, update them.
Kubernetes API server audit policy	The Kubernetes API server `default` and `verbose` audit policies have been updated. If your apps rely on the previous policies, update them.

Important networking changes for VPC clusters created at version 1.30

Beginning with version 1.30, IBM Cloud Kubernetes Service introduced a new security feature for VPC clusters called Secure by Default Cluster VPC Networking.

At a high-level, the security posture for IBM Cloud Kubernetes Service VPC clusters has changed from allowing all outbound traffic and providing users with mechanisms to selectively block traffic as needed to now blocking all traffic that is not crucial to cluster functionality and providing users with mechanisms to selectively allow traffic as needed.

When you provision a new IBM Cloud Kubernetes Service VPC cluster at version 1.30 or later, the default provisioning behavior is to allow only the traffic that is necessary for the cluster to function. All other access is blocked. To implement Secure by Default Networking, there are changes to the default VPC security groups settings as well as new Virtual Private Endpoints (VPEs) for common IBM services.

Some key notes for Secure by Default Networking are:

Applies to VPC clusters only. Classic clusters are not impacted.
Does not affect existing clusters. Existing clusters in your VPC will continue to function as they do today.
Applies only to IBM Cloud Kubernetes Service clusters newly provisioned at version 1.30. The security group configurations for existing IBM Cloud Kubernetes Service clusters that are upgraded to version 1.30, including any customizations you've made, are not changed.
The default behavior for clusters created at version 1.30 and later is to enable Secure by Default outbound traffic protection. However, new parameters in the UI, CLI, API, and Terraform allow you to disable this feature. You can also enable and disable outbound traffic protection after you create a cluster.
If your VPC uses a custom DNS resolver, provisioning a new version 1.30 cluster automatically adds rules allowing traffic through the resolver IP addresses on your IKS-managed security group (kube-<clusterID>).

For an overview of Secure by Default Cluster VPC networking, including the security groups, rules, and VPEs that are created by default, see Understanding Secure by Default Cluster VPC Networking.

Which connections are allowed?

In VPC clusters with Secure by Default outbound traffic protection enabled, the following connections are allowed.

Accessing the internal IBM *.icr.io registries to pull necessary container images via a VPE gateway.
Accessing the cluster master and IBM Cloud Kubernetes Service APIs via VPE gateways.
Accessing other essential IBM services such as logging and monitoring over the private IBM network.
Accessing IBM Cloud DNS.

Which connections are blocked?

Review the following examples of connections that are blocked by default. Note that you can selectively enable outbound traffic to these or other external sources that your app needs.

Pulling images from public registries such as quay.io and Docker Hub.
Accessing any service over the public network.

Changes to worker-to-master backup communication

VPC cluster workers use the private network to communicate with the cluster master. Previously, for VPC clusters that had the public service endpoint enabled, if the private network was blocked or unavailable, then the cluster workers could fall back to using the public network to communicate with the cluster master.

In clusters with Secure by Default outbound traffic protection, falling back to the public network is not an option because public outbound traffic from the cluster workers is blocked. You might want to disable outbound traffic protection to allow this public network backup option, however, there is a better alternative. Instead, if there a temporary issue with the worker-to-master connection over the private network, then, at that time, you can add a temporary security group rule to the kube-clusterID security group to allow outbound traffic to the cluster master apiserver port. This way you allow only traffic for the apiserver instead of all traffic. Later, when the problem is resolved, you can remove the temporary rule.

Allowing outbound traffic after creating a 1.30 cluster

If you created a version 1.30 cluster with outbound traffic protection enabled, your apps or services might experience downtime due to dependencies that require external network connections. Review the following options for enabling outbound traffic selectively or allowing all outbound traffic.

For more information, see Managing outbound traffic protection in VPC clusters.