1. Entorno de contenedores
El entorno de contenedores de Kubernetes proporciona contenedores con varios recursos importantes:
- sistema de archivos, que consiste en un espejo y uno o más volúmenes
- Información sobre el propio contenedor.
- Información sobre otros objetos en el clúster
información del contenedor
El nombre de host de un contenedor es el nombre del pod en el que se ejecuta el contenedor. El nombre se puede obtener mediante el comando hostname o llamando a la función gethostname en libc.
Los nombres y espacios de nombres de los pods se pueden convertir en variables de entorno a través de la API descendente.
Las variables de entorno definidas por el usuario en una definición de pod también están disponibles en el contenedor, al igual que cualquier variable de entorno especificada estáticamente en la imagen del contenedor.
información del clúster
Todos los servicios que se estaban ejecutando cuando se creó el contenedor están disponibles como variables de entorno para ese contenedor. Los servicios aquí se limitan a servicios en el mismo espacio de nombres que los pods del nuevo contenedor y servicios en el plano de control de Kubernetes.
Para un servicio llamado foo , cuando se asigna a un contenedor llamado bar , se definen las siguientes variables:
FOO_SERVICE_HOST=<其上服务正运行的主机>
FOO_SERVICE_PORT=<其上服务正运行的端口>
Los servicios tienen direcciones IP dedicadas. Si el complemento DNS está habilitado, se puede acceder a los servicios a través de DNS en el contenedor.
2. Devolución de llamada del ciclo de vida del contenedor
descripción general
Al igual que muchos marcos de lenguaje de programación que tienen componentes de devolución de llamada de ciclo de vida, como Angular, Kubernetes proporciona devoluciones de llamada de ciclo de vida para contenedores. Las devoluciones de llamada permiten que un contenedor esté al tanto de los eventos en su ciclo de vida de administración y ejecuta el código implementado en los controladores cuando se ejecuta la devolución de llamada del ciclo de vida correspondiente.
devolución de llamada del contenedor
Hay dos devoluciones de llamada expuestas al contenedor:
PostInicio
Esta devolución de llamada se ejecuta inmediatamente después de que se crea el contenedor. Sin embargo, no hay garantía de que la devolución de llamada se ejecute antes del punto de entrada del contenedor (ENTRYPOINT). No se pasan parámetros al controlador.
Preparada
Esta devolución de llamada se llama antes de que el contenedor finalice debido a una solicitud de API o un evento de administración (como un sondeo de actividad, falla al iniciar un sondeo, preferencia de recursos, competencia de recursos, etc.). La llamada a la devolución de llamada preStop fallará si el contenedor ya está en estado terminado o completado. La devolución de llamada debe terminar de ejecutarse antes de que se emita la señal TERM utilizada para detener el contenedor. El período de gracia de finalización del Pod comienza a contar antes de que se ejecute la devolución de llamada PreStop, por lo que, independientemente del resultado de la ejecución de la función de devolución de llamada, el contenedor terminará eventualmente dentro del período de gracia de finalización del Pod. No se pasarán argumentos al controlador.
Consulte Terminación de pods para obtener una descripción más detallada del comportamiento de terminación.
Implementación del controlador de devolución de llamada
Los contenedores pueden acceder a esta devolución de llamada implementando y registrando un controlador para esa devolución de llamada. Para los contenedores, hay dos tipos de controladores de devolución de llamada que se pueden implementar:
- Exec: ejecuta un comando específico (p. ej., pre-stop.sh) en los cgroups y espacios de nombres del contenedor. Los recursos consumidos por los comandos se cuentan para el consumo de recursos del contenedor.
- HTTP: realice una solicitud HTTP a un punto final específico en el contenedor.
Se ejecuta el controlador de devolución de llamada
Cuando se invoca la devolución de llamada de gestión del ciclo de vida del contenedor, el sistema de gestión de Kubernetes ejecuta su controlador de acuerdo con la acción de devolución de llamada, httpGet y tcpSocket se ejecutan en el proceso de kubelet, mientras que el contenedor ejecuta exec.
La invocación del controlador de devolución de llamada es síncrona dentro del contexto del pod que contiene el contenedor. Esto significa que para la devolución de llamada PostStart, el punto de entrada del contenedor y la devolución de llamada se activan de forma asincrónica. Sin embargo, si la devolución de llamada se ejecuta o se bloquea durante demasiado tiempo, el contenedor no puede alcanzar el estado de ejecución.
La devolución de llamada PreStop no se ejecuta de forma asíncrona con el controlador de señales que detiene el contenedor; la devolución de llamada debe terminar de ejecutarse antes de que se pueda enviar la señal. Si la devolución de llamada de PreStop se detiene durante la ejecución, la fase del pod se convierte en Terminating y permanece en ese estado hasta que se agotan los segundos de finalización, momento en el cual se cancela el pod. Este período de gracia es para la suma del tiempo de ejecución de la devolución de llamada PreStop y el tiempo de parada normal del contenedor. Por ejemplo, si terminaciónGracePeriodSeconds es 60, la función de devolución de llamada tardó 55 segundos en terminar de ejecutarse y el contenedor tardó 10 segundos en finalizar normalmente después de recibir la señal, entonces el contenedor se eliminará antes de que pueda finalizar normalmente, porque la terminaciónGracePeriodSeconds El valor es menos que el tiempo total dedicado a las dos últimas cosas (55+10).
Mata el contenedor si fallan las devoluciones de llamada PostStart o PreStop.
Los usuarios deben hacer que sus controladores de devolución de llamada sean lo más livianos posible. Pero también hay casos en los que también es útil tener en cuenta los comandos de ejecución prolongada, como guardar el estado antes de detener un contenedor.
Garantía de devolución de llamada
La entrega de la devolución de llamada debe ser al menos una vez , lo que significa que para cualquier evento dado, como PostStart o PreStop, la devolución de llamada se puede llamar varias veces. Cómo manejar correctamente la situación de ser llamado varias veces es un problema que debe ser considerado por la implementación de devolución de llamada.
Por lo general, solo se realizará una única entrega. Por ejemplo, si el receptor de devolución de llamada HTTP está inactivo y no puede recibir tráfico, no intentará volver a enviar. Ocasionalmente, sin embargo, puede ocurrir la posibilidad de una doble entrega. Por ejemplo, si el kubelet se reinicia en medio del envío de una devolución de llamada, la devolución de llamada puede volver a enviarse después de que se reanude el kubelet.
controlador de devolución de llamada de depuración
El registro de los controladores de devolución de llamada no está expuesto en los eventos de Pod. Si el controlador falla por alguna razón, transmitirá un evento. Para PostStart, este es el evento FailedPostStartHook, para PreStop, este es el evento FailedPreStopHook. Para generar usted mismo el evento fallido FailedPostStartHook, modifique el archivo lifecycle-events.yaml para cambiar el comando postStart a "badcommand" y aplicarlo. Aquí hay un resultado de ejemplo de algunos de los eventos resultantes que ve al ejecutar kubectl describe pod lifecycle-demo :
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 7s default-scheduler Successfully assigned default/lifecycle-demo to ip-XXX-XXX-XX-XX.us-east-2...
Normal Pulled 6s kubelet Successfully pulled image "nginx" in 229.604315ms
Normal Pulling 4s (x2 over 6s) kubelet Pulling image "nginx"
Normal Created 4s (x2 over 5s) kubelet Created container lifecycle-demo-container
Normal Started 4s (x2 over 5s) kubelet Started container lifecycle-demo-container
Warning FailedPostStartHook 4s (x2 over 5s) kubelet Exec lifecycle hook ([badcommand]) for Container "lifecycle-demo-container" in Pod "lifecycle-demo_default(30229739-9651-4e5a-9a32-a8f1688862db)" failed - error: command 'badcommand' exited with 126: , message: "OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: exec: \"badcommand\": executable file not found in $PATH: unknown\r\n"
Normal Killing 4s (x2 over 5s) kubelet FailedPostStartHook
Normal Pulled 4s kubelet Successfully pulled image "nginx" in 215.66395ms
Warning BackOff 2s (x2 over 3s) kubelet Back-off restarting failed container