Conexión a Clusters de Kubernetes y Revisión de Salud

Introducción

La conexión a clústeres de Kubernetes y la revisión de su estado de salud son actividades fundamentales para garantizar que las aplicaciones y servicios desplegados funcionen de manera óptima y sin interrupciones. Kubernetes, como plataforma de orquestación de contenedores, permite la gestión eficiente de aplicaciones en un entorno distribuido. Sin embargo, para mantener la disponibilidad y el rendimiento de estas aplicaciones, los administradores de sistemas y equipos de DevOps deben tener las herramientas y los conocimientos necesarios para conectarse a los clústeres, monitorear el estado de los recursos y tomar acciones correctivas cuando sea necesario.

Este tema aborda los métodos para conectarse de forma segura a clústeres de Kubernetes y las mejores prácticas para revisar su estado de salud, incluyendo el uso de comandos y herramientas nativas de Kubernetes para monitorear y diagnosticar problemas potenciales.

Objetivo

Objetivo General:

Capacitar a los profesionales de TI en el proceso de conexión a clústeres de Kubernetes y la revisión de su estado de salud, con el fin de garantizar la estabilidad y el correcto funcionamiento de las aplicaciones y servicios desplegados. El objetivo es que los participantes adquieran las habilidades y mejores prácticas para identificar, diagnosticar y resolver problemas de manera proactiva, asegurando la alta disponibilidad y el rendimiento de sus entornos de Kubernetes.

Laboratorio: Conexión a Clusters de Kubernetes

Antes de comenzar

Contar con el acceso al ambiente de laboratorio
Haber realizado la validación de conexión y funcionamiento
Finalizar las prácticas de laboratorio de las instalaciones de RKE2.

Inicio de laboratorio

Asegurarse de estar en el servidor bastion con el usuario student

student@lab-0-bastion:~>

Exportar la variable de entorno correspondiente al usuario en el ambiente del servidor Bastion: lab-#-aio
```
student@lab-0-bastion:~> export LAB=X
```
Crear un directorio para almacenar los archivos KUBECONFIG de cada cluster creado anteriormente:
```
mkdir -p ~/rke2_conn/aio
```
```
mkdir -p ~/rke2_conn/cluster1
```

Extraer los archivos KUBECONFIG de los clusters:

ssh student@lab-${LAB}-aio sudo cat /etc/rancher/rke2/rke2.yaml >> ~/rke2_conn/aio/aio_kubeconfig.yaml

ssh student@lab-${LAB}-master sudo cat /etc/rancher/rke2/rke2.yaml >> ~/rke2_conn/cluster1/cluster1_kubeconfig.yaml

Realizar la instalación y configuración de la herramienta kubectl en el servidor bastion:

student@lab-0-bastion:~> sudo -i

Agregue el repositorio zypper de Kubernetes.

cat <<EOF | sudo tee /etc/zypp/repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://pkgs.k8s.io/core:/stable:/v1.31/rpm/
enabled=1
gpgcheck=1
gpgkey=https://pkgs.k8s.io/core:/stable:/v1.31/rpm/repodata/repomd.xml.key
EOF

Actualice zyppery confirme la nueva incorporación del repositorio:

zypper update

Cuando aparezca este mensaje, presione 't' o 'a':

New repository or package signing key received:

Repository:       Kubernetes
Key Fingerprint:  1111 2222 3333 4444 5555 6666 7777 8888 9999 AAAA
Key Name:         isv:kubernetes OBS Project <isv:kubernetes@build.opensuse.org>
Key Algorithm:    RSA 2048
Key Created:      Thu 25 Aug 2022 01:21:11 PM -03
Key Expires:      Sat 02 Nov 2024 01:21:11 PM -03 (expires in 85 days)
Rpm Name:         gpg-pubkey-9a296436-6307a177

Note: Signing data enables the recipient to verify that no modifications occurred after the data
were signed. Accepting data with no, wrong or unknown signature can lead to a corrupted system
and in extreme cases even to a system compromise.

Note: A GPG pubkey is clearly identified by its fingerprint. Do not rely on the key's name. If
you are not sure whether the presented key is authentic, ask the repository provider or check
their web site. Many providers maintain a web page showing the fingerprints of the GPG keys they
are using.

Do you want to reject the key, trust temporarily, or trust always? [r/t/a/?] (r): a

Si aparece el mensaje siguiente, elejir la opción n:

Backend:  classic_rpmtrans
Continue? [y/n/v/...? shows all options] (y): n

Instalar kubectl y bash-completion usando zypper

zypper install -y kubectl bash-completion

Salga de la sesión del usuario root, debe asegurarse de estar en la sesión del usuario student:

lab-0-bastion:~ # exit
logout
student@lab-0-bastion:~>

Configurar el Autocompletado

student@lab-0-bastion:~> kubectl completion bash > ~/.completion-bash.sh

student@lab-0-bastion:~> source  ~/.completion-bash.sh

student@lab-0-bastion:~> echo 'source  ~/.completion-bash.sh' >> .bashrc

Salga de la sesión de usuario student, e ingrese nuevamente:

student@lab-0-bastion:~> exit
logout

ssh lab-0-bastion.mx-g01.ws.itmlabs.io -l student -i student-0-private_key.pem

student@lab-0-bastion:~>

Conexión a Cluster AIO: Puedes usar el siguiente comando sed para reemplazar la línea server: https://127.0.0.1:6443 por server: https://lab-0-aio.c.mx-g01.internal:6443 en el archivo /home/student/rke2_conn/aio/aio_kubeconfig.yaml. Asegurarse de reemplazar por los valores correspondientes.

sed -i 's|server: https://127.0.0.1:6443|server: https://lab-0-aio.c.mx-g01.internal:6443|' /home/student/rke2_conn/aio/aio_kubeconfig.yaml

Verificar que se haya ejecutado el cambio en el archivo:

grep 6443 /home/student/rke2_conn/aio/aio_kubeconfig.yaml

Verificar la conexión a All In One Cluster

kubectl --kubeconfig=/home/student/rke2_conn/aio/aio_kubeconfig.yaml get nodes -L cluster

La salida debería de ser similar a la siguiente:

student@lab-0-bastion:~> kubectl --kubeconfig=rke2_conn/aio/aio_kubeconfig.yaml get nodes -L cluster
NAME                          STATUS   ROLES                       AGE   VERSION          CLUSTER
lab-0-aio.c.mx-g01.internal   Ready    control-plane,etcd,master   16h   v1.30.5+rke2r1   rancher
student@lab-0-bastion:~>

Conexión a Cluster 1: Puedes usar el siguiente comando sed para reemplazar la línea server: https://127.0.0.1:6443 por server: https://lab-0-master.c.mx-g01.internal:6443 en el archivo /home/student/rke2_conn/cluster1/cluster1_kubeconfig.yaml. Asegurarse de reemplazar por los valores correspondientes.
```
sed -i 's|server: https://127.0.0.1:6443|server: https://lab-0-master.c.mx-g01.internal:6443|' /home/student/rke2_conn/cluster1/cluster1_kubeconfig.yaml
```
Verificar que se haya ejecutado el cambio en el archivo:
```
grep 6443 /home/student/rke2_conn/cluster1/cluster1_kubeconfig.yaml
```

Verificar la conexión a Cluster 1.

kubectl --kubeconfig=/home/student/rke2_conn/cluster1/cluster1_kubeconfig.yaml get nodes -L cluster

La salida debería de ser similar a la siguiente:

student@lab-0-bastion:~> kubectl --kubeconfig=/home/student/rke2_conn/cluster1/cluster1_kubeconfig.yaml get nodes -L cluster
NAME                             STATUS   ROLES                       AGE   VERSION          CLUSTER
lab-0-master.c.mx-g01.internal   Ready    control-plane,etcd,master   17h   v1.29.9+rke2r1   cluster1
lab-0-node1.c.mx-g01.internal    Ready    <none>                      17h   v1.29.9+rke2r1   
lab-0-node2.c.mx-g01.internal    Ready    <none>                      17h   v1.29.9+rke2r1   
student@lab-0-bastion:~>

Estado de salud de un cluster de Kubernetes

Dentro de las tareas administrativas en un cluster de Kubernetes, está la revisión de salud de todos los componentes importantes para que el cluster funcione adecuadamente, Los comandos/pasos enumerados en esta sección, se pueden usar para verificar los recursos de Kubernetes más importantes y aplicarlos a los clústeres de Kubernetes instalados por Rancher.

Laboratorio: Estado de salud de un cluster de Kubernetes

Descripción

El estudiante aprenderá a verificar el estado de salud del cluster de Kubernetes y sus componentes más importantes.

Objetivos

Verificar el estado de salud del cluster de Kubernetes
Verificar el estado de salud desde Rancher Manager Server

Antes de comenzar

Contar con los accesos y permisos a nivel administrador en el cluster de Kubernetes y Rancher Manager Server

Inicio de laboratorio

Establesca la conexión hacia cluster1 como predeterminada ejecutando los siguientes comandos dentro del servidor Bastion: Asegurarse de estar en el servidor Bastion con el usuario student:
```
student@lab-0-bastion:~>
```
Listar y verificar los archivos dentro del directorio /home/student/rke2_conn/cluster1/:
```
ls -ltr /home/student/rke2_conn/cluster1/
```
Copiar el archivo KUBECONFIG hacia la ubicación predeterminada del cliente kubectl:
```
cp /home/student/rke2_conn/cluster1/cluster1_kubeconfig.yaml /home/student/.kube/
```
Cambiarle nombre al archivo KUBECONFIG:
```
mv /home/student/.kube/cluster1_kubeconfig.yaml /home/student/.kube/config
```
Verifique que la conexión al cluster está funcionando correctamente
```
kubectl version --output=yaml
```
Verifique el estado de los servidores de componen el cluster
```
kubectl get nodes
```
Vista extendida de los nodos
```
kubectl get nodes -o wide
```
Verifique el consumo de recursos de hardware de todos los servidores del cluster
```
kubectl top nodes
```
Verifique el consumo de recursos de un servidor en particular
```
kubectl top node (Node-Name)
```
Revise la configuración de los nodos
```
kubectl describe node (Node-Name)
```

Ejecute el siguiente comando para listar nodos con Node Conditions

kubectl get nodes -o go-template='{{range .items}}{{$node := .}}{{range .status.conditions}}{{$node.metadata.name}}{{": "}}{{.type}}{{":"}}{{.status}}{{"\n"}}{{end}}{{end}}'

Revise los servicios principales en el Namespace KUBE-SYSTEM
```
kubectl get pods -n kube-system
```
Verifique que los PODS de cattle-cluster-agent estan presentes en el cluster, que se encuentran en estado Running y que no tienen una alta cantidad de reinicios:
```
kubectl -n cattle-system get pods -l app=cattle-cluster-agent -o wide
```

Verifique los logs de los PODS de cattle-cluster-agent:

kubectl -n cattle-system logs -l app=cattle-cluster-agent

El Ingress Controller predeterminado es NGINX y se implementa como DaemonSet en el Namespace kube-system, ejecute el siguiente comando para verificar su estado:
```
kubectl -n kube-system get pods -o wide
```

Si un POD no se ejecuta correctamente (Su estado es: not Running, si su estado Ready no muestra: 1/1 o si se observan muchos reinicios), debe revisar los detalles del POD, logs y eventos del Namespace.

kubectl -n kube-system describe pods -l app.kubernetes.io/instance=rke2-ingress-nginx

kubectl -n kube-system logs -l app.kubernetes.io/instance=rke2-ingress-nginx

kubectl -n kube-system logs <pod name>

kubectl -n kube-system get events

Puede revisar la configuración generada en cada POD del Ingress Controller

kubectl -n kube-system get pods -l app.kubernetes.io/instance=rke2-ingress-nginx --no-headers -o custom-columns=.NAME:.metadata.name | while read pod; do kubectl -n kube-system exec $pod -- cat /etc/nginx/nginx.conf; done

Revise servicios complementarios que tenga instalados, como por ejemplo los siguientes:
```
kubectl get pods -n cattle-logging-system
```
```
kubectl get pods -n cattle-monitoring-system
```
```
kubectl get pods -n longhorn-system
```
Puede que no cuente con todos los servicios listados en este numeral instalados.

Revise el estado de los recursos Deployments

kubectl get deployments --all-namespaces

Revise el estado de los recursos Deployments
```
kubectl get deployments -n (Namespace)
```
Verifique el estado de todos los pods, los cuales deebrían de esta en un estado Running/Completed:
```
kubectl get pods -A
```
Vista extendida de los pods
```
kubectl get pods -A -o wide
```

Revise el detalle de un POD como se muestra en el siguiente ejemplo:

kubectl describe pod POD_NAME -n NAMESPACE

kubectl describe pod rke2-metrics-server-6cd986844b-j2f9t -n kube-system

Revise los logs de un POD como se muestra en el siguiente ejemplo:

kubectl logs POD_NAME -n NAMESPACE

kubectl logs rke2-metrics-server-6cd986844b-j2f9t -n kube-system

kubectl logs -f rke2-metrics-server-6cd986844b-j2f9t -n kube-system

Presione CTRL+C para salir.

Verifique el estado de todos los pods qué se encuentran en estado diferente de “Running”
```
kubectl get pods -A | grep -v Running | grep -v Completed
```
Si todo marcha bien el el cluster, la salida del comando anterior debería de ser vacia.

Revise los PODS que se encuentran en estado Evicted:

kubectl get pods --all-namespaces -o go-template='{{range .items}}{{if eq .status.phase "Failed"}}{{if eq .status.reason "Evicted"}}{{.metadata.name}}{{" "}}{{.metadata.namespace}}{{"\n"}}{{end}}{{end}}{{end}}'

Si todo marcha bien el el cluster, la salida del comando anterior debería de ser vacia.

Verifique el consumo de recursos de los pods

kubectl top pods -n (Namespace)

kubectl top pods -n kube-system

Verifique los eventos de un Namespace

kubectl get events -n (Namespace)

kubectl get events -n kube-system

Verifique que los servicios de DNS estan ejecutándose correctamente:
```
kubectl -n kube-system get pods -l k8s-app=kube-dns
```
Verifique que el Servicio de DNS se encuentra presente y con el cluster-ip correctamente:
```
kubectl -n kube-system get svc -l k8s-app=kube-dns
```
Compruebe si los nombres de los clústeres internos se están resolviendo (en este ejemplo, kubernetes.default), la IP que se muestra después Server: debe ser la misma que la CLUSTER-IP del servicio kube-dns.
```
kubectl run -it --rm --restart=Never busybox --image=busybox:1.28 -- nslookup kubernetes.default 2>/dev/null
```

Compruebe si los nombres externos se están resolviendo correctamente (en este ejemplo, www.google.com)

kubectl run -it --rm --restart=Never busybox --image=busybox:1.28 -- nslookup www.google.com 2>/dev/null

Verifique los logs del servicio de DNS

kubectl -n kube-system logs -l k8s-app=kube-dns

Verifique la configuración del servicio DNS:
```
kubectl -n kube-system get configmap rke2-coredns-rke2-coredns -o go-template={{.data.Corefile}}
```
Nota: Verificar los comandos anteriores desde la Web Console de Rancher también en posible.