Kubernetes 1.35.1 preview: the two node-boot traps to catch now

I’ve watched “boring patch upgrades” take down perfectly healthy node pools. The failure usually hides in a kubelet flag nobody remembers setting, or in one last cgroup v1 box that never got rebuilt.

What breaks first in 1.35.1: kubelet flags and cgroups

Here’s the thing. CI can look green and your control plane can upgrade fine, then a node reboots and kubelet never returns because it dies before it can even register.

The preview signals two changes that hit early in the boot path: kubelet argument parsing and node system validation. You should treat this like a node OS compatibility release, not “just a patch.”

• Kubelet arg hygiene matters again: a removed flag in a systemd drop-in can stop kubelet at service start, before the node can rejoin.
• cgroup v1 stops getting a free pass: kubeadm preflight checks can move from “warn” to “block” for cgroup v1 when you target v1.35+.
• kube-proxy mode has a direction: ipvs deprecation warnings won’t break you today, but they mark work you will have to do.

Patch timing: why you have a small window

Patch calendars feel like background noise. Until they don’t.

Upstream targets the next 1.35.x patch train for Feb 10, 2026, and calls out 1.35.1 as the next patch for 1.35. That’s your cue to test the stuff that fails fast: node bootstrap, kubelet startup, and cgroup compatibility.

Action required: kubelet drops –pod-infra-container-image

This bit me when a “harmless” reboot took a node out for 20 minutes. We upgraded packages, drained cleanly, everything looked normal, then systemd tried to start kubelet and it exited immediately because of one old flag sitting in a drop-in file like a splinter.

The flag –pod-infra-container-image goes away. If your kubelet still sees it, kubelet can fail at service start with an “unknown flag” style error. That failure happens before the node can register, so your usual “did the node rejoin?” checks run too late.

• Where it hides (non-kubeadm nodes): systemd unit overrides and drop-ins under /etc/systemd, plus whatever your image baked into a custom kubelet unit.
• Where it hides (kubeadm history): old extraArgs settings can stick around even after your current automation stopped setting them. Kubeadm won’t always clean up your past choices.
• How it looks at 02:00: the node pings, ssh works, but kubectl get nodes never shows it returning because kubelet never reaches the API server.

cgroup v1: “legacy” turns into “blocked”

Not subtle.

In v1.35+ the project tightens cgroup validation. In kubeadm-driven flows (init, join, upgrade), preflight checks can stop you when the node reports cgroup v1. Mixed fleets turn upgrades into roulette unless you force a baseline first.

• What changes operationally: kubeadm can fail in preflight instead of letting you limp forward and clean it up later.
• Who gets hit: older AMIs, long-lived bare metal, and “we never rebuild nodes” environments.

ipvs deprecation: don’t ignore the warning

Some folks skip canaries for patch releases. I don’t, but I get it.

IPVS mode deprecation in kube-proxy won’t brick the cluster on 1.35.1 by itself. The warning still matters because it tells you where upstream wants kube-proxy to land, and it tells you which code path will get less love over time. I don’t trust “known issues: none” from any project, especially around networking.

• What I’d do in this cycle: stand up a small node pool using nftables mode and watch conntrack behavior, policy edge cases, and node-local DNS quirks.
• What I would not do: wait until the deprecation turns into removal, then try to migrate during an incident.

Canary upgrade plan (small, boring, repeatable)

Go small.

Upgrade one node pool first, and assume you will find one weird config file nobody “owns.” Drain, upgrade, restart, verify, then scale out. For dev clusters, you can yolo it on Friday. For anything that pays your bills, test this twice.

• Run the plan step first: run kubeadm upgrade plan so you see preflight failures before you touch a node.
• Drain before you touch kubelet: run kubectl drain <node> –ignore-daemonsets –delete-emptydir-data, then upgrade kubelet and restart it.
• Keep acceptance tight: node rejoins, pods schedule, DNS works, and your CNI behaves under churn. That’s enough for a patch canary.

Red flags to grep before you declare victory

These show up fast.

Don’t wait for dashboards. Read the logs on the first canary node, then sweep the fleet configs while the blast radius stays small.

• Kubelet won’t start: look for “unknown flag” errors tied to –pod-infra-container-image or other removed args.
• Kubeadm preflight hard-stop: look for SystemVerification failures tied to cgroup v1.
• Kube-proxy warnings: treat ipvs deprecation messaging as “migration required,” not a nice-to-have.

One-liners you’ll actually use

Copy, paste, ship.

Run these before you schedule the rollout. They won’t catch every edge case, but they catch the dumb ones, and the dumb ones cause the loudest pages.

• Find the removed kubelet flag in fleet configs: grep -R “pod-infra-container-image” -n /etc/systemd /var/lib/kubelet /etc/kubernetes || true
• Check cgroup mode on a node: stat -fc %T /sys/fs/cgroup
• Try nftables kube-proxy on a canary: set mode: nftables in KubeProxyConfiguration or start kube-proxy with –proxy-mode nftables

If you run managed Kubernetes, you still own the outage. Your provider just picks the date.

My take: upstream optimizes for modern Linux, and you should too

I’ve seen teams treat “legacy nodes” like old furniture. They keep them around because they still work, then they trip the whole cluster when a default flips.

Upstream keeps removing escape hatches and shrinking the number of kernel and runtime combos they need to test. That’s rational engineering. It also turns old fleets into a liability you can measure. Plan accordingly. There’s probably a better way to test this, but…

Keep Reading

• Kubernetes Upgrade Checklist: the runbook for minor version upgrades
• Kubernetes EOL policy explained for on-call humans
• Kubernetes 1.35 release: the stuff that can break your cluster

Frequently Asked Questions

• What are the two node-boot traps in Kubernetes 1.35.1? First: kubelet completely removes the –pod-infra-container-image flag. If your kubelet configuration or systemd unit file includes this flag, kubelet will fail to start after the upgrade. Second: cgroup v1 support moves from “deprecated” to “blocked by default” — nodes running cgroup v1 (common on older OS images) need explicit kubelet configuration to continue working.
• How do I check if my nodes use cgroup v1 or v2? Run stat -fc %T /sys/fs/cgroup on any node. If it returns tmpfs, you’re on cgroup v1. If it returns cgroup2fs, you’re on cgroup v2. For a cluster-wide check: kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{” “}{.status.nodeInfo.operatingSystem}{”
  “}{end}’ and then SSH to each node type to verify. Most modern distros (Ubuntu 22.04+, RHEL 9+, Amazon Linux 2023) default to cgroup v2.
• How urgent is the Kubernetes 1.35.1 upgrade? If you’re already on 1.35.0, the .1 patch fixes specific edge cases with the cgroup default change and kubelet flag removal. Upgrade within your normal patch window. If you’re still on 1.34.x or earlier, there’s no rush to jump to 1.35 — wait until your team has tested the cgroup v1/v2 implications in staging.
• What’s the safest Kubernetes 1.35.1 upgrade strategy? Canary approach: upgrade one non-critical node first. Before upgrading, grep your kubelet config for –pod-infra-container-image and remove it. Check cgroup version. Upgrade the node, watch kubelet logs for 30 minutes, verify pods schedule correctly, then proceed to the next node. Never upgrade all nodes simultaneously — even in dev clusters.