Sequential Breakdown and Verification of the Update Process

Sequential Breakdown of the Update Process#

Let’s see what happened when we executed the kops update command.

1. Kops retrieved the desired state from the S3 bucket.

2. Kops sent requests to AWS API to change the values of the workers ASG.

3. AWS modified the values of the workers ASG by increasing them by 1.

4. ASG created a new EC2 instance to comply with the new sizing.

5. Protokube installed Kubelet and Docker and created the manifest file with the list of Pods.

6. Kubelet read the manifest file and run the container that forms the kube-proxy Pod (the only Pod on the worker nodes).

7. Kubelet sent a request to the kube-apiserver (through the dns-controller) to register the new node and join it to the cluster. The information about the new node is stored in etcd.

This process is almost identical to the one used to create the nodes of the cluster.

The above illustration shows the sequence of the steps involved in the cluster update process.

Verification of the Update Process#

Unless you are a very fast reader, ASG already created a new EC2 instance, and Kubelet joined it to the cluster. We can confirm that through the kops validate command.

The output is as follows.

We can see that now we have two nodes (there was one before) and that they are located somewhere inside the three us-east-2 availability zones.

Similarly, we can use kubectl to confirm that Kubernetes indeed added the new worker node to the cluster.

The output is as follows.

That was easy, wasn’t it? From now on, we can effortlessly add or remove nodes.

How about upgrading the cluster?

In the next lesson, we will go through the manual upgrading process of the cluster.