Changelog for Kubernetes 1.33
Versions
The deployed Kubernetes patch version varies based on when your cluster is deployed or upgraded. We strive to use the latest versions available.
Current release leverages Kubernetes 1.33. Official release blogpost found here with corresponding official changelog.
Optional addons
Major changes
- Base Ubuntu image upgraded from 22.04 to 24.04.
Kubelet configurations provided by Elastx, not configurable by client
-
NodeDrainVolumeandNodeDrainTimeout: 5 -> 15min- Increased duration to 15 minutes to allow more time for graceful shutdown and controlled startup of workload on new nodes, while respecting
PodDisruptionBudgets.
- Increased duration to 15 minutes to allow more time for graceful shutdown and controlled startup of workload on new nodes, while respecting
-
podPidsLimit: 0 → 4096- Added safety net of a maximum of Per-pod PIDs (process IDs), that is limited and enforced by the kubelet. We used to not have any limitation. Setting this to
4096limits how many PIDs a single pod may create, which helps mitigate runaway processes or fork-bombs.
- Added safety net of a maximum of Per-pod PIDs (process IDs), that is limited and enforced by the kubelet. We used to not have any limitation. Setting this to
-
serializeImagePulls: true → false- Allows the kubelet to pull multiple images in parallel, speeding up startup times.
-
maxParallelImagePulls: 0 → 10- Controls the maximum number of image pulls the kubelet will perform in parallel.
Introducing resource reservations on worker nodes
To improve stability and predictability of the core Kubernetes functionality during heavy load, we introduce node reservations for CPU, memory, and ephemeral storage.
The reservation model follows proven hyperscaler formulas but is tuned conservatively, ensuring more allocatable resources.
Hyperscalers tend to not make a distinction of systemReserved and kubeReserved, and bundle all reservations into and kubeReserved.
We make use of both, but skewed towards kube reservations to align closer with Hyperscalers, but still maintain the reservations of the system.
We calculate the reservations settings based on Cpu cores, Memory and Storage of each flavor dynamically.
Here we’ve provided a sample of what to expect:
CPU Reservations Table
| Cores (int) | System reserved (millicores) | Kube reserved (millicores) | Allocatable of node (%) |
|---|---|---|---|
| 2 | 35 | 120 | 92% |
| 4 | 41 | 180 | 94% |
| 8 | 81 | 240 | 96% |
| 16 | 83 | 320 | 97% |
| 32 | 88 | 480 | 98% |
| 64 | 98 | 800 | 99% |
Memory Reservations
| Memory (Gi) | System reserved (Gi) | Kube reserved (Gi) | Reserved total (Gi) | Eviction Soft (Gi) | Eviction Hard (Gi) | Allocatable of node (%) |
|---|---|---|---|---|---|---|
| 8 | 0.4 | 1.0 | 1.4 | 0.00 | 0.25 | 79% |
| 16 | 0.4 | 1.8 | 2.2 | 0.00 | 0.25 | 85% |
| 32 | 0.4 | 3.4 | 3.8 | 0.00 | 0.25 | 87% |
| 64 | 0.4 | 3.7 | 4.1 | 0.00 | 0.25 | 93% |
| 120 | 0.4 | 4.3 | 4.7 | 0.00 | 0.25 | 96% |
| 240 | 0.4 | 4.5 | 4.9 | 0.00 | 0.25 | 98% |
| 384 | 0.4 | 6.9 | 7.3 | 0.00 | 0.25 | 98% |
| 512 | 0.4 | 8.2 | 8.6 | 0.00 | 0.25 | 98% |
Ephemeral Disk Reservations
NOTE: We use the default of
nodefs.availableat 10%.
| Storage (Gi) | System reserved (Gi) | Kube reserved (Gi) | Reserved total (Gi) | Eviction Soft (Gi) | Eviction Hard (Gi) | Allocatable of node (%) |
|---|---|---|---|---|---|---|
| 60 | 12.0 | 1.0 | 13.0 | 0.0 | 6.0 | 68% |
| 80 | 12.0 | 1.0 | 13.0 | 0.0 | 8.0 | 74% |
| 120 | 12.0 | 1.0 | 13.0 | 0.0 | 12.0 | 79% |
| 240 | 12.0 | 1.0 | 13.0 | 0.0 | 24.0 | 85% |
| 1600 | 12.0 | 1.0 | 13.0 | 0.0 | 160.0 | 89% |
Noteworthy changes in upcoming versions.
Announcement of changes in future versions.
Kubernetes v1.34
The 4k, 8k, 16k, and v1-dynamic-40 storage classes are scheduled to be removed. Existing volumes will not be affected, but the ability to create those legacy volumes will be removed. Please migrate manifests that specify these storage classes to the storage classes prefixed with v2-, which have been available since Kubernetes 1.26 and have been the default since 2024-06-28 (see the announcement). The v1 storage platform was announced as deprecated 2023-12-20 (see the announcement).
Scheduled for upcoming releases:
- We’ll remove the legacy
nodelocaldnswhere still deployed. Relevant only if the cluster was created before v1.26. - Ingress-nginx controller will be fully deprecated from our management, following the news.
- We will not handle migrations of ingresses, but aim to provide an API Gateway controller as addon.
Is downtime expected?
The cluster control plane should remain available during the upgrade; however, pods will be restarted when workloads are migrated to new nodes. Plan for short pod restarts during the upgrade.
Known issues.
Custom node taints and labels lost during upgrade.
Custom taints and labels on worker and control-plane nodes may be lost during the upgrade. We recommend auditing and reapplying any critical custom taints/labels via automation (e.g., cluster bootstrap, configuration management, or a post-upgrade job).
There is a label that is persistent across upgrades that can be used to direct workload to particular nodegroups. Example on how to use it:
spec:
template:
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: nodegroup.node.cluster.x-k8s.io
operator: In
values:
- worker1
Snapshots are not working.
There is currently a limitation in the snapshot controller: it is not topology-aware. As a result, snapshot behavior may be unreliable for topology-sensitive volumes. Avoid depending on snapshots for cross-zone/region recovery until a topology-aware snapshot controller is available or confirm your storage driver’s snapshot semantics.