CRI-O
v1.34.8Kubernetes CoreCRI-O v1.34.8 patches CVE-2026-35469 in the spdystream dependency and adds two operator-facing features: a new runtime metric and configurable GOMAXPROCS injection.
securityPatch CVE-2026-35469 — update to v1.34.8 now
The spdystream library had a vulnerability fixed in this release. spdystream is used for streaming connections (exec, attach, port-forward), so exposure is real in any cluster. Upgrade CRI-O to v1.34.8 on all nodes. No config changes required — the fix is purely a dependency bump.
enhancementUse the new runtime metric to audit node configurations
The `container_runtime_crio_default_runtime` metric lets you confirm — via your existing Prometheus stack — that every node is actually running the runtime you expect (e.g., runc vs. kata-containers). This is particularly useful in mixed-runtime clusters or after node image upgrades where config drift can go undetected. Add an alert for unexpected runtime values once you've upgraded.
enhancementEvaluate min_injected_gomaxprocs for CPU-constrained workloads
If you run containers with very low cpu.request values (e.g., 0.1 cores), Go runtimes default to GOMAXPROCS=1, which can serialize work that should be parallel. Setting `min_injected_gomaxprocs` raises the floor so those containers get a more reasonable thread count. Be cautious on dense nodes: raising GOMAXPROCS across all containers increases goroutine scheduling overhead. Test with a non-Guaranteed workload first and watch CPU throttling metrics before rolling out cluster-wide.
主な変更 (4)
- CVE-2026-35469 fixed by bumping moby/spdystream from v0.5.0 to v0.5.1
- New `container_runtime_crio_default_runtime` metric exposes which container runtime is configured as default on each node
- New `min_injected_gomaxprocs` config option sets a floor for GOMAXPROCS injected into every container CRI-O creates
- GOMAXPROCS injection logic: CRI-O uses max(floor, cpu.request) except for Guaranteed QoS pods or partitioned workloads