¿Sus cargas de trabajo de Kubernetes son realmente tan saludables como parecen? Imagine un clúster de Kubernetes bullicioso donde los Pods parecen estar ejecutándose pero encuentran fallas de estabilidad. Ante esta preocupación, ¿por qué no aprovechar las pruebas de actividad de Kubernetes?

En este tutorial, explorará la prueba de actividad de Kubernetes a través de ejemplos para que Kubernetes sepa si un Pod está activo. Las sondas son los guardianes de la estabilidad y muestran cuándo los contenedores no funcionan correctamente en el clúster de Kubernetes.

¡Embárquese en este viaje para probar Kubernetes y dominar la validación del estado de las cargas de trabajo en Kubernetes!

Requisitos previos

Antes de sumergirse en este tutorial, asegúrese de tener un Implementación de Kubernetes y su sintaxis YML para seguir junto con las demostraciones prácticas.

Creación de sondas de actividad de Kubernetes

Imagínese esto: tiene un servicio crítico en ejecución y desea asegurarse de que siempre esté activo y responda. Si, por algún motivo, su aplicación falla o se atasca en un bucle, una sonda de actividad de Kubernetes interviene y dice: “Oye, algo no está bien aquí; ¡arréglalo lo antes posible!

Una sonda de actividad es como una comprobación del pulso de sus pods, que garantiza que sus aplicaciones no solo se estén ejecutando sino que estén en buen estado y haciendo su trabajo.

Para configurar una sonda de actividad de Kubernetes en acción, debe crearla en el containers nivel de cualquier archivo YAML de implementación de Kubernetes de la siguiente manera:

1. Crea un implementación.yml archivo con su editor preferido y agregue la siguiente configuración para activar un clúster de Kubernetes mínimo usando NGINX.

En la configuración siguiente, el contenedor utiliza livenessProbe para determinar si está activo en el siguiente manifiesto de implementación.

apiVersion: apps/v1
kind: Deployment
metadata:
  # Deployment name
  name: nginx-dep
  labels:
    app: nginx-dep
spec: 
  # Replicas to deploy
  replicas: 1 
  selector:
    matchLabels:
      app: nginx-dep
  template:
    metadata:
      labels:
        app: nginx-dep
    spec:
      # Container deployment level
      containers:
        # Container name
        - name: nginx-dep 
        # Container Docker image
          image: nginx:latest
          imagePullPolicy: Always
          ports:
          # Container traffic port
          - containerPort: 80 
          # Configure the liveness probe
          livenessProbe:
          # Use an HTTP endpoint to check container health
            httpGet:
              path: /
              # Port liveness probe should check within the container
              port: 80 
              # Seconds between when the next probe should be fired.
            periodSeconds: 5  
            # Delay between first liveness probe
            initialDelaySeconds: 5

2. A continuación, ejecute lo siguiente kubectl comando para apply los cambios e implemente su archivo de manifiesto (deployment.yml).

kubectl apply -f deployment.yml

3. Una vez implementado, ejecute lo siguiente kubectl comando para get todo pods disponible para que pueda confirmar que su implementación de NGINX se está ejecutando.

Anota el nombre de tu Pod para usarlo más adelante.

4. Ahora, ejecuta el describe comando a continuación para verificar si el pod en su sonda de vida se está ejecutando.

Asegúrese de reemplazar pod_name con el nombre del Pod que anotó en el paso tres.

kubectl describe pod pod_name

Si todo va bien, verá las propiedades de la sonda de actividad implementada. La prueba de actividad de Kubernetes está bien en este nivel y el contenedor se considera activo. Las sondas de vida arrojan los siguientes resultados:

• El estado de éxito de los contenedores vivos y sanos como se muestra en la captura de pantalla siguiente.
• Un código de error como HTTP 500 (a menudo llamado “Error interno del servidor”) le indica a Kubernetes que el contenedor no está en buen estado y debe reiniciarse (como se demuestra en el paso siete).

Cuando un contenedor no se ejecuta, una sonda de actividad de Kubernetes comprueba y confirma si ese contenedor está activo. Estas comprobaciones se envían periódicamente al plano de control de Kubernetes para evaluar el estado de los contenedores que se ejecutan en un Pod.

5. Ahora, cambie el puerto de la sonda de actividad a 3000 en tus implementación.yml archivo, como se muestra a continuación, para comprobar cómo una sonda de actividad fallida detecta pods en mal estado.

El contenedor dirige el tráfico hacia el puerto. 80. Usando otros puertos como 3000 cambiará el puerto de contenedores a un puerto no emocionante. La sonda de actividad de Kubernetes no debería comprobar una conexión de tráfico válida.

6. Vuelva a ejecutar los siguientes comandos para ejecutar (apply) su deployment.yml cambios en el manifiesto y comprobar si el pod Esta corriendo.

# Apply the changes to deployment
kubectl apply -f deployment.yml
# Get all pods
kubectl get pods

Tome nota del nombre del Pod recién creado.

7. Finalmente, ejecute el kubectl comando a continuación para describe el nuevo pod. Reemplazar pod_name con el nombre asignado al que anotó en el paso seis.

kubectl describe pod pod_name

Este contenedor no expone el puerto 3000 en este ejemplo porque el containerPort está configurado en el puerto 80. Dado que el puerto no está abierto, el contenedor se considera en mal estado incluso si el Pod se ejecuta y se obtienen los siguientes resultados.

Recuerde que confirmar que un contenedor se está ejecutando no garantiza que una aplicación se esté ejecutando. Su Pod puede estar listo pero no atender solicitudes.

¡Pero no te preocupes! kubelet registrará el error como La sonda de vida falló. Al mismo, el livenessProbe mata y reinicia este contenedor automáticamente.

Presidir el tráfico entrante con el Sondas de preparación

Piense en su aplicación como una cafetería que acaba de abrir sus puertas, que puede parecer abierta, pero el barista todavía está configurando todo. En tales casos, el administrador de la cafetería (su sonda de preparación) se asegura de que todo esté en orden antes de que los clientes (o usuarios, en este caso) comiencen a llegar.

Si bien las pruebas de actividad garantizan que un Pod esté activo, Kubernetes también ofrece la prueba de preparación, que decide si el contenedor puede atender el tráfico entrante. Suponiendo que está ejecutando una aplicación web, es solo una prueba de preparación que indica si su aplicación web puede aceptar solicitudes y manejar tráfico externo.

Para ver cómo funcionan las sondas de preparación al controlar el tráfico entrante:

1. Agregue la siguiente configuración, tal como está, en la parte inferior del implementación.yml para crear una sonda de preparación, que utiliza las mismas propiedades que la sonda de actividad de Kubernetes.

# Configure the readiness probe
readinessProbe:
  # An HTTP endpoint to check container health
  httpGet:
	  path: /
    # The port readiness probe should check within the container
    port: 80
  periodSeconds: 5
  initialDelaySeconds: 5

2. A continuación, vuelva a ejecutar los siguientes comandos para ejecutar (apply) sus cambios manifiestos en el deployment.yml archiva y verifica (get) todos corriendo pods.

# Apply the changes to the deployment
kubectl apply -f deployment.yml
# Get all pods
kubectl get pods

3. Ejecute lo siguiente kubectl describe comando para verificar el despliegue readinessProbe propiedades. Asegúrate de cambiar pod_name al que anotó en el paso dos.

kubectl describe pod pod_name

La sonda de preparación garantiza que la aplicación que se ejecuta dentro de su contenedor esté 100% lista para aceptar solicitudes de red y usarse para atenderlas.

Si la prueba de preparación falla, kubelet elimina la dirección IP del Pod de los puntos finales de todos los servicios a los que pertenece. De esta manera, el Pod no forma parte del servicio y no recibirá tráfico.

4. Ahora, cambia el readinessProbe puerto en su implementación.yml archivo a un puerto diferente, como 4000. Hacerlo le permite probar qué podría suceder si cambia las propiedades del puerto y lo vuelve a implementar para probar que no está en buen estado. readinessProbe.

# Configure the readiness probe
readinessProbe:
# Use an HTTP endpoint to check container health
  httpGet:
    path: /
    # Diffrent port from the container port
    port: 4000
  # Seconds between when the next probe should be fired.
  periodSeconds: 5
  # Delay between first readiness probe
  initialDelaySeconds: 5

5. Finalmente, vuelva a ejecutar lo siguiente kubectl describe comando para verificar el recién implementado readinessProbe propiedades.

kubectl describe pod_name

A continuación, puedes ver el Falló la sonda de preparación evento. Tenga en cuenta que esta vez, a diferencia livenessProbeel readinessProbe no cerró el contenedor e intentó reiniciarlo.

Se espera este comportamiento ya que la sonda de preparación solo controla el flujo de tráfico hacia el pod en función de la preparación del contenedor para manejar solicitudes.

Conclusión

A lo largo de este tutorial, ha aprendido acerca de las pruebas de actividad de Kubernetes para mejorar el estado de sus aplicaciones. Con este nuevo conocimiento, puede implementar sus contenedores con confianza y tener la seguridad de su disponibilidad en su clúster de Kubernetes.

Ahora bien, ¿por qué no explorar la monitorización y la observabilidad de Kubernetes? ¡Prometheus y Grafana tienen información valiosa sobre todo lo que sucede dentro de su clúster!