kOps v1.36.2 - Rolling Update and AWS Fixes

kOps v1.36.2 was published on August 8, 2026, with a restored five second delay between pod eviction retries during rolling updates. The patch also narrows channel health signals and corrects AWS node configuration that affects network ownership, root volumes, and the cloud controller manager.

The full release notes and downloads are on the GitHub release page.

The rolling update correction restores the five second pause before another pod eviction attempt. That pacing matters when a node drain cannot evict a pod immediately. Repeating the same request without a gap adds pressure but does not clear the underlying blocker.

For operators, the tradeoff is direct. A constrained drain can spend more wall clock time between attempts, but retry behavior is predictable again. Maintenance automation should account for the pause when it estimates how long a node replacement or cluster rollout can take.

Stateful data services tend to expose this timing because eviction can wait for application shutdown or capacity elsewhere. The patch does not remove those constraints or make eviction succeed sooner. It restores the interval at which kOps asks again, so rollout duration remains controlled by workload behavior.

The channel health correction now treats only known ready conditions as health signals. Other condition types no longer influence the health decision merely because they exist. This reduces ambiguity in automation that waits for channel readiness before proceeding with another operation.

The important detail is the narrower contract. A condition counts only when kOps recognizes its readiness meaning. Operators with custom channel data should check that their expected signal is one of the known ready conditions instead of depending on incidental condition presence.

The AWS network change stops kOps from marking the primary network interface with Unmanaged=yes. Removing that setting avoids placing an ownership policy on the interface that carries the main node path. Teams that maintain custom bootstrap or network configuration should compare rendered node files before rollout and remove any local workaround for the old behavior.

The generated EC2NodeClass root volume mapping is the other notable node change. kOps now emits a block device mapping for the root volume instead of leaving that part of the resource implicit.

Before applying regenerated resources, compare the mapping with the intended root volume settings. This is relevant for pipeline workers that use the root disk for image layers, logs, and temporary processing data even when durable state lives on separate volumes.

The release notes do not call for a storage migration. The operator task is still to inspect the generated resource, confirm the explicit mapping matches policy, and stage the node replacement through the normal capacity and workload availability checks.

The AWS CCM update sets v1.36.1 as the default for every Kubernetes version. A single default removes one source of version variance from generated cluster assets, but it also changes what an older Kubernetes minor can receive when configuration is regenerated.

Do not assume the cluster minor still selects a matching AWS CCM minor after this kOps update. Diff the generated image references, verify any mirrored image is available, and test cloud resource reconciliation before promoting the change across production clusters.

No breaking change is declared for this default. It still belongs in the upgrade diff because image policy, private registry mirrors, and version admission rules can reject a reference even when the controller itself is compatible.