I upgraded EKS to Kubernetes 1.35 on a Tuesday. By Wednesday 6am half my node groups were stuck NotReady, Karpenter was spinning up replacements that failed too, and on-call was paged. The cause was documented. Nobody sees it. Thread:
@theagentpod So far, so good. This one burned me once too often, so I built Tideclear - an open-source scanner that catches EKS upgrade issues before they pick their own priority: https://t.co/LXmsBGe9Ww
1/3 The most expensive ticket I ever deprioritized looked like housekeeping.
AWS stopped publishing AL2 EKS AMIs. No console banner, no Health Dashboard alert. We had a medium-priority ticket to move nodes to AL2023 and it kept sliding - there was always something more urgent.
1/3 Honest question for the infra people here: Terraform, OpenTofu, or Pulumi in 2026?
Context: I work in regulated environments, so my checklist is boring on purpose - state locking I can trust, a plan output an auditor can read,
2/3 and upgrades that don't surprise me six months later.
Terraform still wins on ecosystem, OpenTofu on license purity, Pulumi on real languages. But I keep hearing different answers on which one teams would pick today if they started fresh.
3/3 and an audit trail. A "medium" ticket cost us 10 hours and an incident record.
Lesson I now give every team I work with: treat deprecation notices as P1, even when the vendor doesn't. The quiet ones are the ones that get you.
2/3 Then 1.35 made cgroup v1 a breaking change, and the ticket picked its own priority.
The fix itself took 4 hours. The incident paperwork took 6. That's the part nobody budgets for: in FDA-regulated infra, every unplanned change comes with documentation, approvals,
3/3 3. What breaks silently. The failures that hurt are the ones with no banner and no alert, where a dashboard just looks slightly off.
Upgrade the easy stuff first. Find the hard stuff before it finds you.
1/3 Before any EKS upgrade I run three checks. They take ten minutes and have saved me more than once:
1. Node OS. kubectl get nodes -o custom-columns=NAME:.metadata.name,OS:.status.nodeInfo.osImage - anything on Amazon Linux 2 is a problem, not a footnote.
2/3 AL2 EKS AMIs are no longer published, and 1.35 won't boot a kubelet on cgroup v1.
2. How nodes get replaced. If Karpenter or an autoscaler provisions them, a bad AMI doesn't fail once - it fails in a loop, launching more broken nodes because none ever go Ready.