Kubernetes 1.37 Is Now Available on ZCP

Suppose an online retailer has a queue of image-processing jobs after a product launch. During quiet hours, it wants the worker deployment at zero replicas. When messages arrive, it wants workers to return without an operator changing a replica count. Kubernetes 1.37 makes this pattern more practical upstream, and it is now available for new managed clusters on ZCP.

Kubernetes 1.37.0 is available in YOW-1 and YUL-1. New clusters still default to 1.36.4, so teams can test 1.37 before making it their production baseline.

A practical 1.37 example: queue workers that scale to zero

In Kubernetes 1.37, HorizontalPodAutoscaler support for scaling to zero is beta and enabled by default upstream. It works with external or object metrics. CPU and memory metrics alone cannot bring a deployment back from zero, because no running pod exists to report them.

For a worker that consumes a queue, this example assumes you have configured an external-metrics adapter that exposes a queue-depth metric to the Kubernetes API. With one in place, an HPA might look like this:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: image-worker
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: image-worker
  minReplicas: 0
  maxReplicas: 10
  metrics:
    - type: External
      external:
        metric:
          name: queue_messages_ready # Replace with your adapter's metric name.
        target:
          type: AverageValue
          averageValue: '1'

Start the Deployment with at least one replica. The HPA can reactivate a zero-replica workload only when it performed the scale-down itself. A Deployment manually set to zero remains paused, so ensure your GitOps configuration does not repeatedly apply zero replicas.

Scaling the Deployment to zero removes pods, not cluster costs. Provisioned worker nodes, the managed control plane, storage, and other resources remain billable. Node autoscaling is a separate subject and is constrained by its configured minimum. Scaling to zero also introduces a cold start while Kubernetes schedules new workers. Test queue latency, image pulls, application startup, and the metric adapter before relying on the pattern for a customer-facing workload. Read the upstream HPA scale-to-zero guidance for its requirements and behaviour.

Other upstream improvements worth testing

Kubernetes 1.37, named Garhwal, includes 67 enhancements. A few are useful to application and platform teams:

• The metrics.k8s.io/v1 API is generally available. This offers a stable API for CPU and memory inspection and autoscaling tooling, provided the cluster has a compatible metrics implementation. The v1beta1 API remains for HPA in 1.37 and older clients. See the upstream Metrics API announcement.
• kyaml output graduates to stable in kubectl 1.37 for a cleaner view of API objects. The output format has been available since 1.34, and existing YAML output still works. For example: kubectl get deployment image-worker -o kyaml. See the KYAML output guide.
• Resilient watch-cache initialization is generally available. It limits API-server requests while the watch cache initializes, reducing request spikes during startup.

Feature maturity upstream does not automatically mean every related integration is configured on ZCP. Dynamic Resource Allocation, for example, still depends on an appropriate driver and hardware. Pod certificates and ClusterTrustBundle also need a signer controller. Review the Kubernetes 1.37 release notes and validate the features your workloads use in a test cluster.

Version snapshot on ZCP

As of September 6, 2026, these versions are available for new ZCP managed clusters:

For the current, authoritative list of supported versions, see Create Kubernetes Cluster.

Clusters already on 1.36.1, 1.35.1, or 1.34.3 continue to show those existing versions until an upgrade. The current list is a dated availability snapshot. It is not a commitment to retain 1.34 or a permanent minimum version of 1.35.

Plan upgrades before upstream end of life

Kubernetes minor versions receive roughly 14 months of upstream patch support: about 12 months of standard support followed by a two-month restricted maintenance period. Once a version reaches upstream end of life, it no longer receives upstream security updates or bug fixes. This upstream lifecycle is separate from ZCP’s proposed offering of three recent minor lines.

Maintenance mode is the restricted two-month phase for critical core-component, dependency, and security fixes before end of life. Kubernetes 1.33 reached upstream end of life on June 28, 2026, and 1.32 reached it on February 28, 2026. Earlier minor versions are also end of life. The upstream release history lists the complete record, and patch-release support details explain the maintenance period.

ZCP is proposing to retire Kubernetes 1.34 in December 2026 and to keep three recent ZCP-offered minor lines, currently 1.35 through 1.37. This proposal is distinct from upstream end of life and is not a permanent floor at 1.35. The exact retirement date, eligibility, pricing, and notification process are still to be announced.

Under the proposed policy, clusters below 1.35 would require an upgrade or a separately agreed paid enhanced-support arrangement. Without such an arrangement, ZCP plans to schedule an automatic upgrade after the announced cutoff. Plan an upgrade before Kubernetes 1.34 reaches upstream end of life on October 27 rather than waiting for the proposed December retirement.

Start with a test cluster, then plan production

Create a Kubernetes 1.37 test cluster, validate your applications, add-ons, metrics integrations, and upgrade runbooks, then plan the production change. Upgrades are initiated from Cluster Overview in the ZCP portal by selecting Upgrade Kubernetes Version. Move one minor release at a time: 1.34 to 1.35, 1.35 to 1.36, and 1.36 to 1.37. Patch upgrades within the same minor release are also available.

For the current version list and lifecycle policy, read the ZCP Kubernetes version lifecycle. For portal steps, read upgrade your cluster.