The Stack Observer
Cloud Native

Kubernetes This Week: 1.37 RC, KYAML Goes Mainstream, and containerd 2.4 Beta

•Stackxx•Cloud Native, Kubernetes

Kubernetes remains the beating heart of modern infrastructure. As August 2026 unfolds, the ecosystem is accelerating on multiple fronts: the long-awaited Kubernetes 1.37 release is approaching its general availability date, SIG CLI has introduced a stricter way to write YAML, containerd 2.4 is entering beta with meaningful runtime improvements, and cloud providers are tightening their observability integrations. Here is what matters right now.

Kubernetes 1.37 Hits Release Candidate, GA Expected August 26

The Kubernetes project has shipped v1.37.0-rc.0, putting the final release on track for the expected August 26, 2026 general availability date. The changelog since v1.36.0 is substantial, touching scheduling, API machinery, device resource allocation, and the container runtime interface.

One of the most anticipated features for this cycle is the general availability of the Metrics API. After a long alpha and beta runway, the API stabilizes the interface that the Horizontal Pod Autoscaler, the Vertical Pod Autoscaler, and third-party monitoring tools rely on to read container and node resource usage. GA status means the API contract is now stable enough for production workloads, and deprecation policies apply. Teams that have been holding off on custom autoscaling solutions built on top of the Metrics API can now treat it as a reliable foundation.

Beyond metrics, 1.37 brings a notable batch of scheduling and workload-aware enhancements:

  • SchedulerPreQueueingHints (beta, on by default): Scheduler plugins can now register a PreQueueingHintFn that narrows the set of pods evaluated on cluster events. The Dynamic Resource Allocation (DRA) plugin implements this to optimize ResourceClaimTemplate-based workloads, reducing unnecessary scheduling churn.
  • CompositePodGroup support in the workloadbuilder library, enabling higher-level orchestration frameworks to coordinate pods as groups rather than individual units.
  • DisruptionMode and PreemptionPolicy fields added to Workload and CompositePodGroup APIs, supporting workload-aware preemption that respects the lifecycle context of the entire pod group.
  • DRA device compatibility groups (alpha): Drivers can declare opaque compatibilityGroups on ResourceSlice devices, and the scheduler rejects incompatible co-allocations at scheduling time rather than surfacing them as runtime failures during preparation.
  • DRA derived attributes (alpha): Claims can define virtual attributes using CEL expressions, enabling co-allocation of devices across different domains — for example, matching a GPU and a NIC on the same NUMA node even if their drivers publish different physical attribute schemas.

On the runtime side, the CRI v1 RuntimeService API gains CheckpointPod and RestorePod RPCs (alpha), opening the door to pod-level checkpoint and restore capabilities that could eventually power faster node drains, live migration experiments, and disaster recovery workflows.

For cluster operators, 1.37 also introduces DefaultPodSysctls (alpha, behind the DefaultPodSysctls feature gate), letting administrators define node-level default sysctl values for pods without requiring every workload manifest to repeat them. This is particularly useful for security-hardened clusters that need consistent kernel parameter tuning.

KYAML: A Stricter, Safer Way to Write Kubernetes YAML

On August 11, 2026, the Kubernetes blog published a deep dive into KYAML, a strict subset of standard YAML that SIG CLI introduced via KEP 5295. The idea is elegant: Kubernetes only needs a small portion of YAML’s full feature set, so why not standardize on that portion and eliminate the footguns?

KYAML is not a new parser or a new file extension. It is a dialect of YAML that every existing parser already understands. The differences are in the writing conventions:

  • All string values are explicitly quoted, eliminating silent type coercion (no more “Norway bug” where NO becomes boolean false).
  • Structure is expressed through braces and brackets rather than whitespace indentation, making diffs cleaner and templating safer.
  • Trailing commas are allowed, unlike JSON.
  • Comments are preserved, unlike JSON.
  • A --- header distinguishes KYAML from JSON at a glance.

Since Kubernetes 1.34, kubectl supports KYAML as a native output format via kubectl get deployment my-app -o kyaml. In 1.35+, it moves to beta and is enabled by default (still requiring the explicit -o kyaml flag). For users who want KYAML everywhere, the kuberc configuration file can set it as the default output format. For bulk conversion, both sigs.k8s.io/yaml/yamlfmt and Google’s yamlfmt (v0.21.0+) now ship dedicated KYAML formatters.

KYAML will not replace standard YAML overnight, but it offers a credible migration path for teams that have been bitten by indentation errors, type coercion surprises, or Helm templating edge cases. It sits halfway between JSON’s explicitness and YAML’s readability — and it is backward-compatible with every tool already in the toolchain.

containerd 2.4 Enters Beta with Runtime and Storage Improvements

On August 10, 2026, the containerd project released v2.4.0-beta.0. As a regular (non-LTS) release, 2.4 carries a shorter support window and may include breaking changes; teams prioritizing stability should remain on the 2.3 LTS line until they have validated the upgrade path.

The headline features in this beta include:

  • Warm image cache support for the erofs snapshotter, reducing cold-start latency for containers using the erofs read-only filesystem backend.
  • Parent path additions to runc checkpoint options, giving checkpoint/restore workflows more control over where state is stored.
  • Media type inclusion in content create events, improving event-driven image supply chain tooling that reacts to new layer pushes.
  • OCI runtime feature introspection for non-runc runtimes in the CRI path, which removes assumptions that every runtime behaves like runc and opens the door to tighter integration with alternative low-level runtimes.
  • klauspost/compress/gzip for image decode, a faster decompression path that should speed up image pull operations.

The release also cleans up several deprecated APIs and removes restore logic from CreateContainer, so operators should review deprecation warnings on their current version before upgrading. The dependency tree has been refreshed across the board, including updates to Cilium’s eBPF libraries, OpenTelemetry SDKs, gRPC, and the Kubernetes CRI API packages (v0.36.3).

AWS Tightens Cross-Account Observability for ECS

AWS published a detailed walkthrough on August 6, 2026, for building a centralized ADOT (AWS Distro for OpenTelemetry) gateway that ingests telemetry from Amazon ECS workloads across multiple accounts. The pattern replaces per-task OpenTelemetry collector sidecars with a single fleet running in a dedicated observability account, accessed via an internal Network Load Balancer and AWS Transit Gateway.

The motivation is practical: sidecars do not scale across large multi-account estates, they add per-task CPU and memory overhead, and they cannot run alongside Windows .NET Framework tasks because the ADOT collector is a Linux container. The gateway model centralizes configuration, reduces drift, and gives platform teams a single point to enforce ingestion policy, batching rules, and cardinality limits.

Telemetry flows from instrumented applications through Transit Gateway to the gateway NLB, then to the ADOT collector fleet, which exports traces to AWS X-Ray and metrics/logs to Amazon CloudWatch via the embedded metric format (EMF). AWS provides a Terraform module and a companion sample repository to deploy the stack, making this pattern reproducible rather than advisory.

The Week in Brief

  • Broadcom / VMware highlighted Kubernetes lifecycle management and performance advancements at KubeCon Europe 2026, continuing the push to make Tanzu a credible enterprise platform alongside Red Hat OpenShift and SUSE Rancher.
  • Subaru published a CNCF case study on using Kubernetes and other cloud native projects to accelerate AI development for its next-generation EyeSight driver-assistance system, claiming 99.999% platform availability across multi-cloud deployments.
  • Keycloak updated its operator to deploy clusters across multiple availability zones within a Kubernetes cluster by default, improving resilience for identity workloads.
  • HDFC Bank was also featured by the CNCF for building an enterprise payment hub on Kubernetes, underscoring the continued expansion of financial services onto cloud native infrastructure.

Sources