Linode Kubernetes cluster creation failed after subnet IDs passed one million

Starting October 17, 2026, attempts to stand up new Linode Kubernetes Engine-Enterprise (LKE-E) clusters around the world produced clusters whose core components never left the pending state. According to a dev.to write-up of the incident, the root cause was remarkably small: identifiers for subnets inside Linode's Virtual Private Cloud crossed the 1,000,000 mark and gained a seventh digit.

What broke

The failure lived in the Cloud Controller Manager, the Kubernetes component that requests load balancers, routes, and other network resources from the underlying cloud and keeps them aligned with what the cluster expects. A software logic flaw caused it to handle the now seven-digit subnet IDs through floating-point parsing instead of treating them as plain integers. Once that happens, a value like 1000000 can be rendered in exponent form, such as 1e+06. Numerically the same, textually very different, and invalid to any consumer expecting ordinary digits. Unable to resolve the subnet, the controller could not finish its work, so the core components depending on it stayed pending on every freshly created cluster.

Scope and recovery

The incident summary quoted on dev.to describes a clean split in impact. Existing clusters, running workloads, and scaling of existing clusters all kept functioning throughout; only newly provisioned clusters hung. That asymmetry is diagnostic in itself: when old paths succeed and new ones fail, the fault usually sits somewhere along the creation path rather than in the platform as a whole.

Akamai, Linode's parent company, resolved the issue on two fronts. It changed the code so these identifiers are handled strictly as integers, and it patched the custom resources that had already been written with malformed values, which restored the stuck clusters. After internal testing confirmed that new test clusters provisioned correctly, the impact was declared mitigated at roughly 19:49 UTC on October 20, 2026, with a postmortem update published at 15:49 UTC on October 21.

Why one extra digit caused it

An identifier may look like a number, but it functions as a label. Nobody adds subnet IDs together or averages them; the only real requirement is that the string survive every hop, from database to API to JSON to application code, unchanged. Floating-point breaks that requirement twice over: large integers are not always represented exactly, and formatting a float can change how it looks. The step from 999999 to 1000000 is exactly where many formatters switch to scientific notation, so code that behaved for years can fail on the day a counter grows by one digit. The dev.to author points out that the same trap shows up elsewhere: phone numbers losing leading zeros, card numbers losing precision, timestamps losing their final digits.

The suggested defenses are simple. In Go, parse identifiers with strconv.ParseInt rather than routing them through float64, and use json.Number via the decoder's UseNumber option so JSON numbers are not silently converted to floats before they can be checked. In Python, reject float and boolean values for identifiers and validate that the input is digits only. Keeping IDs as strings end to end, and testing specifically with 999999, 1000000, and 1000001 at the point where identifiers enter a system, catches this bug class before customers do.

Why it matters

This is a concrete, public example of a quiet failure mode: an opaque identifier treated as a number, and a numeric representation leaking across a system boundary. It is especially painful in orchestration tooling because the symptom is silence. A pending cluster with no useful error looks like slowness rather than a defect, which makes triage harder. Teams building provisioning pipelines or Kubernetes controllers that talk to cloud APIs should audit every place an ID passes through a float, a generic formatter, or a permissive JSON parser, and add tests around digit-length boundaries. The incident is also a reminder that growth alone can activate dormant bugs: nothing in the code changed on October 17. The data simply got one digit longer, and a hidden assumption finally gave way.