Cases7 cases

1 to 5 of 7

1. IL-0237 A Kubernetes patch upgrade evicted every Ray Serve head and worker pod at once, and Lucidworks hosted LLMs went down

   Lucidworks2026sev1

   Symptoms

   From 16:18 UTC on 28 May 2026 the Lucidworks AI hosted LLMs in the us-southcarolina region were unavailable: queries to llama-3-8b-instruct, llama-3v2-3b-instruct and phi-4-multimodal-instruct returned 500 or 429 errors. Search, embedding models, the Lucidworks Platform UI and passthrough LLM calls kept working.

   Service outagePod evictionImage pull failures

   Trigger

   A routine Kubernetes patch upgrade on a cluster in us-southcarolina cycled its node pools one after another in quick succession.

   Root cause

   Faulty deployment

   Component

   Node poolModel inference server

   Contributing factor

   No staged rolloutOverlapping failures

   Remediation

   • Deleted the degraded replacement head node that could not pull container images
   • Waited for the LLM image pulls to finish on the replacement nodes
   • Launched new nodes with the required LLM images and redirected Lucidworks AI traffic to them

   Action items

   • Upgrade clusters that host LLM workloads in sequence, with each node pool fully healthy before the next one is upgraded
   • Investigate image pre-loading, such as pre-baked disks or image streaming, for large ML model images
   • Open a support ticket with the cloud provider about the abnormal Docker pull times
   • Coordinate Kubernetes maintenance windows with LLM service owners so they do not clash with ongoing deployments
   • Build tooling to force a Ray cluster failover to the blue or green state instead of waiting for Ray to settle it

   View case
2. IL-0166 A compute host update removed the credential parser used to decode StackScripts, so new Linodes and every new LKE and LKE-E node failed to boot and autoscaling and node recycling failed in all regions

   Linode2026

   Symptoms

   Linodes deployed with StackScripts failed to deploy and could not boot. Every newly created Linode Kubernetes Engine (LKE) and LKE-E node relies on StackScripts, so LKE autoscaling and node recycling failed as well, in all regions.

   Scale-up failure

   Trigger

   A recent update on the compute hosts removed a credential parser that is used when decoding StackScripts.

   Root cause

   Faulty deployment

   Component

   Cluster autoscalerNode pool

   Contributing factor

   –

   Detection

   The issue was identified at 18:18 UTC on 2026-05-15. The first status post went up at 00:42 UTC on 2026-05-16.

   Remediation

   • tested and applied a rollback starting at 01:10 UTC on 2026-05-16, and failures dropped from 01:20 UTC

   Lessons

   Removing a credential parser from the compute hosts broke the boot of every Linode deployed with StackScripts, and every new LKE and LKE-E node is one of them, so node creation, autoscaling and node recycling stopped in all regions. The rollback reduced failures ten minutes after testing began.

   View case
3. 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
4. IL-0163 An API change that slipped through a gap in automated testing made LKE clusters resize to the wrong number of nodes and added billable worker nodes to customer accounts

   Linode2023

   Symptoms

   Resizing an LKE cluster produced an incorrect number of nodes, so some customer clusters were resized in unexpected ways and the extra worker nodes were billed to the customer accounts. The clusters themselves kept functioning. Linode's first status update, at 05:07 UTC on 1 June 2023, advised customers to avoid resizing their clusters if possible.

   Autoscaler misbehaviour

   Trigger

   At about 16:00 UTC on 31 May 2023 a change to the API that caused LKE clusters to scale improperly was pushed to production.

   Root cause

   Faulty deployment

   Component

   Node pool

   Contributing factor

   Gap in automated tests

   Detection

   The first status update, at 05:07 UTC on 1 June, said Linode had been made aware of an issue when resizing LKE clusters, about 13 hours after the change went out.

   Remediation

   • advised customers to avoid resizing their clusters
   • deployed a hotfix at 09:40 UTC on 1 June that corrected the scaling behaviour
   • left the extra worker nodes in place to avoid disrupting customer workloads
   • contacted affected customers by ticket about credit adjustments and further mitigation

   Action items

   • Audit the automated tests
   • Add pre-deployment checklist items so the same failure does not happen again

   Lessons

   An API change that alters scaling behaviour resized customer clusters and added cost while the clusters themselves kept working; Linode announced the issue about 13 hours after the change went out. Removing the extra nodes would have disrupted workloads, so the cost was handled through credits instead.

   View case
5. IL-0164 An incremental Linode Kubernetes Engine production update that was missing changes from the previous release made cluster upgrades and node additions fail silently

   Linode2022

   Symptoms

   From about 18:30 UTC on June 15, 2022, customers of the Linode Kubernetes Engine (LKE) who tried to upgrade a cluster or add nodes saw those operations fail silently, without an error. The status page opened an investigation of an LKE issue at 19:54 UTC, and the affected list covered LKE in eleven regions.

   Upgrade stall

   Trigger

   An incremental update pushed to the LKE production environment at about 18:30 UTC.

   Root cause

   Faulty deployment

   Component

   Node pool

   Contributing factor

   –

   Detection

   The status page began investigating at 19:54 UTC, 1 hour 24 minutes after the update.

   Remediation

   • Released a follow-up LKE update at about 21:00 UTC that contained the missing changes

   Action items

   • Add steps and automation to the update process

   View case

By root cause1