Update (2023-09): Autopilot now supports the ability to add additional Pod IP ranges, so you no longer need to plan this up front. Read the official docs, and my test run.
One of the most important decisions you can make for your Autopilot cluster is selecting the right network size. Too small and you’ll constraint your potential growth. Too large and you might run out of IPs if you have a lot of cluster. You can’t change the Pod address size after creation, so it’s important to get it right.
Kubernetes uses a lot of internal (RFC1918) IPs, as each Pod is given its own IP. This is actually a core tenant of Kubernetes as it allows Pods to be network routable, and for them to be treated just as you would a host or virtual machine. But it uses a lot of IPs. In Autopilot’s case, each Node is configured to run up to 32 Pods, resulting in a /26 being provisioned, that is 64 IPs per node.
To calculate your total Pod network size requirement therefore, multiply the number of nodes you wish to support by the number of IPs per node (64 for Autopilot) and pick a CIDR suffix large enough. For example, the default today of /17 results in 32766 usable IPs, resulting in 511 max nodes (32766/64). This may not be enough if you’re expecting growth, consider a /16 (65536 IPs) which would give you a larger 1023 nodes and some room to grow. On the other hand, if you’re IP address constrained and run a lot of smaller clusters (e.g. a SaaS product with one cluster per tenant), you could choose a smaller /22 for at most 15 nodes.
Once you’ve calculated the desire network size, use it when creating the cluster. On the CLI that would use --cluster-ipv4-cidr "/16". On the UI it’s the field named “Pod address range”.
FAQ
Isn’t Autopilot “nodeless”, why do I have to care about this? Autopilot still has nodes. We made that decision consciously, as there are a lot of advantages, like being able to use Kubernetes constructs like DaemonSet, affinity, and being able to support flexible pod sizes of between 0.25 and 28 cores in 0.25 core increments — none of which is possible without the node construct. The only drawback is that you do still need to figure node counts in your IP planning.
Can’t you handle IP allocation as well? Possibly. Stay tuned.
How can I calculate the number of Nodes I’ll need if Autopilot creates them for me? Unfortunately there is no great answer here, so I’d recommend using an approximation based on your expected cluster size. Always go with a larger amount, unless you are IP constrained. As you don’t have direct control over node sizes, it’s wise to go a little higher. Worse case (from an IP allocation point of view), Autopilot can provision one node per pod, though typically it will pack several pods into a node.
| Range | Max Nodes | Comment |
| /13 | 8191 | Enough nodes for the largest current possible Autopilot cluster |
| /14 | 4095 | |
| /15 | 2047 | |
| /16 | 1023 | Best choice for large clusters, or if you’re not IP constrained |
| /17 | 511 | The current default, a decent mid-range choice. |
| /18 | 255 | /18 and below are for smaller clusters when you’re IP constrained and know you won’t need too many nodes |
| /19 | 127 | |
| /20 | 63 | |
| /21 | 31 | |
| /22 | 15 | Very small clusters, e.g. a single tenant application |
1 comment
Comments are closed.