Reducing AKS cold starts with Prepared Image Specification
Have you ever watched your Azure Kubernetes Service (AKS) cluster add nodes right on cue, only to wait several more minutes before any of them could take traffic? Or kept extra nodes running all day so a traffic spike wouldn't leave you waiting on cold starts? If large container images or runtime dependencies are making your scale-outs slow and your bill bigger, this post is for you.
A new virtual machine (VM) is only the start. Each node still has to join the cluster, install whatever your hosts need, pull your container images, and start your workload. With a multi-gigabyte inference image, a Windows app, or a runtime that every node installs at boot, that work adds up quickly, and it repeats on every new node.
The usual workarounds all cost something. You can keep spare nodes running and pay for idle capacity, accept slow recovery when demand jumps, or maintain bootstrap scripts that every new node has to rerun.
Prepared Image Specification (PIS) takes a different approach. You tell AKS which container images and setup scripts your nodes need, such as a large inference image, a language runtime, or an internal CA bundle. AKS bakes them into a versioned node image once, and every new node in the pool boots with that work already done.
