Our Kubernetes Release Review for v1.34 ‘Of Wind & Will’

As usual, there has been a new release of the Kubernetes project at the end of August, and so in our Kubernetes release review we take another look at the new features , improvements and deprecated features in our favorite container orchestrator.

The new release Of Wind & Will emphasizes that Kubernetes continues to exist as an open source project primarily due to the will and motivation of the many contributors, regardless of headwinds. Once again, 58 improvements have made it into the release, including

• 23 stable enhancements
• 22 beta enhancements
• 13 alpha enhancements

As usual, there are also a few announcements about features that will be removed in future releases, but more on that later. Let’s get started!

Kubernetes Release Review: Our Most Important Stable Enhancements

As the operators of NETWAYS Managed Kubernetes®, new features that improve the stability and performance of Kubernetes clusters are of course particularly relevant to us. In that regard, Kubernetes v1.34 brings several improvements to the stable category, so that we and our customers can benefit from them in the future:

• Dynamic Resource Allocation has come a long way, and some API resources are now stable, including ResourceClaims, DeviceClasses, ResourceClaimTemplates and ResourceSlices. More information can be found in KEP #4381.
• Namespaces and the objects they contain are now deleted in an orderly manner. This means that security-relevant racing conditions such as the deletion of network policies before workloads protected by them are a thing of the past. More information can be found in KEP #5080.
• Querying extensive listings, e.g. of pods or CustomResources, used to consume a lot of memory within the Kubernetes API server. By streaming such requests, the load on the API server is now significantly reduced. The feature is active by default for JSON and the Kubernetes protobuf format. More information can be found in KEP #5116.
• Relaxed DNS search path validation for applications in the cluster now ensures that not every query has to go through the internal DNS servers of the cluster, but can be resolved directly for external hostnames. More information can be found in KEP #4427.
• Swap on Linux nodes is now stable and therefore generally available in Kubernetes v1.34. This means that workloads with varying, possibly large memory consumption can be better managed. However, the kubelet service on the respective cluster nodes must still be configured accordingly. More information can be found in KEP #2400.

Beta Enhancements in Kubernetes v1.34

In addition to the new stable enhancements in Kubernetes v1.34, there are also some features that are entering beta phase for the time being. In our Kubernetes release review, we would like to highlight some quality-of-life functions for cluster administrators and end users:

• Resource requests and limits can be set at Pod level instead of container level in Kubernetes v1.34. This solves the dilemma of potential overprovisioning of resources or complex micromanagement, which was previously often necessary for Pods consisting of several containers. The resource budget set for a Pod is shared across all containers, and components such as the Horizontal Pod Autoscaler (HPA) or Scheduler can refer to this budget in their decisions. More information can be found in KEP #2837.
• A new configuration file for kubectl user settings has been introduced via .kuberc. Default settings and command aliases that previously had to be managed separately and/or manually can now be maintained in this file. More information can be found in KEP #3104.
• Mutating Admission Policies in Kubernetes v1.34 offer a new, simpler way for administrators to define admission controls directly in Kubernetes’ API server. The policies are based on CEL and JSON patch strategy. More information can be found in KEP #3962.

Kubernetes Release Review: New Enhancements in the Alpha Phase

Last but not least, some brand new features have of course also made it into alpha phase starting with Kubernetes v1.34, including Kubernetes’ new YAML subset KYAML:

• KYAML is a YAML dialect created for Kubernetes that corresponds to a more secure and clearer YAML subset. In particular, existing weaknesses of YAML on the one hand (e.g. the well-known ‘Norway bug’ or incorrect indentation) and JSON on the other (e.g. lack of support for comments) have been accounted for. KYAML can be used as an input and output format for kubectl, and remains valid YAML at all times. The following command in the terminal provides an example of KYAML syntax. More information can be found in KEP #5295.

KUBECTL_KYAML=true kubectl run kyaml-demo --image=nginx:latest --dry-run=client -o=kyaml
---
{
  kind: "Pod",
  apiVersion: "v1",
  metadata: {
  name: "kyaml-demo",
  labels: {
  run: "kyaml-demo",
  },
  },
  spec: {
  containers: [{
  name: "kyaml-demo",
  image: "nginx:latest",
  resources: {},
  }],
  restartPolicy: "Always",
  dnsPolicy: "ClusterFirst",
  },
  status: {},
}

KUBECTL_KYAML=true kubectl run kyaml-demo --image=nginx:latest --dry-run=client -o=kyaml
---
{
  kind: "Pod",
  apiVersion: "v1",
  metadata: {
    name: "kyaml-demo",
    labels: {
      run: "kyaml-demo",
    },
  },
  spec: {
    containers: [{
      name: "kyaml-demo",
      image: "nginx:latest",
      resources: {},
    }],
    restartPolicy: "Always",
    dnsPolicy: "ClusterFirst",
  },
  status: {},
}

• The Restricted Pod Security Standard no longer allows remote probes in Kubernetes v1.34. This prevents the host field from being set in the probe or lifecycle configuration of a Pod, as it could theoretically be set to any value other than the respective podIP. More information can be found in KEP #4940.
• Container restart rules within the same Pod may differ between containers in Kubernetes v1.34. Previously, all containers followed the same restart rule defined at Pod level in .spec.restartPolicy. In Pods with multiple containers (e.g. init and workload containers), however, it makes sense to handle restarts differently in some scenarios. This can now be enabled and configured using the feature gate ContainerRestartRules. More information can be found in CEP #5307.

Deprecations Announced in Kubernetes v1.34

In addition to many new features, Kubernetes v1.34 also includes announcements of discontinuation of some existing features. So let’s conclude our Kubernetes release review with those:

• Manual configuration of cgroup drivers in the kubelet configuration is now officially deprecated after Kubernetes v1.28 introduced a way to automatically detect correct cgroup drivers. The feature will not be finally removed before Kubernetes v1.36. More information can be found in KEP #4033.
• containerd 1.x support will be discontinued in Kubernetes v1.36. While containerd 1.7 and several LTS versions of the container runtime are still supported in Kubernetes v1.34, this will no longer be the case starting with Kubernetes v1.36 and an upgrade to containerd 2.x will be necessary. More information can be found in KEP #4033.

These were the highlights of our Kubernetes release review for Kubernetes v1.34 “Of Wind & Will”. You can find the more detailed release blog post on the Kubernetes project website here.
We will of course spend the coming weeks making Kubernetes v1.34 available to you in NETWAYS Managed Kubernetes® as soon as possible – as always with certified conformity to the upstream project and certified support from our MyEngineers®.

And in just over four months’ time, it will be time to say: Hello, Kubernetes v1.35!