ANTHONY BUSHONG: Kubernetes networking
is famously designed around core principles that
can vary in implementation.
Thus, it's essential to understand
the specific way cluster networking works
when using GKE.
[MUSIC PLAYING]
There are various resources we interact with in GKE,
so let's break this down, starting with GKE nodes.
In GCP, these nodes are VMs that live
within the construct of a VPC--
in other words, a private network in the cloud.
Each GKE node gets a private IP and connectivity
to the rest of the cluster and the rest of the network.
At cluster creation time, you will
need to define your first IP range, the node range,
from which these nodes will get their IP address.
By default, creating a GKE cluster
will also allocate a public IP to each node as well.
If you want to lock down your cluster from the internet,
it's recommended that you configure
GKE to run as a private cluster, in which the nodes will not
receive a public IP address.
If you want to run a private cluster
but also want to establish outbound connections
with the internet, you'll need to configure
a service like Cloud NAT for egress to the internet.
The next resource we want to review in GKE
are pods, the atomic Kubernetes resource that encompass
our containerised application.
In Kubernetes, each pod gets its own IP address.
In GKE, this is accomplished via alias IP ranges.
This means that each Pod will have an IP address unique
in the VPC and can be natively addressed
from other clients in the network.
When you create a GKE cluster, you
will need to define your second IP range, the range from which
pods will get their IP address.
Each GKE node gets a number of IPs from this range
that it can assign to its pods.
By default, a /24 is carved out for each node,
which is 256 IPs in total.
Pods can be scheduled and rescheduled
on various nodes throughout the lifecycle of the cluster.
One challenge with this is that it
means that the IP address that each pod gets
may change a number of times.
This brings us to our final resource
for which we must configure an IP range at cluster
creation, Kubernetes services.
Kubernetes services are how clients within a cluster
can access a target set of pods via a stable virtual IP, known
as cluster IP in Kubernetes.
At cluster creation time, we must define a private range
for those service cluster IPs.
Client pods can access other pods
in the cluster via a cluster IP associated with their service.
This IP address will remain stable,
even as the target pods scale up and down
or shuffle across the cluster.
Hopefully, you've gotten a good picture
of what needs to be configured at cluster creation time.
Given that this IP address management
can require careful planning, GKE has introduced two features
to make this process easier.
The first feature is Flexible Pod CIDR.
Earlier, we talked about how each node, by default,
will get a /24 from which they can assign IP addresses
to their Pods.
But what if we only plan on running 30 pods on a node?
We could potentially strand many IP addresses.
Flexible Pod CIDR allows users to reduce the number of IPs
that nodes in a node pool are given to assign to their pods.
For example, in Node Pool A, each node is configured to have
a range smaller than a /24 from which they can allocate IP
addresses to their pods.
This helps users reduce stranded IP addresses,
which is huge when trying to plan out cluster networking.
But what do we do when we cannot predict how many pods we may
actually need to run in our cluster?
This is where the second GKE feature comes into play,
discontiguous multipod CIDR.
Rather than trying to get a single pod range
size correct at cluster creation time,
this feature allows users to incrementally increase
the IP range provided for pods.
For example, in this diagram, we have a second pod range in blue
that we have added after cluster creation for pods.
In summary, we need to ensure we plan out
and allocate IP space for nodes, pods, and services
when we create a GKE cluster.
GKE provides additional features to help with this planning,
enabling users to preserve IP addresses
and incrementally grow their cluster's network over time.
Now that we've covered the essentials
for setting up cluster networking in GKE,
visit the links here to learn more.
With the concepts discussed in this video,
we're confident you'll be on your way
to building a GKE cluster that suits your needs.
Stay tuned as we expand on other GKE topics and GKE essentials.
[MUSIC PLAYING]