kops Is Tracking Kubernetes 1.37 in 2026 — and Still Proves Why Cluster API Won the Heterogeneous Fleet

Reports of kops' death are exaggerated — and that is exactly what makes it interesting. The old-school Kubernetes lifecycle tool shipped a full 1.36 release tracking upstream Kubernetes, has 1.37 support already in flight (its k8s.io dependencies moved to v0.37.0 on September 2, shortly after Kubernetes 1.37 "Garhwal" shipped), and keeps adding cloud providers. A dying project does not do that.

But read those same release notes closely and they prove the opposite point too: kops survives by being the best way to run Kubernetes on AWS, while the industry's heterogeneous fleets — on-prem plus cloud, Hetzner plus AWS, bare metal plus VMs — standardized on Cluster API. One tool won depth. The other won breadth. And the mechanism of that split, visible line by line in kops' own 2026 changelog, is worth understanding before you pick a provisioning layer for hardware you own.

One correction up front, because honesty matters more than a catchy premise: kops is not literally AWS-only. AWS and GCE are officially supported, DigitalOcean, Hetzner, and OpenStack sit in beta, Azure is in alpha, and 1.36 lays groundwork for Linode (Akamai). The accurate claim is narrower and more damning: kops is AWS-first, and every other cloud is a per-cloud code path inside one binary, maintained at whatever priority the (overwhelmingly AWS-focused) contributor base gives it. That distinction is the whole story.

What kops actually shipped in 2026​

Start with the evidence, because "old tool still maintained" undersells it. kOps 1.36 is a serious release: Kubernetes 1.36 support, the completed removal of in-tree cloud providers, containerd v2.2 as the default runtime, a reworked kops-channels addon manager, and the deprecation of gossip DNS (new clusters now default to dns=none, with a hybrid bootstrap path so workers no longer need protokube).

The most telling items are the AWS-deep ones. kOps 1.36 refreshes its Karpenter integration to v1.13.0 and now generates a managed EC2NodeClass and NodePool for every instance group with spec.manager: Karpenter, pruning them when the group is removed — plus the kind of fix only a tool living inside AWS IAM day to day produces, like adding missing EC2 read permissions to the Karpenter IAM policy. Rolling updates now abort when load-balancer target deregistration fails instead of marching on with degraded targets. This is depth you only get from a decade of operating one cloud's failure modes.

The non-AWS sections of the same notes make the contrast for you. Hetzner support expanded — Cluster Autoscaler enabled, a new hcloud/node-group label for node-group membership, minSize redefined as a floor rather than a shrink trigger, hcloud CCM and CSI upgrades — but it remains beta, and each of those bullets is bespoke Hetzner logic inside the kops codebase. Azure gets its cloud-controller-manager, Disk CSI driver, and an experimental Terraform target; still alpha. Linode is newly registered as an experimental provider and explicitly "not yet ready for production use."

And 1.37, already tracking upstream before release, continues the pattern: Kubernetes 1.37 support, gossip DNS removed outright, AWS Classic Load Balancer support for the API removed (deprecated since 1.26 — an eleven-release deprecation tail that tells you how seriously this project treats upgrade discipline), Kopeio networking dropped, containerd 2.3.4 by default, and expanded Karpenter plus Akamai support.

So the 2026 verdict on kops-the-project is: healthy, AWS-superb, and structurally incapable of treating its fifth cloud the way it treats its first. Every new provider multiplies code paths in one CLI. That is not a criticism of the maintainers — it is the architecture.

The bet Cluster API won​

Cluster API's bet was that cluster lifecycle should look like workload lifecycle: you declare Cluster and Machine objects, and controllers reconcile reality toward them, continuously, whether a human is watching or not. kops' bet was that an expert operator driving a CLI — preview with kops update cluster, apply with --yes, roll with kops rolling-update cluster, confirm with kops validate cluster — produces a better cluster on the cloud the tool knows best.

For one cloud, the CLI bet is genuinely competitive; more on that below. The moment the fleet stops being one cloud, three things tip the table, and all three are visible in production in 2026:

New infrastructure stops being a fork. Adding Linode to kops means API registration, VFS object-storage schema, VPC cloudup tasks, and nodeup identity work inside the kops repo — the 1.36 notes list each piece. Adding a new environment to a CAPI fleet means pointing the same Cluster/MachineDeployment shapes at a different provider (CAPH for Hetzner, CAPA for AWS, CAPO for OpenStack). CNCF's 2026 case-study slate keeps rewarding this shape: on-premises Kubernetes built with Cluster API and ArgoCD for strategic autonomy, 100-plus-cluster fleets managed across regions, and the CNCF Annual Report 2025 winner using Cluster API with Crossplane and ArgoCD to cut platform costs 44% and upgrade lead times 85%. Nobody files those outcomes under "we shell-scripted five clouds' CLIs."

Desired state lives where GitOps can see it. kops keeps cluster truth in an external state store — an S3 bucket most commonly — mutated by CLI invocations. CAPI keeps it as objects in etcd on the management cluster, which means the same Flux/ArgoCD pipeline that syncs workloads syncs the fleet definition, and drift gets reconciled by a control loop rather than discovered at the next human-driven update. That is the difference between "the production environment matches the manifest" as an aspiration and as a continuously enforced property.

Remediation stops needing a human with a runbook. kops validates after the fact: rolling-update defaults to failing when validate cluster fails, which is good gate design, but the loop still starts with an operator typing a command. CAPI's MachineHealthCheck plus autoscaler pairing notices an unhealthy node and replaces it without a ticket. On owned hardware — where there is no managed control plane to absorb the toil — the controller doing it at 3 a.m. beats the runbook describing how a human would.

As Meltwater principal engineer Federico Hernandez put it in The New Stack's comparison: kops "is very opinionated, which is a good thing" — for singular clusters you configure deeply. CAPI describes nodes and clusters as objects for multicluster deployments. The industry spent the years since voting with its fleets.

The honest counter: what kops still does better​

A verdict with no counter-argument is marketing, so here is the steelman. If your fleet is AWS and will stay AWS, kops in 2026 is arguably more productive than CAPI-plus-CAPA, not less:

Opinionated depth beats composable generality. kops ships one coherent AWS happy path — VPC topology, IAM roles, autoscaling groups or Karpenter, addon manifests, DNS — tuned by a decade of production scars (aborting rolls on LB deregistration failure is exactly the scar tissue a general framework never grows). CAPI gives you primitives to assemble the equivalent. Assembly is flexibility if you need it and toil if you don't.

The upgrade workflow is a designed artifact. update previews, --yes applies, rolling-update rolls per instance group with node intervals and validation gates, validate confirms. The sequence is learnable in an afternoon and scriptable in a week. A CAPI upgrade path — bump the Kubernetes version across KubeadmControlPlane and MachineDeployments, watch the rollout, rely on health checks — is equally automatable but far less legible to a new operator. Legibility is a feature.

The real competitor on AWS is EKS, not CAPI. Operator notes increasingly file kops under "being replaced by EKS," and the migration guides (when to switch, how to move CNIs, what breaks) are a small literature of their own. That framing is clarifying: kops' fight is "self-managed control plane with full configurability versus managed control plane with an AWS bill." If EKS wins that fight for your org, CAPI was never the alternative — and if kops wins it, you chose depth deliberately.

None of this rescues the heterogeneous case. It just says: the tool that lost breadth did not lose it by being bad. It lost it by being optimized for something else.

Steal this for your Cluster API runbook​

Here is the constructive part — the reason this post exists on a self-hosting PaaS blog rather than as a history essay. kops' decade of operator experience distilled several ergonomics that a CAPH-based fleet should adopt outright, mapped here from the kops command to the CAPI-runbook equivalent:

1. Dry-run discipline: kops update cluster (no --yes) → clusterctl generate + kubectl diff before every apply. kops makes preview the default and mutation the flagged exception; fleet automation should too. No manifest reaches the management cluster without a rendered diff in the PR. This is free and saves more outages than any other item on this list.

2. Validation gates with teeth: --fail-on-validate-error (default true) → post-rollout kubectl wait + clusterctl describe assertions in CI. kops refuses to call a rolling update done when validation fails. Mirror that: after bumping a MachineDeployment, your pipeline asserts ready-replica counts, MachineHealthCheck quiet periods, and workload-cluster validate-equivalents before merging the next change. Default-true, opt-out loudly.

3. Per-group rolling discipline: --instance-group / --instance-group-roles → roll control plane, then system node pools, then tenant pools, as separate applies. kops operators routinely roll masters first and workload pools in named batches with --node-interval pacing. CAPI makes it tempting to bump everything at once because it is "just" manifest edits. Resist that: sequence the rollout across KubeadmControlPlane and each MachineDeployment with explicit pauses, the way --instance-group-roles Master first, workers after, enforces by construction.

4. Abort on degraded load-balancer state → pre-roll LB health assertion. kOps 1.36's abort-on-failed-deregistration fix exists because a roll that proceeds while targets deregister is how you get a new node set behind a broken front door. On a CAPH fleet fronted by Hetzner Load Balancers, assert target health before each rollout step and halt the pipeline on degradation — the managed-LB equivalent of the gate kops just built in.

5. Deprecation tails, not flag days: gossip DNS deprecated across 1.36, removed in 1.37 → announce fleet API changes one minor version before enforcing. kops gave operators a full release to leave gossip (and eleven releases to leave CLB). When your platform changes a ClusterClass default or drops a Kubernetes minor version, ship the warning first, enforce later. Your tenants' upgrade runbooks deserve the same courtesy upstream extends to you.

None of these require kops. All of them were learned the hard way by people running it.

What this means for hardware you own​

The through-line for self-hosters: provisioning tools converge on the shape of the fleet they serve. Single-cloud depth produced the best AWS Kubernetes installer ever written — and then the world built fleets that span clouds, regions, and bare metal, where "one binary with per-cloud code paths" cannot keep up with "one API with per-environment providers." kops tracking Kubernetes 1.37 within days of GA is admirable. It is also the clearest possible demonstration that release velocity was never the moat; the reconciliation model was.

If you run a heterogeneous fleet on Cluster API today — Hetzner workers via CAPH, a local CAPD loop for development, maybe an AWS overflow pool via CAPA — you are standing on the winning side of that bet. The work now is operational maturity: dry-run discipline, validation gates, sequenced rollouts, deprecation tails. kops spent ten years learning those lessons on AWS. Take them for free.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.