Kubernetes Versions and Upgrades
OSC provides a defined set of supported Kubernetes versions. Customers select a supported version when creating a Shoot and can upgrade the cluster as newer versions become available.
Gardener coordinates the upgrade of the control plane and worker nodes. This reduces the operational effort, but it does not remove the need for application preparation. Kubernetes releases can deprecate APIs, change defaults or affect add-ons and policies used by customer workloads.
Before an upgrade, customers should review release notes, validate deprecated APIs and test critical workloads in a non-production cluster. Applications should tolerate rolling replacement of worker nodes and should not depend on local, non-persistent node state.
Worker pools are normally upgraded through a rolling process. New nodes are created with the target version or operating-system image, workloads are rescheduled and old nodes are removed. The exact behavior depends on cluster configuration, disruption budgets and available capacity.
OSC communicates supported version ranges and required upgrade windows. Customers remain responsible for scheduling upgrades in time and ensuring that their applications are compatible with the target version. Staying within the supported lifecycle is necessary for security updates and reliable platform operation.
Operating a resilient application on OSC follows a shared responsibility model. Please take note of the detailed responsibilities overview.