|
| 1 | +--- |
| 2 | +layout: blog |
| 3 | +title: 'A Peek at Kubernetes v1.30' |
| 4 | +date: 2024-03-12 |
| 5 | +slug: kubernetes-1-30-upcoming-changes |
| 6 | +--- |
| 7 | + |
| 8 | +**Authors:** Amit Dsouza, Frederick Kautz, Kristin Martin, Abigail McCarthy, Natali Vlatko |
| 9 | + |
| 10 | +## A quick look: exciting changes in Kubernetes v1.30 |
| 11 | + |
| 12 | +It's a new year and a new Kubernetes release. We're halfway through the release cycle and |
| 13 | +have quite a few interesting and exciting enhancements coming in v1.30. From brand new features |
| 14 | +in alpha, to established features graduating to stable, to long-awaited improvements, this release |
| 15 | +has something for everyone to pay attention to! |
| 16 | + |
| 17 | +To tide you over until the official release, here's a sneak peek of the enhancements we're most |
| 18 | +excited about in this cycle! |
| 19 | + |
| 20 | +## Major changes for Kubernetes v1.30 |
| 21 | + |
| 22 | +### Structured parameters for dynamic resource allocation ([KEP-4381](https://kep.k8s.io/4381)) |
| 23 | + |
| 24 | +[Dynamic resource allocation](/docs/concepts/scheduling-eviction/dynamic-resource-allocation/) was |
| 25 | +added to Kubernetes as an alpha feature in v1.26. It defines an alternative to the traditional |
| 26 | +device-plugin API for requesting access to third-party resources. By design, dynamic resource |
| 27 | +allocation uses parameters for resources that are completely opaque to core Kubernetes. This |
| 28 | +approach poses a problem for the Cluster Autoscaler (CA) or any higher-level controller that |
| 29 | +needs to make decisions for a group of pods (e.g. a job scheduler). It cannot simulate the effect of |
| 30 | +allocating or deallocating claims over time. Only the third-party DRA drivers have the information |
| 31 | +available to do this. |
| 32 | + |
| 33 | +Structured Parameters for dynamic resource allocation is an extension to the original |
| 34 | +implementation that addresses this problem by building a framework to support making these claim |
| 35 | +parameters less opaque. Instead of handling the semantics of all claim parameters themselves, |
| 36 | +drivers could manage resources and describe them using a specific "structured model" pre-defined by |
| 37 | +Kubernetes. This would allow components aware of this "structured model" to make decisions about |
| 38 | +these resources without outsourcing them to some third-party controller. For example, the scheduler |
| 39 | +could allocate claims rapidly without back-and-forth communication with dynamic resource |
| 40 | +allocation drivers. Work done for this release centers on defining the framework necessary to enable |
| 41 | +different "structured models" and to implement the "named resources" model. This model allows |
| 42 | +listing individual resource instances and, compared to the traditional device plugin API, adds the |
| 43 | +ability to select those instances individually via attributes. |
| 44 | + |
| 45 | +### Node memory swap support ([KEP-2400](https://kep.k8s.io/2400)) |
| 46 | + |
| 47 | +In Kubernetes v1.30, memory swap support on Linux nodes gets a big change to how it works - with a |
| 48 | +strong emphasis on improving system stability. In previous Kubernetes versions, the `NodeSwap` |
| 49 | +feature gate was disabled by default, and when enabled, it used `UnlimitedSwap` behavior as the |
| 50 | +default behavior. To achieve better stability, `UnlimitedSwap` behavior (which might compromise node |
| 51 | +stability) will be removed in v1.30. |
| 52 | + |
| 53 | +The updated, still-beta support for swap on Linux nodes will be available by default. However, the |
| 54 | +default behavior will be to run the node set to `NoSwap` (not `UnlimitedSwap`) mode. In `NoSwap` |
| 55 | +mode, the kubelet supports running on a node where swap space is active, but Pods don't use any of |
| 56 | +the page file. You'll still need to set `--fail-swap-on=false` for the kubelet to run on that node. |
| 57 | +However, the big change is the other mode: `LimitedSwap`. In this mode, the kubelet actually uses |
| 58 | +the page file on that node and allows Pods to have some of their virtual memory paged out. |
| 59 | +Containers (and their parent pods) do not have access to swap beyond their memory limit, but the |
| 60 | +system can still use the swap space if available. |
| 61 | + |
| 62 | +Kubernetes' Node special interest group (SIG Node) will also update the documentation to help you |
| 63 | +understand how to use the revised implementation, based on feedback from end users, contributors, |
| 64 | +and the wider Kubernetes community. |
| 65 | + |
| 66 | +Read the previous [blog post](/blog/2023/08/24/swap-linux-beta/) or the [node swap |
| 67 | +documentation](/docs/concepts/architecture/nodes/#swap-memory) for more details on |
| 68 | +Linux node swap support in Kubernetes. |
| 69 | + |
| 70 | +### Support user namespaces in pods ([KEP-127](https://kep.k8s.io/127)) |
| 71 | + |
| 72 | +[User namespaces](/docs/concepts/workloads/pods/user-namespaces) is a Linux-only feature that better |
| 73 | +isolates pods to prevent or mitigate several CVEs rated high/critical, including the just-published |
| 74 | +[CVE-2024-21626](https://github.com/opencontainers/runc/security/advisories/GHSA-xr7r-f8xq-vfvv). In |
| 75 | +Kubernetes 1.30, support for user namespaces is migrating to beta, and now supports pods with and |
| 76 | +without volumes, custom UID/GID ranges and more! |
| 77 | + |
| 78 | +### Structured authorization configuration ([KEP-3221](https://kep.k8s.io/3221)) |
| 79 | + |
| 80 | +The Structured Authorization Configuration feature is moving to beta and will be enabled by default. |
| 81 | +This |
| 82 | +[feature](https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/3221-structured-authorization-configuration) |
| 83 | +enables the creation of authorization chains with multiple webhooks with well-defined parameters |
| 84 | +that validate requests in a particular order and allows fine-grained control – such as explicit Deny |
| 85 | +on failures. The configuration file approach even allows you to specify |
| 86 | +[CEL](/docs/reference/using-api/cel/) rules to pre-filter requests before they are dispatched to |
| 87 | +webhooks, helping you to prevent unnecessary invocations. The API server also automatically reloads |
| 88 | +the authorizer chain when the configuration file is modified. |
| 89 | + |
| 90 | +You must specify the path to that authorization configuration using the `--authorization-config` |
| 91 | +command line argument. If you want to keep using command line flags instead of a |
| 92 | +configuration file, those will continue to work as-is. To gain access to new authorization webhook |
| 93 | +capabilities like multiple webhooks, failure policy, and pre-filter rules, switch to putting options |
| 94 | +in an `--authorization-config` file. From Kubernetes 1.30, the configuration file format is |
| 95 | +beta-level, and only requires specifying `--authorization-config` since the feature gate is enabled by |
| 96 | +default. An example configuration with all possible values is provided in the [Authorization |
| 97 | +docs](/docs/reference/access-authn-authz/authorization/#configuring-the-api-server-using-an-authorization-config-file). |
| 98 | +For more details, read the [Authorization |
| 99 | +docs](/docs/reference/access-authn-authz/authorization/#configuring-the-api-server-using-an-authorization-config-file). |
| 100 | + |
| 101 | +### Container resource based pod autoscaling ([KEP-1610](https://kep.k8s.io/1610)) |
| 102 | + |
| 103 | +HPA ContainerResource type metric graduates to stable in v1.30. It allows you to configure |
| 104 | +Autoscaling based on resource usage of individual containers. See [our previous |
| 105 | +blog](/blog/2023/05/02/hpa-container-resource-metric/) for further details. |
| 106 | + |
| 107 | +### CEL for admission control ([KEP-3488](https://kep.k8s.io/3488)) |
| 108 | + |
| 109 | +Integrating Common Expression Language (CEL) for admission control in Kubernetes introduces a more |
| 110 | +dynamic and expressive way of evaluating admission requests. This feature allows complex, |
| 111 | +fine-grained policies to be defined and enforced directly through the Kubernetes API, enhancing |
| 112 | +security and governance capabilities without compromising performance or flexibility. |
| 113 | + |
| 114 | +CEL's addition to Kubernetes admission control empowers cluster administrators to craft intricate |
| 115 | +rules that can evaluate the content of API requests against the desired state and policies of the |
| 116 | +cluster without resorting to Webhook-based access controllers. This level of control is crucial for |
| 117 | +maintaining the integrity, security, and efficiency of cluster operations, making Kubernetes |
| 118 | +environments more robust and adaptable to various use cases and requirements. For more information |
| 119 | +on using CEL for admission control, see the [API |
| 120 | +documentation](/docs/reference/access-authn-authz/validating-admission-policy/) for |
| 121 | +ValidatingAdmissionPolicy. |
| 122 | + |
| 123 | +We hope you're as excited for this release as we are. Keep an eye out for the official release |
| 124 | +blog in a few weeks for more highlights! |
0 commit comments