Day 8/#30daysofK8s

Versioning in K8s components —

At a time 3 minor versions are supported(think back on CFME, where at a time only 2 versions[5.10, 5.11] were supported). All the K8s components can be at the same version. There are a few rules when it comes to using components with different versions.

Components include — kube-apiserver, kubelet, kube-proxy, controller, kube-scheduler

The main component i.e. kube-apiserver can be at any supported version, but all the other components of the node must be at a version lower than it. kubectl can be at one version higher than kube-apiserver.

kubeapi-server = Version X
[if kube-apiserver is at v1.10]

X-1 ≤ controller, kube-scheduler ≤ X
[controller and kube-scheduler can be at v1.9 or v1.10]

X-2 ≤ kubelet, kube-proxy ≤ X
[kubelet and kube-proxy can be at v1.8 or v1.9 or v1.10]

X-1 ≤ kubectl ≤ X+1
[kubectl can be at v1.9 or v1.10 or v1.11]

The upgrade from (for e.g.) v1.10 to v1.12 cannot be done directly, it must go from v1.10 > v1.11 > v1.12.

These rules allow for an easy upgrade.

alias k=kubectl

• Bringing down master node does not bring down it’s worker. While it is down, all the operations related to it will be down, so if I wanted to do k get pods, that would not work, but the applications on the pods will continue to run.
• What happens when the master node is up? Don’t you need to set it up, the kube-apiserver and controller and scheduler and everything?
  I think that will be taken care of by the replicas. But does replicaset work without the kube-apiserver? Or does it create a temporary master node? That seems unlikely. What about the services running on nodes? Aren’t they disrupted by the master node/kube-apiserver being down?

After the master node has been upgraded, there are 2 strategies to upgrade the nodes — 1) Bring down all the nodes at once and then back up, this requires downtime 2) Bring down one node at a time, drain a node so that it’s pods are recreated on another node, upgrade the node, mark it schedule-able, repeat the process on another node.

kubeadm: the command to bootstrap the cluster. kubeadm does not install kubelet and kubectl

kubelet: the component that runs on all of the machines in your cluster and does things like starting pods and containers.

kubectl: the command line util to talk to your cluster.

kubeadm upgrade plan — lists out a plan for upgrading the cluster.

k upgrade apply <version> — does the actual upgrading.

It is advisable to first upgrade the kubeadmversion before upgrading the cluster. This can be done via any package manager, for e.g. dnf upgrade kubeadm . kubelet can also be upgraded in the same way.

The version that we see on k get nodes VERSIONcolumn is of kubelet on the node and not that of the node’s kube-apiserver itself.

# TODO: Learn how to upgrade nodes as below.

k drain node01
dnf upgrade kubeadm, kubelet
kubeadm upgrade node config --kubelet-version <kubelet_version>
systemctl restart kubelet.service
k uncordon node01