Proceso de Actualización del Cluster

Sabemos que Kubernetes es una maraña de proyectos. Vamos a enfocarnos solo en estos por ahora.

No es obligatorio que todos los componentes estén en la misma versión, pero como todos se comunican con el kube-apiserver, nadie puede estar en una versión superior a él.

Tenemos la excepción del kubectl que puede estar con 1 más hasta uno menos para dar comandos en el cluster. La regla para esta distorsión es la siguiente considerando el minor.

Esto nos permite hacer la actualización de componentes por componente separadamente.

Ahora vamos a las recomendaciones para un upgrade del cluster considerando la regla que tenemos arriba. No podemos tener una distorsión mayor que 2 entre kube-apiserver y kubelet y kube-proxy.

Vamos a imaginar que estamos en la versión 1.10 y fue lanzada la versión 1.11 y 1.12. Sería ok hacer el upgrade de los componentes del master con esa diferencia de 2 para los nodos workers que contienen el kubelet y el kube-proxy.

Si la versión 1.13 fuera lanzada ya no sería más posible. El mejor momento para hacer el upgrade de un cluster es antes de la próxima versión no soportable.

Para no estar haciendo upgrade todo el tiempo, es interesante esperar esa diferencia de 2, pero nunca de 3.

Lo ideal y recomendable es que se haga el upgrade 1 por 1.

El proceso de upgrade depende mucho de cómo fue construido el cluster.

• En clouds, generalmente con pocos clics podemos hacer el upgrade de un cluster entero, pues ellos nos dan esa facilidad.

• Si fue construido un cluster usando kubeadm podemos utilizar el propio kubeadm para hacer el upgrade.

• Si el cluster fue construido desde cero necesita ser hecho manualmente.

Kubeadm Update

Son necesarias 2 etapas para actualizar un cluster.

• Primero actualizar TODOS los masters

  • Mientras los masters están sufriendo actualizaciones no es posible crear, eliminar y modificar nada en el cluster, pero lo que ya existe funciona normalmente siempre que los nodos no queden fuera.
  • Si algo se detiene, por ejemplo un pod muere, no será recreado pues los controllers están sufriendo update.
  • No es posible acceder al cluster usando kubectl pues el kube-apiserver estará sufriendo update también.
  • Cuando los nodos master vuelvan todo debe funcionar normalmente.
  • Recordando que solamente debe estar como máximo 2 versiones por encima del kubelet y del kube-proxy que corren en los workers.

• Segundo actualizar los nodos

  • Estrategia all in once (todos de una vez)
    • Si se hace el upgrade de todos los workers de una vez, todas las aplicaciones del cluster quedarán inoperantes.
    • Cuando los nodos estén listos nuevas aplicaciones serán agendadas para los nodos y todo deberá volver a funcionar normalmente.
  • Estrategia one node as time a time (Uno por vez)
    • Usamos la estrategia de drenar los un nodo por vez y hacer el update de este nodo.
  • Agregar nuevos nodos con versiones más recientes
    • Este caso es uno de los mejores escenarios principalmente si está con el cluster en una cloud en lugar de un ambiente on premises.
    • Una vez agregados nuevos nodos, podemos ir eliminando los nodos antiguos ya que los pods serán automáticamente reubicados para los nuevos nodos (con recurso disponible).
    • Buen momento para actualización del sistema operativo.

Un detalle muy importante; la versión mostrada abajo es la versión del Kubelet dentro de cada uno de los nodos.

Dependiendo del tipo de instalación, caso el Kubelet no esté disponible en el master, él ni aparecería aquí. O sea, el comando get nodes solamente trae los nodos con el Kubelet instalado.

kubectl get nodes
NAME                       STATUS   ROLES                  AGE     VERSION
k3d-k3s-default-agent-1    Ready    <none>                 2d13h   v1.27.4+k3s1
k3d-k3s-default-agent-0    Ready    <none>                 2d13h   v1.27.4+k3s1
k3d-k3s-default-server-0   Ready    control-plane,master   2d13h   v1.27.4+k3s1

El comando kubeadm no actualiza el Kubelet

En el nodo master puedes correr el comando para ver cuáles son los posibles upgrade. Aunque sea posible hacer dos upgrades hacia adelante debes hacer uno a la vez.

El kubeadm mantiene las versiones iguales de los componentes de Kubernetes entonces haz el upgrade de él para la versión que va a instalar.

Siempre es bueno seguir la documentación https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/

Pero aquí va un breve resumen.

Solo de observar esto podemos ver que siempre es bueno ir de uno en uno en el minor.

Actualiza el repositorio para la versión que deseas hacer el update.

# En este ejemplo tenemos la versión 1.28, pero si fuera hacer para 1.29 edita el archivo abajo.
nano /etc/apt/sources.list.d/kubernetes.list
deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.28/deb/ /

sudo apt update
sudo apt-cache madison kubeadm
sudo apt-get install kubeadm

sudo apt-mark unhold kubeadm && \
sudo apt-get update && sudo apt-get install -y kubeadm='1.28.x-*' && \
sudo apt-mark hold kubeadm

kubeadm version

# Generalmente en masters no se tienen pods corriendo que es la buena práctica pero si tiene necesita drenar.
kubectl drain <node_name_master> --ignore-daemonsets

# Actualiza el repo
apt-get update

# Generalmente estos paquetes están marcados para no ser actualizados
apt-mark unhold kubeadm
apt-get upgrade -y kubeadm=1.XX+1.0-00
#apt-get upgrade -y kubeadm=1.XX+1.0-00 --allow-downgrade
apt-mark hold kubeadm # Marca nuevamente
# El kubeadm también actualiza el kubectl, pero siempre es bueno conferir

# Ahora puedes ejecutar nuevamente el plan para ver hasta dónde puedes ir con el nuevo kubeadm
kubeadm upgrade plan
# Ahora con la versión del kubeadm correcta
kubeadm upgrade apply v1.XX.Y

# Si son otros control planes en lugar del primero solamente actualiza
kubeadm upgrade node

# Caso el master tenga el kubelet, es necesario actualizar también
apt-mark unhold kubelet
apt-get upgrade -y kubelet=1.XX+1.0-00 --allow-downgrades
apt-mark hold kubelet

systemctl daemon-reload
systemctl restart kubelet

# Si en el caso tuvo que drenar
kubectl uncordon <node_name_master>

Ahora cada uno de los nodos workers (uno por uno).

kubectl drain nodeX --ignore-daemonsets # Drenar los pods
cat /etc/*release*  # mostrará para ti cuál distro es (Si fuera diferente de ubuntu)

# También necesita hacer el upgrade del kubeadm
apt-mark unhold kubeadm
apt-get upgrade -y kubeadm=1.XX+1.0-00
apt-mark hold kubeadm

sudo kubeadm upgrade node # Pero necesita llamar después para actualizar con los masters

# Ahora vamos a hacer del kubectl y del kubelet
apt-mark unhold kubelet kubectl
apt-get upgrade -y kubelet=1.XX+1.0-00 kubectl=1.XX+1.0-00 # dentro del nodo actualiza el kubelet
apt-mark hold kubelet kubectl

systemctl daemon-reload
systemctl restart kubelet # para reiniciar el servicio con el nuevo binario

kubectl uncordon nodeX # libera el nodo para schedule

Todo esto debe ser hecho nuevamente después que hagamos un cluster from scratch usando también el kubeadm.

Es bueno hacer las pruebas con más de un master.