CNCF graduated・incubatingプロジェクトのリリースノートのAI分析。
Lima v2.1.4は、いくつかの不具合修正とnerdctlの更新、CLI・テンプレートの小さな改善をまとめたルーティンパッチです。破壊的変更やセキュリティ修正、非推奨化はありません。
CRI-O v1.34.10はバグ修正のみのパッチで、gomaxprocsのCPU注入ロジックの修正と、再起動後のコンテナステータスにおけるImageRef形式のリグレッション修正の2件が含まれます。セキュリティ、API、設定の変更はありません。
etcd v3.6.13は、--listen-client-http-urlsを設定しているクラスタのgRPCリスナーでCRL検証がバイパスされるHIGH深刻度の脆弱性(GHSA-3wh4-j44w-pg92)を修正するセキュリティパッチです。WebSocketのbearerトークン認証の修正と、v2-deprecationフラグへのオプション追加も含まれます。
--listen-client-http-urlsを設定しているクラスタでは、gRPCリスナーで証明書失効リスト(CRL)の検証がスキップされており、失効済みのクライアント証明書でも認証が通ってしまいます。v3.6.13へ更新してください。
etcd v3.5.32は、--listen-client-http-urlsを設定した際にgRPCリスナーでCRLが適用されなかったHIGH深刻度の脆弱性(GHSA-3wh4-j44w-pg92)を修正するセキュリティリリースです。v2-deprecationのバイパスオプション追加やいくつかのバグ修正も含まれます。
--listen-client-http-urlsを設定している場合、gRPCリスナーでCRLが適用されず、失効した証明書が受け入れられる状態でした。mTLSと証明書失効リストを併用している環境では、v3.5.32へ更新してください。
Helm v3.21.2 updates Kubernetes client libraries to match v1.36. This is a routine patch for client library alignment; upgrade to stay compatible with Kubernetes v1.36 clusters.
Helm v3.21.2 updates its Kubernetes client libraries (client-go) to match the v1.36 API. If you already run Kubernetes v1.36 clusters, upgrade Helm to v3.21.2 to ensure full compatibility and avoid potential client-server version skew issues. Teams on earlier Kubernetes versions are not blocked — the upgrade is optional but recommended for consistency.
Lima v2.1.3 is a security-focused patch release fixing two CVEs: a privilege escalation in QEMU VMs and multiple containerd CVEs bundled via nerdctl v2.3.3. Upgrade promptly.
Any unprivileged user inside a QEMU-backed Lima VM could gain root inside that VM by abusing the guest agent socket. If you share Lima VMs among multiple users or run untrusted workloads, this is high priority. Upgrade to v2.1.3 and restart affected VMs.
Five CVEs in containerd are fixed in the bundled nerdctl v2.3.3 (containerd v2.3.2). If your Lima instances run container workloads, the old containerd is exposed. Upgrade Lima and recreate or restart VMs to pick up the new nerdctl binary.
Lima no longer sets containerd.user=true by default on non-Linux guests (macOS, Windows). If you relied on rootless containerd on those platforms without explicitly setting this, validate your VM config after upgrading and set containerd.user=true explicitly if needed.
containerd v2.1.9 is a security-focused patch release fixing 5 CVEs. Upgrade immediately if you run any containerd 2.1.x deployment.
This release closes 5 CVEs in containerd itself. The advisories are not yet public so severity details are unavailable, but 5 CVEs in a single patch release is unusually high. Any team running containerd 2.1.x on production nodes should plan an upgrade this week. Check your Kubernetes node images, managed node groups, and any bare-metal CRI setups.
The bundled runc binary ships as v1.3.6, which likely carries its own fixes. If you manage runc independently (common on Kubernetes nodes), confirm you are also running v1.3.6 or later — upgrading containerd alone will not replace a separately installed runc binary.
Three CRI fixes tighten checkpoint/restore: unexpected archive content is now rejected, re-tagging of restored checkpoints is skipped, and CDI annotations are filtered. If your team uses container checkpointing (e.g., CRIU-based live migration), test restore workflows after upgrading to confirm behavior is unchanged.
containerd 1.7.33 patches two containerd CVEs and one go-jose CVE, updates runc to v1.3.6, and bumps Go. Security-only motivation to upgrade.
Two CVEs in containerd itself (CVE-2026-53488, CVE-2026-47262) and one in go-jose (CVE-2026-34986) are patched here. Full details are in the GitHub security advisories. If you are running containerd 1.7.x in production, upgrade now — there is no other reason to stay on an earlier 1.7.x patch.
A fix was added to prevent reserved labels being propagated from image configs. If your environment relies on label-based access control or policy enforcement, verify that behavior is unchanged after upgrading and check the advisory for CVE-2026-47262 for scope.
The bundled runc binary moves from whatever 1.7.32 shipped to v1.3.6. If you manage runc separately, make sure your installed version is at least v1.3.6 to stay consistent with what containerd expects.
containerd v2.0.10 patches two CVEs (CVE-2026-53488, CVE-2026-47262) and updates runc to v1.3.6. Upgrade promptly if running 2.0.x in production.
CVE-2026-53488 and CVE-2026-47262 are both addressed in this release. The advisories (GHSA-xhf5-7wjv-pqxp and GHSA-jpcc-p29g-p8mq) have full details on impact and scope. Any containerd 2.0.x node running in production should be upgraded to v2.0.10 before assessing whether you're actually exposed — these are runtime-level issues and the blast radius can be broad.
The runc binary shipped with containerd is updated to v1.3.6, which itself carries fixes from v1.3.4 and v1.3.5. If you manage runc separately (e.g., installed via package manager), verify your runc version independently and align it with v1.3.6.
Labels reserved by containerd are now stripped from image configs before use. If you rely on any tooling that reads propagated reserved labels from running containers, test behavior after upgrading — this is a quiet behavioral change that may affect label-based automation.
containerd 2.3.2 is a security-heavy patch release fixing 5 CVEs alongside runtime stability fixes. Upgrade promptly if you're running 2.3.x in production.
Five CVEs are patched in this release, covering containerd's core. The advisories are not yet fully public, but the breadth (5 in one patch) suggests meaningful attack surface. Teams running containerd 2.3.x in any environment should upgrade to 2.3.2 without waiting for the next maintenance window. Check your node provisioning pipelines and update the containerd binary alongside runc (now v1.4.3).
The resolver now retries on transient network errors when the last configured host is tried. This reduces pull failures in flaky network environments without requiring any config change. No action needed, but useful context if you've been seeing intermittent image pull errors under network instability.
A lock in the runc shim was held across the runc create call, causing concurrent RPC timeouts and startup failures when container creation was slow. This is now fixed. If you've seen containers stuck or failing to start under load, this patch likely addresses it.
containerd 2.2.5 is a security-heavy patch release fixing 5 CVEs, with runc bumped to v1.3.6 and Go updated to 1.26.4/1.25.11. Upgrade promptly if running 2.2.x.
This release closes 5 CVEs in containerd itself. Details are in the linked security advisories. Any cluster running containerd 2.2.x should upgrade to 2.2.5. The runc bump to v1.3.6 may also carry its own fixes — check the runc release notes before rolling out.
golang.org/x/crypto jumped from v0.45.0 to v0.53.0 and golang.org/x/net from v0.47.0 to v0.55.0. If you vendor containerd or build plugins against its libraries, re-vendor and rebuild. The crypto jump in particular covers several upstream security fixes across that range.
Three separate CRI fixes land here: CDI annotations are now filtered on checkpoint restore, restored checkpoints are no longer incorrectly re-tagged, and the restore path is hardened against malformed archive content. If you use container checkpoint/restore in production, this release is worth prioritizing.
Helm v4.2.2 reverts a premature exit fix in WaitForDelete that was causing test failures. A one-line patch addressing a race condition in status observation.
The patch that fixed a race condition in WaitForDelete (where the status observer canceled the watch too early) has been reverted in v4.2.2. If you run comprehensive Helm test suites or rely on WaitForDelete behavior, you may see intermittent hangs or timeouts again. Monitor test runs for flakiness after upgrading. A proper fix is likely incoming in a future patch—do not stay on v4.2.2 longer than necessary.
Helm v4.2.1 fixes data races in concurrent operations, corrects output routing for command messages, and resolves version constraint parsing issues that caused false negatives.
Helm command success messages now correctly write to stdout instead of stderr. If your CI/CD pipelines, monitoring, or shell scripts redirect or filter Helm output by stream, they may behave unexpectedly. Check any grep, tee, or output capture logic that assumes helm writes to stderr. Most scripts should work unchanged, but streaming-dependent logic needs review.
Helm 4 previously rejected or warned about valid version range constraints like prerelease versions and missing spaces (e.g., 'v1.0.0||v1.1.0'). This is now fixed. If you've avoided version ranges or used pinned versions as a workaround, you can now adopt constraint-based version selection, which simplifies dependency management in large deployments.
Multiple race conditions in concurrent goroutines (upgrade + rollback, install + uninstall on the same client, and WaitForDelete timing) are now fixed. Teams running high-concurrency Helm operations (e.g., multi-chart deployments, parallel reconciliation loops, or large test suites) should upgrade to eliminate intermittent failures. This is particularly important if you see flaky test results in your CI pipeline.
Helm v3.21.1 fixes a nil pointer panic in template operations and updates dependencies. A straightforward patch for stability.
golang.org/x/net was bumped to v0.55.0 to fix GO-2026-5026. This is a supply-chain dependency, not directly exposed in Helm's API. Upgrade if your security scanning flags net vulnerabilities. No action needed if you're just using Helm normally—the fix is built in.
Helm template commands executed without cluster access (ClientOnly mode) previously crashed with nil pointer panics. v3.21.1 returns proper template errors instead. If you have automation that catches panics, update error handling to expect typed template errors. Test your template workflows before production rollout.
Registry operations now keep credentials when falling back from HTTPS to plain HTTP, thanks to oras-go v2.6.1. If you use private registries with HTTP-only endpoints, this improves reliability. No configuration change needed; the fix is automatic.
Kubernetes v1.36.2 is a patch release fixing critical bugs in Dynamic Resource Allocation (DRA) scheduler, CSI volume republishing, and endpoint controller, plus a Go 1.26.4 build update.
Kubernetes 1.34+ had a regression where containers could not properly read environment variables set from Secret API objects containing binary non-UTF8 data. This is fixed in 1.36.2. If your workloads use non-text Secret data in environment variables, upgrade to prevent decode errors or silent failures.
Kubernetes 1.36.0–1.36.1 has a scheduler bug that assigns mutually exclusive device partitions to multiple Pods when drivers use SharedCounters with multi-allocatable devices. This can cause workload failures, device conflicts, crashes, or data loss. If you use DRA with multi-allocatable devices (especially GPUs or custom accelerators with shared counters), upgrade to 1.36.2 immediately. Review recent Pod scheduling decisions for conflicts.
Kubelet was incorrectly deleting CSI mount directories when periodic NodePublishVolume calls (triggered by requiresRepublish=true) failed, leaving pods with stale volume content. This is fixed in 1.36.2. If you run CSI drivers with requiresRepublish=true, this patch eliminates a data consistency risk—upgrade to prevent potential data issues on transient network or storage errors.
Kubernetes v1.35.6 fixes critical issues in pod scheduling with multi-node claims, DRA device selection, CSI volume republishing, and endpoint handling; includes a Go runtime upgrade and performance improvements.
A 1.34+ regression broke environment variable injection from Secrets containing non-UTF8 binary data (e.g., certificates, keys in base64-encoded Secrets). If you inject Secrets as env vars and those Secrets contain binary data, upgrade to v1.35.6. Test this quickly if you run database credentials or keys via Secrets—the bug may have silently broken injection.
Kubernetes v1.35.6 is built with Go 1.25.11. If you run custom controllers or operators on the same Go version, verify compatibility and rebuild. If your CI/CD locks Go versions, update your build configuration. This is standard but must be done; old Go versions may have security gaps you're inheriting.
Three bugs are fixed: (1) scheduler no longer panics on DRA ResourceClaim with AllocationMode All and shared counters; (2) pods using multi-node and per-node claims no longer deadlock in Pending; (3) kubelet no longer deletes CSI mount directories on transient NodePublishVolume errors, preventing stale volume data. If you use DRA (dynamic resource allocation) or CSI with republish enabled, this release eliminates previously deadlocking scenarios. Upgrade to clear stuck pods and prevent future hangs.
Kubernetes v1.34.9 fixes volume handling in CSI mounts, binary secret data in containers, endpoint controller panics, and kubeadm certificate handling. Go 1.25.11 build improves runtime performance.
A 1.34+ regression caused kubelet to delete CSI mount directories on republish failures, stranding pods with stale volume data. If you run CSI drivers with spec.requiresRepublish=true, upgrade immediately. Check your CSI driver specs and watch for failed republish attempts in kubelet logs before upgrading to confirm you hit this bug.
v1.34 broke environment variable parsing for containers referencing Secrets with binary (non-UTF8) data. If your workloads inject Secret data into environment variables, test them after upgrading. Check application startup logs for parsing errors; you may need to base64-encode binary Secret values instead.
v1.34.9 uses Go 1.25.11, which includes runtime optimizations and security patches. Upgrade when you next rotate your control plane and worker nodes. No code changes needed on your side, but the Go update may improve latency and reduce memory usage in your cluster.
CoreDNS v1.14.4 delivers a broad set of targeted fixes and new capabilities: DNSSEC signing correctness fix, cache behavior improvements, forward plugin now resolves hostnames, and several transport security hardening items.
The fix to sign each RRset with its owning zone rather than the query zone is technically correct, but if you have multi-zone DNSSEC setups with delegations, validate your signed responses after upgrading. Zones that were relying on the previous (incorrect) signing behavior may produce different signatures. Run dnssec-verify on a sample of records before cutting over in production.
The forward plugin now resolves hostnames for TO endpoints at runtime. If your CoreDNS configs currently pin upstream resolver IPs, you can switch to FQDNs and let CoreDNS handle resolution. This simplifies config management in environments where upstream IPs change (e.g., cloud-managed resolvers). Test in staging first — resolution failures at startup could affect forwarding.
Cache TTLs were previously capped at 3600s regardless of the DNS record's actual TTL. That cap is gone. For stable records (root hints, internal authoritative zones) you can now set higher max_ttl values to reduce upstream query load. Audit your cache plugin config and raise max_ttl where it makes sense.
CRI-O v1.35.4 is a patch release with no code changes or dependency updates from v1.35.3 — essentially a rebuild or re-tag of the previous patch.
There are zero changelog entries and zero dependency changes. This release is likely a rebuild triggered by a CI/pipeline issue or a signing/artifact correction. If you're already on v1.35.3 and it's working, there's no functional reason to upgrade. Check the CRI-O GitHub issue tracker or release PR for context on why this tag was cut before deciding to roll it out.
Even for a no-change release, practice your supply chain verification workflow: use cosign to verify the signature on the tarball and the bom tool to validate the SPDX SBOM. This is good hygiene to establish before you need it on a critical release.
CRI-O v1.36.1 is a small patch fixing a container status regression where ImageRef flipped to a raw image ID after restart, plus a debug log verbosity reduction.
Before this fix, CRI-O restarts caused ImageRef in container status to switch from a repo@digest string to a raw image ID. Any tooling that parses ImageRef — admission controllers, audit pipelines, image policy enforcers — could silently receive the wrong format and fail validation or produce incorrect audit records. If you run workloads where CRI-O restarts are common (e.g., upgrades, node reboots), patch to v1.36.1 immediately and validate your tooling handles the repo@digest format consistently.
Clusters with aggressive monitoring or reconciliation loops generating frequent ListContainers/ListPodSandboxes calls were generating excessive debug log volume, which hurt CRI-O performance under high load. After this patch, debug logging is less chatty for these paths. If you previously reduced log levels specifically to work around this noise, you can now safely re-enable debug logging without the same overhead.
CRI-O v1.34.9 fixes two concurrency bugs: a panic from racing StopContainer calls and a spurious exit code 255 on fast-exiting containers. Pure bug-fix release, no dependency changes.
If your cluster drains nodes, runs batch workloads with rapid pod churn, or uses any automation that issues multiple StopContainer calls in parallel, the pre-fix versions could panic CRI-O, taking down the container runtime on that node. This is a hard crash, not a graceful error. Upgrade to v1.34.9 immediately on any node where concurrent stop operations are plausible.
Exit code 255 is often treated as a runtime-level failure in monitoring stacks and can trigger unnecessary pod restarts or alerts. If you have OOMKill or fast-exit workloads (init containers, short-lived jobs) and have seen spurious 255 exit codes in your logs or metrics, those were false positives from this race. After upgrading, audit your alerting rules and CrashLoopBackOff history — you may find some pods were incorrectly flagged.
Single-fix patch release resolving a race condition that caused CRI-O to incorrectly report exit code 255 for fast-exiting containers.
If your monitoring, alerting, or restart policies key off exit code 255, you may have been misclassifying fast-exiting containers as crashed. After upgrading, audit any runbooks or OOMKill/CrashLoopBackOff workflows that treat exit code 255 as a specific signal — the real exit codes from short-lived containers will now surface correctly.
This is a clean drop-in replacement for v1.33.12. No dependency bumps, no config changes required. Plan a rolling node drain and replace the CRI-O binary. Prioritize nodes running batch jobs, init containers, or short-lived workloads where fast exits are common and exit code accuracy matters most.
Security patch release fixing CVE-2026-46680 plus runtime bugs in sandbox service, AppArmor compatibility, and OCI USER spec handling.
CVE-2026-46680 is the primary driver for this release. Review the GHSA advisory to understand the attack surface and severity. If you run containerd 2.1.x in any environment, upgrading to 2.1.8 should be your next deployment task. There are no dependency changes, so the upgrade path is straightforward.
Previously, out-of-range USER values in OCI specs could silently fall through to username/group lookups, masking misconfigurations. Now containerd returns an explicit error. If any of your containers or image builds set numeric USER values outside valid UID/GID ranges, they will start failing visibly after this upgrade. Audit your specs before rolling out to production.
The conditional AppArmor abi fix is a real blocker for anyone on older AppArmor (e.g., Ubuntu 20.04 ships 2.x). The sandbox service bug also affects event-driven workflows and correct sandbox creation — silent misconfiguration is worse than a visible error. If you use Kata Containers or any sandbox-based runtime, this fix directly affects you.
etcd v3.6.12 is a patch release in the 3.6 series. The release notes are sparse — check the full CHANGELOG for specifics before upgrading.
The release notes for v3.6.12 are essentially empty — no changes are listed inline. Before upgrading any etcd cluster, pull the full CHANGELOG-3.6.md from the repo and review all entries since your current version. The official upgrade guide explicitly warns of potential breaking changes in the 3.6 series.
etcd maintains two registries: gcr.io is primary, quay.io is secondary. If your CI/CD or deployment manifests pin to quay.io, confirm it stays in sync with the primary. For production clusters, prefer gcr.io/etcd-development/etcd to avoid lag.
etcd v3.5.31 is a patch release on the 3.5 branch. Release notes are minimal — check the full CHANGELOG for specifics before upgrading.
The etcd team explicitly calls out that breaking changes can appear in patch releases. Don't skip the upgrade guide assuming this is safe to apply blindly. Verify any API or storage format changes against your current deployment before scheduling maintenance.
The release notes published here are sparse. Before rolling this out, pull the full CHANGELOG-3.5.md directly from the etcd repo to identify any bug fixes or behavioral changes that affect your cluster. Patch releases on 3.5 have historically included compaction fixes and lease handling improvements — worth verifying what specifically landed here.
etcd v3.4.45 is a maintenance release on the 3.4 branch. Release notes are sparse — check the full CHANGELOG for specifics before upgrading.
The release explicitly flags that breaking changes may exist. Etcd 3.4.x is a mature but still-active branch used heavily in Kubernetes clusters. Verify the upgrade guide at etcd.io before rolling this out, especially in production environments where quorum and data integrity are non-negotiable.
This release page contains almost no detail. Before upgrading, pull up CHANGELOG-3.4.md directly in the etcd GitHub repo to understand what actually changed. Blind upgrades on etcd — your cluster's source of truth — are a bad idea regardless of how minor a patch looks.
Lima v2.1.2 is a broad maintenance release fixing hostagent resource leaks, zombie processes, and gRPC connection leaks — plus template updates for Kubernetes 1.36, Ubuntu 26.04, and Fedora 44.
The generic `template:alpine` has been split into `template:alpine-3.21`, `template:alpine-3.22`, and `template:alpine-3.23`. If you reference `template:alpine` in scripts, CI, or configs, those references will break. Audit and update them to a specific versioned template before upgrading.
If you have the `_LIMA_QEMU_UEFI_IN_BIOS` environment variable set in any scripts or dotfiles, remove it now. The flag is deprecated in this release and will likely be removed in a future version. Check wrapper scripts and CI pipelines that invoke limactl with QEMU.
Four separate hostagent fixes address GuestAgentClient leaks, inotify watcher accumulation, and gRPC stream mishandling on reconnect. If you've seen memory creep or stale connections in long-running Lima instances, this release directly addresses those issues. Upgrade proactively rather than waiting.
containerd v2.2.4 is a security-focused patch release addressing two CVEs plus several runtime fixes for overlay, sandbox, AppArmor, and seccomp behavior.
Two CVEs are fixed here: one in containerd itself (CVE-2026-46680) and one in the go-jose dependency (CVE-2026-34986). Both affect production deployments. Don't wait for your next maintenance window — push this update through your standard emergency patch process. If you run containerd on Kubernetes nodes, this applies to all container runtimes backed by containerd regardless of the orchestrator.
The default seccomp profile now blocks AF_ALG (kernel crypto API via sockets). This reduces attack surface, but any workload relying on AF_ALG sockets — unusual but possible in cryptography-heavy or hardware-offload scenarios — will start seeing syscall denials. Run a quick audit of workloads with custom or permissive seccomp profiles before upgrading in production.
If you run rootless containers or pods using user namespaces with the overlay snapshotter, the previous 'rebase' capability caused layer extraction failures. This patch disables that capability automatically in UserNS contexts. No config change needed — just upgrade and verify your rootless workloads mount correctly post-update.
containerd 2.0.9 patches CVE-2026-46680 and fixes a TOCTOU race in tar extraction, lost container exit events on restart, and several security hardening issues.
A security vulnerability tracked as CVE-2026-46680 is fixed in this release. Any containerd 2.0.x deployment should be upgraded to 2.0.9 immediately. Check the GHSA advisory for affected configurations and severity before scheduling maintenance windows — this shouldn't wait.
The TOCTOU race during tar extraction could be exploited with a crafted image layer to escape expected paths. This is relevant for any environment pulling untrusted or third-party images. Upgrade and consider auditing your image pull policies if you haven't already restricted sources.
The AppArmor ABI field is now set conditionally, so systems running AppArmor older than 3.0 won't have an incompatible ABI injected into generated profiles. If you've been working around this with custom profiles, test your AppArmor setup after upgrading to confirm behavior is as expected.
If you've seen containers stuck in unexpected states after a containerd restart — particularly in Kubernetes environments with rapid pod cycling — this fix addresses the root cause. No config change needed; upgrading is enough.
containerd 1.7.32 is a security-focused patch addressing CVE-2026-46680, plus hardening the default seccomp profile by blocking AF_ALG sockets and fixing OCI spec USER handling.
CVE-2026-46680 is the primary driver for this release. Details are in the containerd security advisory. If you're running any 1.7.x version, treat this as a mandatory upgrade. Check the advisory for severity and attack surface before deciding on your maintenance window — but don't defer this long.
The default seccomp policy now blocks the AF_ALG (kernel crypto) socket family. Containers relying on AF_ALG for hardware crypto offloading will break after this upgrade. Audit your workloads — most standard containers won't be affected, but custom crypto or HSM-adjacent workloads might. If needed, override via a custom seccomp profile rather than relaxing the default.
Previously, an out-of-range UID/GID in the OCI spec could silently trigger name lookups with unpredictable results. Now containerd returns an error. If you have images or specs with numeric USER values outside valid range, containers will fail to start instead of behaving unexpectedly. Run a pre-upgrade check on your image inventory, especially anything using high numeric UIDs.
If you're running containerd on Ubuntu 20.04, Debian Bullseye, or any distro shipping AppArmor 2.x, earlier 1.7.x releases may have caused AppArmor profile load failures. This fix conditionally omits the abi directive. Upgrade and verify AppArmor profile loading if you've been seeing related errors.
containerd 2.3.1 patches CVE-2026-46680 and fixes several runtime/snapshotter bugs including seccomp hardening that blocks AF_ALG sockets by default.
CVE-2026-46680 is fixed in this release. Details are in the containerd security advisory. If you're on 2.3.0, treat this as a mandatory upgrade. Check your package manager or deployment pipeline to roll out 2.3.1 across all nodes before the vulnerability details are widely circulated.
The default seccomp profile now blocks AF_ALG (Linux kernel crypto API via sockets). Most containerized applications won't touch this, but anything using AF_ALG directly for cryptographic operations will break. Before upgrading in production, verify your workloads don't rely on AF_ALG — run a quick strace or audit your application's socket calls. Custom seccomp profiles are unaffected.
The sandbox task API endpoint fix and deprecation of task fields in Runc options targets non-runc runtime setups (e.g., Kata Containers, gVisor). If your cluster uses alternative runtimes, validate that container creation and task management still work as expected post-upgrade. The deprecation of task fields means you should audit any custom Runc options configs to remove deprecated fields before they're removed in a future version.
Patch release fixing sandbox task API endpoints broken for non-runc shims — critical for anyone running alternative runtimes like Kata Containers or gVisor.
The bug in api/v1.11.0 caused sandbox task API endpoints to malfunction for any shim that isn't runc — think Kata Containers, gVisor, or custom shims. If your cluster uses these runtimes and you're on 1.11.0, task operations against sandboxed workloads may silently fail or misbehave. Update to api/v1.11.1 immediately and verify task lifecycle operations (create, delete, exec) work correctly post-upgrade.
The fix adds the task API address to CreateTaskRequest at the proto level. If you maintain a custom shim, review whether your implementation reads this field — it's now populated where it wasn't before. No action needed for standard runc workloads, but non-standard shim authors should test task creation flows against this API version.
Helm v3.21.0 bumps Kubernetes client libs to v1.36, patches OpenTelemetry CVEs, fixes OCI index chart pulling, and corrects nil value preservation in chart merging. Helm v3 EOL is approaching.
OpenTelemetry packages were patched specifically to address CVEs. If you're running Helm in CI/CD pipelines or as part of automation tooling, upgrade to v3.21.0 now. Don't wait for the next patch release.
The release explicitly warns that Helm v3 is approaching end-of-life. This is not a distant concern — v3.22.0 targets Kubernetes v1.37 and v3.21.1 is just a bug fix release. Start evaluating Helm v4 changes now, especially if you maintain custom plugins or automation built around Helm's CLI or Go SDK.
The fix for pulling charts from OCI indices means setups using image index manifests (common in multi-arch environments) should now work reliably. If you previously worked around this with direct digest references or manifest-specific tags, revisit those workarounds — they may no longer be necessary.
Helm v4.2.0 ships Kubernetes 1.36 client support, a new mustToToml template function, fixes for dry-run server mode with generateName, and several post-renderer YAML parsing correctness fixes.
Both flags are now deprecated and will likely be removed in a future release. Audit your helm install/upgrade/template invocations in CI pipelines and scripts. Dropping them now avoids a forced migration later when they're removed entirely.
The new mustToToml function behaves like mustToJson — it returns an error instead of silently failing when TOML serialization goes wrong. If you're using toToml anywhere in your chart templates, swap it for mustToToml so template rendering failures are surfaced as actual errors rather than empty or malformed output.
Previously, --dry-run=server skipped resources that used generateName instead of name, which gave false confidence that those resources were being validated. That's fixed now. Re-run your server-side dry-run checks against any charts that use generateName — you may catch validation errors that were previously being silently ignored.
Kubernetes v1.36.1 is a focused patch release fixing 8 bugs across networking, node, and cluster lifecycle — most impacting Windows environments, ZFS nodes, and kubeadm-managed clusters.
kubelet fails to start on ZFS-backed nodes in v1.36.0 due to a missing cadvisor plugin. If you deployed v1.36.0 on ZFS storage, those nodes are likely not running. Patch to v1.36.1 before any further ZFS node rollouts.
Stale HNS endpoints caused traffic to route to wrong nodes when pod IPs were reused, producing silent DNS failures. This is hard to diagnose and easy to misattribute to DNS config. If you run Windows nodes with L2Bridge networking, treat this as a high-priority patch.
Previously, kubeadm init could fail or behave unexpectedly when the control plane load balancer wasn't ready yet. The fix makes bootstrap use the local API endpoint first, then defer to the LB endpoint — a meaningful improvement for cloud environments where the LB provisions asynchronously. Worth upgrading before your next cluster init or upgrade cycle.
Kubernetes v1.35.5 is a focused patch release fixing scheduler state corruption, Windows networking, kube-proxy large-cluster behavior, and several kubeadm initialization issues.
The kubeadm init change to use localAPIEndpoint for admin.conf and super-admin.conf is a behavioral fix, but clusters with custom controlPlaneEndpoint setups should validate that kubeconfigs are generated correctly after upgrading. If you rely on the controlPlaneEndpoint in generated configs for post-init tooling, test in staging first.
If you're running 1000+ endpoints, kube-proxy was previously triggering full-sync operations it shouldn't. This patch stops that. The fix directly reduces CPU and network overhead on busy clusters — upgrade kube-proxy as part of your next maintenance window.
The scheduler bug with in-flight state tracking could cause unbounded growth in memory usage when pods with reused names fail scheduling repeatedly. If you've observed scheduling delays or growing scheduler memory consumption, this patch addresses the root cause directly.
v1.34.8 is a focused bug-fix patch addressing IPv6 CIDR allocation errors, a scheduler memory leak, Windows DNS routing failures, and several kubeadm cluster lifecycle issues.
The kube-apiserver's kubelet client is now bound to 'system:kubelet-api-admin' instead of a shared role. For kubeadm-managed clusters, re-running 'kubeadm init phase bootstrap-token' or upgrading via kubeadm will apply this change. Existing clusters upgraded in-place will get this tighter RBAC scoping automatically — verify with 'kubectl get clusterrolebinding' post-upgrade.
The 64-bit IPv6 ServiceCIDR bug means some clusters may have services with IPs that technically fall outside the configured subnet. After upgrading to v1.34.8, check whether any existing service IPs are out-of-range and consider recreating affected services. This primarily impacts clusters using /64 IPv6 service CIDRs.
If you're running clusters with 1000+ endpoints, kube-proxy was performing expensive full-sync operations unnecessarily in large-cluster mode. This patch stops that. The benefit is lower CPU and latency spikes during endpoint churn. No config changes needed — upgrade and monitor kube-proxy CPU usage to confirm the improvement.
