リリース

日本語 準備中containerd 2.3.0 is the first LTS release under the new Kubernetes-aligned 4-month cadence, offering 2+ years of support with major NRI, EROFS, and observability improvements.

• breakingRename NRI plugins with commas in their names before upgrading

  The new OCI hook owner accumulation logic uses commas as delimiters internally, so any NRI plugin whose name contains a comma will break. Audit your NRI plugin names now. If any contain commas, rename them before rolling out 2.3.0 — this affects both the plugin binary name and any configuration referencing it.

• enhancementPlan your 1.7 → 2.3 LTS migration now

  This is the designated upgrade target from containerd 1.7 LTS. The project explicitly tests and supports direct sequential LTS-to-LTS upgrades. If you're still on 1.7, this is the right time to build a migration plan — 2.3 gets at least two years of support, making it the stable foundation for Kubernetes clusters through roughly 2027.

• enhancementEnable trace propagation for better plugin and runtime observability

  OTel traces now flow through gRPC RPCs between containerd and its plugins, and trace IDs can be injected into log lines. If you run a distributed tracing stack (Jaeger, Tempo, etc.), configure the OTLP exporter in containerd's config and enable trace ID injection in logging. This closes a major gap where container lifecycle events were invisible to your tracing backend.

日本語 準備中containerd API v1.11.0 ships a new shim bootstrap protocol, container filesystem copy transfer types, and sandbox spec field support — aligning with the containerd 2.3 runtime release.

• securitygRPC updated from v1.59.0 to v1.79.3 — multiple CVE fixes included

  A 20-minor-version jump in gRPC covers a significant span of security and stability fixes. If your environment pins or vendors gRPC separately, reconcile your dependency tree against v1.79.3. The golang.org/x/* packages also moved forward across the board, so a full dependency audit is warranted before deploying this API version in production.

• breakingSandbox API: Container field removed, update any sandbox metadata consumers

  The Container field has been dropped from sandbox metadata and replaced with a spec field. If you have tooling, controllers, or custom runtimes that read or write sandbox metadata directly, audit them now. This is an API-level change — anything compiled against the old proto definitions will break at runtime when targeting containerd 2.3.

• breakingShim bootstrap protocol is now protobuf — custom shim implementations need updating

  The new shim bootstrap protocol switches from JSON to protobuf and uses enums instead of strings for capabilities and log levels. If you maintain a custom shim or vendor the containerd API, you must update your bootstrap handling before deploying containerd 2.3. Third-party shims (e.g., kata-containers, nydus) likely need corresponding releases — check their compatibility before upgrading.

日本語 準備中Kubernetes v1.36 is a large release with multiple GA promotions, significant DRA expansions, new gang-scheduling APIs, and several metric renames that require immediate action before upgrading.

• breakingUpdate monitoring before upgrading: two metric renames

  The metrics `volume_operation_total_errors` and `etcd_bookmark_counts` have been renamed to `volume_operation_errors_total` and `etcd_bookmark_total` respectively. Any Prometheus alerts or Grafana dashboards using the old names will silently stop firing after upgrade. Audit your monitoring stack and update all references before rolling out v1.36 to production.

• breakingDRA RBAC changes required if using DRAResourceClaimGranularStatusAuthorization

  The `DRAResourceClaimGranularStatusAuthorization` feature gate is beta and on by default in v1.36. DRA schedulers and controllers now need explicit `update`/`patch` on `resourceclaims/binding`, and DRA drivers need `associated-node:update` or `arbitrary-node:update` on `resourceclaims/driver` scoped to their specific `resourceNames`. If you run DRA drivers, audit and update their RBAC manifests before upgrading, or pods will fail to schedule.

• breakingflex-volume and git-repo volume plugin removals

  kubeadm no longer mounts the flex-volume plugin directory automatically, and the git-repo volume plugin is permanently disabled. If any workloads still use git-repo volumes, they will stop working — there's no flag to re-enable it. Migrate to an init container pattern or a CSI driver. For flex-volumes in kubeadm environments, you must manually configure extraVolumes and a non-distroless KCM image before upgrading to v1.36.

• breakingStrictIPCIDRValidation on by default — check your IP/CIDR fields

  API fields now reject IPs with leading zeros (e.g., `010.0.0.1`) and CIDRs with host bits set (e.g., `192.168.1.5/24` instead of `192.168.1.0/24`). Existing objects are preserved via validation ratcheting, but new creates and updates will fail if they use these formats. Audit your manifests, Helm charts, and automation for non-canonical IP/CIDR values before upgrading.

• enhancementMutatingAdmissionPolicy is now GA — consider replacing webhook boilerplate

  MutatingAdmissionPolicy (CEL-based mutation) is now v1 and enabled by default. If you're running simple mutating webhooks that set defaults or inject labels/annotations, this is a good time to evaluate replacing them with MutatingAdmissionPolicy resources. CEL-based policies eliminate the need to maintain webhook servers, certificates, and availability concerns. Start with low-risk, stateless mutations.

日本語 準備中CoreDNS v1.14.3 ships full TSIG verification across all transports, multiple Go security CVE fixes, cache prefetch improvements, and a new forward plugin max_age option — a solid operational hardening release.

• securityUpgrade immediately for 13 Go CVE fixes and TSIG transport hardening

  Go 1.26.2 in this build addresses 13 CVEs. Beyond the runtime fixes, TSIG verification gaps in DoH, DoH3, QUIC, and gRPC transports are now closed — if you run any of those transports with TSIG, unauthenticated requests could previously slip through. Upgrade to v1.14.3 and verify your TSIG configurations are still valid after the stricter enforcement.

• breakingDoH oversized GET requests are now rejected — validate your clients

  CoreDNS now rejects oversized dns query parameters in DoH GET requests. Any client sending unusually large DNS-over-HTTPS GET queries will start getting errors. Test your DoH clients against this build in staging before rolling out; most well-behaved clients are unaffected, but custom or non-standard DoH implementations should be checked.

• enhancementUse max_age in the forward plugin to prevent stale upstream connections

  Long-lived upstream connections can silently degrade or get dropped by middleboxes. The new max_age option in the forward plugin lets you set an absolute connection lifetime. If you've seen sporadic upstream timeouts or resolution failures that resolve themselves, configure max_age to force periodic reconnection — start with something like 30s–5m depending on your upstream stability.

日本語 準備中v1.33.11 is a targeted patch fixing two networking bugs — apiserver startup failures with MultiCIDRServiceAllocator and kube-proxy nftables breakage on nft 1.1.3 — plus a Go 1.25.9 compiler bump.

• breakingUpgrade now if using MultiCIDRServiceAllocator with large clusters

  If you have MultiCIDRServiceAllocator enabled and a large namespace count, apiserver can fail to start during an upgrade — it was hitting Forbidden errors from admission plugins that weren't ready yet and not retrying. This patch makes that retry happen. If you've been deferring upgrades to 1.33 because of this, you're now unblocked. Check your apiserver logs for 'Forbidden' errors from the IP repair controller as a diagnostic signal.

• breakingkube-proxy nftables mode is broken on nft 1.1.3 — patch immediately

  Systems running nft 1.1.3 (which ships in some recent distro releases) will have silently broken kube-proxy nftables mode. Traffic may appear to work at first but rule updates won't apply correctly. If your nodes run nft 1.1.3, either pin to an older nft version as a workaround or — better — upgrade to this patch release. Run 'nft --version' on your nodes to check.

• enhancementOTel dependency jump to v1.41.0 — validate your observability pipeline

  The OpenTelemetry Go SDK went from v1.33.0 to v1.41.0 in this patch, which is a substantial version range. If you're consuming Kubernetes telemetry data or running sidecars that interact with the OTel SDK, verify compatibility with your collectors and backends after upgrading. No functional changes are documented for Kubernetes itself, but the jump is large enough to warrant a smoke test of your tracing and metrics pipelines in a non-prod environment first.

日本語 準備中v1.34.7 is a focused patch release fixing two regressions — audit log latency annotations and nftables kube-proxy compatibility — plus a Go 1.25.9 rebuild.

• breakingAudit log latency data was silently missing — patch if you rely on it

  Any 1.34.x cluster prior to this patch has been dropping the request latency annotation from audit logs whenever a request exceeded 500ms. If your security or compliance tooling parses these annotations for SLO tracking or anomaly detection, your data has gaps. Upgrade to v1.34.7 and consider whether historical audit logs need to be flagged as incomplete for that window.

• breakingnftables kube-proxy is broken on nft 1.1.3 — don't skip this patch

  Clusters running kube-proxy in nftables mode on nodes with nft 1.1.3 (common in newer distros like Fedora 42 or Ubuntu 25.04) have non-functional networking. This isn't a performance issue — it's a hard failure. Either pin nft to an older version as a workaround or upgrade to v1.34.7 immediately. The fix is in the knftables library bump (v0.0.17 → v0.0.21).

• enhancementOTel dependency jump to v1.41.0 — verify your tracing integrations

  The OpenTelemetry Go packages moved from v1.35.0 to v1.41.0, which is a substantial jump. If you have custom instrumentation or sidecars that interact with Kubernetes' OTel spans, test in staging first. The change is backward-compatible in the API but internal behavior around span propagation and metric collection has evolved.

日本語 準備中v1.35.4 is a focused patch fixing five real-world bugs: sidecar container restart failure, StatefulSet parallel scaling regression, kube-proxy nftables breakage, and audit log latency annotation errors.

• breakingCheck StatefulSet workloads if you rely on MaxUnavailable rolling behavior

  The MaxUnavailableStatefulSet feature gate is now disabled by default in 1.35.4, reversing behavior introduced earlier in 1.35. If you upgraded to 1.35.x expecting parallel pod management with maxUnavailable, that behavior is gone until the feature stabilizes. Audit your StatefulSet specs: if you set maxUnavailable, it will be silently ignored. Plan accordingly before upgrading, and watch for the gate to re-enable in a future minor.

• breakingSidecar + startupProbe combination was silently broken — upgrade promptly

  Any pod using an initContainer with restartPolicy: Always alongside a startupProbe would silently fail to restart crashed containers after a kubelet restart, showing RestartCount: 0 forever. This affects production workloads relying on sidecars (e.g., service mesh proxies, log shippers). If you've seen pods stuck in this state, upgrading to 1.35.4 and then manually deleting/recreating affected pods is the remediation path.

• enhancementUpgrade kube-proxy if running nft 1.1.3 on nodes

  Systems with nft (nftables) version 1.1.3 were broken in kube-proxy's nftables mode. This is a quiet but hard failure — networking simply doesn't work. If you're on newer distros shipping nft 1.1.3 (some recent Debian/Ubuntu variants), prioritize this patch upgrade for your node components.

日本語 準備中containerd v2.2.3 patches CVE-2026-35469 in spdystream and fixes several bugs including whiteout handling in parallel unpacks, TOCTOU race in tar extraction, and Go 1.24 symlink regressions.

• securityPatch CVE-2026-35469: upgrade to v2.2.3 now

  CVE-2026-35469 affects moby/spdystream, which containerd uses for streaming connections. The fix is in spdystream v0.5.1, bundled in this release. If you're running any 2.2.x version, treat this as a mandatory upgrade — don't wait for your next maintenance window.

• breakingParallel unpack whiteout bug could mean corrupted layer state — verify images

  A bug caused whiteout files (which signal file deletions between layers) to be ignored when parallel unpack was enabled. If you've been using parallel unpack with overlayfs, layer deletion semantics may not have applied correctly. After upgrading, re-pull any images that were unpacked in parallel to ensure their layer state is consistent.

• enhancementGo 1.24 users on NixOS or symlink-heavy rootfs: this fixes your container startup failures

  Absolute symlink handling in rootfs user/group lookups regressed with Go 1.24. This affected systems where /etc/passwd or /etc/group are symlinks (common on NixOS-style setups). If you've seen user lookup failures or container start errors after moving to Go 1.24-built binaries, upgrading to v2.2.3 resolves this.

日本語 準備中containerd 2.0.8 patches CVE-2026-35469 in spdystream, fixes a credential leak in CRI error messages, and resolves a CNI DEL lifecycle bug after containerd restarts.

• securityPatch CVE-2026-35469 by upgrading to 2.0.8 now

  CVE-2026-35469 lives in the moby/spdystream dependency. Details are in a GitHub security advisory. If you're running containerd 2.0.x in any cluster, upgrade to 2.0.8 — this is the primary reason for the release. Don't wait for your next maintenance window if the advisory turns out to be high severity.

• securityCheck your pod event logs for past credential exposure

  Before this fix, registry credentials or other secrets embedded in URLs could appear in plaintext inside CRI gRPC error messages and pod events. If you're shipping pod events to a logging backend (Datadog, Splunk, ELK, etc.), audit recent logs for query parameters that shouldn't be there. Going forward, 2.0.8 redacts these before they leave containerd.

• breakingValidate CNI network cleanup works correctly after upgrading

  The CNI DEL bug meant network namespaces and CNI plugin state weren't cleaned up when a pod was deleted after a containerd restart. This could leave stale network state on nodes. After upgrading to 2.0.8, verify that pod deletion properly invokes CNI DEL — especially on nodes that have experienced containerd restarts. If you've noticed orphaned network interfaces or IP allocation issues, this fix is the likely culprit.

日本語 準備中containerd 2.1.7 patches CVE-2026-35469 in spdystream and ships several hardening fixes including credential leak prevention via gRPC and a TOCTOU race in tar extraction.

• securityPatch CVE-2026-35469 by upgrading to 2.1.7 now

  CVE-2026-35469 in moby/spdystream is fixed in this release. spdystream is used in the CRI streaming path, so any cluster running Kubernetes workloads with exec/attach/port-forward is potentially exposed. Upgrade containerd to 2.1.7 on all nodes. No config changes needed, just a binary swap and daemon restart.

• securityCredential leak via gRPC pod events is now closed

  Before this fix, raw errors containing registry credentials could surface in pod events visible to namespace-scoped users. If your clusters allow broad pod event access, assume credentials may have been exposed in logs or event streams. Rotate any registry pull secrets used on affected clusters, then upgrade to 2.1.7 to prevent recurrence.

• enhancementCNI DEL fix prevents IP/resource leaks after restarts

  A bug meant CNI DEL was never called for sandboxes cleaned up after a containerd restart, leaking network resources. If you've seen stale IPs or CNI state after node restarts, this is likely why. Upgrade to 2.1.7 and consider draining nodes before restarting containerd to clear any existing leaked state.

日本語 準備中v1.7.31 patches CVE-2026-35469 in spdystream, fixes a CNI DEL regression after restarts, and closes a credential leak in pod events via gRPC error sanitization.

• securityPatch CVE-2026-35469 by upgrading to v1.7.31 now

  CVE-2026-35469 affects the moby/spdystream library used for SPDY multiplexing. The fix is in spdystream v0.5.1, bundled here. If you're running any 1.7.x release prior to this, upgrade immediately — especially on clusters where the CRI streaming server is exposed or where kubectl exec/attach/port-forward traffic flows through containerd.

• securityAudit pod event logs for previously leaked credentials

  A bug caused raw error messages — potentially containing registry credentials — to be returned over gRPC and surface in pod events. After upgrading, review historical pod event logs (kubectl get events, or your log aggregation system) for any entries containing auth tokens, passwords, or image pull secrets from before this fix was applied. Rotate any credentials you find.

• breakingVerify CNI network teardown is working correctly after upgrade

  The CNI DEL fix means containers that previously left behind stale network state after a containerd restart will now properly clean up. This is the right behavior, but if you have automation or scripts that assumed CNI DEL was idempotent-by-absence (i.e., expected cleanup to be skipped), test those workflows. Nodes with a history of unclean restarts may see cleanup activity on first pod deletion post-upgrade.

日本語 準備中Security-only patch fixing a path traversal vulnerability in chart extraction. Upgrade immediately if you pull charts from untrusted sources.

• securityPatch a chart extraction path traversal — upgrade now

  A crafted Chart.yaml using dot-segments (e.g., '..') in the chart name could cause Helm to write files outside the intended extraction directory. This is a classic directory traversal attack vector. If your pipelines pull charts from public repos, third-party registries, or any source you don't fully control, treat this as critical and upgrade to v3.20.2 today. Teams operating fully air-gapped with only internally authored charts have lower immediate risk, but should still upgrade on the next maintenance window.

日本語 準備中Helm v4.1.4 is a security-only patch fixing three vulnerabilities: chart extraction path traversal, plugin signature bypass, and plugin version path traversal enabling arbitrary file writes.

• securityUpgrade immediately — all three CVEs are exploitable via untrusted input

  Two of these bugs (chart extraction collapse and plugin version path traversal) allow writing files to arbitrary locations on the filesystem. The third lets anyone install an unsigned plugin if they control the distribution channel. If your CI/CD pipeline pulls charts or plugins from external or semi-trusted sources, you are exposed on any Helm version before this patch. Upgrade to v4.1.4 (or v3.20.3 when released April 8) now. Don't wait for a maintenance window.

• securityAudit your plugin sources before upgrading — unsigned plugins may have slipped through

  The provenance bypass (GHSA-q5jf-9vfq-h4h7) means any Helm installation that had plugin verification enabled could still have installed unsigned plugins if the .prov file was simply absent. Before upgrading, audit installed plugins with 'helm plugin list' and verify their origins manually. After upgrading, reinstall any plugins from official sources to ensure provenance is properly checked.

• enhancementPin Helm in CI to this exact version now

  If you use a floating version reference like 'latest' or a minor-pinned tag in your CI pipeline, update it to v4.1.4 explicitly. The Helm team also pinned the CodeQL action to a commit SHA in this release — a good reminder to apply the same discipline to your own toolchain dependencies.

日本語 準備中Lima v2.1.1 is a focused patch release adding Windows binary artifacts and fixing a handful of edge-case bugs, with an important bundled nerdctl security update.

• securityUpdate nerdctl distribution for BuildKit and CNI security fixes

  The bundled nerdctl was bumped from v2.2.1 to v2.2.2, which updates BuildKit to 0.28.1 and CNI plugins to 1.9.1. Both upstream releases include security patches. If you use Lima's nerdctl template for container workloads, upgrade to v2.1.1 promptly and check the BuildKit and CNI plugin release notes to assess CVE impact for your environment.

• enhancementWindows users can now consume official Lima binaries

  Lima v2.1.1 ships pre-built Windows artifacts for the first time. If your team has Windows developers using Lima (e.g., via WSL2), point them at the official release binaries rather than maintaining custom builds. This simplifies onboarding and keeps everyone on a verified, reproducible build.

• enhancementFix UID range issues for enterprise/LDAP-managed macOS users

  macOS guests now accept UIDs outside the conventional range. If any users in your org run Lima on corporate-managed Macs with directory-assigned UIDs (common with LDAP or Active Directory integration), this fixes silent failures that were hard to diagnose. No config change needed — just upgrade.

日本語 準備中v1.33.11 is a maintenance patch with no code changes or dependency updates — purely a rebuild/re-release against the v1.33.10 baseline.

• enhancementSkip this upgrade if you're already on v1.33.10

  There are zero functional or security changes here. If your nodes are running v1.33.10 without issues, there's no practical reason to roll this out. Watch for v1.33.12 or a patch with actual fixes before scheduling maintenance windows.

• enhancementUse SBOM and cosign artifacts for supply chain verification

  Every build ships SPDX SBOMs and cosign bundle files. If your org has supply chain security requirements, integrate cosign verification into your upgrade pipeline now — this is a low-risk release to test that workflow against before a more impactful update arrives.

日本語 準備中CRI-O v1.35.2 is a focused bug-fix patch addressing image pull credential verification, metrics reporting gaps, and OCI artifact store contamination issues.

• breakingVerify credential provider workflows after upgrading

  The PullImage fix changes what gets returned during image pulls. If you use Kubernetes credential provider plugins or have automation that validates image pull behavior, test those flows before rolling this to production. The old behavior could silently bypass credential checks in edge cases.

• enhancementAudit your metrics pipelines — you may have been missing data

  The metrics bug means any cluster running v1.35.x before this patch was likely returning incomplete metrics when 'all' was set. After upgrading, expect metric cardinality to increase. Check dashboards and alerting thresholds — a spike in metrics volume is expected and correct, not a problem.

• enhancementUse additional_artifact_stores for air-gapped or mirrored artifact setups

  If you run air-gapped clusters or internal artifact mirrors, the new 'additional_artifact_stores' option lets you configure multiple read-only sources without hacking around existing config. Pair this with the pinned_images fix to ensure pinned artifacts are pulled from the right store consistently.

日本語 準備中CRI-O v1.34.7 is a patch release with no code changes or dependency updates from v1.34.6 — essentially a rebuild or release process artifact.

• enhancementSafe to skip unless you need the rebuild

  This release carries zero functional or security changes. If you're already on v1.34.6, there's no operational reason to upgrade immediately. That said, if your pipeline requires the latest patch tag for compliance or artifact provenance reasons, the SPDX SBOM and cosign bundles are all present and accounted for.

日本語 準備中etcd v3.6.10 is a patch release in the 3.6 series. Release notes are minimal — check the full CHANGELOG for specifics before upgrading.

• breakingRead the upgrade guide before rolling this out

  The release explicitly warns of potential breaking changes in v3.6. Before upgrading any cluster, check the official upgrade guide for v3.6 and review the full CHANGELOG-3.6.md. Don't treat this as a routine drop-in patch without that review.

• enhancementPrefer gcr.io images over quay.io for production pulls

  etcd now designates gcr.io/etcd-development/etcd as the primary registry and quay.io/coreos/etcd as secondary. If your image pull policy or air-gapped mirror config still points primarily to quay.io, update it to reduce dependency on a secondary source.

日本語 準備中etcd v3.5.29 is a maintenance release on the 3.5 branch with no detailed changelog published in the release notes themselves.

• securityVerify container image source after upgrade

  If you pull etcd images in CI/CD pipelines, confirm you're pointing to gcr.io/etcd-development/etcd as the primary registry. The quay.io mirror is secondary and may lag. Pin to the exact digest rather than the floating tag to avoid supply chain risk.

• breakingReview the official upgrade guide even for patch releases

  The release explicitly calls out that breaking changes may exist even in 3.5.x patch versions. Don't skip the upgrade guide. Test in a staging environment first, especially if you're running etcd as the backing store for Kubernetes — a botched etcd upgrade can take down your entire control plane.

• enhancementCheck CHANGELOG-3.5.md before upgrading

  The release notes here are skeletal — no specific fixes or changes are listed. Before upgrading any etcd cluster, pull up CHANGELOG-3.5.md on the etcd GitHub repo and filter for v3.5.29 entries. Patch releases on 3.5 typically carry bug fixes and CVE patches that aren't always obvious from the version bump alone.

日本語 準備中etcd v3.4.43 is a maintenance release on the 3.4 branch. Release notes are sparse — check the full CHANGELOG for specifics before upgrading.

• breakingAlways consult the upgrade guide on 3.4 patch bumps

  Even on patch releases, the etcd team occasionally introduces subtle behavioral changes or deprecations. The official upgrade guide for v3.4 should be checked — don't assume a patch bump is always safe to apply without review, especially in etcd's case given its role as a control plane data store.

• enhancementReview CHANGELOG before upgrading

  The release notes themselves contain no inline change details. Before upgrading, pull up CHANGELOG-3.4.md directly and diff against your current version. 3.4.x patches typically carry bug fixes and CVE backports, so skipping the review risks missing a relevant fix or behavioral change.