EKS 1.34 to 1.35 upgrade: what breaks at this step

The Kubernetes deprecated API migration guide has no entry for 1.35: nothing you apply today stops being served at this hop. The last removal on the EKS path was flowcontrol.apiserver.k8s.io/v1beta3 at 1.32, and a chart or manifest that still uses it has failed on every version since. Run the check anyway. It is the one item that is cheap to fix today and expensive to find during the window.

Nothing for 1.35. Move any leftover flowcontrol.apiserver.k8s.io/v1beta3 manifest to v1; the fields are the same.

Lists every removed and deprecated API still in use, read from the live cluster, so a 1.32 leftover shows up here even though 1.35 removes nothing new.

A node that boots on cgroup v1 with a 1.35 kubelet never joins the cluster. AL2023 is cgroup v2 by default, so stock node groups are fine. The risk is a launch template or nodeadm config that put AL2023 back on cgroup v1 (systemd.unified_cgroup_hierarchy=0 on the kernel command line is the usual way) and custom AMIs built on an older base. Bottlerocket 1.35 sets failCgroupV1: false itself, and Fargate is unaffected.

• Move the node group to cgroup v2: drop the cgroup v1 kernel parameter from user data, or rebuild the custom AMI on AL2023 and let it default.
• If a workload really needs cgroup v1, set failCgroupV1: false in the kubelet config (nodeadm NodeConfig → spec.kubelet.config) before rolling nodes to 1.35. That keeps you on a deprecated mode, so plan the migration anyway.

Reads kubelet_cgroup_version from each kubelet's /metrics and lists the hosts still on v1 (rule rtz-k8s-node-cgroupv1-fails-1.35). It needs nodes/metrics access for that; without it the item is reported as unchecked, not as clean.

Nothing stops at this hop. EKS-optimized AMIs have shipped containerd 2.1 since 1.34, so managed node groups on a current AMI are already done. Custom AMIs and self-managed nodes that pinned containerd 1.7 keep working on 1.35 and are blocked at 1.36. Treat 1.35 as the version where you fix it, because the next hop will not wait.

• Rebuild custom AMIs on a containerd 2.x base (the EKS AL2023 and Bottlerocket images already are) and test anything that writes /etc/containerd/config.toml: the config schema changed between 1.x and 2.x.
• Roll those node groups while you are on 1.35, so the 1.36 hop is only a version change.

Reads kubelet_cri_losing_support from each kubelet's /metrics, the gauge the kubelet sets when its own container runtime loses support at a coming version (rule rtz-k8s-node-cri-losing-support), and prints the node and the version it is lost at.

A kubelet started with a flag it no longer knows exits at once, so a node that still passes --pod-infra-container-image never becomes Ready on 1.35. EKS-optimized AMIs don't set it. Where it hides: bootstrap user data (--kubelet-extra-args on AL2, spec.kubelet.flags in a nodeadm NodeConfig on AL2023), Karpenter EC2NodeClass user data, and custom AMI build scripts. Kubelet flags live on the host, not in any Kubernetes object, so no cluster-side query sees them.

• Delete the flag. The pause image is containerd's to pick: set sandbox_image under the CRI plugin in /etc/containerd/config.toml if you need a copy from a private registry.
• Boot one 1.35 node from the changed template before rolling the group.

Does not check kubelet command-line flags, and says so rather than reporting clean: they are a host-level fact with no object in the API, so the catalog marks rtz-k8s-kubelet-pod-infra-container-image-removed not detectable. Grep the user data yourself.

Nothing breaks at 1.35: IPVS keeps working and logs a deprecation warning. EKS defaults to iptables, so this only applies if someone set mode: ipvs in the kube-proxy add-on configuration. The replacement is nftables, GA since 1.33, which needs a 5.13 or newer kernel (AL2023 and Bottlerocket qualify). Switching the proxy mode is a data-plane change: give it its own window, not the upgrade's.

• Follow AWS's nftables guide: set mode: nftables in the kube-proxy add-on configuration and roll the kube-proxy pods. Check first that nothing on the nodes manages its own iptables rules that nftables mode would bypass.
• Don't change the proxy mode and the Kubernetes version in the same change.

Reads mode: from the kube-proxy ConfigMap and reports ipvs as deprecated from 1.35 (rule rtz-kube-proxy-1.35-ipvs-mode-deprecated). A mode passed only as a container argument is not read.

Nothing about 1.35 changes how the controller runs. The problem is that there are no more releases: the next CVE in the controller or in the bundled NGINX stays open, and the last release's compatibility table ends at 1.35, so a later Kubernetes hop has no supported version to move to. AWS puts this in the 1.35 notes because this is the upgrade window in which to start the migration.

• Pick a target: Gateway API with a maintained implementation, or a maintained Ingress controller. Inventory the nginx.ingress.kubernetes.io/* annotations you depend on first; snippets and auth annotations are where the direct translation stops.
• Pin the last release in the meantime and watch its image for CVEs.

Lists ingress-nginx under add-on compatibility with the version window its own release notes publish; the newest release covers Kubernetes 1.31 to 1.35. The retirement itself is not a version check. At the 1.36 hop no release lists the target, and the report says so instead of passing it.