SANDEEP DINESH: Everyone knows it's a good idea
to keep your application dependencies up to date.
Kubernetes and Docker can make these updates much easier,
as you can build a new container with the updated dependencies
and deploy it with relative ease.
Just like your application dependencies,
Kubernetes is constantly getting new features and security
updates.
So the underlying nodes and Kubernetes' infrastructure
needs to be kept up to date as well.
In this episode of "Kubernetes Best Practices,"
let's take a look at how Google Kubernetes
Engine can make upgrading your Kubernetes cluster painless.
[MUSIC PLAYING]
When it comes to upgrading your cluster,
there are two parts that need to be upgraded--
the masters and the nodes.
The masters need to be updated first,
and then the nodes can follow.
Let's see how to upgrade both using Google Kubernetes Engine.
Google Kubernetes Engine will automatically
upgrade the master as point releases are released.
However, it usually won't upgrade to a new version--
for example, 1.7 to 1.8 automatically.
When you're ready to upgrade to a new version,
you can just click the Upgrade Master
button in the GKE console.
However, you may have noticed that the dialog
box has the following.
Changing the master version can result in several minutes
of control plane downtime.
During that period, you'll be unable to edit this cluster.
Wow, OK.
So when the master goes down for the upgrade,
deployments, and services, and the all that normal Kubernetes
stuff will continue to work as expected.
However, anything that requires the Kubernetes API
will stop working.
So this means [? QPTL ?] will sop working,
applications that use the Kubernetes API to get
information about the cluster will stop working,
and basically, you can't make any changes to the cluster
while it's being upgraded.
So how do you update the master with zero downtime?
While the standard zonal GKE cluster can only
have one master backing them, you
can actually create regional clusters
that provide multi-zone high-availability masters.
So when creating your cluster, be
sure to select the regional option.
And that's it.
Your nodes and masters will automatically
be created in three zones, and the masters
will be behind a load-balanced IP address.
So the Kubernetes API will continue
to work during an upgrade.
When upgrading nodes, there are a few different strategies
that you can use.
There's two that I want to focus on--
rolling updates, and migration using node pools.
The simplest way to update your Kubernetes nodes
is using a rolling update.
This is the default upgrade mechanism
that GKE uses to update your nodes.
A rolling update works in the following way.
One by one, a node is drained and cordoned
so that there are no more pods running on that node.
Then the node is deleted, and the new node
is created with the updated Kubernetes version.
Once that node is up and running,
the next node is updated, and so on and so forth,
until all the nodes are updated.
You can let GKE manage this process for you
completely by enabling automatic node upgrades on the node pool.
Now, if you don't select this option,
the GKE dashboard will alert you when an upgrade is available.
Just click the link, follow the prompts,
and you'll begin your rolling update.
It's important to make sure your pods are managed
by a replica set, deployment, stateful set, or something
similar.
Standalone pods won't be rescheduled.
So while a rolling update is simple to perform on GKE,
it does have a few drawbacks.
One drawback is you actually get one less node
of capacity in your cluster.
While it's updating, that node is
being taken out of commission.
But this issue is easily solved by scaling up your node pool
to add extra capacity, and then scaling it
back down once the upgrade is finished.
Also, the fully automated nature of the rolling update
makes it easy to do, but you have less control
over the process.
So if something goes wrong and you had to rollback,
it takes time to roll back to the old version,
because you have to stop the rolling update
and then undo it.
So now let's look at how you can use multiple node
pools to upgrade your cluster.
So instead of upgrading the active node pool,
as you would with the rolling update,
you create a brand new fresh node pool,
wait for all the nodes to be running,
and then migrate workloads over one node at a time.
Because you're running these commands yourself,
you have more control over the migration process.
But GKE is still managing the nodes for you.
So let's assume that our Kubernetes cluster has
three VMs right now.
You can see the nodes with the get node command.
To create a new node pool with the name
pool two, run the following command.
Remember to customize this command
so the new node pool is the same as the old pool.
You can also use the GUI to create a new node
pool if you want.
Check out the link for more information.
So now if you check the nodes, you'll
notice that there's three more nodes with the new pool name.
However, the pods will still be on the old nodes.
So let's move them over.
We need to move pods to the new node pool.
Let's move over one node at a time in a rolling fashion.
First, cordon each of the old nodes.
This will prevent new pods from being scheduled onto them.
Once all the old nodes are cordoned,
pods can only be scheduled onto the new nodes.
This means you can start to remove pods from the old nodes,
and Kubernetes will automatically schedule them
onto the new nodes.
Then we need to drain each node.
So this will delete all the pods on that node.
After you drain a node, make sure the new pods
are up and running before moving on to the next one.
If you have any issues during migration,
uncordon the old pool, and then cordon and drain the new pool.
And so the pods will automatically
get rescheduled back to the old pool.
Once all the pods are safely rescheduled,
it's just time to delete the old pool.
Replace default-pool with the pool you want to delete.
By using Google Kubernetes Engine,
you can keep your Kubernetes cluster up
to date with just a few clicks.
I highly recommend using GKE regional clusters
for the high-availability masters,
and using automatic node upgrades
to have a hassle-free upgrade experience.
If you need extra control for your node updates,
using node pools gives you that control
without giving up the advantages of the manage platform
that GKE gives you.
If you're not using a manage service like GKE,
you can still use a rolling update or node pools method
with your own cluster to upgrade nodes.
The difference is, you need to manually add the new nodes
to your cluster and perform the master upgrades
yourself, which can be tricky.
I'll see you on the next episode of "Kubernetes Best Practices."
[MUSIC PLAYING]