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 1.29 (soon to be 1.30); however, you have the flexibility to opt for immediate deployment of version 1.30.
Kubernetes 1.30 highlights
In addition to all the great Kubernetes features provided in this release, IBM Cloud Kubernetes Service version 1.30 also includes numerous component updates that our community is excited about. Some of the highlights for the release include:
-
Secure by Default Cluster VPC Networking: This feature aims to significantly harden the security stature of clusters provisioned in IBM Cloud VPC. When provisioning a new cluster, networking restrictions are employed - only allowing connectivity that is necessary for the cluster to operate. If your new clusters require egress connectivity, additional steps must be performed. For detailed information about Secure by Default VPC Networking and how to operate within this environment, visit here.
-
Kubernetes API server audit policy improvements: The Kubernetes API server for IKS clusters is enabled for auditing by default. Check out Kubernetes API server audit policies to learn more and set up log forwarding for auditing data.
-
Pod Scheduling enhancements: In a real-world scenario, you might have a microservice application deployed in Kubernetes that relies on a service. When a new pod for your microservice is created, it might not be ready for scheduling immediately. It may stay in a “miss-essential-resources" state for a long time, churning the scheduler and some downstream integrators like your Cluster AutoScaler. At the same time, you’re trying to ensure your microservice pods are spread across different zones to avoid a single-node failure. The field .spec.schedulingGates can be used to define a condition that checks if the pod is successfully connected to the service, and you can define a constraint with topologySpreadConstrains that requires pods to be scheduled on different nodes that host that service. For more information on ensuring pod readiness and improved resiliency, visit Pod Scheduling Readiness and Pod Topology Spread.
-
Webhook improvements: Validating admission policies is highly configurable and use the Common Expression Language (CEL) to offer admission webhooks to be replaced with policies by declaring the validation rules of a policy. This enables defining policies that can be scoped to resources. If you need fine-grained request filtering, you can use Match Conditions. See Validating Admission Policy and Matching requests for more on this.
Kubernetes version support updates
Now that IBM Cloud Kubernetes Service supports Kubernetes version 1.30, clusters running version 1.27 are now deprecated with end of support tentatively scheduled for September 18, 2024. It is important to note clusters that run a deprecated Kubernetes version may not receive fixes for security vulnerabilities until they are updated to a non-deprecated 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.26 remain deprecated with end of support tentatively scheduled for May 31, 2024. Clusters running a deprecated version may not receive fixes for security vulnerabilities until they are updated to a non-deprecated version.
-
Clusters running Kubernetes version 1.25 remain unsupported with end of support reached on January 31, 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 shutdown the control planes of such clusters.