Skip to content

Registro y Revisión de Logs en Rancher Kubernetes Engine v2

Introducción

El registro de logs es una herramienta esencial para la supervisión, resolución de problemas y auditoría de sistemas y aplicaciones. En entornos que utilizan RKE2, una distribución ligera de Kubernetes, el manejo de logs abarca tanto los servicios principales del clúster como los contenedores que se ejecutan dentro de él. Comprender dónde y cómo acceder a estos logs permite a los administradores mantener un control efectivo del estado del sistema y abordar incidentes rápidamente.

Objetivo

Objetivo General:

  • El objetivo de este tema es proporcionar una guía clara y detallada sobre cómo acceder y gestionar los logs generados por RKE2, Containerd, Kubelet y otros componentes críticos del clúster. Además, se busca explicar cómo los logs pueden utilizarse para monitorear y depurar tanto el plano de control como los contenedores en ejecución.

Logging en RKE2

El manejo de logs en RKE2 es un proceso distribuido entre diferentes componentes y ubicaciones. A continuación, se detalla cómo acceder a los logs generados en varias partes del sistema:

  1. Para acceder a los Logs en los servidores con rol de Master o Server en la terminología de RKE2 puedes establecer una sesión como el usuario student al servidor lab-#-master de la siguiente forma.

    Asegurarse de estar en el servidor bastion con el usuario student. 

    student@lab-0-bastion:~>
    Exporta la variable LAB con el número asignado del laboratorio. 
    export LAB=X
    Establece una conexión SSH hacia el servidor Master. 
    ssh student@lab-${LAB}-master
    Cambiar al usuario root 
    sudo -i

    export KUBECONFIG=/etc/rancher/rke2/rke2.yaml

    export PATH=$PATH:/var/lib/rancher/rke2/bin
    Revisar los Logs del servidor RKE2 con el siguiente comando. 
    journalctl -u rke2-server
    La salida debe ser similar a la siguiente. 
    lab-0-master:~ # journalctl -u rke2-server
Nov 21 14:02:14 lab-0-master systemd[1]: Starting Rancher Kubernetes Engine v2 (server)...
Nov 21 14:02:14 lab-0-master sh[1409]: + /usr/bin/systemctl is-enabled --quiet nm-cloud-setup.service
Nov 21 14:02:20 lab-0-master rke2[1538]: time="2024-11-21T14:02:20Z" level=warning msg="not running in CIS mode"
Nov 21 14:02:20 lab-0-master rke2[1538]: time="2024-11-21T14:02:20Z" level=info msg="Applying Pod Security Admission Configuration"
Nov 21 14:02:20 lab-0-master rke2[1538]: time="2024-11-21T14:02:20Z" level=info msg="Starting rke2 v1.30.5+rke2r1 (0c83bc82315cd61664880

  2. Logs del plano de control de Kubernetes.

    Los componentes del plano de control, como el API Server, Scheduler y Controller Manager, se ejecutan como Pods estáticos en el espacio de nombres kube-system. Sus logs pueden ser accedidos usando el comando kubectl, estando en el servidor lab-#-master y ejecuta los siguientes comandos.

    Para acceder a los logs del componente kube-apiserver: 

    kubectl --kubeconfig \
/etc/rancher/rke2/rke2.yaml logs -n kube-system -l \
component=kube-apiserver
    Para ver los logs del componente kube-scheduler: 
    kubectl --kubeconfig \
/etc/rancher/rke2/rke2.yaml logs -n kube-system -l \
component=kube-scheduler
    Para acceder a los logs del componente kube-controller-manager:
    kubectl --kubeconfig \
/etc/rancher/rke2/rke2.yaml logs -n kube-system -l \
component=kube-controller-manager
    Explora los Logs de cada comando y posteriormente puedes salir de la sesión del servidor: 
    lab-0-master:~ # exit

    student@lab-0-master:~> exit

  3. Para acceder a los Logs en los servidores con rol de Worker o Agent en la terminología de RKE2 puedes establecer una sesión como el usuario student al servidor lab-#-node1 de la siguiente forma:

    Asegurarse de estar en el servidor bastion con el usuario student 

    student@lab-0-bastion:~>
    Exporta la variable LAB con el número asignado del laboratorio: 
    export LAB=X
    Establece una conexión SSH hacia el servidor Master: 
    ssh student@lab-${LAB}-node1
    Cambiar al usuario root 
    sudo -i
    Revisar los Logs del servidor RKE2 con el siguiente comando: 
    journalctl -u rke2-agent
    La salida debe ser similar a la siguiente: 
    lab-0-node1:~ # journalctl -u rke2-agent
Nov 21 14:02:09 lab-0-node1 systemd[1]: Starting Rancher Kubernetes Engine v2 (agent)...
Nov 21 14:02:09 lab-0-node1 sh[1227]: + /usr/bin/systemctl is-enabled --quiet nm-cloud-setup.service
Nov 21 14:02:15 lab-0-node1 rke2[1267]: time="2024-11-21T14:02:15Z" level=warning msg="Unknown flag --write-kubeconfig-mode found in config>
Nov 21 14:02:15 lab-0-node1 rke2[1267]: time="2024-11-21T14:02:15Z" level=warning msg="not running in CIS mode"
Nov 21 14:02:15 lab-0-node1 rke2[1267]: time="2024-11-21T14:02:15Z" level=info msg="Applying Pod Security Admission Configuration"
Nov 21 14:02:15 lab-0-node1 rke2[1267]: time="2024-11-21T14:02:15Z" level=info msg="Starting rke2 agent v1.30.5+rke2r1 (0c83bc82315cd616

  4. Logs de Containerd.

    El runtime de contenedores Containerd, utilizado por RKE2, genera sus logs en la siguiente ubicación /var/lib/rancher/rke2/agent/containerd/containerd.log puedes revisarlos con el siguiente comando.

    tail -f /var/lib/rancher/rke2/agent/containerd/containerd.log
    Estos logs proporcionan información valiosa sobre la gestión de contenedores, incluido el inicio, detención y fallos.

  5. Logs del Kubelet.

    El servicio kubelet, que gestiona los nodos en Kubernetes, escribe sus logs en /var/lib/rancher/rke2/agent/logs/kubelet.log puedes revisarlos con el siguiente comando: 

    tail -f /var/lib/rancher/rke2/agent/logs/kubelet.log
    Estos logs son esenciales para diagnosticar problemas relacionados con la asignación de pods, la conexión con el plano de control y el estado general del nodo.

  6. Logs de kube Proxy.

    Usando journalctl puedes revisar los Logs de kube-proxy: 

    journalctl -u rke2-agent -f | grep kube-proxy

  7. Logs de los contenedores. Cada contenedor ejecutado en el clúster escribe sus logs en la ubicación /var/log/pods puedes revisarlos con los siguientes pasos. 

    cd /var/log/pods/kube-system_rke2-coredns-rke2-coredns... # Completa este comndo con el nombre correcto del directorio

    cd coredns/

    ls -ltr 

    -rw-r----- 1 root root 598 Nov 21 00:42 4.log
-rw-r----- 1 root root 408 Nov 21 14:05 5.log

    cat 4.log
    La salida debe mostrar algo similar a lo siguiente: 
    2024-11-20T19:52:23.690281859Z stdout F .:53
2024-11-20T19:52:23.690484069Z stdout F [INFO] plugin/reload: Running configuration SHA512 = c18591e7950724fe7f26bd172b7e98b6d72581b4a8fc4e5fc4cfd08229eea58f4ad043c9fd3dbd1110a11499c4aa3164cdd63ca0dd5ee59651d61756c4f671b7
2024-11-20T19:52:23.69058696Z stdout F CoreDNS-1.11.1
2024-11-20T19:52:23.690727501Z stdout F linux/amd64, go1.22.7 X:boringcrypto, ae2bbc29b
2024-11-21T00:42:21.629712527Z stdout F [INFO] SIGTERM: Shutting down servers then terminating
2024-11-21T00:42:21.645889053Z stdout F [INFO] plugin/health: Going into lameduck mode for 5s

  8. También es posible acceder a estos logs usando crictl, una herramienta CLI para interactuar con Containerd. Para utilizar este método, primero, exporta la variable de entorno para el endpoint del runtime de contenedores y la ubicación de los archivo binarios. 

    export PATH=$PATH:/var/lib/rancher/rke2/bin

    export CRI_CONFIG_FILE=/var/lib/rancher/rke2/agent/etc/crictl.yaml

  9. Listar los pods con una la etiqueta de los servicios de coredns. 

    crictl pods --label k8s-app=kube-dns
    La salida debe ser similar a la siguiente: 
    POD ID              CREATED             STATE               NAME                                         NAMESPACE           ATTEMPT             RUNTIME
cd1666a923d83       7 hours ago         Ready               rke2-coredns-rke2-coredns-55bf79979b-kh2rt   kube-system         5                   (default)
1c8aff9569130       25 hours ago        NotReady            rke2-coredns-rke2-coredns-55bf79979b-kh2rt   kube-system         4                   (default)

  10. Listar los conteendores dentro de un Pod utilizando su ID con el comando crictl ps --pod <POD ID. 

    crictl ps --pod cd1666a923d83 # Reemplazar con un ID válido
    La salida debe ser similar a la siguiente: 
    CONTAINER           IMAGE               CREATED             STATE               NAME                ATTEMPT             POD ID              POD
eda719d12b756       1ebdf98f6ac9e       7 hours ago         Running             coredns             5                   cd1666a923d83       rke2-coredns-rke2-coredns-55bf79979b-kh2rt

  11. Varifica los logs del contenedor con el siguiente comando crictl logs <CONTAINER_ID>: 

    crictl logs eda719d12b756 # Reemplazar con un ID válido
    Salida del log de ejemplo: 
    .:53
[INFO] plugin/reload: Running configuration SHA512 = c18591e7950724fe7f26bd172b7e98b6d72581b4a8fc4e5fc4cfd08229eea58f4ad043c9fd3dbd1110a11499c4aa3164cdd63ca0dd5ee59651d61756c4f671b7
CoreDNS-1.11.1
linux/amd64, go1.22.7 X:boringcrypto, ae2bbc29b

Conclusión

Esta guía proporciona una referencia centralizada para acceder y analizar los logs en un clúster RKE2. Dominar estas herramientas y ubicaciones permite a los administradores identificar problemas rápidamente y mantener la estabilidad del clúster. Es esencial incluir estas prácticas como parte de las rutinas operativas para garantizar un monitoreo efectivo del sistema.