From ecb44b697a191db6eb667adda182e29ec7a638e9 Mon Sep 17 00:00:00 2001 From: Matteo Bianchi <37507190+mbianchidev@users.noreply.github.com> Date: Tue, 29 Oct 2024 09:32:23 +0100 Subject: [PATCH 01/27] Kubernetes v1.32 sneak peek blog Add 2024-11-04-kubernetes-1.32-sneak-peek.md --- .../2024-11-04-kubernetes-1.32-sneak-peek.md | 133 ++++++++++++++++++ 1 file changed, 133 insertions(+) create mode 100644 content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md diff --git a/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md b/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md new file mode 100644 index 0000000000000..dc500082a2c0c --- /dev/null +++ b/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md @@ -0,0 +1,133 @@ +--- +layout: blog +title: 'Kubernetes v1.32 sneak peek' +date: 2024-11-04 +slug: kubernetes-1-32-upcoming-changes +author: > + Matteo Bianchi, + Edith Puclla, + William Rizzo, + Ryota Sawada, + Rashan Smith +--- + +As we get closer to the release date for Kubernetes v1.32, the project develops and matures, features may be deprecated, removed, or replaced with better ones for the project's overall health. + +This blog outlines some of the planned changes for the Kubernetes v1.32 release, that the release team feels you should be aware of, for the continued mantainance of your Kubernetes enviroment and keeping up to date with the latest changes. Information listed below is based on the current status of the v1.32 release and may change before the actual release date. + +### The Kubernetes API Removal and Deprecation process +The Kubernetes project has a well-documented [deprecation policy](https://kubernetes.io/docs/reference/using-api/deprecation-policy/) for features. This policy states that stable APIs may only be deprecated when a newer, stable version of that same API is available and that APIs have a minimum lifetime for each stability level. A deprecated API has been marked for removal in a future Kubernetes release, it will continue to function until removal (at least one year from the deprecation), but usage will result in a warning being displayed. Removed APIs are no longer available in the current version, at which point you must migrate to using the replacement. + +* Generally available (GA) or stable API versions may be marked as deprecated but must not be removed within a major version of Kubernetes. + +* Beta or pre-release API versions must be supported for 3 releases after the deprecation. + +* Alpha or experimental API versions may be removed in any release without prior deprecation notice, this process can become a withdrawal in cases where a different implementation for the same feature is already in place. + +Whether an API is removed as a result of a feature graduating from beta to stable or because that API simply did not succeed, all removals comply with this deprecation policy. Whenever an API is removed, migration options are communicated in the [documentation](https://kubernetes.io/docs/reference/using-api/deprecation-guide/). + +## A note about the DRA removal + +This enhancement initially introduced Dynamic Resource Allocation (DRA) in Kubernetes 1.26. + +However, in Kubernetes v1.32, this KEP is withdrawn, and related code will be removed, leaving KEP [#4381](https://github.com/kubernetes/enhancements/issues/4381) as the base functionality. + +The decision to remove this feature originated from its incompatibility with cluster autoscaling, as resource availability was made non-transparent, complicating decision making for both Cluster Autoscaler and controllers. +The newly added Structured Parameter model substitutes the functionality. + +This removal allows Kubernetes to handle new hardware requirements and resource claims more predictably, bypassing the complexities of back and forth API calls to the kube-apiserver. + +Please also see the issue [#3063](https://github.com/kubernetes/enhancements/issues/3063) to find out more. + +## Sneak peek of Kubernetes v1.32 + +### Even more DRA enhancements + +In this release, like the previous one, we are continuing to introduce a number of enhancements to the Dynamic Resource Allocation (DRA), which is a key component of the Kubernetes resource management system. These enhancements aim to improve the flexibility and efficiency of resource allocation for workloads that require specialized hardware, such as GPUs, FPGAs and network adapters. The enhancements include: + +- Partionable devices support: KEP [#4815](https://github.com/kubernetes/enhancements/issues/4815) +- Resource Claim Status and standardized network interface data: KEP [#4817](https://github.com/kubernetes/enhancements/issues/4817) +- Structured parameters: KEP [#4381](https://github.com/kubernetes/enhancements/issues/4381) +- Prioritized Alternatives in Device Requests: KEP [#4816](https://github.com/kubernetes/enhancements/issues/4816) +- Resource Health Status in Pod Status: KEP [#4680](https://github.com/kubernetes/enhancements/issues/4680) + +**Partitionable devices support** + +KEP [#4815](https://github.com/kubernetes/enhancements/issues/4815) introduces improvements to Kubernetes' Dynamic Resource Allocation (DRA) framework, enabling more efficient support for high-performance partitionable devices like GPUs, FPGAs, and network adapters. Currently, these devices are treated as whole units, potentially leading to resource inefficiencies when workloads require only a fraction of a device’s capacity. +By extending the DRA framework, this enhancement allows workloads to request and consume portions of these resources, increasing utilization and scheduling flexibility. The proposed enhancement also provides primitives for representing both full devices and their partitions in a more compact manner, supporting the recent transition from what was called "classic DRA" to the "structured parameters" approach. +The newly proposed extensions, fully transparent to the end-user, enable vendors to provision “overlapping” partitions, ensuring that the scheduler does not allocate conflicting partitions. This approach allows vendors to dynamically create new partitions after allocation, eliminating the need for pre-partitioned configurations, while still supporting device partition selection through existing mechanisms like `ResourceClaim` and `ResourceSlice` in Kubernetes v1.31. + +**Resource Claim Status and standardized network interface data** + +KEP [#4817](https://github.com/kubernetes/enhancements/issues/4817) adds driver-owned fields in `ResourceClaim.Status` with the possibility of having standardized network interface data. +This proposal enhances the `ResourceClaim.Status` field by adding a new sub-field: `Devices`. +The new entry allows to report driver-specific device status data for each allocated device in a `ResourceClaim`. Allowing the drivers to report such data will improve observability and troubleshooting, as well as enabling new functionalities such as, for example, network services (in case the IP addresses of a network device are reported). + + +**DRA Structured parameters** + +The original dynamic resource allocation (DRA) uses claim and class parameters that are opaque to Kubernetes. KEP [#4381](https://github.com/kubernetes/enhancements/issues/4381) introduces structured parameters so that kube-scheduler and Cluster Autoscaler can handle a claim allocation themselves without relying on a third-party driver. +As users are increasingly adopting Kubernetes as their management solution for batch-processing workloads and edge computing, the need of exposing specialized hardware to Pods is increasing. +Such workloads no longer need just RAM and CPU - so this KEP introduced a new API for describing which of these specialized resources a Pod needs, for example devices like a GPU or other kinds of accelerators. + + +**Prioritized Alternatives in Device Requests** + +KEP [#4816](https://github.com/kubernetes/enhancements/issues/4816) adds support for a prioritized list of selection criteria, attached to a device request in a `ResourceClaim`. +The DRA's Structured Parameters feature has added the ability to make requests for very specific types of devices using a `ResourceClaim`. + +However, the current API did not allow the user to indicate any priority when multiple types or configurations of devices might have met the needs of the workload. This feature allows the user to specify alternative requests that satisfy the workloads need, giving more flexibility to the scheduler in the workloads' scheduling phase. + + +**Add Resource Health Status to the Pod Status** + +When a Pod is using a device that has failed or is temporarily unhealthy, it is difficult to know. KEP [#4680](https://github.com/kubernetes/enhancements/issues/4680) makes troubleshooting of Pod crashes easier by exposing device health via `Pod Status`. + + +### Windows strikes back! + +KEP [#4802](https://github.com/kubernetes/enhancements/issues/4802) adds support for graceful shutdown of Windows nodes in Kubernetes clusters. +Currently, Kubernetes provides graceful node shutdown functionality for Linux nodes but lacked equivalent support for Windows. This enhancement aims to enable the kubelet on Windows nodes to handle system shutdown events properly. By doing so, it ensures that Pods running on Windows nodes are gracefully terminated, allowing workloads to be rescheduled without disruption. This improvement enhances the reliability and stability of clusters that include Windows nodes, especially during a planned maintenance or any system updates. + +KEP [#4885](https://github.com/kubernetes/enhancements/issues/4885) adds CPU and memory affinity support to Windows nodes in Kubernetes, thus improving performance for workloads that benefit from cache vicinity and NUMA optimizations, this effort also aligns Windows capabilities with Linux nodes. + +### Almost every ASCII character in env variables - KEP [#4369](https://github.com/kubernetes/enhancements/issues/4369) + +With the graduation of KEP-4369 to beta, Kubernetes now allows almost all printable ASCII characters (excluding "=") to be used as environment variable names. This change addresses the limitations previously imposed on variable naming, facilitating broader adoption of Kubernetes by accommodating various application needs. The relaxed validation will be enabled by default via `RelaxedEnvironmentVariableValidation` feature gate, ensuring that users can easily utilize environment variables without strict constraints, enhancing flexibility for developers working with applications like .NET Core that require special characters in their configurations. + +### Field status.hostIPs added for Pod - KEP [#2681](https://github.com/kubernetes/enhancements/issues/2681) + +This enhancement introduces a new field, status.hostIPs, to the Kubernetes Pod API, enabling support for multiple IP addresses (IPv4 and IPv6) assigned to a node. Previously, the Pod status only included a singular HostIP field, which limited address configurations, particularly in dual-stack networks. This enhancement allows the API to store multiple IP addresses in an array, accessible via the Downward API, which applications can leverage for environments with complex IP requirements, such as IPv6 migrations. +The feature is controlled by the PodHostIPs feature gate, supporting flexibility for gradual rollout. + +### Make Kubernetes aware of the LoadBalancer behaviour - KEP [#1860](https://github.com/kubernetes/enhancements/issues/1860) + +KEP [#1860](https://github.com/kubernetes/enhancements/issues/1860) graduates to GA, introducing the `ipMode` field for a Service of `type: LoadBalancer`, which can be set to either `"VIP"` or `"Proxy"`. The existing behavior of kube-proxy is preserved when using `"VIP"`, where kube-proxy handles the load balancing. The use of `"Proxy"` results in traffic sent directly to the load balancer, providing cloud providers greater control over relying on kube-proxy. + +### Support PSI based on cgroupv2 - KEP [#4205](https://github.com/kubernetes/enhancements/issues/4205) +This KEP adds support in the Kubelet to read Pressure Stall Information (PSI) metrics for CPU, Memory and I/O resources exposed from cAdvisor and runc. Pressure metrics are like a barometer that can warn about impending resource shortages on a node. This will enable the Kubelet to report node conditions, which can be utilized to prevent scheduling of Pods on nodes experiencing significant resource constraints. + +### Retry generate name for Resources - KEP [#4420](https://github.com/kubernetes/enhancements/issues/4420) +This enhancement improves the handling of name conflicts for Kubernetes resources created with the `generateName` field. Previously, if a name conflict occurred, the API server returned a 409 error, and clients had to manually retry the request. With this update, the API server now automatically retries generating a new name up to seven times in case of a conflict. This significantly reduces the chances of collision, ensuring smooth generation of up to 1 million names with less than a 0.1% probability of a conflict, providing more resilience for large-scale workloads. + +### Mutating admission policies - KEP [#3962](https://github.com/kubernetes/enhancements/issues/3962) + +This enhancement introduces "Mutating Admission Policies" using CEL (Common Expression Language), allowing Kubernetes users to define in-line mutating policies without the need for complex admission webhooks. +This enhancement simplifies common mutating tasks—such as adding labels, setting fields, or injecting sidecars—by enabling policies to be directly defined within the Kubernetes API server. With CEL's object instantiation and Server-Side Apply merge algorithms, these policies can minimize reinvocation, reduce latency, and eliminate the overhead associated with webhook management. This new approach enhances Kubernetes extensibility by reducing operational complexity, also provides a scalable, built-in solution for secure and efficient policy management across diverse use cases like GitOps and CI/CD, making Kubernetes admission control more accessible and powerful for developers and administrators alike. + +### Control over terminating Pods in Deployments - KEP [#3973](https://github.com/kubernetes/enhancements/issues/3973) + +This enhancement adds a new field `.spec.PodReplacementPolicy` to Deployments, to specify whether new Pods can be scheduled only after old Pods have finished terminating, or once old Pods start terminating. The default behavior depends on the deployment strategy. Specifying this Pod replacement policy can potentially help avoid problems with excessive resource usage or slow scheduling during rollouts and scaling. + +## Want to know more? +New features and deprecations are also announced in the Kubernetes release notes. We will formally announce what's new in [Kubernetes v1.32](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.32.md) as part of the CHANGELOG for this release. + +You can see the announcements of changes in the release notes for: + +* [Kubernetes v1.31](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.31.md) + +* [Kubernetes v1.30](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.30.md) + +* [Kubernetes v1.29](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.29.md) + +* [Kubernetes v1.28](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.28.md) From bb8405920cc63823ddadf1b5ebf2c8ef81fa35b7 Mon Sep 17 00:00:00 2001 From: Matteo Bianchi <37507190+mbianchidev@users.noreply.github.com> Date: Tue, 29 Oct 2024 15:29:58 +0100 Subject: [PATCH 02/27] Updated link to relative as suggested Update content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md Co-authored-by: Dipesh Rawat --- content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md b/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md index dc500082a2c0c..fc2b3c41d09ca 100644 --- a/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md +++ b/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md @@ -24,7 +24,7 @@ The Kubernetes project has a well-documented [deprecation policy](https://kubern * Alpha or experimental API versions may be removed in any release without prior deprecation notice, this process can become a withdrawal in cases where a different implementation for the same feature is already in place. -Whether an API is removed as a result of a feature graduating from beta to stable or because that API simply did not succeed, all removals comply with this deprecation policy. Whenever an API is removed, migration options are communicated in the [documentation](https://kubernetes.io/docs/reference/using-api/deprecation-guide/). +Whether an API is removed as a result of a feature graduating from beta to stable or because that API simply did not succeed, all removals comply with this deprecation policy. Whenever an API is removed, migration options are communicated in the [documentation](/docs/reference/using-api/deprecation-guide/). ## A note about the DRA removal From 381b71432cfa1dee0407b0cf3f29eedc0eed24cc Mon Sep 17 00:00:00 2001 From: Matteo Bianchi <37507190+mbianchidev@users.noreply.github.com> Date: Tue, 29 Oct 2024 15:30:12 +0100 Subject: [PATCH 03/27] Updated link to relative as suggested Update content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md Co-authored-by: Dipesh Rawat --- content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md b/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md index fc2b3c41d09ca..50bc623b803ed 100644 --- a/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md +++ b/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md @@ -16,7 +16,7 @@ As we get closer to the release date for Kubernetes v1.32, the project develops This blog outlines some of the planned changes for the Kubernetes v1.32 release, that the release team feels you should be aware of, for the continued mantainance of your Kubernetes enviroment and keeping up to date with the latest changes. Information listed below is based on the current status of the v1.32 release and may change before the actual release date. ### The Kubernetes API Removal and Deprecation process -The Kubernetes project has a well-documented [deprecation policy](https://kubernetes.io/docs/reference/using-api/deprecation-policy/) for features. This policy states that stable APIs may only be deprecated when a newer, stable version of that same API is available and that APIs have a minimum lifetime for each stability level. A deprecated API has been marked for removal in a future Kubernetes release, it will continue to function until removal (at least one year from the deprecation), but usage will result in a warning being displayed. Removed APIs are no longer available in the current version, at which point you must migrate to using the replacement. +The Kubernetes project has a well-documented [deprecation policy](/docs/reference/using-api/deprecation-policy/) for features. This policy states that stable APIs may only be deprecated when a newer, stable version of that same API is available and that APIs have a minimum lifetime for each stability level. A deprecated API has been marked for removal in a future Kubernetes release, it will continue to function until removal (at least one year from the deprecation), but usage will result in a warning being displayed. Removed APIs are no longer available in the current version, at which point you must migrate to using the replacement. * Generally available (GA) or stable API versions may be marked as deprecated but must not be removed within a major version of Kubernetes. From 8b685a357a1400c294e687b63af5080e721387a5 Mon Sep 17 00:00:00 2001 From: Matteo Bianchi <37507190+mbianchidev@users.noreply.github.com> Date: Tue, 29 Oct 2024 16:35:54 +0100 Subject: [PATCH 04/27] Lang nit British -> American Update 2024-11-04-kubernetes-1.32-sneak-peek.md --- content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md b/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md index 50bc623b803ed..d1c5635005112 100644 --- a/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md +++ b/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md @@ -100,7 +100,7 @@ With the graduation of KEP-4369 to beta, Kubernetes now allows almost all printa This enhancement introduces a new field, status.hostIPs, to the Kubernetes Pod API, enabling support for multiple IP addresses (IPv4 and IPv6) assigned to a node. Previously, the Pod status only included a singular HostIP field, which limited address configurations, particularly in dual-stack networks. This enhancement allows the API to store multiple IP addresses in an array, accessible via the Downward API, which applications can leverage for environments with complex IP requirements, such as IPv6 migrations. The feature is controlled by the PodHostIPs feature gate, supporting flexibility for gradual rollout. -### Make Kubernetes aware of the LoadBalancer behaviour - KEP [#1860](https://github.com/kubernetes/enhancements/issues/1860) +### Make Kubernetes aware of the LoadBalancer behavior - KEP [#1860](https://github.com/kubernetes/enhancements/issues/1860) KEP [#1860](https://github.com/kubernetes/enhancements/issues/1860) graduates to GA, introducing the `ipMode` field for a Service of `type: LoadBalancer`, which can be set to either `"VIP"` or `"Proxy"`. The existing behavior of kube-proxy is preserved when using `"VIP"`, where kube-proxy handles the load balancing. The use of `"Proxy"` results in traffic sent directly to the load balancer, providing cloud providers greater control over relying on kube-proxy. From 84190688d51aa8189d0ba8cf682dfa98a8e9d779 Mon Sep 17 00:00:00 2001 From: Matteo Bianchi <37507190+mbianchidev@users.noreply.github.com> Date: Tue, 29 Oct 2024 16:51:53 +0100 Subject: [PATCH 05/27] Updated phrasing to avoid "removal of DRA" confusion Update 2024-11-04-kubernetes-1.32-sneak-peek.md --- .../en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md b/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md index d1c5635005112..619b680e4fd48 100644 --- a/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md +++ b/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md @@ -26,7 +26,7 @@ The Kubernetes project has a well-documented [deprecation policy](/docs/referenc Whether an API is removed as a result of a feature graduating from beta to stable or because that API simply did not succeed, all removals comply with this deprecation policy. Whenever an API is removed, migration options are communicated in the [documentation](/docs/reference/using-api/deprecation-guide/). -## A note about the DRA removal +## Note on the removal of the old DRA implementation This enhancement initially introduced Dynamic Resource Allocation (DRA) in Kubernetes 1.26. @@ -41,9 +41,9 @@ Please also see the issue [#3063](https://github.com/kubernetes/enhancements/iss ## Sneak peek of Kubernetes v1.32 -### Even more DRA enhancements +### Even more DRA enhancements! -In this release, like the previous one, we are continuing to introduce a number of enhancements to the Dynamic Resource Allocation (DRA), which is a key component of the Kubernetes resource management system. These enhancements aim to improve the flexibility and efficiency of resource allocation for workloads that require specialized hardware, such as GPUs, FPGAs and network adapters. The enhancements include: +In this release, like the previous one, the Kubernetes project continues to introduce enhancements to the Dynamic Resource Allocation (DRA), which is a key component of the Kubernetes resource management system. These enhancements aim to improve the flexibility and efficiency of resource allocation for workloads that require specialized hardware, such as GPUs, FPGAs and network adapters. The enhancements for this release include: - Partionable devices support: KEP [#4815](https://github.com/kubernetes/enhancements/issues/4815) - Resource Claim Status and standardized network interface data: KEP [#4817](https://github.com/kubernetes/enhancements/issues/4817) From a6212caacf6de74fad90151d76648eb88c5fd831 Mon Sep 17 00:00:00 2001 From: Matteo Bianchi <37507190+mbianchidev@users.noreply.github.com> Date: Tue, 29 Oct 2024 16:53:35 +0100 Subject: [PATCH 06/27] Update 2024-11-04-kubernetes-1.32-sneak-peek.md --- .../en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md b/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md index 619b680e4fd48..a42b61a40cf2f 100644 --- a/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md +++ b/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md @@ -28,9 +28,9 @@ Whether an API is removed as a result of a feature graduating from beta to stabl ## Note on the removal of the old DRA implementation -This enhancement initially introduced Dynamic Resource Allocation (DRA) in Kubernetes 1.26. +This enhancement [#3063](https://github.com/kubernetes/enhancements/issues/3063) initially introduced Dynamic Resource Allocation (DRA) in Kubernetes 1.26. -However, in Kubernetes v1.32, this KEP is withdrawn, and related code will be removed, leaving KEP [#4381](https://github.com/kubernetes/enhancements/issues/4381) as the base functionality. +However, in Kubernetes v1.32, it is withdrawn and related code will be removed, leaving KEP [#4381](https://github.com/kubernetes/enhancements/issues/4381) as the "new" base functionality. The decision to remove this feature originated from its incompatibility with cluster autoscaling, as resource availability was made non-transparent, complicating decision making for both Cluster Autoscaler and controllers. The newly added Structured Parameter model substitutes the functionality. From 4fb4bda7277e920f48e7327f0427e3bbc2dbfa21 Mon Sep 17 00:00:00 2001 From: Matteo Bianchi <37507190+mbianchidev@users.noreply.github.com> Date: Tue, 29 Oct 2024 17:13:51 +0100 Subject: [PATCH 07/27] Removal -> Withdrawal Update 2024-11-04-kubernetes-1.32-sneak-peek.md --- content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md b/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md index a42b61a40cf2f..870c9da21dbb1 100644 --- a/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md +++ b/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md @@ -26,7 +26,7 @@ The Kubernetes project has a well-documented [deprecation policy](/docs/referenc Whether an API is removed as a result of a feature graduating from beta to stable or because that API simply did not succeed, all removals comply with this deprecation policy. Whenever an API is removed, migration options are communicated in the [documentation](/docs/reference/using-api/deprecation-guide/). -## Note on the removal of the old DRA implementation +## Note on the withdrawal of the old DRA implementation This enhancement [#3063](https://github.com/kubernetes/enhancements/issues/3063) initially introduced Dynamic Resource Allocation (DRA) in Kubernetes 1.26. From b8ad49bf96d5f4a881bf334fb4a8d17856647e3f Mon Sep 17 00:00:00 2001 From: Matteo Bianchi <37507190+mbianchidev@users.noreply.github.com> Date: Tue, 29 Oct 2024 21:21:43 +0100 Subject: [PATCH 08/27] Avoid mentioning scheduling as requested during review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Update content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md Co-authored-by: Filip Křepinský --- content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md b/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md index 870c9da21dbb1..d74d57a82f40f 100644 --- a/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md +++ b/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md @@ -117,7 +117,7 @@ This enhancement simplifies common mutating tasks—such as adding labels, setti ### Control over terminating Pods in Deployments - KEP [#3973](https://github.com/kubernetes/enhancements/issues/3973) -This enhancement adds a new field `.spec.PodReplacementPolicy` to Deployments, to specify whether new Pods can be scheduled only after old Pods have finished terminating, or once old Pods start terminating. The default behavior depends on the deployment strategy. Specifying this Pod replacement policy can potentially help avoid problems with excessive resource usage or slow scheduling during rollouts and scaling. +This enhancement adds a new field `.spec.podReplacementPolicy` to Deployments, to specify whether new Pods can be created only after old Pods have finished terminating, or once old Pods start terminating. The default behavior depends on the deployment strategy. Specifying this Pod replacement policy can help to better control the speed of rollouts/scaling, and potentially avoid problems with excessive resource usage. ## Want to know more? New features and deprecations are also announced in the Kubernetes release notes. We will formally announce what's new in [Kubernetes v1.32](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.32.md) as part of the CHANGELOG for this release. From 4958194c4f0ee0019bf1e86c0ba2a5e7ff6db5a9 Mon Sep 17 00:00:00 2001 From: Matteo Bianchi <37507190+mbianchidev@users.noreply.github.com> Date: Wed, 30 Oct 2024 09:09:53 +0100 Subject: [PATCH 09/27] KEP 4369 title changed as suggested during review Update content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md Co-authored-by: divya-mohan0209 --- content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md b/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md index d74d57a82f40f..505d5e4ffae54 100644 --- a/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md +++ b/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md @@ -91,7 +91,7 @@ Currently, Kubernetes provides graceful node shutdown functionality for Linux no KEP [#4885](https://github.com/kubernetes/enhancements/issues/4885) adds CPU and memory affinity support to Windows nodes in Kubernetes, thus improving performance for workloads that benefit from cache vicinity and NUMA optimizations, this effort also aligns Windows capabilities with Linux nodes. -### Almost every ASCII character in env variables - KEP [#4369](https://github.com/kubernetes/enhancements/issues/4369) +### Allow special characters in environment variables - KEP [#4369](https://github.com/kubernetes/enhancements/issues/4369) With the graduation of KEP-4369 to beta, Kubernetes now allows almost all printable ASCII characters (excluding "=") to be used as environment variable names. This change addresses the limitations previously imposed on variable naming, facilitating broader adoption of Kubernetes by accommodating various application needs. The relaxed validation will be enabled by default via `RelaxedEnvironmentVariableValidation` feature gate, ensuring that users can easily utilize environment variables without strict constraints, enhancing flexibility for developers working with applications like .NET Core that require special characters in their configurations. From fe0e3915e0756afdb0133a3df5e3bcc0c659d481 Mon Sep 17 00:00:00 2001 From: Matteo Bianchi <37507190+mbianchidev@users.noreply.github.com> Date: Wed, 30 Oct 2024 09:19:50 +0100 Subject: [PATCH 10/27] Addressed first review comments from sig-docs-blog Update 2024-11-04-kubernetes-1.32-sneak-peek.md --- .../2024-11-04-kubernetes-1.32-sneak-peek.md | 36 +++++++++---------- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md b/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md index 505d5e4ffae54..1786ca6a236a4 100644 --- a/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md +++ b/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md @@ -15,7 +15,7 @@ As we get closer to the release date for Kubernetes v1.32, the project develops This blog outlines some of the planned changes for the Kubernetes v1.32 release, that the release team feels you should be aware of, for the continued mantainance of your Kubernetes enviroment and keeping up to date with the latest changes. Information listed below is based on the current status of the v1.32 release and may change before the actual release date. -### The Kubernetes API Removal and Deprecation process +### The Kubernetes API removal and deprecation process The Kubernetes project has a well-documented [deprecation policy](/docs/reference/using-api/deprecation-policy/) for features. This policy states that stable APIs may only be deprecated when a newer, stable version of that same API is available and that APIs have a minimum lifetime for each stability level. A deprecated API has been marked for removal in a future Kubernetes release, it will continue to function until removal (at least one year from the deprecation), but usage will result in a warning being displayed. Removed APIs are no longer available in the current version, at which point you must migrate to using the replacement. * Generally available (GA) or stable API versions may be marked as deprecated but must not be removed within a major version of Kubernetes. @@ -37,7 +37,7 @@ The newly added Structured Parameter model substitutes the functionality. This removal allows Kubernetes to handle new hardware requirements and resource claims more predictably, bypassing the complexities of back and forth API calls to the kube-apiserver. -Please also see the issue [#3063](https://github.com/kubernetes/enhancements/issues/3063) to find out more. +Please also see the enhancement issue [#3063](https://github.com/kubernetes/enhancements/issues/3063) to find out more. ## Sneak peek of Kubernetes v1.32 @@ -45,11 +45,11 @@ Please also see the issue [#3063](https://github.com/kubernetes/enhancements/iss In this release, like the previous one, the Kubernetes project continues to introduce enhancements to the Dynamic Resource Allocation (DRA), which is a key component of the Kubernetes resource management system. These enhancements aim to improve the flexibility and efficiency of resource allocation for workloads that require specialized hardware, such as GPUs, FPGAs and network adapters. The enhancements for this release include: -- Partionable devices support: KEP [#4815](https://github.com/kubernetes/enhancements/issues/4815) -- Resource Claim Status and standardized network interface data: KEP [#4817](https://github.com/kubernetes/enhancements/issues/4817) +- Partitionable devices support: [KEP #4815](https://github.com/kubernetes/enhancements/issues/4815) +- Resource Claim Status and standardized network interface data: [KEP #4817](https://github.com/kubernetes/enhancements/issues/4817) - Structured parameters: KEP [#4381](https://github.com/kubernetes/enhancements/issues/4381) -- Prioritized Alternatives in Device Requests: KEP [#4816](https://github.com/kubernetes/enhancements/issues/4816) -- Resource Health Status in Pod Status: KEP [#4680](https://github.com/kubernetes/enhancements/issues/4680) +- Prioritized Alternatives in Device Requests: [KEP #4816](https://github.com/kubernetes/enhancements/issues/4816) +- Resource Health Status in Pod Status: [KEP #4680](https://github.com/kubernetes/enhancements/issues/4680) **Partitionable devices support** @@ -57,21 +57,21 @@ KEP [#4815](https://github.com/kubernetes/enhancements/issues/4815) introduces i By extending the DRA framework, this enhancement allows workloads to request and consume portions of these resources, increasing utilization and scheduling flexibility. The proposed enhancement also provides primitives for representing both full devices and their partitions in a more compact manner, supporting the recent transition from what was called "classic DRA" to the "structured parameters" approach. The newly proposed extensions, fully transparent to the end-user, enable vendors to provision “overlapping” partitions, ensuring that the scheduler does not allocate conflicting partitions. This approach allows vendors to dynamically create new partitions after allocation, eliminating the need for pre-partitioned configurations, while still supporting device partition selection through existing mechanisms like `ResourceClaim` and `ResourceSlice` in Kubernetes v1.31. -**Resource Claim Status and standardized network interface data** +**Resource Claim status and standardized network interface data** KEP [#4817](https://github.com/kubernetes/enhancements/issues/4817) adds driver-owned fields in `ResourceClaim.Status` with the possibility of having standardized network interface data. This proposal enhances the `ResourceClaim.Status` field by adding a new sub-field: `Devices`. The new entry allows to report driver-specific device status data for each allocated device in a `ResourceClaim`. Allowing the drivers to report such data will improve observability and troubleshooting, as well as enabling new functionalities such as, for example, network services (in case the IP addresses of a network device are reported). -**DRA Structured parameters** +**DRA Structured Parameters** The original dynamic resource allocation (DRA) uses claim and class parameters that are opaque to Kubernetes. KEP [#4381](https://github.com/kubernetes/enhancements/issues/4381) introduces structured parameters so that kube-scheduler and Cluster Autoscaler can handle a claim allocation themselves without relying on a third-party driver. As users are increasingly adopting Kubernetes as their management solution for batch-processing workloads and edge computing, the need of exposing specialized hardware to Pods is increasing. Such workloads no longer need just RAM and CPU - so this KEP introduced a new API for describing which of these specialized resources a Pod needs, for example devices like a GPU or other kinds of accelerators. -**Prioritized Alternatives in Device Requests** +**Prioritized alternatives in device requests** KEP [#4816](https://github.com/kubernetes/enhancements/issues/4816) adds support for a prioritized list of selection criteria, attached to a device request in a `ResourceClaim`. The DRA's Structured Parameters feature has added the ability to make requests for very specific types of devices using a `ResourceClaim`. @@ -79,7 +79,7 @@ The DRA's Structured Parameters feature has added the ability to make requests f However, the current API did not allow the user to indicate any priority when multiple types or configurations of devices might have met the needs of the workload. This feature allows the user to specify alternative requests that satisfy the workloads need, giving more flexibility to the scheduler in the workloads' scheduling phase. -**Add Resource Health Status to the Pod Status** +**Add resource health status to the Pod status** When a Pod is using a device that has failed or is temporarily unhealthy, it is difficult to know. KEP [#4680](https://github.com/kubernetes/enhancements/issues/4680) makes troubleshooting of Pod crashes easier by exposing device health via `Pod Status`. @@ -91,31 +91,31 @@ Currently, Kubernetes provides graceful node shutdown functionality for Linux no KEP [#4885](https://github.com/kubernetes/enhancements/issues/4885) adds CPU and memory affinity support to Windows nodes in Kubernetes, thus improving performance for workloads that benefit from cache vicinity and NUMA optimizations, this effort also aligns Windows capabilities with Linux nodes. -### Allow special characters in environment variables - KEP [#4369](https://github.com/kubernetes/enhancements/issues/4369) +### Allow special characters in environment variables - [KEP #4369](https://github.com/kubernetes/enhancements/issues/4369) With the graduation of KEP-4369 to beta, Kubernetes now allows almost all printable ASCII characters (excluding "=") to be used as environment variable names. This change addresses the limitations previously imposed on variable naming, facilitating broader adoption of Kubernetes by accommodating various application needs. The relaxed validation will be enabled by default via `RelaxedEnvironmentVariableValidation` feature gate, ensuring that users can easily utilize environment variables without strict constraints, enhancing flexibility for developers working with applications like .NET Core that require special characters in their configurations. -### Field status.hostIPs added for Pod - KEP [#2681](https://github.com/kubernetes/enhancements/issues/2681) +### Field status.hostIPs added for Pod - [KEP #2681](https://github.com/kubernetes/enhancements/issues/2681) -This enhancement introduces a new field, status.hostIPs, to the Kubernetes Pod API, enabling support for multiple IP addresses (IPv4 and IPv6) assigned to a node. Previously, the Pod status only included a singular HostIP field, which limited address configurations, particularly in dual-stack networks. This enhancement allows the API to store multiple IP addresses in an array, accessible via the Downward API, which applications can leverage for environments with complex IP requirements, such as IPv6 migrations. +This enhancement introduces a new field, `status.hostIPs`, to the Kubernetes Pod API, enabling support for multiple IP addresses (IPv4 and IPv6) assigned to a node. Previously, the Pod status only included a singular HostIP field, which limited address configurations, particularly in dual-stack networks. This enhancement allows the API to store multiple IP addresses in an array, accessible via the Downward API, which applications can leverage for environments with complex IP requirements, such as IPv6 migrations. The feature is controlled by the PodHostIPs feature gate, supporting flexibility for gradual rollout. -### Make Kubernetes aware of the LoadBalancer behavior - KEP [#1860](https://github.com/kubernetes/enhancements/issues/1860) +### Make Kubernetes aware of the LoadBalancer behavior - [KEP #1860](https://github.com/kubernetes/enhancements/issues/1860) KEP [#1860](https://github.com/kubernetes/enhancements/issues/1860) graduates to GA, introducing the `ipMode` field for a Service of `type: LoadBalancer`, which can be set to either `"VIP"` or `"Proxy"`. The existing behavior of kube-proxy is preserved when using `"VIP"`, where kube-proxy handles the load balancing. The use of `"Proxy"` results in traffic sent directly to the load balancer, providing cloud providers greater control over relying on kube-proxy. -### Support PSI based on cgroupv2 - KEP [#4205](https://github.com/kubernetes/enhancements/issues/4205) +### Support PSI based on cgroupv2 - [KEP #4205](https://github.com/kubernetes/enhancements/issues/4205) This KEP adds support in the Kubelet to read Pressure Stall Information (PSI) metrics for CPU, Memory and I/O resources exposed from cAdvisor and runc. Pressure metrics are like a barometer that can warn about impending resource shortages on a node. This will enable the Kubelet to report node conditions, which can be utilized to prevent scheduling of Pods on nodes experiencing significant resource constraints. -### Retry generate name for Resources - KEP [#4420](https://github.com/kubernetes/enhancements/issues/4420) +### Retry generate name for resources - [KEP #4420](https://github.com/kubernetes/enhancements/issues/4420) This enhancement improves the handling of name conflicts for Kubernetes resources created with the `generateName` field. Previously, if a name conflict occurred, the API server returned a 409 error, and clients had to manually retry the request. With this update, the API server now automatically retries generating a new name up to seven times in case of a conflict. This significantly reduces the chances of collision, ensuring smooth generation of up to 1 million names with less than a 0.1% probability of a conflict, providing more resilience for large-scale workloads. -### Mutating admission policies - KEP [#3962](https://github.com/kubernetes/enhancements/issues/3962) +### Mutating admission policies - [KEP #3962](https://github.com/kubernetes/enhancements/issues/3962) This enhancement introduces "Mutating Admission Policies" using CEL (Common Expression Language), allowing Kubernetes users to define in-line mutating policies without the need for complex admission webhooks. This enhancement simplifies common mutating tasks—such as adding labels, setting fields, or injecting sidecars—by enabling policies to be directly defined within the Kubernetes API server. With CEL's object instantiation and Server-Side Apply merge algorithms, these policies can minimize reinvocation, reduce latency, and eliminate the overhead associated with webhook management. This new approach enhances Kubernetes extensibility by reducing operational complexity, also provides a scalable, built-in solution for secure and efficient policy management across diverse use cases like GitOps and CI/CD, making Kubernetes admission control more accessible and powerful for developers and administrators alike. -### Control over terminating Pods in Deployments - KEP [#3973](https://github.com/kubernetes/enhancements/issues/3973) +### Control over terminating Pods in deployments - [KEP #3973](https://github.com/kubernetes/enhancements/issues/3973) This enhancement adds a new field `.spec.podReplacementPolicy` to Deployments, to specify whether new Pods can be created only after old Pods have finished terminating, or once old Pods start terminating. The default behavior depends on the deployment strategy. Specifying this Pod replacement policy can help to better control the speed of rollouts/scaling, and potentially avoid problems with excessive resource usage. From 9c59132fa792f695cb4d8a08cbb4d5d475baf91b Mon Sep 17 00:00:00 2001 From: Matteo Bianchi <37507190+mbianchidev@users.noreply.github.com> Date: Wed, 30 Oct 2024 18:07:28 +0100 Subject: [PATCH 11/27] Addressed some grammar and nits Update 2024-11-04-kubernetes-1.32-sneak-peek.md --- .../en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md b/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md index 1786ca6a236a4..5de7d36076e0e 100644 --- a/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md +++ b/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md @@ -13,7 +13,7 @@ author: > As we get closer to the release date for Kubernetes v1.32, the project develops and matures, features may be deprecated, removed, or replaced with better ones for the project's overall health. -This blog outlines some of the planned changes for the Kubernetes v1.32 release, that the release team feels you should be aware of, for the continued mantainance of your Kubernetes enviroment and keeping up to date with the latest changes. Information listed below is based on the current status of the v1.32 release and may change before the actual release date. +This blog outlines some of the planned changes for the Kubernetes v1.32 release, that the release team feels you should be aware of, for the continued maintenance of your Kubernetes environment and keeping up to date with the latest changes. Information listed below is based on the current status of the v1.32 release and may change before the actual release date. ### The Kubernetes API removal and deprecation process The Kubernetes project has a well-documented [deprecation policy](/docs/reference/using-api/deprecation-policy/) for features. This policy states that stable APIs may only be deprecated when a newer, stable version of that same API is available and that APIs have a minimum lifetime for each stability level. A deprecated API has been marked for removal in a future Kubernetes release, it will continue to function until removal (at least one year from the deprecation), but usage will result in a warning being displayed. Removed APIs are no longer available in the current version, at which point you must migrate to using the replacement. @@ -47,7 +47,7 @@ In this release, like the previous one, the Kubernetes project continues to intr - Partitionable devices support: [KEP #4815](https://github.com/kubernetes/enhancements/issues/4815) - Resource Claim Status and standardized network interface data: [KEP #4817](https://github.com/kubernetes/enhancements/issues/4817) -- Structured parameters: KEP [#4381](https://github.com/kubernetes/enhancements/issues/4381) +- Structured parameters: [KEP #4381](https://github.com/kubernetes/enhancements/issues/4381) - Prioritized Alternatives in Device Requests: [KEP #4816](https://github.com/kubernetes/enhancements/issues/4816) - Resource Health Status in Pod Status: [KEP #4680](https://github.com/kubernetes/enhancements/issues/4680) From b32320077b16675dc693dd1d40705a6d57cfac80 Mon Sep 17 00:00:00 2001 From: Matteo Bianchi <37507190+mbianchidev@users.noreply.github.com> Date: Wed, 30 Oct 2024 18:08:47 +0100 Subject: [PATCH 12/27] Documentation -> Deprecation guide Update 2024-11-04-kubernetes-1.32-sneak-peek.md --- content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md b/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md index 5de7d36076e0e..e76d41296f54e 100644 --- a/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md +++ b/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md @@ -24,7 +24,7 @@ The Kubernetes project has a well-documented [deprecation policy](/docs/referenc * Alpha or experimental API versions may be removed in any release without prior deprecation notice, this process can become a withdrawal in cases where a different implementation for the same feature is already in place. -Whether an API is removed as a result of a feature graduating from beta to stable or because that API simply did not succeed, all removals comply with this deprecation policy. Whenever an API is removed, migration options are communicated in the [documentation](/docs/reference/using-api/deprecation-guide/). +Whether an API is removed as a result of a feature graduating from beta to stable or because that API simply did not succeed, all removals comply with this deprecation policy. Whenever an API is removed, migration options are communicated in the [deprecation guide](/docs/reference/using-api/deprecation-guide/). ## Note on the withdrawal of the old DRA implementation From 468dc22edce7ef3f60200616c9d3df635ffe029d Mon Sep 17 00:00:00 2001 From: Matteo Bianchi <37507190+mbianchidev@users.noreply.github.com> Date: Thu, 31 Oct 2024 09:57:19 +0100 Subject: [PATCH 13/27] Implemented a number of suggestions from code review Update 2024-11-04-kubernetes-1.32-sneak-peek.md --- .../2024-11-04-kubernetes-1.32-sneak-peek.md | 54 +++++++++---------- 1 file changed, 27 insertions(+), 27 deletions(-) diff --git a/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md b/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md index e76d41296f54e..23c461ddf293f 100644 --- a/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md +++ b/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md @@ -11,28 +11,28 @@ author: > Rashan Smith --- -As we get closer to the release date for Kubernetes v1.32, the project develops and matures, features may be deprecated, removed, or replaced with better ones for the project's overall health. +As we get closer to the release date for Kubernetes v1.32, the project develops and matures. Features may be deprecated, removed, or replaced with better ones for the project's overall health. This blog outlines some of the planned changes for the Kubernetes v1.32 release, that the release team feels you should be aware of, for the continued maintenance of your Kubernetes environment and keeping up to date with the latest changes. Information listed below is based on the current status of the v1.32 release and may change before the actual release date. ### The Kubernetes API removal and deprecation process -The Kubernetes project has a well-documented [deprecation policy](/docs/reference/using-api/deprecation-policy/) for features. This policy states that stable APIs may only be deprecated when a newer, stable version of that same API is available and that APIs have a minimum lifetime for each stability level. A deprecated API has been marked for removal in a future Kubernetes release, it will continue to function until removal (at least one year from the deprecation), but usage will result in a warning being displayed. Removed APIs are no longer available in the current version, at which point you must migrate to using the replacement. +The Kubernetes project has a well-documented [deprecation policy](/docs/reference/using-api/deprecation-policy/) for features. This policy states that stable APIs may only be deprecated when a newer, stable version of that API is available and that APIs have a minimum lifetime for each stability level. A deprecated API has been marked for removal in a future Kubernetes release will continue to function until removal (at least one year from the deprecation). Its usage will result in a warning being displayed. Removed APIs are no longer available in the current version, so you must migrate to use the replacement instead. * Generally available (GA) or stable API versions may be marked as deprecated but must not be removed within a major version of Kubernetes. * Beta or pre-release API versions must be supported for 3 releases after the deprecation. -* Alpha or experimental API versions may be removed in any release without prior deprecation notice, this process can become a withdrawal in cases where a different implementation for the same feature is already in place. +* Alpha or experimental API versions may be removed in any release without prior deprecation notice; this process can become a withdrawal in cases where a different implementation for the same feature is already in place. -Whether an API is removed as a result of a feature graduating from beta to stable or because that API simply did not succeed, all removals comply with this deprecation policy. Whenever an API is removed, migration options are communicated in the [deprecation guide](/docs/reference/using-api/deprecation-guide/). +Whether an API is removed due to a feature graduating from beta to stable or because that API did not succeed, all removals comply with this deprecation policy. Whenever an API is removed, migration options are communicated in the [deprecation guide](/docs/reference/using-api/deprecation-guide/). ## Note on the withdrawal of the old DRA implementation -This enhancement [#3063](https://github.com/kubernetes/enhancements/issues/3063) initially introduced Dynamic Resource Allocation (DRA) in Kubernetes 1.26. +This enhancement [#3063](https://github.com/kubernetes/enhancements/issues/3063) introduced Dynamic Resource Allocation (DRA) in Kubernetes 1.26. -However, in Kubernetes v1.32, it is withdrawn and related code will be removed, leaving KEP [#4381](https://github.com/kubernetes/enhancements/issues/4381) as the "new" base functionality. +However, in Kubernetes v1.32, such enhancement is withdrawn. Related code will be removed, leaving KEP [#4381](https://github.com/kubernetes/enhancements/issues/4381) as the "new" base functionality. -The decision to remove this feature originated from its incompatibility with cluster autoscaling, as resource availability was made non-transparent, complicating decision making for both Cluster Autoscaler and controllers. +The decision to remove this feature originated from its incompatibility with cluster autoscaling, as resource availability was made non-transparent, complicating decision-making for both Cluster Autoscaler and controllers. The newly added Structured Parameter model substitutes the functionality. This removal allows Kubernetes to handle new hardware requirements and resource claims more predictably, bypassing the complexities of back and forth API calls to the kube-apiserver. @@ -43,7 +43,7 @@ Please also see the enhancement issue [#3063](https://github.com/kubernetes/enha ### Even more DRA enhancements! -In this release, like the previous one, the Kubernetes project continues to introduce enhancements to the Dynamic Resource Allocation (DRA), which is a key component of the Kubernetes resource management system. These enhancements aim to improve the flexibility and efficiency of resource allocation for workloads that require specialized hardware, such as GPUs, FPGAs and network adapters. The enhancements for this release include: +In this release, like the previous one, the Kubernetes project continues introducing enhancements to the Dynamic Resource Allocation (DRA), a key component of the Kubernetes resource management system. These enhancements aim to improve the flexibility and efficiency of resource allocation for workloads that require specialized hardware, such as GPUs, FPGAs and network adapters. The improvements for this release include: - Partitionable devices support: [KEP #4815](https://github.com/kubernetes/enhancements/issues/4815) - Resource Claim Status and standardized network interface data: [KEP #4817](https://github.com/kubernetes/enhancements/issues/4817) @@ -54,46 +54,46 @@ In this release, like the previous one, the Kubernetes project continues to intr **Partitionable devices support** KEP [#4815](https://github.com/kubernetes/enhancements/issues/4815) introduces improvements to Kubernetes' Dynamic Resource Allocation (DRA) framework, enabling more efficient support for high-performance partitionable devices like GPUs, FPGAs, and network adapters. Currently, these devices are treated as whole units, potentially leading to resource inefficiencies when workloads require only a fraction of a device’s capacity. -By extending the DRA framework, this enhancement allows workloads to request and consume portions of these resources, increasing utilization and scheduling flexibility. The proposed enhancement also provides primitives for representing both full devices and their partitions in a more compact manner, supporting the recent transition from what was called "classic DRA" to the "structured parameters" approach. -The newly proposed extensions, fully transparent to the end-user, enable vendors to provision “overlapping” partitions, ensuring that the scheduler does not allocate conflicting partitions. This approach allows vendors to dynamically create new partitions after allocation, eliminating the need for pre-partitioned configurations, while still supporting device partition selection through existing mechanisms like `ResourceClaim` and `ResourceSlice` in Kubernetes v1.31. +By extending the DRA framework, this enhancement allows workloads to request and consume portions of these resources, increasing utilization and scheduling flexibility. The proposed enhancement also provides primitives for representing both full devices and their partitions more compactly, supporting the recent transition from "classic DRA" to the "structured parameters" approach. +The newly proposed extensions, fully transparent to the end-user, enable vendors to provision “overlapping” partitions, ensuring that the scheduler does not allocate conflicting partitions. This approach allows vendors to dynamically create new partitions after allocation, eliminating the need for pre-partitioned configurations while still supporting device partition selection through existing mechanisms like `ResourceClaim` and `ResourceSlice` in Kubernetes v1.31. **Resource Claim status and standardized network interface data** KEP [#4817](https://github.com/kubernetes/enhancements/issues/4817) adds driver-owned fields in `ResourceClaim.Status` with the possibility of having standardized network interface data. This proposal enhances the `ResourceClaim.Status` field by adding a new sub-field: `Devices`. -The new entry allows to report driver-specific device status data for each allocated device in a `ResourceClaim`. Allowing the drivers to report such data will improve observability and troubleshooting, as well as enabling new functionalities such as, for example, network services (in case the IP addresses of a network device are reported). +The new entry allows the reporting of driver-specific device status data for each allocated device in a `ResourceClaim`. Allowing the drivers to report such data will improve observability and troubleshooting and enable new functionalities such as network services (in case the IP addresses of a network device are reported). **DRA Structured Parameters** -The original dynamic resource allocation (DRA) uses claim and class parameters that are opaque to Kubernetes. KEP [#4381](https://github.com/kubernetes/enhancements/issues/4381) introduces structured parameters so that kube-scheduler and Cluster Autoscaler can handle a claim allocation themselves without relying on a third-party driver. -As users are increasingly adopting Kubernetes as their management solution for batch-processing workloads and edge computing, the need of exposing specialized hardware to Pods is increasing. -Such workloads no longer need just RAM and CPU - so this KEP introduced a new API for describing which of these specialized resources a Pod needs, for example devices like a GPU or other kinds of accelerators. +The original dynamic resource allocation (DRA) uses claim and class parameters that are opaque to Kubernetes. KEP [#4381](https://github.com/kubernetes/enhancements/issues/4381) introduces structured parameters so that kube-scheduler and Cluster Autoscaler can handle a claim allocation without relying on a third-party driver. +As users increasingly adopt Kubernetes as their management solution for batch-processing workloads and edge computing, the need to expose specialized hardware to Pods is increasing. +Such workloads no longer need just RAM and CPU, so this KEP introduced a new API to describe which of these specialized resources a Pod needs, such as devices like a GPU or other kinds of accelerators. **Prioritized alternatives in device requests** -KEP [#4816](https://github.com/kubernetes/enhancements/issues/4816) adds support for a prioritized list of selection criteria, attached to a device request in a `ResourceClaim`. +KEP [#4816](https://github.com/kubernetes/enhancements/issues/4816) adds support for a prioritized list of selection criteria attached to a device request in a `ResourceClaim`. The DRA's Structured Parameters feature has added the ability to make requests for very specific types of devices using a `ResourceClaim`. -However, the current API did not allow the user to indicate any priority when multiple types or configurations of devices might have met the needs of the workload. This feature allows the user to specify alternative requests that satisfy the workloads need, giving more flexibility to the scheduler in the workloads' scheduling phase. +However, the current API did not allow the user to indicate any priority when multiple types or configurations of devices might have met the workload's needs. This feature allows the user to specify alternative requests that satisfy the workloads' need, giving more flexibility to the scheduler in the workloads' scheduling phase. **Add resource health status to the Pod status** -When a Pod is using a device that has failed or is temporarily unhealthy, it is difficult to know. KEP [#4680](https://github.com/kubernetes/enhancements/issues/4680) makes troubleshooting of Pod crashes easier by exposing device health via `Pod Status`. +It isn't easy to know when a Pod uses a device that has failed or is temporarily unhealthy. KEP [#4680](https://github.com/kubernetes/enhancements/issues/4680) makes troubleshooting of Pod crashes easier by exposing device health via `Pod Status`. ### Windows strikes back! -KEP [#4802](https://github.com/kubernetes/enhancements/issues/4802) adds support for graceful shutdown of Windows nodes in Kubernetes clusters. -Currently, Kubernetes provides graceful node shutdown functionality for Linux nodes but lacked equivalent support for Windows. This enhancement aims to enable the kubelet on Windows nodes to handle system shutdown events properly. By doing so, it ensures that Pods running on Windows nodes are gracefully terminated, allowing workloads to be rescheduled without disruption. This improvement enhances the reliability and stability of clusters that include Windows nodes, especially during a planned maintenance or any system updates. +KEP [#4802](https://github.com/kubernetes/enhancements/issues/4802) adds support for graceful shutdowns of Windows nodes in Kubernetes clusters. +Before this release, Kubernetes provided graceful node shutdown functionality for Linux nodes but lacked equivalent support for Windows. This enhancement enables the kubelet on Windows nodes to handle system shutdown events properly. Doing so, it ensures that Pods running on Windows nodes are gracefully terminated, allowing workloads to be rescheduled without disruption. This improvement enhances the reliability and stability of clusters that include Windows nodes, especially during a planned maintenance or any system updates. -KEP [#4885](https://github.com/kubernetes/enhancements/issues/4885) adds CPU and memory affinity support to Windows nodes in Kubernetes, thus improving performance for workloads that benefit from cache vicinity and NUMA optimizations, this effort also aligns Windows capabilities with Linux nodes. +KEP [#4885](https://github.com/kubernetes/enhancements/issues/4885) adds CPU and memory affinity support to Windows nodes in Kubernetes, thus improving performance for workloads that benefit from cache vicinity and NUMA optimizations; this effort also aligns Windows capabilities with Linux nodes. ### Allow special characters in environment variables - [KEP #4369](https://github.com/kubernetes/enhancements/issues/4369) -With the graduation of KEP-4369 to beta, Kubernetes now allows almost all printable ASCII characters (excluding "=") to be used as environment variable names. This change addresses the limitations previously imposed on variable naming, facilitating broader adoption of Kubernetes by accommodating various application needs. The relaxed validation will be enabled by default via `RelaxedEnvironmentVariableValidation` feature gate, ensuring that users can easily utilize environment variables without strict constraints, enhancing flexibility for developers working with applications like .NET Core that require special characters in their configurations. +With the graduation of KEP-4369 to beta, Kubernetes now allows almost all printable ASCII characters (excluding "=") to be used as environment variable names. This change addresses the limitations previously imposed on variable naming, facilitating a broader adoption of Kubernetes by accommodating various application needs. The relaxed validation will be enabled by default via the `RelaxedEnvironmentVariableValidation` feature gate, ensuring that users can easily utilize environment variables without strict constraints, enhancing flexibility for developers working with applications like .NET Core that require special characters in their configurations. ### Field status.hostIPs added for Pod - [KEP #2681](https://github.com/kubernetes/enhancements/issues/2681) @@ -102,22 +102,22 @@ The feature is controlled by the PodHostIPs feature gate, supporting flexibility ### Make Kubernetes aware of the LoadBalancer behavior - [KEP #1860](https://github.com/kubernetes/enhancements/issues/1860) -KEP [#1860](https://github.com/kubernetes/enhancements/issues/1860) graduates to GA, introducing the `ipMode` field for a Service of `type: LoadBalancer`, which can be set to either `"VIP"` or `"Proxy"`. The existing behavior of kube-proxy is preserved when using `"VIP"`, where kube-proxy handles the load balancing. The use of `"Proxy"` results in traffic sent directly to the load balancer, providing cloud providers greater control over relying on kube-proxy. +KEP [#1860](https://github.com/kubernetes/enhancements/issues/1860) graduates to GA, introducing the `ipMode` field for a Service of `type: LoadBalancer`, which can be set to either `"VIP"` or `"Proxy"`. The existing behavior of kube-proxy is preserved when using `"VIP"`, where kube-proxy handles the load balancing. Using `"Proxy"` results in traffic sent directly to the load balancer, providing cloud providers greater control over relying on kube-proxy. ### Support PSI based on cgroupv2 - [KEP #4205](https://github.com/kubernetes/enhancements/issues/4205) -This KEP adds support in the Kubelet to read Pressure Stall Information (PSI) metrics for CPU, Memory and I/O resources exposed from cAdvisor and runc. Pressure metrics are like a barometer that can warn about impending resource shortages on a node. This will enable the Kubelet to report node conditions, which can be utilized to prevent scheduling of Pods on nodes experiencing significant resource constraints. +This KEP adds support in the Kubelet to read Pressure Stall Information (PSI) metrics for CPU, Memory and I/O resources exposed from cAdvisor and runc. Pressure metrics are like a barometer that can warn about impending resource shortages on a node. This will enable the Kubelet to report node conditions, which can be utilized to prevent the scheduling of Pods on nodes experiencing significant resource constraints. ### Retry generate name for resources - [KEP #4420](https://github.com/kubernetes/enhancements/issues/4420) -This enhancement improves the handling of name conflicts for Kubernetes resources created with the `generateName` field. Previously, if a name conflict occurred, the API server returned a 409 error, and clients had to manually retry the request. With this update, the API server now automatically retries generating a new name up to seven times in case of a conflict. This significantly reduces the chances of collision, ensuring smooth generation of up to 1 million names with less than a 0.1% probability of a conflict, providing more resilience for large-scale workloads. +This enhancement improves how name conflicts are handled for Kubernetes resources created with the `generateName` field. Previously, if a name conflict occurred, the API server returned a 409 HTTP Conflict error and clients had to manually retry the request. With this update, the API server automatically retries generating a new name up to seven times in case of a conflict. This significantly reduces the chances of collision, ensuring smooth generation of up to 1 million names with less than a 0.1% probability of a conflict, providing more resilience for large-scale workloads. ### Mutating admission policies - [KEP #3962](https://github.com/kubernetes/enhancements/issues/3962) -This enhancement introduces "Mutating Admission Policies" using CEL (Common Expression Language), allowing Kubernetes users to define in-line mutating policies without the need for complex admission webhooks. -This enhancement simplifies common mutating tasks—such as adding labels, setting fields, or injecting sidecars—by enabling policies to be directly defined within the Kubernetes API server. With CEL's object instantiation and Server-Side Apply merge algorithms, these policies can minimize reinvocation, reduce latency, and eliminate the overhead associated with webhook management. This new approach enhances Kubernetes extensibility by reducing operational complexity, also provides a scalable, built-in solution for secure and efficient policy management across diverse use cases like GitOps and CI/CD, making Kubernetes admission control more accessible and powerful for developers and administrators alike. +This enhancement introduces "Mutating Admission Policies" using CEL (Common Expression Language), allowing Kubernetes users to define in-line mutating policies without complex admission webhooks. +This enhancement simplifies common mutating tasks—such as adding labels, setting fields, or injecting sidecars—by enabling policies to be directly defined within the Kubernetes API server. With CEL's object instantiation and Server-Side Apply merge algorithms, these policies can minimize reinvocation, reduce latency, and eliminate the overhead associated with webhook management. This new approach enhances Kubernetes extensibility by reducing operational complexity, while providing a scalable, built-in solution for secure and efficient policy management across diverse use cases like GitOps and CI/CD. Making Kubernetes admission control more accessible and powerful for developers and administrators alike. ### Control over terminating Pods in deployments - [KEP #3973](https://github.com/kubernetes/enhancements/issues/3973) -This enhancement adds a new field `.spec.podReplacementPolicy` to Deployments, to specify whether new Pods can be created only after old Pods have finished terminating, or once old Pods start terminating. The default behavior depends on the deployment strategy. Specifying this Pod replacement policy can help to better control the speed of rollouts/scaling, and potentially avoid problems with excessive resource usage. +This enhancement adds a new field `.spec.podReplacementPolicy` to Deployments to specify whether new Pods can be created only after old Pods have finished terminating or once old Pods start terminating. The default behavior depends on the deployment strategy. Specifying this Pod replacement policy can better control the speed of rollouts/scaling and potentially avoid problems with excessive resource usage. ## Want to know more? New features and deprecations are also announced in the Kubernetes release notes. We will formally announce what's new in [Kubernetes v1.32](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.32.md) as part of the CHANGELOG for this release. From 147f4cd5234c57d02ff8d7f22314144df456df6d Mon Sep 17 00:00:00 2001 From: Matteo Bianchi <37507190+mbianchidev@users.noreply.github.com> Date: Thu, 31 Oct 2024 10:02:30 +0100 Subject: [PATCH 14/27] Clarified KEP 1860 Update 2024-11-04-kubernetes-1.32-sneak-peek.md --- content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md b/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md index 23c461ddf293f..c0c209b7e3c9a 100644 --- a/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md +++ b/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md @@ -102,7 +102,7 @@ The feature is controlled by the PodHostIPs feature gate, supporting flexibility ### Make Kubernetes aware of the LoadBalancer behavior - [KEP #1860](https://github.com/kubernetes/enhancements/issues/1860) -KEP [#1860](https://github.com/kubernetes/enhancements/issues/1860) graduates to GA, introducing the `ipMode` field for a Service of `type: LoadBalancer`, which can be set to either `"VIP"` or `"Proxy"`. The existing behavior of kube-proxy is preserved when using `"VIP"`, where kube-proxy handles the load balancing. Using `"Proxy"` results in traffic sent directly to the load balancer, providing cloud providers greater control over relying on kube-proxy. +KEP [#1860](https://github.com/kubernetes/enhancements/issues/1860) graduates to GA, introducing the `ipMode` field for a Service of `type: LoadBalancer`, which can be set to either `"VIP"` or `"Proxy"`. This enhancement is aimed at improving how cloud providers load balancers interact with kube-proxy and it is a change transparent to the end user. The existing behavior of kube-proxy is preserved when using `"VIP"`, where kube-proxy handles the load balancing. Using `"Proxy"` results in traffic sent directly to the load balancer, providing cloud providers greater control over relying on kube-proxy; this means that you could see an improvement in the performance of your load balancer for some cloud providers. ### Support PSI based on cgroupv2 - [KEP #4205](https://github.com/kubernetes/enhancements/issues/4205) This KEP adds support in the Kubelet to read Pressure Stall Information (PSI) metrics for CPU, Memory and I/O resources exposed from cAdvisor and runc. Pressure metrics are like a barometer that can warn about impending resource shortages on a node. This will enable the Kubelet to report node conditions, which can be utilized to prevent the scheduling of Pods on nodes experiencing significant resource constraints. From fd4123271f50eecaba262f00c11896bb32575353 Mon Sep 17 00:00:00 2001 From: Matteo Bianchi <37507190+mbianchidev@users.noreply.github.com> Date: Thu, 31 Oct 2024 15:31:22 +0100 Subject: [PATCH 15/27] Even more DRA clarifications Update content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md Co-authored-by: Sean McGinnis --- content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md b/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md index c0c209b7e3c9a..056ddc060dd3c 100644 --- a/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md +++ b/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md @@ -30,7 +30,7 @@ Whether an API is removed due to a feature graduating from beta to stable or bec This enhancement [#3063](https://github.com/kubernetes/enhancements/issues/3063) introduced Dynamic Resource Allocation (DRA) in Kubernetes 1.26. -However, in Kubernetes v1.32, such enhancement is withdrawn. Related code will be removed, leaving KEP [#4381](https://github.com/kubernetes/enhancements/issues/4381) as the "new" base functionality. +However, in Kubernetes v1.32, this approach to DRA has been significantly changed. Code related to the original implementation will be removed, leaving KEP [#4381](https://github.com/kubernetes/enhancements/issues/4381) as the "new" base functionality. The decision to remove this feature originated from its incompatibility with cluster autoscaling, as resource availability was made non-transparent, complicating decision-making for both Cluster Autoscaler and controllers. The newly added Structured Parameter model substitutes the functionality. From 0242acdfc14e4a4c941aa1dc08acb319e59fda8a Mon Sep 17 00:00:00 2001 From: Matteo Bianchi <37507190+mbianchidev@users.noreply.github.com> Date: Fri, 1 Nov 2024 11:00:43 +0100 Subject: [PATCH 16/27] Added API removal for 1.32 Update 2024-11-04-kubernetes-1.32-sneak-peek.md --- .../_posts/2024-11-04-kubernetes-1.32-sneak-peek.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md b/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md index 056ddc060dd3c..b6fe80d416784 100644 --- a/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md +++ b/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md @@ -39,6 +39,16 @@ This removal allows Kubernetes to handle new hardware requirements and resource Please also see the enhancement issue [#3063](https://github.com/kubernetes/enhancements/issues/3063) to find out more. +## API removal + +There is only a single API removal planned for [Kubernetes v1.32](/docs/reference/using-api/deprecation-guide/#v1-32): + +* The `flowcontrol.apiserver.k8s.io/v1beta3` API version of FlowSchema and PriorityLevelConfiguration has been removed. +To prepare for this, you can edit your existing manifests and rewrite client software to use the `flowcontrol.apiserver.k8s.io/v1 API` version, available since v1.29. +All existing persisted objects are accessible via the new API. Notable changes in flowcontrol.apiserver.k8s.io/v1beta3 include that the PriorityLevelConfiguration `spec.limited.nominalConcurrencyShares` field only defaults to 30 when unspecified, and an explicit value of 0 is not changed to 30. + +For more information, please refer to the [API deprecation guide](/docs/reference/using-api/deprecation-guide/#v1-32). + ## Sneak peek of Kubernetes v1.32 ### Even more DRA enhancements! From f2e6a632585745c4e716d9705cce02f5e6926277 Mon Sep 17 00:00:00 2001 From: Matteo Bianchi <37507190+mbianchidev@users.noreply.github.com> Date: Fri, 1 Nov 2024 23:11:13 +0100 Subject: [PATCH 17/27] Remove KEP links from headings Update 2024-11-04-kubernetes-1.32-sneak-peek.md --- .../2024-11-04-kubernetes-1.32-sneak-peek.md | 26 +++++++++---------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md b/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md index b6fe80d416784..3ba39c140cc91 100644 --- a/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md +++ b/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md @@ -101,33 +101,33 @@ Before this release, Kubernetes provided graceful node shutdown functionality fo KEP [#4885](https://github.com/kubernetes/enhancements/issues/4885) adds CPU and memory affinity support to Windows nodes in Kubernetes, thus improving performance for workloads that benefit from cache vicinity and NUMA optimizations; this effort also aligns Windows capabilities with Linux nodes. -### Allow special characters in environment variables - [KEP #4369](https://github.com/kubernetes/enhancements/issues/4369) +### Allow special characters in environment variables -With the graduation of KEP-4369 to beta, Kubernetes now allows almost all printable ASCII characters (excluding "=") to be used as environment variable names. This change addresses the limitations previously imposed on variable naming, facilitating a broader adoption of Kubernetes by accommodating various application needs. The relaxed validation will be enabled by default via the `RelaxedEnvironmentVariableValidation` feature gate, ensuring that users can easily utilize environment variables without strict constraints, enhancing flexibility for developers working with applications like .NET Core that require special characters in their configurations. +With the graduation of [this feature](https://github.com/kubernetes/enhancements/issues/4369) to beta, Kubernetes now allows almost all printable ASCII characters (excluding "=") to be used as environment variable names. This change addresses the limitations previously imposed on variable naming, facilitating a broader adoption of Kubernetes by accommodating various application needs. The relaxed validation will be enabled by default via the `RelaxedEnvironmentVariableValidation` feature gate, ensuring that users can easily utilize environment variables without strict constraints, enhancing flexibility for developers working with applications like .NET Core that require special characters in their configurations. -### Field status.hostIPs added for Pod - [KEP #2681](https://github.com/kubernetes/enhancements/issues/2681) +### Field status.hostIPs added for Pod -This enhancement introduces a new field, `status.hostIPs`, to the Kubernetes Pod API, enabling support for multiple IP addresses (IPv4 and IPv6) assigned to a node. Previously, the Pod status only included a singular HostIP field, which limited address configurations, particularly in dual-stack networks. This enhancement allows the API to store multiple IP addresses in an array, accessible via the Downward API, which applications can leverage for environments with complex IP requirements, such as IPv6 migrations. +[This enhancement](https://github.com/kubernetes/enhancements/issues/2681) introduces a new field, `status.hostIPs`, to the Kubernetes Pod API, enabling support for multiple IP addresses (IPv4 and IPv6) assigned to a node. Previously, the Pod status only included a singular HostIP field, which limited address configurations, particularly in dual-stack networks. This enhancement allows the API to store multiple IP addresses in an array, accessible via the Downward API, which applications can leverage for environments with complex IP requirements, such as IPv6 migrations. The feature is controlled by the PodHostIPs feature gate, supporting flexibility for gradual rollout. -### Make Kubernetes aware of the LoadBalancer behavior - [KEP #1860](https://github.com/kubernetes/enhancements/issues/1860) +### Make Kubernetes aware of the LoadBalancer behavior KEP [#1860](https://github.com/kubernetes/enhancements/issues/1860) graduates to GA, introducing the `ipMode` field for a Service of `type: LoadBalancer`, which can be set to either `"VIP"` or `"Proxy"`. This enhancement is aimed at improving how cloud providers load balancers interact with kube-proxy and it is a change transparent to the end user. The existing behavior of kube-proxy is preserved when using `"VIP"`, where kube-proxy handles the load balancing. Using `"Proxy"` results in traffic sent directly to the load balancer, providing cloud providers greater control over relying on kube-proxy; this means that you could see an improvement in the performance of your load balancer for some cloud providers. -### Support PSI based on cgroupv2 - [KEP #4205](https://github.com/kubernetes/enhancements/issues/4205) -This KEP adds support in the Kubelet to read Pressure Stall Information (PSI) metrics for CPU, Memory and I/O resources exposed from cAdvisor and runc. Pressure metrics are like a barometer that can warn about impending resource shortages on a node. This will enable the Kubelet to report node conditions, which can be utilized to prevent the scheduling of Pods on nodes experiencing significant resource constraints. +### Support PSI based on cgroupv2 +[This KEP](https://github.com/kubernetes/enhancements/issues/4205) adds support in the Kubelet to read Pressure Stall Information (PSI) metrics for CPU, Memory and I/O resources exposed from cAdvisor and runc. Pressure metrics are like a barometer that can warn about impending resource shortages on a node. This will enable the Kubelet to report node conditions, which can be utilized to prevent the scheduling of Pods on nodes experiencing significant resource constraints. -### Retry generate name for resources - [KEP #4420](https://github.com/kubernetes/enhancements/issues/4420) -This enhancement improves how name conflicts are handled for Kubernetes resources created with the `generateName` field. Previously, if a name conflict occurred, the API server returned a 409 HTTP Conflict error and clients had to manually retry the request. With this update, the API server automatically retries generating a new name up to seven times in case of a conflict. This significantly reduces the chances of collision, ensuring smooth generation of up to 1 million names with less than a 0.1% probability of a conflict, providing more resilience for large-scale workloads. +### Retry generate name for resources +[This enhancement](https://github.com/kubernetes/enhancements/issues/4420) improves how name conflicts are handled for Kubernetes resources created with the `generateName` field. Previously, if a name conflict occurred, the API server returned a 409 HTTP Conflict error and clients had to manually retry the request. With this update, the API server automatically retries generating a new name up to seven times in case of a conflict. This significantly reduces the chances of collision, ensuring smooth generation of up to 1 million names with less than a 0.1% probability of a conflict, providing more resilience for large-scale workloads. -### Mutating admission policies - [KEP #3962](https://github.com/kubernetes/enhancements/issues/3962) +### Mutating admission policies -This enhancement introduces "Mutating Admission Policies" using CEL (Common Expression Language), allowing Kubernetes users to define in-line mutating policies without complex admission webhooks. +[This enhancement](https://github.com/kubernetes/enhancements/issues/3962) introduces "Mutating Admission Policies" using CEL (Common Expression Language), allowing Kubernetes users to define in-line mutating policies without complex admission webhooks. This enhancement simplifies common mutating tasks—such as adding labels, setting fields, or injecting sidecars—by enabling policies to be directly defined within the Kubernetes API server. With CEL's object instantiation and Server-Side Apply merge algorithms, these policies can minimize reinvocation, reduce latency, and eliminate the overhead associated with webhook management. This new approach enhances Kubernetes extensibility by reducing operational complexity, while providing a scalable, built-in solution for secure and efficient policy management across diverse use cases like GitOps and CI/CD. Making Kubernetes admission control more accessible and powerful for developers and administrators alike. -### Control over terminating Pods in deployments - [KEP #3973](https://github.com/kubernetes/enhancements/issues/3973) +### Control over terminating Pods in deployments -This enhancement adds a new field `.spec.podReplacementPolicy` to Deployments to specify whether new Pods can be created only after old Pods have finished terminating or once old Pods start terminating. The default behavior depends on the deployment strategy. Specifying this Pod replacement policy can better control the speed of rollouts/scaling and potentially avoid problems with excessive resource usage. +[This enhancement](https://github.com/kubernetes/enhancements/issues/3973) adds a new field `.spec.podReplacementPolicy` to Deployments to specify whether new Pods can be created only after old Pods have finished terminating or once old Pods start terminating. The default behavior depends on the deployment strategy. Specifying this Pod replacement policy can better control the speed of rollouts/scaling and potentially avoid problems with excessive resource usage. ## Want to know more? New features and deprecations are also announced in the Kubernetes release notes. We will formally announce what's new in [Kubernetes v1.32](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.32.md) as part of the CHANGELOG for this release. From 72e67a16612a561872644decd0abd00465774d3a Mon Sep 17 00:00:00 2001 From: Matteo Bianchi <37507190+mbianchidev@users.noreply.github.com> Date: Sun, 3 Nov 2024 11:48:49 +0100 Subject: [PATCH 18/27] Deadline change Update 2024-11-04-kubernetes-1.32-sneak-peek.md --- content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md b/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md index 3ba39c140cc91..fc356e0ae099a 100644 --- a/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md +++ b/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md @@ -1,7 +1,7 @@ --- layout: blog title: 'Kubernetes v1.32 sneak peek' -date: 2024-11-04 +date: 2024-11-09 slug: kubernetes-1-32-upcoming-changes author: > Matteo Bianchi, From 21fa315ecbc9b60330fcee326f86766b61b13c3e Mon Sep 17 00:00:00 2001 From: Matteo Bianchi <37507190+mbianchidev@users.noreply.github.com> Date: Sun, 3 Nov 2024 11:59:10 +0100 Subject: [PATCH 19/27] Chaning deadline to Friday 8th as initially intended. Update 2024-11-04-kubernetes-1.32-sneak-peek.md --- content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md b/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md index fc356e0ae099a..58c263608f093 100644 --- a/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md +++ b/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md @@ -1,7 +1,7 @@ --- layout: blog title: 'Kubernetes v1.32 sneak peek' -date: 2024-11-09 +date: 2024-11-08 slug: kubernetes-1-32-upcoming-changes author: > Matteo Bianchi, From 2e49c2ae8c83b38b814b11c5d01f5691700b1099 Mon Sep 17 00:00:00 2001 From: Matteo Bianchi <37507190+mbianchidev@users.noreply.github.com> Date: Sun, 3 Nov 2024 12:05:35 +0100 Subject: [PATCH 20/27] Renamed file name since the deadline changed Rename 2024-11-04-kubernetes-1.32-sneak-peek.md to 2024-11-08-kubernetes-1.32-sneak-peek.md --- ....32-sneak-peek.md => 2024-11-08-kubernetes-1.32-sneak-peek.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename content/en/blog/_posts/{2024-11-04-kubernetes-1.32-sneak-peek.md => 2024-11-08-kubernetes-1.32-sneak-peek.md} (100%) diff --git a/content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md b/content/en/blog/_posts/2024-11-08-kubernetes-1.32-sneak-peek.md similarity index 100% rename from content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md rename to content/en/blog/_posts/2024-11-08-kubernetes-1.32-sneak-peek.md From f2ef74acad5ee577b6e40900192cee01b28406c6 Mon Sep 17 00:00:00 2001 From: Matteo Bianchi <37507190+mbianchidev@users.noreply.github.com> Date: Mon, 4 Nov 2024 17:31:59 +0100 Subject: [PATCH 21/27] Addressing more review comments from sig-docs-blog Update 2024-11-08-kubernetes-1.32-sneak-peek.md --- .../2024-11-08-kubernetes-1.32-sneak-peek.md | 52 +++++++++---------- 1 file changed, 25 insertions(+), 27 deletions(-) diff --git a/content/en/blog/_posts/2024-11-08-kubernetes-1.32-sneak-peek.md b/content/en/blog/_posts/2024-11-08-kubernetes-1.32-sneak-peek.md index 58c263608f093..e10347ae226d9 100644 --- a/content/en/blog/_posts/2024-11-08-kubernetes-1.32-sneak-peek.md +++ b/content/en/blog/_posts/2024-11-08-kubernetes-1.32-sneak-peek.md @@ -30,12 +30,12 @@ Whether an API is removed due to a feature graduating from beta to stable or bec This enhancement [#3063](https://github.com/kubernetes/enhancements/issues/3063) introduced Dynamic Resource Allocation (DRA) in Kubernetes 1.26. -However, in Kubernetes v1.32, this approach to DRA has been significantly changed. Code related to the original implementation will be removed, leaving KEP [#4381](https://github.com/kubernetes/enhancements/issues/4381) as the "new" base functionality. +However, in Kubernetes v1.32, this approach to DRA will be significantly changed. Code related to the original implementation will be removed, leaving KEP [#4381](https://github.com/kubernetes/enhancements/issues/4381) as the "new" base functionality. The decision to remove this feature originated from its incompatibility with cluster autoscaling, as resource availability was made non-transparent, complicating decision-making for both Cluster Autoscaler and controllers. The newly added Structured Parameter model substitutes the functionality. -This removal allows Kubernetes to handle new hardware requirements and resource claims more predictably, bypassing the complexities of back and forth API calls to the kube-apiserver. +This removal will Kubernetes to handle new hardware requirements and resource claims more predictably, bypassing the complexities of back and forth API calls to the kube-apiserver. Please also see the enhancement issue [#3063](https://github.com/kubernetes/enhancements/issues/3063) to find out more. @@ -56,43 +56,39 @@ For more information, please refer to the [API deprecation guide](/docs/referenc In this release, like the previous one, the Kubernetes project continues introducing enhancements to the Dynamic Resource Allocation (DRA), a key component of the Kubernetes resource management system. These enhancements aim to improve the flexibility and efficiency of resource allocation for workloads that require specialized hardware, such as GPUs, FPGAs and network adapters. The improvements for this release include: - Partitionable devices support: [KEP #4815](https://github.com/kubernetes/enhancements/issues/4815) -- Resource Claim Status and standardized network interface data: [KEP #4817](https://github.com/kubernetes/enhancements/issues/4817) +- Resource Claim status and standardized network interface data: [KEP #4817](https://github.com/kubernetes/enhancements/issues/4817) - Structured parameters: [KEP #4381](https://github.com/kubernetes/enhancements/issues/4381) -- Prioritized Alternatives in Device Requests: [KEP #4816](https://github.com/kubernetes/enhancements/issues/4816) -- Resource Health Status in Pod Status: [KEP #4680](https://github.com/kubernetes/enhancements/issues/4680) +- Prioritized alternatives in device requests: [KEP #4816](https://github.com/kubernetes/enhancements/issues/4816) +- Resource health status in Pod status: [KEP #4680](https://github.com/kubernetes/enhancements/issues/4680) **Partitionable devices support** -KEP [#4815](https://github.com/kubernetes/enhancements/issues/4815) introduces improvements to Kubernetes' Dynamic Resource Allocation (DRA) framework, enabling more efficient support for high-performance partitionable devices like GPUs, FPGAs, and network adapters. Currently, these devices are treated as whole units, potentially leading to resource inefficiencies when workloads require only a fraction of a device’s capacity. +KEP [#4815](https://github.com/kubernetes/enhancements/issues/4815) proposes improvements to Kubernetes' Dynamic Resource Allocation (DRA) framework, enabling more efficient support for high-performance partitionable devices like GPUs, FPGAs, and network adapters. Currently, these devices are treated as whole units, potentially leading to resource inefficiencies when workloads require only a fraction of a device’s capacity. By extending the DRA framework, this enhancement allows workloads to request and consume portions of these resources, increasing utilization and scheduling flexibility. The proposed enhancement also provides primitives for representing both full devices and their partitions more compactly, supporting the recent transition from "classic DRA" to the "structured parameters" approach. -The newly proposed extensions, fully transparent to the end-user, enable vendors to provision “overlapping” partitions, ensuring that the scheduler does not allocate conflicting partitions. This approach allows vendors to dynamically create new partitions after allocation, eliminating the need for pre-partitioned configurations while still supporting device partition selection through existing mechanisms like `ResourceClaim` and `ResourceSlice` in Kubernetes v1.31. +The newly proposed extensions, fully transparent to the end-user, enable device management plugins to provision “overlapping” partitions, ensuring that the scheduler does not allocate conflicting partitions. This approach allows vendors to dynamically create new partitions after allocation, eliminating the need for pre-partitioned configurations while still supporting device partition selection through existing mechanisms like `ResourceClaim` and `ResourceSlice` in Kubernetes v1.31. -**Resource Claim status and standardized network interface data** +**ResourceClaim status and standardized network interface data** -KEP [#4817](https://github.com/kubernetes/enhancements/issues/4817) adds driver-owned fields in `ResourceClaim.Status` with the possibility of having standardized network interface data. -This proposal enhances the `ResourceClaim.Status` field by adding a new sub-field: `Devices`. -The new entry allows the reporting of driver-specific device status data for each allocated device in a `ResourceClaim`. Allowing the drivers to report such data will improve observability and troubleshooting and enable new functionalities such as network services (in case the IP addresses of a network device are reported). +KEP [#4817](https://github.com/kubernetes/enhancements/issues/4817) proposes adding new driver-owned fields in the `status` field of ResourceClaim with the possibility of having standardized network interface data. +This is a proposal to enhance the `status` field of ResourceClaims by adding a new sub-field: `devices`. +The new field will allow the reporting of driver-specific device status data for each allocated device in a ResourceClaim. Allowing the drivers to report such data will improve observability and troubleshooting and enable new functionalities such as network services (in case the IP addresses of a network device are reported). - -**DRA Structured Parameters** +**DRA structured parameters** The original dynamic resource allocation (DRA) uses claim and class parameters that are opaque to Kubernetes. KEP [#4381](https://github.com/kubernetes/enhancements/issues/4381) introduces structured parameters so that kube-scheduler and Cluster Autoscaler can handle a claim allocation without relying on a third-party driver. As users increasingly adopt Kubernetes as their management solution for batch-processing workloads and edge computing, the need to expose specialized hardware to Pods is increasing. -Such workloads no longer need just RAM and CPU, so this KEP introduced a new API to describe which of these specialized resources a Pod needs, such as devices like a GPU or other kinds of accelerators. +Such workloads no longer need just RAM and CPU, so Kubernetes v1.32 will introduce a new API to describe which of these specialized resources a Pod needs, such as devices like a GPU or other kinds of accelerators. **Prioritized alternatives in device requests** -KEP [#4816](https://github.com/kubernetes/enhancements/issues/4816) adds support for a prioritized list of selection criteria attached to a device request in a `ResourceClaim`. -The DRA's Structured Parameters feature has added the ability to make requests for very specific types of devices using a `ResourceClaim`. - -However, the current API did not allow the user to indicate any priority when multiple types or configurations of devices might have met the workload's needs. This feature allows the user to specify alternative requests that satisfy the workloads' need, giving more flexibility to the scheduler in the workloads' scheduling phase. - +KEP [#4816](https://github.com/kubernetes/enhancements/issues/4816) proposes support for prioritized selection criteria associated to a device request in a ResourceClaim. +DRA _structured parameters_ will gain the ability to make requests for very specific types of devices using a ResourceClaim. **Add resource health status to the Pod status** -It isn't easy to know when a Pod uses a device that has failed or is temporarily unhealthy. KEP [#4680](https://github.com/kubernetes/enhancements/issues/4680) makes troubleshooting of Pod crashes easier by exposing device health via `Pod Status`. - +It isn't easy to know when a Pod uses a device that has failed or is temporarily unhealthy. +KEP [#4680](https://github.com/kubernetes/enhancements/issues/4680) proposes exposing device health via Pod `status`, making troubleshooting of Pod crashes easier. ### Windows strikes back! @@ -103,31 +99,33 @@ KEP [#4885](https://github.com/kubernetes/enhancements/issues/4885) adds CPU and ### Allow special characters in environment variables -With the graduation of [this feature](https://github.com/kubernetes/enhancements/issues/4369) to beta, Kubernetes now allows almost all printable ASCII characters (excluding "=") to be used as environment variable names. This change addresses the limitations previously imposed on variable naming, facilitating a broader adoption of Kubernetes by accommodating various application needs. The relaxed validation will be enabled by default via the `RelaxedEnvironmentVariableValidation` feature gate, ensuring that users can easily utilize environment variables without strict constraints, enhancing flexibility for developers working with applications like .NET Core that require special characters in their configurations. +With the graduation of this [enhancement](https://github.com/kubernetes/enhancements/issues/4369) to beta, Kubernetes now allows almost all printable ASCII characters (excluding "=") to be used as environment variable names. This change addresses the limitations previously imposed on variable naming, facilitating a broader adoption of Kubernetes by accommodating various application needs. The relaxed validation will be enabled by default via the `RelaxedEnvironmentVariableValidation` feature gate, ensuring that users can easily utilize environment variables without strict constraints, enhancing flexibility for developers working with applications like .NET Core that require special characters in their configurations. ### Field status.hostIPs added for Pod -[This enhancement](https://github.com/kubernetes/enhancements/issues/2681) introduces a new field, `status.hostIPs`, to the Kubernetes Pod API, enabling support for multiple IP addresses (IPv4 and IPv6) assigned to a node. Previously, the Pod status only included a singular HostIP field, which limited address configurations, particularly in dual-stack networks. This enhancement allows the API to store multiple IP addresses in an array, accessible via the Downward API, which applications can leverage for environments with complex IP requirements, such as IPv6 migrations. +This [enhancement](https://github.com/kubernetes/enhancements/issues/2681) introduces a new field, `status.hostIPs`, to the Kubernetes Pod API, enabling support for multiple IP addresses (IPv4 and IPv6) assigned to a node. Previously, the Pod status only included a singular HostIP field, which limited address configurations, particularly in dual-stack networks. This enhancement allows the API to store multiple IP addresses in an array, accessible via the Downward API, which applications can leverage for environments with complex IP requirements, such as IPv6 migrations. The feature is controlled by the PodHostIPs feature gate, supporting flexibility for gradual rollout. +For more information about giving containers information about themselves, visit the [downward-api documentation](https://kubernetes.io/docs/concepts/workloads/pods/downward-api/). + ### Make Kubernetes aware of the LoadBalancer behavior KEP [#1860](https://github.com/kubernetes/enhancements/issues/1860) graduates to GA, introducing the `ipMode` field for a Service of `type: LoadBalancer`, which can be set to either `"VIP"` or `"Proxy"`. This enhancement is aimed at improving how cloud providers load balancers interact with kube-proxy and it is a change transparent to the end user. The existing behavior of kube-proxy is preserved when using `"VIP"`, where kube-proxy handles the load balancing. Using `"Proxy"` results in traffic sent directly to the load balancer, providing cloud providers greater control over relying on kube-proxy; this means that you could see an improvement in the performance of your load balancer for some cloud providers. ### Support PSI based on cgroupv2 -[This KEP](https://github.com/kubernetes/enhancements/issues/4205) adds support in the Kubelet to read Pressure Stall Information (PSI) metrics for CPU, Memory and I/O resources exposed from cAdvisor and runc. Pressure metrics are like a barometer that can warn about impending resource shortages on a node. This will enable the Kubelet to report node conditions, which can be utilized to prevent the scheduling of Pods on nodes experiencing significant resource constraints. +This [KEP](https://github.com/kubernetes/enhancements/issues/4205) adds support in the Kubelet to read Pressure Stall Information (PSI) metrics for CPU, Memory and I/O resources exposed from cAdvisor and runc. Pressure metrics are like a barometer that can warn about impending resource shortages on a node. This will enable the Kubelet to report node conditions, which can be utilized to prevent the scheduling of Pods on nodes experiencing significant resource constraints. ### Retry generate name for resources -[This enhancement](https://github.com/kubernetes/enhancements/issues/4420) improves how name conflicts are handled for Kubernetes resources created with the `generateName` field. Previously, if a name conflict occurred, the API server returned a 409 HTTP Conflict error and clients had to manually retry the request. With this update, the API server automatically retries generating a new name up to seven times in case of a conflict. This significantly reduces the chances of collision, ensuring smooth generation of up to 1 million names with less than a 0.1% probability of a conflict, providing more resilience for large-scale workloads. +This [enhancement](https://github.com/kubernetes/enhancements/issues/4420) improves how name conflicts are handled for Kubernetes resources created with the `generateName` field. Previously, if a name conflict occurred, the API server returned a 409 HTTP Conflict error and clients had to manually retry the request. With this update, the API server automatically retries generating a new name up to seven times in case of a conflict. This significantly reduces the chances of collision, ensuring smooth generation of up to 1 million names with less than a 0.1% probability of a conflict, providing more resilience for large-scale workloads. ### Mutating admission policies -[This enhancement](https://github.com/kubernetes/enhancements/issues/3962) introduces "Mutating Admission Policies" using CEL (Common Expression Language), allowing Kubernetes users to define in-line mutating policies without complex admission webhooks. +This [enhancement](https://github.com/kubernetes/enhancements/issues/3962) will introduce _mutating admission policies_ using CEL (Common Expression Language), allowing Kubernetes users to declaratively in-line mutating policies without complex admission webhooks. This enhancement simplifies common mutating tasks—such as adding labels, setting fields, or injecting sidecars—by enabling policies to be directly defined within the Kubernetes API server. With CEL's object instantiation and Server-Side Apply merge algorithms, these policies can minimize reinvocation, reduce latency, and eliminate the overhead associated with webhook management. This new approach enhances Kubernetes extensibility by reducing operational complexity, while providing a scalable, built-in solution for secure and efficient policy management across diverse use cases like GitOps and CI/CD. Making Kubernetes admission control more accessible and powerful for developers and administrators alike. ### Control over terminating Pods in deployments -[This enhancement](https://github.com/kubernetes/enhancements/issues/3973) adds a new field `.spec.podReplacementPolicy` to Deployments to specify whether new Pods can be created only after old Pods have finished terminating or once old Pods start terminating. The default behavior depends on the deployment strategy. Specifying this Pod replacement policy can better control the speed of rollouts/scaling and potentially avoid problems with excessive resource usage. +This [enhancement](https://github.com/kubernetes/enhancements/issues/3973) adds a new field `.spec.podReplacementPolicy` to Deployments to specify whether new Pods can be created only after old Pods have finished terminating or once old Pods start terminating. The default behavior depends on the deployment strategy. Specifying this Pod replacement policy can better control the speed of rollouts/scaling and potentially avoid problems with excessive resource usage. ## Want to know more? New features and deprecations are also announced in the Kubernetes release notes. We will formally announce what's new in [Kubernetes v1.32](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.32.md) as part of the CHANGELOG for this release. From 91a4cbd693f442d292f12d2303420cec81445a09 Mon Sep 17 00:00:00 2001 From: Matteo Bianchi <37507190+mbianchidev@users.noreply.github.com> Date: Tue, 5 Nov 2024 11:26:35 +0100 Subject: [PATCH 22/27] Reinforced concept: enhancement status can change until release Update 2024-11-08-kubernetes-1.32-sneak-peek.md --- content/en/blog/_posts/2024-11-08-kubernetes-1.32-sneak-peek.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/content/en/blog/_posts/2024-11-08-kubernetes-1.32-sneak-peek.md b/content/en/blog/_posts/2024-11-08-kubernetes-1.32-sneak-peek.md index e10347ae226d9..28429a0b2da64 100644 --- a/content/en/blog/_posts/2024-11-08-kubernetes-1.32-sneak-peek.md +++ b/content/en/blog/_posts/2024-11-08-kubernetes-1.32-sneak-peek.md @@ -51,6 +51,8 @@ For more information, please refer to the [API deprecation guide](/docs/referenc ## Sneak peek of Kubernetes v1.32 +The following list of enhancements is likely to be included in the v1.32 release. This is not a commitment and the release content is subject to change. + ### Even more DRA enhancements! In this release, like the previous one, the Kubernetes project continues introducing enhancements to the Dynamic Resource Allocation (DRA), a key component of the Kubernetes resource management system. These enhancements aim to improve the flexibility and efficiency of resource allocation for workloads that require specialized hardware, such as GPUs, FPGAs and network adapters. The improvements for this release include: From 481af09104d0f1b841c300562984a73226d69f87 Mon Sep 17 00:00:00 2001 From: Matteo Bianchi <37507190+mbianchidev@users.noreply.github.com> Date: Wed, 6 Nov 2024 11:30:16 +0100 Subject: [PATCH 23/27] Accepted suggestion Update content/en/blog/_posts/2024-11-08-kubernetes-1.32-sneak-peek.md Co-authored-by: Dipesh Rawat --- content/en/blog/_posts/2024-11-08-kubernetes-1.32-sneak-peek.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/blog/_posts/2024-11-08-kubernetes-1.32-sneak-peek.md b/content/en/blog/_posts/2024-11-08-kubernetes-1.32-sneak-peek.md index 28429a0b2da64..81441dc5aea63 100644 --- a/content/en/blog/_posts/2024-11-08-kubernetes-1.32-sneak-peek.md +++ b/content/en/blog/_posts/2024-11-08-kubernetes-1.32-sneak-peek.md @@ -35,7 +35,7 @@ However, in Kubernetes v1.32, this approach to DRA will be significantly changed The decision to remove this feature originated from its incompatibility with cluster autoscaling, as resource availability was made non-transparent, complicating decision-making for both Cluster Autoscaler and controllers. The newly added Structured Parameter model substitutes the functionality. -This removal will Kubernetes to handle new hardware requirements and resource claims more predictably, bypassing the complexities of back and forth API calls to the kube-apiserver. +This removal will allow Kubernetes to handle new hardware requirements and resource claims more predictably, bypassing the complexities of back and forth API calls to the kube-apiserver. Please also see the enhancement issue [#3063](https://github.com/kubernetes/enhancements/issues/3063) to find out more. From 2306d5ac4df450f4fb712965b05628f64c01cb06 Mon Sep 17 00:00:00 2001 From: Matteo Bianchi <37507190+mbianchidev@users.noreply.github.com> Date: Wed, 6 Nov 2024 11:31:05 +0100 Subject: [PATCH 24/27] Relative URL update Update content/en/blog/_posts/2024-11-08-kubernetes-1.32-sneak-peek.md Co-authored-by: Dipesh Rawat --- content/en/blog/_posts/2024-11-08-kubernetes-1.32-sneak-peek.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/blog/_posts/2024-11-08-kubernetes-1.32-sneak-peek.md b/content/en/blog/_posts/2024-11-08-kubernetes-1.32-sneak-peek.md index 81441dc5aea63..fc17d5585e7f4 100644 --- a/content/en/blog/_posts/2024-11-08-kubernetes-1.32-sneak-peek.md +++ b/content/en/blog/_posts/2024-11-08-kubernetes-1.32-sneak-peek.md @@ -108,7 +108,7 @@ With the graduation of this [enhancement](https://github.com/kubernetes/enhancem This [enhancement](https://github.com/kubernetes/enhancements/issues/2681) introduces a new field, `status.hostIPs`, to the Kubernetes Pod API, enabling support for multiple IP addresses (IPv4 and IPv6) assigned to a node. Previously, the Pod status only included a singular HostIP field, which limited address configurations, particularly in dual-stack networks. This enhancement allows the API to store multiple IP addresses in an array, accessible via the Downward API, which applications can leverage for environments with complex IP requirements, such as IPv6 migrations. The feature is controlled by the PodHostIPs feature gate, supporting flexibility for gradual rollout. -For more information about giving containers information about themselves, visit the [downward-api documentation](https://kubernetes.io/docs/concepts/workloads/pods/downward-api/). +For more information about giving containers information about themselves, visit the [downward-api documentation](/docs/concepts/workloads/pods/downward-api/). ### Make Kubernetes aware of the LoadBalancer behavior From 55c76b71d7a22204486490a55f4883bcf990e58d Mon Sep 17 00:00:00 2001 From: Matteo Bianchi <37507190+mbianchidev@users.noreply.github.com> Date: Thu, 7 Nov 2024 11:51:12 +0100 Subject: [PATCH 25/27] Including tracked changes only (removed most of the content) Update 2024-11-08-kubernetes-1.32-sneak-peek.md --- .../2024-11-08-kubernetes-1.32-sneak-peek.md | 55 +------------------ 1 file changed, 2 insertions(+), 53 deletions(-) diff --git a/content/en/blog/_posts/2024-11-08-kubernetes-1.32-sneak-peek.md b/content/en/blog/_posts/2024-11-08-kubernetes-1.32-sneak-peek.md index fc17d5585e7f4..e04acd230c52f 100644 --- a/content/en/blog/_posts/2024-11-08-kubernetes-1.32-sneak-peek.md +++ b/content/en/blog/_posts/2024-11-08-kubernetes-1.32-sneak-peek.md @@ -55,39 +55,9 @@ The following list of enhancements is likely to be included in the v1.32 release ### Even more DRA enhancements! -In this release, like the previous one, the Kubernetes project continues introducing enhancements to the Dynamic Resource Allocation (DRA), a key component of the Kubernetes resource management system. These enhancements aim to improve the flexibility and efficiency of resource allocation for workloads that require specialized hardware, such as GPUs, FPGAs and network adapters. The improvements for this release include: +In this release, like the previous one, the Kubernetes project continues proposing a number of enhancements to the Dynamic Resource Allocation (DRA), a key component of the Kubernetes resource management system. These enhancements aim to improve the flexibility and efficiency of resource allocation for workloads that require specialized hardware, such as GPUs, FPGAs and network adapters. This release introduces improvements, including the addition of resource health status in the Pod status, as outlined in KEP [#4680](https://github.com/kubernetes/enhancements/issues/4680). -- Partitionable devices support: [KEP #4815](https://github.com/kubernetes/enhancements/issues/4815) -- Resource Claim status and standardized network interface data: [KEP #4817](https://github.com/kubernetes/enhancements/issues/4817) -- Structured parameters: [KEP #4381](https://github.com/kubernetes/enhancements/issues/4381) -- Prioritized alternatives in device requests: [KEP #4816](https://github.com/kubernetes/enhancements/issues/4816) -- Resource health status in Pod status: [KEP #4680](https://github.com/kubernetes/enhancements/issues/4680) - -**Partitionable devices support** - -KEP [#4815](https://github.com/kubernetes/enhancements/issues/4815) proposes improvements to Kubernetes' Dynamic Resource Allocation (DRA) framework, enabling more efficient support for high-performance partitionable devices like GPUs, FPGAs, and network adapters. Currently, these devices are treated as whole units, potentially leading to resource inefficiencies when workloads require only a fraction of a device’s capacity. -By extending the DRA framework, this enhancement allows workloads to request and consume portions of these resources, increasing utilization and scheduling flexibility. The proposed enhancement also provides primitives for representing both full devices and their partitions more compactly, supporting the recent transition from "classic DRA" to the "structured parameters" approach. -The newly proposed extensions, fully transparent to the end-user, enable device management plugins to provision “overlapping” partitions, ensuring that the scheduler does not allocate conflicting partitions. This approach allows vendors to dynamically create new partitions after allocation, eliminating the need for pre-partitioned configurations while still supporting device partition selection through existing mechanisms like `ResourceClaim` and `ResourceSlice` in Kubernetes v1.31. - -**ResourceClaim status and standardized network interface data** - -KEP [#4817](https://github.com/kubernetes/enhancements/issues/4817) proposes adding new driver-owned fields in the `status` field of ResourceClaim with the possibility of having standardized network interface data. -This is a proposal to enhance the `status` field of ResourceClaims by adding a new sub-field: `devices`. -The new field will allow the reporting of driver-specific device status data for each allocated device in a ResourceClaim. Allowing the drivers to report such data will improve observability and troubleshooting and enable new functionalities such as network services (in case the IP addresses of a network device are reported). - -**DRA structured parameters** - -The original dynamic resource allocation (DRA) uses claim and class parameters that are opaque to Kubernetes. KEP [#4381](https://github.com/kubernetes/enhancements/issues/4381) introduces structured parameters so that kube-scheduler and Cluster Autoscaler can handle a claim allocation without relying on a third-party driver. -As users increasingly adopt Kubernetes as their management solution for batch-processing workloads and edge computing, the need to expose specialized hardware to Pods is increasing. -Such workloads no longer need just RAM and CPU, so Kubernetes v1.32 will introduce a new API to describe which of these specialized resources a Pod needs, such as devices like a GPU or other kinds of accelerators. - - -**Prioritized alternatives in device requests** - -KEP [#4816](https://github.com/kubernetes/enhancements/issues/4816) proposes support for prioritized selection criteria associated to a device request in a ResourceClaim. -DRA _structured parameters_ will gain the ability to make requests for very specific types of devices using a ResourceClaim. - -**Add resource health status to the Pod status** +#### Add resource health status to the Pod status It isn't easy to know when a Pod uses a device that has failed or is temporarily unhealthy. KEP [#4680](https://github.com/kubernetes/enhancements/issues/4680) proposes exposing device health via Pod `status`, making troubleshooting of Pod crashes easier. @@ -97,38 +67,17 @@ KEP [#4680](https://github.com/kubernetes/enhancements/issues/4680) proposes exp KEP [#4802](https://github.com/kubernetes/enhancements/issues/4802) adds support for graceful shutdowns of Windows nodes in Kubernetes clusters. Before this release, Kubernetes provided graceful node shutdown functionality for Linux nodes but lacked equivalent support for Windows. This enhancement enables the kubelet on Windows nodes to handle system shutdown events properly. Doing so, it ensures that Pods running on Windows nodes are gracefully terminated, allowing workloads to be rescheduled without disruption. This improvement enhances the reliability and stability of clusters that include Windows nodes, especially during a planned maintenance or any system updates. -KEP [#4885](https://github.com/kubernetes/enhancements/issues/4885) adds CPU and memory affinity support to Windows nodes in Kubernetes, thus improving performance for workloads that benefit from cache vicinity and NUMA optimizations; this effort also aligns Windows capabilities with Linux nodes. - ### Allow special characters in environment variables With the graduation of this [enhancement](https://github.com/kubernetes/enhancements/issues/4369) to beta, Kubernetes now allows almost all printable ASCII characters (excluding "=") to be used as environment variable names. This change addresses the limitations previously imposed on variable naming, facilitating a broader adoption of Kubernetes by accommodating various application needs. The relaxed validation will be enabled by default via the `RelaxedEnvironmentVariableValidation` feature gate, ensuring that users can easily utilize environment variables without strict constraints, enhancing flexibility for developers working with applications like .NET Core that require special characters in their configurations. -### Field status.hostIPs added for Pod - -This [enhancement](https://github.com/kubernetes/enhancements/issues/2681) introduces a new field, `status.hostIPs`, to the Kubernetes Pod API, enabling support for multiple IP addresses (IPv4 and IPv6) assigned to a node. Previously, the Pod status only included a singular HostIP field, which limited address configurations, particularly in dual-stack networks. This enhancement allows the API to store multiple IP addresses in an array, accessible via the Downward API, which applications can leverage for environments with complex IP requirements, such as IPv6 migrations. -The feature is controlled by the PodHostIPs feature gate, supporting flexibility for gradual rollout. - -For more information about giving containers information about themselves, visit the [downward-api documentation](/docs/concepts/workloads/pods/downward-api/). - ### Make Kubernetes aware of the LoadBalancer behavior KEP [#1860](https://github.com/kubernetes/enhancements/issues/1860) graduates to GA, introducing the `ipMode` field for a Service of `type: LoadBalancer`, which can be set to either `"VIP"` or `"Proxy"`. This enhancement is aimed at improving how cloud providers load balancers interact with kube-proxy and it is a change transparent to the end user. The existing behavior of kube-proxy is preserved when using `"VIP"`, where kube-proxy handles the load balancing. Using `"Proxy"` results in traffic sent directly to the load balancer, providing cloud providers greater control over relying on kube-proxy; this means that you could see an improvement in the performance of your load balancer for some cloud providers. -### Support PSI based on cgroupv2 -This [KEP](https://github.com/kubernetes/enhancements/issues/4205) adds support in the Kubelet to read Pressure Stall Information (PSI) metrics for CPU, Memory and I/O resources exposed from cAdvisor and runc. Pressure metrics are like a barometer that can warn about impending resource shortages on a node. This will enable the Kubelet to report node conditions, which can be utilized to prevent the scheduling of Pods on nodes experiencing significant resource constraints. - ### Retry generate name for resources This [enhancement](https://github.com/kubernetes/enhancements/issues/4420) improves how name conflicts are handled for Kubernetes resources created with the `generateName` field. Previously, if a name conflict occurred, the API server returned a 409 HTTP Conflict error and clients had to manually retry the request. With this update, the API server automatically retries generating a new name up to seven times in case of a conflict. This significantly reduces the chances of collision, ensuring smooth generation of up to 1 million names with less than a 0.1% probability of a conflict, providing more resilience for large-scale workloads. -### Mutating admission policies - -This [enhancement](https://github.com/kubernetes/enhancements/issues/3962) will introduce _mutating admission policies_ using CEL (Common Expression Language), allowing Kubernetes users to declaratively in-line mutating policies without complex admission webhooks. -This enhancement simplifies common mutating tasks—such as adding labels, setting fields, or injecting sidecars—by enabling policies to be directly defined within the Kubernetes API server. With CEL's object instantiation and Server-Side Apply merge algorithms, these policies can minimize reinvocation, reduce latency, and eliminate the overhead associated with webhook management. This new approach enhances Kubernetes extensibility by reducing operational complexity, while providing a scalable, built-in solution for secure and efficient policy management across diverse use cases like GitOps and CI/CD. Making Kubernetes admission control more accessible and powerful for developers and administrators alike. - -### Control over terminating Pods in deployments - -This [enhancement](https://github.com/kubernetes/enhancements/issues/3973) adds a new field `.spec.podReplacementPolicy` to Deployments to specify whether new Pods can be created only after old Pods have finished terminating or once old Pods start terminating. The default behavior depends on the deployment strategy. Specifying this Pod replacement policy can better control the speed of rollouts/scaling and potentially avoid problems with excessive resource usage. - ## Want to know more? New features and deprecations are also announced in the Kubernetes release notes. We will formally announce what's new in [Kubernetes v1.32](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.32.md) as part of the CHANGELOG for this release. From 46e4540bca4c7cb09849bfb1e1b343f3905bd0b0 Mon Sep 17 00:00:00 2001 From: Matteo Bianchi <37507190+mbianchidev@users.noreply.github.com> Date: Thu, 7 Nov 2024 13:12:39 +0100 Subject: [PATCH 26/27] Addressed nit Update content/en/blog/_posts/2024-11-08-kubernetes-1.32-sneak-peek.md Co-authored-by: divya-mohan0209 --- content/en/blog/_posts/2024-11-08-kubernetes-1.32-sneak-peek.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/blog/_posts/2024-11-08-kubernetes-1.32-sneak-peek.md b/content/en/blog/_posts/2024-11-08-kubernetes-1.32-sneak-peek.md index e04acd230c52f..4369c81f20f8b 100644 --- a/content/en/blog/_posts/2024-11-08-kubernetes-1.32-sneak-peek.md +++ b/content/en/blog/_posts/2024-11-08-kubernetes-1.32-sneak-peek.md @@ -28,7 +28,7 @@ Whether an API is removed due to a feature graduating from beta to stable or bec ## Note on the withdrawal of the old DRA implementation -This enhancement [#3063](https://github.com/kubernetes/enhancements/issues/3063) introduced Dynamic Resource Allocation (DRA) in Kubernetes 1.26. +The enhancement [#3063](https://github.com/kubernetes/enhancements/issues/3063) introduced Dynamic Resource Allocation (DRA) in Kubernetes 1.26. However, in Kubernetes v1.32, this approach to DRA will be significantly changed. Code related to the original implementation will be removed, leaving KEP [#4381](https://github.com/kubernetes/enhancements/issues/4381) as the "new" base functionality. From 61d8b116d4d9fcce1098662612aa6c88ea38045d Mon Sep 17 00:00:00 2001 From: Matteo Bianchi <37507190+mbianchidev@users.noreply.github.com> Date: Thu, 7 Nov 2024 13:13:12 +0100 Subject: [PATCH 27/27] Rewording around DRA for clarity Update content/en/blog/_posts/2024-11-08-kubernetes-1.32-sneak-peek.md Co-authored-by: divya-mohan0209 --- content/en/blog/_posts/2024-11-08-kubernetes-1.32-sneak-peek.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/blog/_posts/2024-11-08-kubernetes-1.32-sneak-peek.md b/content/en/blog/_posts/2024-11-08-kubernetes-1.32-sneak-peek.md index 4369c81f20f8b..b7a3cb5c95c1e 100644 --- a/content/en/blog/_posts/2024-11-08-kubernetes-1.32-sneak-peek.md +++ b/content/en/blog/_posts/2024-11-08-kubernetes-1.32-sneak-peek.md @@ -32,7 +32,7 @@ The enhancement [#3063](https://github.com/kubernetes/enhancements/issues/3063) However, in Kubernetes v1.32, this approach to DRA will be significantly changed. Code related to the original implementation will be removed, leaving KEP [#4381](https://github.com/kubernetes/enhancements/issues/4381) as the "new" base functionality. -The decision to remove this feature originated from its incompatibility with cluster autoscaling, as resource availability was made non-transparent, complicating decision-making for both Cluster Autoscaler and controllers. +The decision to change the existing approach originated from its incompatibility with cluster autoscaling as resource availability was non-transparent, complicating decision-making for both Cluster Autoscaler and controllers. The newly added Structured Parameter model substitutes the functionality. This removal will allow Kubernetes to handle new hardware requirements and resource claims more predictably, bypassing the complexities of back and forth API calls to the kube-apiserver.