Overview
In this chapter, we will discuss how to upgrade your cluster without downtime. We will first understand the need to keep your Kubernetes cluster up to date. Then, we will understand basic application deployment strategies that can help zero-downtime upgrades of the Kubernetes cluster. We will then put these strategies into action by performing an upgrade on a Kubernetes cluster with no downtime for your application.
We learned how to set up a multi-node Kubernetes platform on AWS using kops in Chapter 11, Build Your Own HA Cluster. In this chapter, you will learn about upgrading the Kubernetes platform to a new version. We will walk you through hands-on examples of the steps that are required to upgrade the Kubernetes platform. These exercises will also equip you with the skills required to maintain a Kubernetes cluster.
Different organizations set up and maintain their Kubernetes clusters in different ways. You saw in Chapter 12, Your Application and HA, that there are numerous ways to set up a cluster. We will present a simple technique to upgrade your cluster and, depending on the cluster you are dealing with, the exact techniques and steps that you will need to take for upgrading may be different, although the basic principles and precautions that we will mention here will be applicable regardless of how you go about upgrading your cluster.
Building up your business application and putting it out in the world is only half the game. Making your application usable by customers in a secure, scalable, and consistent way is the other half and the one that you have to keep working on. To be able to execute this other half well, you need a rock-solid platform.
In today's highly competitive environment, delivery of the latest features to customers in a timely manner is important to give your business an edge. This platform has to not only be dependable but also provide new and updated features to keep up with the demands of running modern applications. Kubernetes is a fast-moving platform and is well suited for such a dynamic environment. The pace of development and advancement of Kubernetes is evidenced by the number of commits in the official Kubernetes GitHub repository. Let's take a look at the following screenshot:
Figure 18.1: Daily commits to...
By now, you are already aware of the basic components of the Kubernetes platform. Just as a refresher, let's revisit the major components:
When we update the platform, as you will see in the later sections, we are going to utilize these components and upgrade them as separate modules.
Kubernetes...
In this section, you will see the steps required to upgrade the Kubernetes platform. Note that upgrading the underlying OS is not covered here. To meet the requirement of zero-downtime upgrades, you must have an HA Kubernetes cluster with a minimum of three masters and etcd servers, which enables frictionless upgrades. The process will take one node out of the three and upgrade it. The upgraded component then will rejoin the cluster, and then we take the second node and apply the upgrade process to it. Since, at any given time, at least two of the servers are kept available, the cluster will remain available during the upgrade.
We have guided you through the creation of an HA Kubernetes cluster in Chapter 11, Build Your Own HA Cluster. Hence, in this chapter, we will walk you through upgrading the same cluster.
As mentioned in that chapter, there are various ways of deploying and managing a Kubernetes cluster. We have opted...
When you are running Kubernetes in any capacity that is important for your organization, you will be running the platform in an HA configuration. To achieve that, the typical configuration is at least three replicas of master components, running on three different nodes. This allows you to upgrade single nodes from one minor version to the next, one by one, while still maintaining API compatibility when an upgraded node rejoins the cluster because Kubernetes provides compatibility across one minor version. This means the master components can be on different versions when you are upgrading each node at a time. The following table provides a logical flow of the versions. Let's assume you are upgrading from version 1.14 to 1.15:
Figure 18.14: Upgrade plan for three master nodes
In the following exercise, we will proceed with upgrading the Kubernetes master components.
Although Kubernetes supports compatibility between master (API server) and worker nodes (kubelet) within one minor version, it is highly recommended that you upgrade the master and worker nodes in one go. Using kops, upgrading worker nodes is similar to upgrading master nodes. Due to the backward compatibility within one minor version, the worker nodes may still work if they are not version-matched by the master nodes, but it is strongly discouraged to run different versions of Kubernetes on worker and master nodes since this may create problems for the cluster.
However, the following considerations are of extreme importance if you want to keep your application online during the upgrade:
In this chapter, you have learned that keeping your Kubernetes platform up to date is very important when it comes to providing a secure and reliable foundation for running your applications. In this fast-moving digital world, many businesses rely on critical applications and keeping them available, even though upgrading the underlying platform is important.
You have seen that a no-downtime upgrade of the platform is possible if you have set up the cluster in a high availability configuration to start with. However, the platform does not guarantee the availability of your applications unless you have designed and deployed your application in a fault-tolerant manner. One factor is to make sure that you have multiple instances of your application running and that the application is designed to handle the termination of these instances gracefully.
With that taken into account, we have seen the important considerations for upgrading your cluster in a way that the platform...
© 2020 Packt Publishing Limited All Rights Reserved
