ANTHONY BUSHONG: Welcome to Bit by Bit,
a series where we highlight one thing you can do to optimize
and potentially run a bit better in Google Cloud.
Today's topic-- IP address management.
It's not always easy, and it's not always fun,
but we always want to make sure we use our network space
efficiently.
In GKE Standard, one way to do that
is by configuring the maximum number of pods per node
to effectively get smaller pod CIDRs on nodes.
So let's get to it.
[MUSIC PLAYING]
[WHOOSH]
So start out with a GKE Standard cluster
that has only three nodes.
And you can see here it's set to my current context
in my kubeconfig.
And so we know that, in Kubernetes, every pod
gets a unique IP address.
I love this implementation, and the way
that it gets this IP address is that each node in the cluster
gets a CIDR block, from which it can assign network identities
to the pods that it runs.
So we can demonstrate that pretty quickly.
We're going to describe the nodes in our cluster and grep
for PodCIDRs.
OK, so we can see here that we have three nodes.
And so we get three ranges back from--
describing all of our nodes in our cluster.
And if we quickly run a pod and grep for its IP,
we can see that it gets an IP address
from one of these blocks because this is getting its IP
from the node that it runs on.
If we grep for IP, then we can see from the 10.44.2 block
that we now get our pod's IP address.
So this is so far, so good, until we begin to run the math.
So we can see the address box for each node listed here,
and each of them is a /24, and that's 256 IP addresses.
So by default, GKE Standard clusters
and their respective node pools default
to 110 maximum pods per node if you never tweak that value.
And some of this is for buffer needed
in case of high pod churn rates as pods come and go,
but you could end up stranding a lot of IP addresses
in the long run if you don't tune max pods per node.
So we're going to create a new node pool here, but instead,
we're going to set it to 50 pods per node for max pods per node,
and we'll see that we immediately get a smaller range
for nodes in this node pool, a /25.
If you jump over to the documentation,
you can see here that as you tweak the max pods per node,
you'll get a different CIDR block allocated
for pods on that node.
And you can see how that correlates
to the number of IP addresses.
And the thing about this here is that this now
begins to become a planning exercise,
where you understand roughly what types of resources
will be running on certain node pools and node types.
And will they run out of CPU memory
before they run out of IP addresses in terms of how
many pods can fit on that node?
So we're going to let this node pool create.
Now we'll just take a second.
Now that that node pool has completed creation,
we can see we've added nine nodes to our cluster.
These are all in pool 1, and they're ready to go.
And keep in mind that these smaller ranges,
when you tune maximum pods per node,
it's also pulling from the same pod IP address range
that the whole cluster gets.
It's just allocating them to each node more
sparingly when max pods per node value is set.
So we're just going to do a quick check that this worked.
We're going to run the same command and grep for PodCIDRs
as we describe our nodes.
We'll see the original three nodes that we had with
/24's, but we can now see that all the nodes that we added
afterwards had a /25, thus preserving the IP address space
that we have for the pods in our cluster and our overall network
topology.
Network space is finite, and for many users,
GKE isn't the only part of that network.
So in your GKE Standard clusters,
consider reducing the maximum number of pods per node
to make sure that you can preserve more IP addresses.
As always, can learn more in the links in the description below,
and we'll see you in a bit.
[MUSIC PLAYING]