Este artículo explica las sondas de preparación y actividad en Kubernetes y cómo puede configurarlas para un contenedor.
¿Qué es una sonda en Kubernetes?
Las aplicaciones pueden volverse poco confiables debido a muchas razones. Debe asegurarse de que la aplicación esté en el estado deseado. Kubernetes ofrece una forma de comprobar el estado de un contenedor. Este diagnóstico de salud se llama sonda.
Formas de sondear un contenedor
El kubelet realiza un sondeo en su contenedor utilizando una de las siguientes formas:
1. ejecutivo
Kubelet ejecuta un comando dentro del contenedor. El resultado depende del código de salida del comando. Un código de salida de 0 indica un diagnóstico exitoso.
2. httpObtener
Kubelet envía unGETsolicitud al puerto especificado de la dirección IP del contenedor. Un código de respuesta entre 200 y 400 (inclusive) indica un diagnóstico exitoso.
3. tcpSocket
Kubelet intenta establecer una conexión TCP en el puerto especificado de la dirección IP del contenedor. Una conexión establecida indica un diagnóstico exitoso.
Tipos de sondas
Hay tres tipos de sondas en Kubernetes:
-
sonda de vida
-
Sonda de preparación
-
Iniciar sonda
La sonda de inicio es una adición reciente a esta lista y no se trata en este artículo.
sonda de vida
La sonda de vida detecta si el contenedor está vivo. Esto se utiliza para garantizar la disponibilidad de un pod. El kubelet no hace nada si la sonda de actividad tiene éxito porque el contenedor ya se encuentra en el estado deseado. Si falla, el kubelet elimina el contenedor y el curso de acción posterior depende de la especificaciónpolítica de reiniciodel contenedor
¿Por qué usar la sonda Liveness?
Kubelet verifica la salud de un contenedor observando el estado de suPID 1. El problema es que el estado dePID 1no refleja el estado de los procesos secundarios de un contenedor. No necesita especificar una sonda de actividad si tiene un solo contenedor de proceso. De lo contrario, debe usar una sonda de vida.
Sonda de preparación
Una sonda de preparación detecta si el contenedor está listo para atender las solicitudes de red entrantes. No desea enviar tráfico a un pod que no está listo para funcionar. Si la sonda de preparación falla, el panel de control detiene el tráfico de red al pod. Antes de que se ejecute el primer sondeo de preparación en el pod, el estado de preparación predeterminado se establece comoFailure. La sonda de preparación se ejecuta periódicamente en el contenedor durante todo su ciclo de vida.
¿Por qué utilizar la sonda de preparación?
El tráfico de red debe enviarse al contenedor una vez que se inicien todos los procesos secundarios. Sin una sonda de preparación, Kubernetes enviará tráfico de red al contenedor tan pronto comoPID 1empieza. Esto no significa que los procesos secundarios hayan comenzado. Enviar tráfico de red al contenedor en este estado puede provocar errores. La aplicación se enfrentará a errores cada vez que se reinicie el contenedor o se cree una nueva instancia de la aplicación.
Cómo configurar una sonda en Kubernetes
Una sonda se define dentro de lapods.spec.containerscampo. Cada sonda tiene los siguientes cinco parámetros:
-
segundos de retraso inicial: Esto especifica el tiempo (en segundos) que se debe esperar después de que se inicie el contenedor para que se ejecute la sonda. El valor predeterminado es 0.
-
periodoSegundos: Esto especifica el intervalo de tiempo entre cada prueba periódica. El valor predeterminado es 10.
-
tiempo de esperaSegundos: Esto especifica el tiempo que cada sonda debe esperar para obtener la respuesta. El valor predeterminado es 0.
-
umbral de éxito: Esto especifica la cantidad de sondeos exitosos que indicarían un diagnóstico exitoso. El valor predeterminado es 1.
-
Umbral de falla: Esto especifica el recuento de sondeos fallidos que indicarían un diagnóstico fallido. El valor predeterminado es 3.
Todos estos parámetros se utilizan para configurar la sonda. Para seguir esta guía, necesitará un clúster de Kubernetes y un cliente de kubectl configurados. Puede usar Vultr Kubernetes Engine para implementar un clúster de Kubernetes en la nube y probar las sondas. Configurarkubectlen su máquina y siga adelante.
Creación de una sonda de vida
Mira el siguiente archivo de configuración:
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-demo
spec:
containers:
- name: basic-container
image: registry.k8s.io/busybox
args:
- /bin/sh
- -c
- touch /tmp/healthy; sleep 20; rm -f /tmp/healthy; sleep 1000
livenessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 10
Esta configuración crea un solo contenedor y define una sonda de actividad. Esta sonda utilizaexecpara realizar el diagnóstico. Una vez creado el contenedor,touch /tmp/healthy; sleep 20; rm -f /tmp/healthy; sleep 100se ejecuta el comando. Este comando:
-
Crear un
/tmp/healthyhora de oficina -
Espere 20 segundos.
-
Borrar el
/tmp/healthyhora de oficina. -
Mantenga vivo el contenedor durante otros 1000 segundos.
observarlalivenessProbecampo bajo elcontainerscampo. Aquí es donde se define la sonda de actividad. Aquí, la sonda de actividad esperará 5 segundos después de que se cree el contenedor para iniciar el diagnóstico periódico en un intervalo de tiempo de 10 segundos. Utiliza la forma exec para realizar la sonda. Si el comandocat /tmp/healthydevuelve 0, la sonda es exitosa.
Crea la vaina:
kubectl apply -f config.yaml
Verifique los eventos del pod:
kubectl describe liveness-demo
Al final de la salida, puede esperar ver algo como:
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 25s default-scheduler Successfully assigned default/liveness-demo to probescluster-3a397dd3c5ec
Normal Pulling 25s kubelet Pulling image "registry.k8s.io/busybox"
Normal Pulled 22s kubelet Successfully pulled image "registry.k8s.io/busybox" in 3.292188263s
Normal Created 22s kubelet Created container basic-container
Normal Started 22s kubelet Started container basic-container
Hasta ahora, la cápsula está sana y funcionando. Después de 25 segundos, verifique los eventos del pod nuevamente:
kubectl apply -f config.yaml
Puedes esperar ver algo como:
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 56s default-scheduler Successfully assigned default/liveness-demo to probescluster-3a397dd3c5ec
Normal Pulling 55s kubelet Pulling image "registry.k8s.io/busybox"
Normal Pulled 52s kubelet Successfully pulled image "registry.k8s.io/busybox" in 3.292188263s
Normal Created 52s kubelet Created container basic-container
Normal Started 52s kubelet Started container basic-container
Warning Unhealthy 5s (x3 over 25s) kubelet Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory
Normal Killing 5s kubelet Container basic-container failed liveness probe, will be restarted
En el resultado, puede ver que hace 5 segundos, la sonda de actividad falló, lo que provocó que kubectl reiniciara el contenedor. Ahora, verifique el estado del pod:
kubectl get pod liveness-demo
Rendimiento esperado:
NAME READY STATUS RESTARTS AGE
liveness-demo 1/1 Running 1 (4s ago) 85s
Note que elREINICIAespectáculos de campo1lo que confirma que el contenedor se reinició.
Configuración de una sonda de preparación
La configuración de la sonda de preparación es similar a la configuración de la sonda de actividad. Puede crear una sonda similar para la verificación de preparación agregando lo siguiente en el archivo de configuración bajo elpods.spec.containerscampo.
readinessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 10
Conclusión
Este artículo explica las sondas de actividad y preparación de Kubernetes, su uso y cómo configurarlas. Para obtener más información, consulteConfigurar sondas de actividad, preparación y puesta en marchaen kubernetes.io.
Título del artículo Nombre (opcional) Correo electrónico (opcional) Descripción
Enviar sugerencia
