Kubernetes 1.35 Features That Matter in Production

Kubernetes 1.35 Features That Matter in Production

Kubernetes v1.35 is already here. The changes worth your attention are practical ones: in-place Pod resize is GA, StatefulSet rollouts can move faster, HPA tolerance is now configurable per workload, image volumes stay in beta by default, and Pod certificates introduce a new upstream-native path for workload credentials.

TL;DR

  • Kubernetes v1.35 was released on December 17, 2025.
  • As of March 11, 2026, the Kubernetes releases page lists v1.35.2 as the latest patch in the 1.35 line.
  • The most immediately useful features are in-place Pod resource resize reaching GA, configurable HPA tolerance, StatefulSet maxUnavailable, and image volumes.
  • Pod certificates are one of the most interesting security additions, but they still need deliberate evaluation because they are beta.
  • The biggest upgrade cautions are not optional: Kubernetes v1.35 retires cgroup v1 support and is the last release that supports containerd 1.x.

Kubernetes 1.35 Is Current, Not Speculative

Kubernetes v1.35 is a released upstream version, not a roadmap placeholder. The official release announcement was published on December 17, 2025, and the current Kubernetes releases page listed v1.35.2 as the latest patch in that series on March 11, 2026. The release team counted 60 enhancements across stable, beta, and alpha features.

That matters because this branch is not just about API churn. Several v1.35 items reduce day-to-day operator pain: resizing Pods without restarts, tuning autoscaling sensitivity per workload, updating StatefulSets faster, and mounting OCI artifacts directly as volumes. The release is also a forcing function to audit older nodes because the upstream project is retiring cgroup v1 support and treating v1.35 as the last release that supports containerd 1.x.

1. In-place Pod Resource Resize Reaches GA

This is the clearest production win in the release. Kubernetes now supports resizing CPU and memory requests and limits on an existing Pod without forcing a restart. For stateful services, queue consumers, and long-running workers, that removes one of the most frustrating tradeoffs in vertical scaling.

The official v1.35 task documentation shows the resize flow through the /resize subresource:

kubectl patch pod resize-demo --subresource resize --patch '{"spec":{"containers":[{"name":"pause","resources":{"requests":{"cpu":"0.3","memory":"150Mi"},"limits":{"cpu":"0.5","memory":"300Mi"}}}]}}'

The important nuance is that v1.35 does not make every resource resizable. The docs still scope this to CPU and memory, note that Windows Pods are not supported, and explain that the original QoS class of the Pod remains fixed after a resize. Even with those limits, GA status makes this feature something most operators should test immediately.

2. HPA Tolerance Is Finally Workload-specific

Older Kubernetes versions effectively baked a 10% tolerance into HorizontalPodAutoscaler behavior. That was reasonable for some workloads and wrong for others. If you needed a more sensitive scale-up threshold, you were stuck with the cluster default.

In v1.35, the HPA documentation exposes tolerance under both scaleUp and scaleDown behavior:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-hpa
spec:
  minReplicas: 2
  maxReplicas: 20
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60
  behavior:
    scaleUp:
      tolerance: 0.05
    scaleDown:
      tolerance: 0.10

This is a small API change with outsized operational value. Latency-sensitive APIs, bursty event consumers, and any workload that needs a tighter response curve can now tune scaling behavior without forcing a global compromise on the cluster.

3. StatefulSet maxUnavailable Becomes Beta by Default

StatefulSet rollouts have traditionally been conservative. That is exactly what you want until your application can safely tolerate more than one unavailable Pod and you still have to wait for a one-at-a-time update.

The v1.35 StatefulSet docs show rollingUpdate.maxUnavailable as a beta feature enabled by default:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: nginx
  replicas: 6
  podManagementPolicy: Parallel
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: nginx
        image: registry.k8s.io/nginx-slim:0.24

If your workload already has quorum handling, replication, or client retry behavior that can tolerate more than one unavailable replica, this setting can shorten maintenance windows without inventing a new rollout controller.

4. Image Volumes Make OCI Registries More Useful

Kubernetes v1.35 keeps image volumes in beta and enabled by default. This lets you mount content from an OCI artifact or image into a Pod volume instead of baking everything into the main container or scripting downloads into an emptyDir.

The volumes docs show the feature directly:

apiVersion: v1
kind: Pod
metadata:
  name: image-volume
spec:
  containers:
  - name: shell
    command: ["sleep", "infinity"]
    image: debian
    volumeMounts:
    - name: volume
      mountPath: /volume
  volumes:
  - name: volume
    image:
      reference: quay.io/crio/artifact:v2
      pullPolicy: IfNotPresent

This is a practical improvement for teams that want to distribute large static assets, configuration bundles, or model files through the same registry pipeline they already trust. The documentation also makes one operational requirement explicit: you need a compatible runtime such as containerd 2.1 or later.

5. Pod Certificates Are the Security Feature to Watch

The most interesting security addition in v1.35 is the PodCertificate API. The release post highlights Pod certificates as a beta feature for workload identity and certificate delivery, and the current projected volumes documentation now describes podCertificate sources that let the kubelet generate keys and rotate credentials for a Pod.

The projected volumes docs show the shape of the new source:

volumes:
- name: credentials
  projected:
    sources:
    - podCertificate:
        signerName: example.com/mysigner
        keyType: ED25519
        maxExpirationSeconds: 86400
        credentialBundlePath: credentialbundle.pem

This does not mean every cluster should rip out existing certificate tooling tomorrow. The v1.35 documentation explicitly says support for Pod Certificates must be enabled, and the feature is still beta. But it is the clearest upstream-native attempt so far to reduce the amount of external Secret, controller, and sidecar plumbing required for workload certificates.

The Upgrade Warnings Matter More Than the Shiny Features

The most operationally important part of the v1.35 release may be the warnings, not the feature list.

  • The official release notes say Kubernetes is retiring cgroup v1 support in v1.35. If any node pools still depend on older Linux distributions without cgroup v2 support, kubelet startup validation needs to happen before you even discuss new features.
  • The same release notes call v1.35 the last Kubernetes release that supports containerd 1.x. If you still run containerd 1.x anywhere, treat this release as a migration window rather than a steady-state destination.

A reasonable adoption order is straightforward: patch to the newest 1.35 build available for your environment, validate node OS and runtime compatibility, move off containerd 1.x, and only then broaden rollout of the workload-facing features that actually reduce toil in your cluster.

Frequently Asked Questions

Q: What are the most important Kubernetes 1.35 features for most production teams?
A: The highest-impact features for most teams are in-place Pod resize reaching GA, configurable HPA tolerance, StatefulSet maxUnavailable, and beta image volumes. Those change daily operations more than the alpha features do.

Q: Is Kubernetes 1.35 ready for production use?
A: Yes. Kubernetes v1.35 is a released upstream branch, and as of March 11, 2026 the current releases page lists v1.35.2 as the latest patch in the line. Production usage should target a patched 1.35 release rather than staying on the original .0 build.

Q: Is PodCertificate ready to replace cert-manager or SPIFFE everywhere?
A: No. Pod certificates are more credible in v1.35 because the feature is now beta, but the docs still require explicit enablement and the feature needs deliberate evaluation before broad replacement decisions.

Q: What should I verify before upgrading to Kubernetes 1.35?
A: Verify cgroup v2 readiness on nodes and plan your move away from containerd 1.x. Those are the two upgrade cautions the official release notes make hardest to ignore.

References

Comments

Post a Comment

Popular posts from this blog

Bootstrapping Kubernetes Clusters with Terraform and Argo CD: A Durable Two-Layer Approach

Image
Bootstrapping Kubernetes Clusters with Terraform and Argo CD: A Durable Two-Layer Approach Robust cluster bootstrap separates infrastructure provisioning from continuous reconciliation. This guide details a production-grade Terraform plus Argo CD model with explicit governance. TL;DR A production-ready Kubernetes bootstrap is more reliable when Terraform and Argo CD have explicit responsibilities. Terraform should provision and manage infrastructure primitives, cluster lifecycle resources, and state safety controls. Argo CD should continuously reconcile platform and workload resources from Git using declarative application definitions. This model reduces drift and clarifies incident ownership. Teams should harden Terraform workflows with plan review and state management controls, and treat Argo CD app-of-apps repositories as privileged automation surfaces with strict access and project boundaries. App-of-apps accelerates bootstrap, but should be managed as privileged automation. Bo...
Read more

Argo CD Auto-Sync and Health Checks: An Operator's Guide to Safe GitOps Reconciliation

Image
Argo CD Auto-Sync and Health Checks: An Operator's Guide to Safe GitOps Reconciliation Auto-sync and health are not the same thing in Argo CD. This guide shows how reconciliation, pruning, self-healing, retries, health checks, hooks, and sync waves fit together in real clusters. TL;DR Argo CD auto-sync and health checks solve different problems. Auto-sync decides when the controller reconciles Git with the cluster, while health checks decide whether the resulting resources are ready, degraded, or suspended. In practice, you need both: automated sync with prune and self-heal keeps desired state converged, retry refresh helps failed syncs recover on new revisions, and health checks plus custom Lua logic make readiness visible to operators. Sync waves and hooks add ordering when resources depend on each other. The control loop most teams misunderstand Argo CD has two separate jobs that often get blurred together in day-to-day platform talk. The first is reconciliation. Should Arg...
Read more

Kubernetes Multi-Tenancy with Namespaces and Network Policies: A Practical Guide for GitOps Teams

Image
Kubernetes Multi-Tenancy with Namespaces and Network Policies: A Practical Guide for GitOps Teams Namespaces are only the first layer of tenant isolation. This guide shows how to combine RBAC, Pod Security Admission, quotas, NetworkPolicies, and Flux service-account impersonation so teams can share a cluster without sharing blast radius. TL;DR Kubernetes multi-tenancy works only when you treat namespaces as one control in a larger isolation stack. A shared cluster needs per-tenant namespaces, namespace-scoped RBAC, Pod Security Admission labels, ResourceQuota and LimitRange defaults, and default-deny NetworkPolicies with explicit exceptions. If you use Flux CD, you also need controller lockdown and service-account impersonation so one tenant's GitOps objects cannot reach across namespaces. The practical goal is not perfect isolation from a namespace alone, but predictable blast-radius control for teams that share a cluster. A shared-cluster multi-tenancy model needs namespace bo...
Read more