Dominando las Primitivas de Kubernetes: La Clave para Aplicaciones Autónomas. Bloque 2. Tema 2.5 del CKA.

Kubernetes se ha convertido en el estándar para la orquestación de contenedores, no solo por su capacidad de ejecutar aplicaciones en clústeres distribuidos, sino también por los mecanismos avanzados que ofrece para garantizar que estas aplicaciones sean autosuficientes, es decir, capaces de recuperarse automáticamente de fallos y de escalar según sea necesario. En este artículo, profundizaremos en las primitivas clave que Kubernetes utiliza para gestionar estas aplicaciones autosuficientes y cómo se configuran para mantener una alta disponibilidad y rendimiento en tus cargas de trabajo.

Definición:

 Una primitiva es un componente básico o unidad fundamental que se utiliza para construir y gestionar aplicaciones dentro del clúster. Son las piezas esenciales sobre las que se estructura y organiza todo el sistema, como los Pods, Service, ReplicaSet, Deployment, StatefulSet, DaemonSet, Jobs y Cronjobs.

Estas primitivas son los recursos que Kubernetes pone a disposición para gestionar las cargas de trabajo (workloads) y otros aspectos del sistema.    

Primitivas de Kubernetes para Aplicaciones Autosuficientes

Las primitivas de Kubernetes son los bloques fundamentales que permiten construir y desplegar las cargas de trabajo de las aplicaciones. Entre estas se encuentran recursos como Pods, Servicios, ReplicaSets, Deployments, StatefulSets y CronJobs. Cada uno de estos recursos tiene su rol en la orquestación de aplicaciones, desde la ejecución básica hasta la programación avanzada, escalado y recuperación automática.

Ejemplo de ReplicaSets y la Recuperación de Pods Fallidos

Una de las primitivas más importantes es el ReplicaSet, que garantiza que el número deseado de réplicas de un Pod esté siempre en ejecución. Si un Pod falla, Kubernetes detectará este fallo y creará uno nuevo para cumplir con el estado deseado. Esto asegura que la carga de trabajo no se vea interrumpida por fallos ocasionales de los Pods o de los nodos donde se ejecutan.

yaml:

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: example-replicaset
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: my-app-image:v1

Este ejemplo asegura que siempre haya 3 réplicas del Pod en ejecución, y si una falla, Kubernetes la reemplazará de inmediato.

Autosuficiencia Mediante Pruebas de Salud (Health Checks)

Las pruebas de salud son fundamentales para garantizar que los contenedores estén funcionando correctamente. Kubernetes proporciona tres tipos principales de probes (sondas) que permiten monitorear el estado de las aplicaciones y asegurarse de que se comportan como se espera:

1. Startup Probe: Se utiliza para verificar si una aplicación se ha inicializado completamente antes de recibir tráfico.
2. Readiness Probe: Monitorea si el contenedor está listo para manejar solicitudes. Si falla, Kubernetes dejará de enviar tráfico a ese Pod hasta que vuelva a estar listo.
3. Liveness Probe: Verifica si un contenedor está funcionando correctamente. Si falla, Kubernetes reiniciará el contenedor automáticamente.

Ejemplo de Liveness Probe con Exec

A continuación, un ejemplo de cómo configurar una liveness probe que ejecuta un comando dentro del contenedor. Si el comando devuelve un código de salida diferente de cero, Kubernetes considerará que el contenedor está fallando y lo reiniciará.

yaml:

spec:
  containers:
    - name: my-container
      image: my-app-image
      livenessProbe:
        exec:
          command:
          - cat
          - /tmp/healthy
        initialDelaySeconds: 5
        periodSeconds: 5

Este probe ejecutará el comando cat /tmp/healthy cada 5 segundos, verificando si el archivo existe. Si no existe o el comando falla, Kubernetes reiniciará el contenedor.

Programación de Pods y Escalado Automático

La programación de Pods en Kubernetes es el proceso mediante el cual el Scheduler decide en qué nodo del clúster debe ejecutarse cada Pod, basándose en la disponibilidad de recursos y otras restricciones. Este proceso asegura una distribución uniforme de las cargas de trabajo, minimizando el impacto de posibles problemas de hardware o de infraestructura.

Cluster Autoscaler y Horizontal Pod Autoscaler (HPA)

El Cluster Autoscaler es responsable de ajustar la cantidad de nodos en el clúster según la demanda. Si Kubernetes detecta que no hay suficientes recursos disponibles para ejecutar nuevas réplicas de Pods, el Cluster Autoscaler añadirá más nodos automáticamente.

Por otro lado, el Horizontal Pod Autoscaler (HPA) ajusta el número de réplicas de Pods basándose en el uso de recursos, como CPU o memoria. Esto es crucial en aplicaciones que experimentan picos de tráfico, ya que el HPA aprovisionará más Pods para manejar el aumento de la carga.

bash:

kubectl autoscale deployment my-app-deployment --cpu-percent=50 --min=2 --max=10

Este comando configura el HPA para que mantenga entre 2 y 10 réplicas de Pods, escalando automáticamente según el uso de CPU.

Especificación de Recursos y Scheduling de Pods

Kubernetes permite configurar solicitudes y límites de recursos para garantizar que los Pods solo se programen en nodos que puedan satisfacer sus necesidades de CPU y memoria.

Ejemplo de Configuración de Recursos

yaml:

resources:
  requests:
    memory: "256Mi"
    cpu: "200m"
  limits:
    memory: "512Mi"
    cpu: "500m"

En este ejemplo, el contenedor solicita 200 milicores de CPU y 256 MiB de memoria, y tiene un límite máximo de 500 milicores de CPU y 512 MiB de memoria. Estos valores permiten a Kubernetes gestionar de manera eficiente los recursos del clúster y evitar la sobrecarga de los nodos.

Estrategias de Actualización y Autosuficiencia

Kubernetes también ofrece estrategias avanzadas de actualización, como RollingUpdate y Recreate, que aseguran que las actualizaciones de la aplicación se realicen sin interrupciones o con el menor impacto posible.

• RollingUpdate: Reemplaza los Pods de manera gradual, uno por uno, minimizando el impacto en el servicio.
• Recreate: Elimina todos los Pods antiguos antes de lanzar los nuevos, útil cuando no es posible que diferentes versiones convivan al mismo tiempo.
• Rollback: Permite volver rápidamente a una versión anterior si algo sale mal durante el despliegue.

bash:

kubectl rollout undo deployment my-deployment

Este comando deshace el último despliegue y restaura la versión anterior de la aplicación.