Cases19 cases

2 to 6 of 19

1. IL-0020 During an EKS 1.30 upgrade the descheduler tried to reschedule every pod on the cordoned nodes at once and production workloads went down

   UK Ministry of Justice2025

   Symptoms

   At 09:36 on 18 March 2025, during the upgrade of the live cluster to EKS 1.30, users reported that their pods were being terminated and were not restarting automatically, in both production and non-production environments. Automated infrastructure alerts fired as well, and production services had outages.

   Pod evictionPods PendingService outageUpgrade stall

   Trigger

   Upgrading the live EKS cluster from 1.29 to 1.30, during which the descheduler attempted to reschedule all pods on the cordoned nodes simultaneously.

   Root cause

   Faulty deployment

   Component

   DeschedulerNode poolCluster autoscaler

   Contributing factor

   No headroomNo alert on limitUnreviewed defaults

   Detection

   Users reported at 09:36 that pods were being terminated and not restarting, and automated infrastructure alerts fired.

   Remediation

   • Removed the cordon annotation so pods could be rescheduled
   • Deleted stuck 1.30 nodes to force their recreation
   • Added a new node group of 20 nodes running 1.30 by hand
   • Cordoned and drained all old 1.29 nodes onto the new 1.30 nodes

   Action items

   • Raise an AWS Production System Down support case (Case ID: 174229643100496)
   • Get guidance from AWS support on querying control-plane logs to find the root cause of similar issues
   • Document a runbook for emergency scaling of a new node group in case of unexpected capacity shortages
   • Alert on an imbalance between the autoscaling group and the Kubernetes nodes
   • Review the descheduler configuration to understand why it throws pods off cordoned nodes, and fix it where possible
   • Alert on spikes in the pending pod count

   Lessons

   The write-up lists review actions rather than lessons. They show the team had no documented way to add an emergency node group, no alert on a mismatch between the autoscaling group and the nodes Kubernetes sees, no alert on a spike in pending pods, and no clear understanding of how the descheduler treats cordoned nodes.

   View case
2. IL-0007 The AWS VPC CNI could not assign IP addresses to pods as an EKS cluster ran out of IPv4 space

   Adevinta2024

   Symptoms

   One evening the platform team that runs SCHIP, Adevinta's internal runtime platform on Kubernetes, was paged because some DaemonSets were failing. Checking the pod status showed this error from the network plugin: name="aws-cni" failed (add): add cmd: failed to assign an IP address to container

   IP address exhaustionPods Pending

   Trigger

   Not stated for the first page. It came in June, during the migration from SCHIP's kube-aws-based clusters to EKS-based clusters; the write-up mentions spikes of pods, such as a job that goes rogue or failing jobs that keep their IPs, as ways a cluster can run out.

   Root cause

   Capacity exhaustion

   Component

   AWS VPC CNIVPC subnet or pod address rangeKarpenter

   Contributing factor

   Unreviewed defaultsNo capacity planning

   Detection

   A pager alert that some DaemonSets were failing. The on-call engineer checked the pod status and found the aws-cni error about failing to assign an IP address.

   Remediation

   • Rolled out VPC CNI custom networking with a secondary CIDR to the smaller clusters from late August
   • Paused the EKS migration in September while available IPs were very low
   • Rolled out custom networking to the rest of the fleet
   • Added the --reserved-enis parameter to the Karpenter deployment

   Action items

   • Use VPC CNI custom networking with a secondary CIDR across the whole fleet
   • Make Karpenter account for custom networking with the --reserved-enis parameter

   Lessons

   For a platform team, the VPC CNI is not ready to scale in production without time spent on capacity planning, and every option has its pros and cons. For large clusters started today, IPv6 is the cheaper and more future-proof option. Do not assume that what works in small clusters will keep working when they grow.

   View case
3. IL-0148 A kube-scheduler regression in Kubernetes v1.27.14, v1.28.10 and v1.29.5 made the scheduler panic on a pod whose node affinity named a nonexistent node, so no pods were scheduled on affected AKS clusters

   Microsoft Azure2024

   Symptoms

   On AKS clusters running Kubernetes v1.27.14, v1.28.10 or v1.29.5, kube-scheduler panicked whenever the cluster contained a pod with a bad node affinity, and from then on no pod in the cluster was scheduled.

   Pods Pending

   Trigger

   A pod in the cluster with a required node affinity whose matchFields term names a node that does not exist.

   Root cause

   Software defect

   Component

   Pod scheduling and placement

   Contributing factor

   –

   Detection

   The AKS team found the bug; the issue does not say how.

   Remediation

   • AKS engineers fixed the impacted clusters
   • Rolled out a fixed kube-scheduler to all regions, applied to clusters automatically

   View case
4. IL-0114 An unpinned AWS VPC CNI plugin was updated automatically during a capacity expansion, leaving new pods Pending without IP addresses and stopping CoW Protocol settlements for about 3.5 hours

   CoW Protocol2024

   Symptoms

   At 16:40 UTC on 19 April 2024 CoW Protocol's mainnet production environment stopped producing settlements; the outage officially began then.

   Pods PendingIP address exhaustionPod evictionService outage

   Trigger

   During a cluster capacity expansion, the Infrastructure as Code automation updated the AWS VPC CNI plugin, because the CNI version was not hardcoded in the IaC and the IaC library version had recently changed.

   Root cause

   Configuration change

   Component

   AWS VPC CNINode pool

   Contributing factor

   Unpinned versionOverlapping failures

   Detection

   The CNI version mismatch was identified as the cause at 17:03 UTC, 23 minutes after settlements stopped.

   Remediation

   • upgraded the Kubernetes cluster
   • set up new node groups with a new version of the networking plugin

   Lessons

   Versions in IaC scripts should be specified explicitly so an automation run cannot update a component such as the CNI plugin unintentionally. Changes in production need change management that is easy to revert.

   View case
5. IL-0231 Deleting EKS managed node groups also deleted Karpenter's instance profile, and every Stytch worker node shut down

   Stytch2023

   Symptoms

   On 23 February 2023 Stytch's EKS worker nodes went Ready:Unknown one after another, Karpenter failed to launch replacement nodes, and with fewer and fewer pods scheduled the Live Stytch API went down for 14 minutes, returning 5XX on every call.

   Node NotReadyScale-up failurePod evictionPods PendingService outage

   Trigger

   At 14:21 UTC Stytch landed a change to remove unused EKS managed node groups, because it had decided to run its data plane applications fully on nodes provisioned by Karpenter. Because Crossplane resources use an orphan deletion policy, engineers deleted the node groups in the AWS console, first in staging and then in production.

   Root cause

   Configuration change

   Component

   KarpenterNode poolConfiguration templating

   Contributing factor

   Unverified assumptionShared credentialChange with a delayed effectIgnored early signal

   Detection

   Low-urgency alerts that Karpenter could not find the instance profile fired in staging at 16:06 UTC and in production at 17:48 UTC but were not treated as an incident. The incident process started at 20:26 UTC when node launch failures spiked the Karpenter error rate, and Kubernetes monitoring alerts in production followed at 20:44 UTC. The support team flagged the outage at 21:14 UTC.

   Remediation

   • Reverted the node group deletion, which recreated the managed node groups
   • Manually scaled up one of the Live API node groups with more and much larger nodes and removed its taints
   • Removed node selectors from the applications one after another so their pods could be scheduled

   Action items

   • Treat Karpenter errors as high-urgency alerts that page the on-call engineer
   • Tune cluster alerting thresholds to send a high-urgency page earlier
   • Add alerts for nodes that stay NotReady or Unknown for long periods
   • Raise the thresholds of other deployment alerts, such as unschedulable pods and replicas not available
   • Give Karpenter its own IAM instance profile, separate from the one used by the node groups
   • Separate other AWS resources that were shared between uses, specifically IAM and security groups
   • Rework the EKS and Karpenter configuration so system instance profiles are unique, static per cluster and generated by Karpenter
   • Introduce a cloud visualization tool for engineers making infrastructure changes
   • Add live system and product metrics to the status page
   • Ask AWS to confirm the undocumented actions and side effects of deleting a node group
   • Correct the shared use of IAM roles and security groups across the infrastructure

   Lessons

   The IAM role for Karpenter's self-managed nodes should never have been the same as the one for the managed node groups; sharing it is what let the node group deletion break Karpenter, and the roles had been left combined for speed and simplicity when Karpenter was first set up. The hours-long delay between the configuration change and its effect made the incident hard to assess, and AWS confirmed that this delay is expected, so Stytch will allow for it in future IAM instance profile changes.

   View case

By root cause6