Error en Tanzu Kubernetes Grid: «Node has disk preassure” 

Quiero agradecer a mi colega y amigo HERNAN FANTONI, por animarme a incursionar en este mundo del blog para entregar conocimientos de las plataformas que dominamos en nuestra área y esperamos se vuelvan útiles para la comunidad, y así puedan avanzar mas rápido en la incorporación de nuevas habilidades. Por toda su mentoría y su liderazgo, gracias totales!!!

Para comenzar primero explicaremos que es el proceso de desalojo de pods, para lo cual la teoría dice lo siguiente: 

“El desalojo es un proceso en el que se solicita la finalización de un pod asignado a un nodo. Son despedidos, generalmente como resultado de no tener suficientes recursos. Por lo tanto, Kubernetes desalojará una cierta cantidad de pods del nodo para garantizar que haya suficientes recursos en el nodo. Además, Kubernetes verifica constantemente los recursos y expulsa los pods si es necesario, mediante un proceso llamado desalojo por presión de nodo (Node pressure eviction)” .

SINTOMAS: 

Cuando ejecutamos: kubectl get events -n namespace ; podemos observar alertas de «disk pressure«:

Al detallar los pods de un namespace podemos evidenciar el mensaje con dicha advertencia: kubectl describe pod -n namespace podname

CAUSA: 

En Kubernetes, los pods se pueden desalojar de un nodo debido a recursos insuficientes.  Además de finalizar el pod, cada vez que un nodo experimenta “disk preassure”, se puede activar un proceso llamado “Node pressure eviction” (Desalojo de presión de nodo), que utiliza Kubelet para realizar la recolección de elementos no utilizados y eliminar los objetos inactivos de Kubernetes para que no utilicen recursos. Cuando se finaliza un pod, Kubernetes puede generar varios archivos temporales básicos que, si no se limpian correctamente, pueden provocar que el disco se quede sin espacio. Si bien este proceso está automatizado, es posible que en ciertas ocasiones, se requiera de una intervención manual.  

SOLUCIÓN:

Conectarse al worker mediante un jumphost.  

Procedimiento creación jumphost para conexión al Worker Node: 

1) Conectarse al Supervisor Cluster. 

2) Crear una variable de entorno denominada NAMESPACE cuyo valor el vSphere Namespace donde se aprovisiona el Cluster Tanzu Kubernetes Grid de destino. 

export NAMESPACE=VSPHERE-NAMESPACE 

3) Cambiar el contexto al vSphere Namespace donde se aprovisiona el clúster de Tanzu Kubernetes Grid. 

kubectl config use-context $NAMESPACE 

4) Obtener el objeto «secret” –>TKGS-CLUSTER-NAME-ssh  

kubectl get secrets 

5) Crear un vSphere Pod con el siguiente jumpbox.yaml

apiVersion: v1
kind: Pod
metadata:
  name: jumpbox
  namespace: vSPHERENAMESPACE   #modificar con vSphere Mamespace que se desea conectar
spec:
  containers:
  - image: "photon:3.0"
    name: jumpbox
    command: [ "/bin/bash", "-c", "--" ]
    args: [ "yum install -y openssh-server; mkdir /root/.ssh; cp /root/ssh/ssh-privatekey /root/.ssh/id_rsa; chmod 600 /root/.ssh/id_rsa; while true; do sleep 30; done;" ]
    volumeMounts:
      - mountPath: "/root/ssh"
        name: ssh-key
        readOnly: true
    resources:
      requests:
        memory: 2Gi
  volumes:
    - name: ssh-key
      secret:
        secretName: SECRETKEY   #modificar con la key

Nota: Reemplazar el valor del Namespace «YOUR-NAMESPACE» con el vSphere Namespace donde se aprovisiona el clúster TKG de destino. Reemplace el valor de «secretName: YOUR-CLUSTER-NAME-ssh» con el nombre del clúster de destino. 

6) Implementar el pod aplicando la especificación jumpbox.yaml. 

kubectl apply -f jumpbox.yaml 

pod/jumpbox created 

7) Crear una variable de entorno con la dirección IP del nodo del clúster de destino ejecutando el siguiente conjunto de comandos. 

    A) Obtener el nombre de la máquina virtual de destino 

kubectl get virtualmachines 

    B) Crear la variable de entorno VMNAME cuyo valor sea el nombre del nodo de destino. 

export VMNAME=NAME-OF-THE-VIRTUAL-MACHINE 

    C) Crear la variable de entorno VMIP cuyo valor sea la dirección IP de la máquina virtual del nodo de destino. 

export VMIP=$(kubectl -n $NAMESPACE get virtualmachine/$VMNAME -o jsonpath='{.status.vmIp}’) 

8) Utilizar SSH para el nodo del clúster mediante el módulo Jump Box ejecutando el siguiente comando. 

kubectl exec -it jumpbox  /usr/bin/ssh vmware-system-user@$VMIP 

9) Confirmar la autenticidad del host ingresando al mismo

Ahora que generamos el jumhost pod, y estamos conectado podemos realizar el análisis de nuestro Worker Node 

Verificar el espacio disponible en disco del Worker Node

Con la sesión de worker obtener el uso del sistema de archivos 

df –kh 

La partición /root, no debe tener un uso mayor a 85%. Una vez que se confirmó que el problema esta en un mayor consumo del espacio del /root en el Worker Node debemos generar un espacio adicional para resolver esta problemática, finalizar la sesión del Worker Node. 

Listar los TKG Clusters disponibles en el contexto actual , con el comando:

kubectl get tanzukubernetescluster 

Elegir el Cluster que se va a editar y asignar nuevo espacio al volumen: 

kubectl edit tanzukubernetescluster/NOMBRECLUSTERTKG 

Nota: Solo puede modificar/agregar espacio a los Worker Nodes, a los Control Plane Nodes no se les puede modificar/agregar espacio. Si bien al iniciar la edición del manifiesto con el procedimiento, un Control Plane permite el agregado, al momento de guardar el cambio el sistema indicará que hay un error y no tomará el cambio. 

Modificar el manifiesto correspondiente al Cluster a editar:

Se debe modificar el manifiesto ingresando al modo edición presionando las teclas «SHIFT+i», buscar la sección WORKERS, en la línea vmClass: best-effort-xxx , agregar la siguiente información: 

volumes: 

–  capacity: 

        storage: 50Gi   #ESPACIO PARA SER AGREGADO 

    mountPath: /var/lib/containerd 

    name: containerd 

Salir del modo edición con la tecla “ESC” luego escribir «:wq! + ENTER»  para guardar los cambios realizados. 

La plataforma iniciara la actualización del cambio en los nodos agregando el espacio para la ruta seleccionada. 

Ingresar nuevamente al jumphost con el paso 8 (descrito anteriormente) y volver a verificar el espacio del Worker Node. Podremos confirmar como el consumo de /root bajo su porcentaje distribuyendo la carga con la nueva unidad de disco que agregamos: 

Ahora nuestros despliegues pueden ser implementados sin contratiempo, para este caso podemos resumir que los Worker Nodes vienen con un espacio de 16GB por default para su sistema de archivo, pero con la acción anterior hemos incrementado el espacio para la gestión del sistema archivos. 

Otra estrategia a considerar puede ser la de incrementar espacio en los OVF que contiene las imágenes de los Kubernetes Release (Content Image), esta modificación la vamos a detallar en un próximo articulo. 

Por ahora esperamos que este procedimiento pueda ayudarlos con su correcta operación. 

¡¡Hasta la próxima!!

Se autoriza la reproducción de los materiales de este blog citando la fuente e incluyendo un enlace al mismo.