[Back to blog](https://zcp.zsoftly.ca/blog)
 [Announcements](https://zcp.zsoftly.ca/blog/category/announcements)

# Kubernetes 1.37 Is Now Available on ZCP

Kubernetes 1.37 is available for new ZCP managed clusters. Explore a queue-worker scaling example, supported versions, upstream support dates, and a practical upgrade plan.

ZSoftly Team

September 6, 2026

5 min read

Share

![ZCP announcement: Kubernetes 1.37. Now on ZCP. New features, upgrades, and version support.](https://zcp.zsoftly.ca/images/blog/2026/kubernetes-1-37-now-available.webp)

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:

```yaml
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](https://kubernetes.io/blog/2026/09/02/kubernetes-v1-37-hpa-scale-to-zero-beta/) 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](https://kubernetes.io/blog/2026/08/27/kubernetes-v1-37-metrics-api-ga/).
- `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](https://kubernetes.io/blog/2026/08/11/how-to-pretty-print-kubernetes-yaml-as-kyaml/).
- 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](https://kubernetes.io/blog/2026/08/26/kubernetes-v1-37-release/) 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:

| Version | Status |
| --- | --- |
| 1.37.0 | New minor version |
| 1.36.4 | Default for new clusters |
| 1.35.8 | Available for new clusters |
| 1.34.11 | Available for new clusters |

For the current, authoritative list of supported versions, see [Create Kubernetes Cluster](https://docs.zcp.zsoftly.ca/public-cloud/kubernetes/create-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.

| Kubernetes minor | Maintenance mode starts | Upstream end of life |
| --- | --- | --- |
| 1.34 | August 27, 2026 | October 27, 2026 |
| 1.35 | December 28, 2026 | February 28, 2027 |
| 1.36 | April 28, 2027 | June 28, 2027 |
| 1.37 | August 28, 2027 | October 28, 2027 |

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](https://kubernetes.io/releases/) lists the complete record, and [patch-release support details](https://kubernetes.io/releases/patch-releases/) 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](https://docs.zcp.zsoftly.ca/public-cloud/kubernetes/create-cluster/#version-lifecycle). For portal steps, read [upgrade your cluster](https://docs.zcp.zsoftly.ca/public-cloud/kubernetes/cluster-overview/#upgrade-your-cluster).

## Related articles

Announcements

October 20, 2026

### [Why We Are Building ZCP Certification](https://zcp.zsoftly.ca/blog/why-we-are-building-zcp-training-and-certification)

ZSoftly is launching ZCP certification in January 2027: four levels, free learning paths and labs, paid exams, and a learning platform built on Moodle with IOMAD.

Announcements

October 11, 2026

### [ZCP Store: Buy Services and Licences From Your Console](https://zcp.zsoftly.ca/blog/zcp-store-buy-services-and-licences-from-your-console)

The Store is a new tab in the ZCP console. Buy support, professional services, dedicated servers and licences there, and they bill on the same invoice as your instances.

Announcements

October 11, 2026

### [Our CLI and Terraform Provider Reach v1](https://zcp.zsoftly.ca/blog/zcp-cli-terraform-v1)

ZCP CLI v1.0.1 and the Terraform and OpenTofu provider v1.0.0 are available today, bringing Pricing V2 configuration, Kubernetes role sizing, VM backup schedules, and lifecycle fixes to automation workflows.