IL-0149 Microsoft Azure · 2019-09-28kubernetesazure
On 3 October 2019 AKS engineering opened a known-issue report: clusters using VMSS that were created before 07:20 UTC on 28 September 2019 failed to upgrade, because the node image the scale set referenced was reported as not available. The preliminary root cause was a recent service update that left instances of a backend service unhealthy, so requests could not complete. Customers were told not to upgrade these clusters until the issue was mitigated.
Customers could fix a cluster themselves with two az vmss update commands, setting VirtualMachineProfile.StorageProfile.ImageReference.version to "2019.09.25" and VirtualMachineProfile.StorageProfile.ImageReference.Sku to "aks-ubuntu-1604-201909" on the scale set in the MC resource group, and then running the upgrade again. Those who could not were asked to file a support request. The AKS and VMSS teams mitigated affected clusters by hand and rolled hot fixes out region by region; 14 regions were patched by 4 October, and the issue was closed on 15 October 2019 when all regions were patched.
The issue title says clusters created before 20 September, while its body gives 07:20 UTC on 28 September 2019.
From 07:20 UTC on 28 September 2019, customers running Azure Kubernetes Service clusters on Virtual Machine Scale Sets (VMSS) got failures when they tried any cluster upgrade. The error read: "The platform image 'microsoft-aks:aks:aks-ubuntu-1604-201909:2019.08.21' is not available. Verify that all fields in the storage profile are correct." The issue title calls the error PlatformImageNotFound.
All VMSS-based clusters created before that time were affected, in all regions, and could not be upgraded without manual intervention. A customer asked in the issue how to tell whether a cluster was affected without trying an operation and having it fail; the issue gives no answer.
Symptom Upgrade stall
Root cause Faulty deployment
Customers received failure messages when they tried to upgrade their clusters.
–
–
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 regionsLinode · 2026same root cause · shared Node pool
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 downUK Ministry of Justice · 2025same root cause · shared Node pool
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 accountsLinode · 2023same root cause · shared Node pool
IL-0164 An incremental Linode Kubernetes Engine production update that was missing changes from the previous release made cluster upgrades and node additions fail silentlyLinode · 2022same root cause · shared Node pool
https://incidentlib-mcp.benchlet.com/mcpThe API needs no key. The MCP server offers search_incidents, get_incident, list_incidents, get_topic and vocab; both are explained on API and MCP.