Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Conmutación por error de un pod de Kubernetes mediante desconexiones de red
Empezaremos con un repaso de los conceptos, componentes y ajustes clave que influyen en el comportamiento de Kubernetes durante las desconexiones de red entre los nodos y el plano de control de Kubernetes. EKS es compatible con Kubernetes en su fase inicial, por lo que todos los conceptos, componentes y ajustes de Kubernetes que se describen aquí se aplican a las implementaciones de EKS y de nodos híbridos de EKS.
Se han realizado mejoras en EKS específicamente para mejorar el comportamiento de conmutación por error de los pods durante las desconexiones de la red. Para obtener más información, consulte los números #131294 y #131481 del repositorio de Kubernetes anterior. GitHub https://github.com/kubernetes/kubernetes/pull/131294
Conceptos
Pertinencias y tolerancias: en Kubernetes se utilizan restricciones y tolerancias para controlar la programación de los pods en los nodos. El controlador del ciclo de vida de los nodos establece las restricciones para indicar que los nodos no cumplen los requisitos para la programación o que los pods de esos nodos deben desalojarse. Cuando no se puede acceder a los nodos debido a una desconexión de la red, el controlador del ciclo de vida del nodo aplica el comando node.kubernetes. io/unreachable mancha con un efecto y con un efecto si se cumplen ciertas condiciones. NoSchedule NoExecute El node.kubernetes. io/unreachable taint corresponde a Ready being Unknown. NodeCondition Los usuarios pueden especificar las tolerancias de las contaminaciones a nivel de aplicación en. PodSpec
-
NoSchedule: No hay ningún pod nuevo programado en el nodo contaminado, a menos que tengan una tolerancia equivalente. Los pods que ya están en ejecución en el nodo no se desalojan.
-
NoExecute: Los módulos que no toleran la contaminación se desalojan inmediatamente. Los pods que toleran la contaminación (sin especificar TolerationSeconds) permanecen enlazados para siempre. Los pods que toleran la contaminación con un TolerationSeconds específico permanecen enlazados durante el tiempo especificado. Una vez transcurrido ese tiempo, el controlador del ciclo de vida del nodo desaloja los pods del nodo.
Arrendamientos de nodos: Kubernetes usa la API de arrendamiento para comunicar los latidos de los nodos de Kubelet al servidor de API de Kubernetes. Para cada nodo, hay un objeto de arrendamiento con un nombre coincidente. Internamente, cada latido de kubelet actualiza el campo spec.renewTime del objeto Lease. El plano de control de Kubernetes usa la marca de tiempo de este campo para determinar la disponibilidad de los nodos. Si los nodos están desconectados del plano de control de Kubernetes, no pueden actualizar spec.renewTime para su arrendamiento, y el plano de control interpreta eso como si el estado listo fuera desconocido. NodeCondition
Componentes
| Componente | Sub-component | Description (Descripción) |
|---|---|---|
|
Plano de control de Kubernetes |
servidor de API kube |
El servidor de API es un componente central del plano de control de Kubernetes que expone la API de Kubernetes. |
|
Plano de control de Kubernetes |
controlador de ciclo de vida de nodo |
Uno de los controladores que ejecuta el kube-controller-manager. Es responsable de detectar y responder a los problemas de los nodos. |
|
Plano de control de Kubernetes |
programador de kube |
Un componente del plano de control que busca los pods recién creados sin ningún nodo asignado y selecciona un nodo en el que ejecutarlos. |
|
nodos de Kubernetes |
kubelet |
Un agente que se ejecuta en cada nodo del clúster. El kubelet vigila PodSpecs y se asegura de que los contenedores descritos en ellos PodSpecs estén funcionando y en buen estado. |
Opciones de configuración
| Componente | Opción | Description (Descripción) | K8 es el valor predeterminado | EKS predeterminado | Configurable en EKS |
|---|---|---|---|---|---|
|
servidor kube-api-server |
segundos de tolerancia inalcanzables predeterminados |
Indica la tolerancia |
300 |
300 |
No |
|
controlador de ciclo de vida de nodo |
período de gracia del monitor de nodo |
La cantidad de tiempo que un nodo puede permanecer sin responder antes de ser marcado como no saludable. Debe ser N veces más que el de kubelet |
40 |
40 |
No |
|
controlador del ciclo de vida del nodo |
umbral de tamaño de clúster grande |
El número de nodos en los que el controlador del ciclo de vida del nodo considera que el clúster es grande para la lógica de desalojo. |
50 |
100 000 |
No |
|
controlador de ciclo de vida de nodo |
umbral de zona poco saludable |
El porcentaje de ganglios de una zona que no deben estar preparados para que esa zona se considere no saludable. |
55% |
55% |
No |
|
kubelet |
frecuencia de actualización del estado del nodo |
Con qué frecuencia el kubelet publica el estado del nodo en el plano de control. Debe ser compatible con el controlador del ciclo de vida del |
10 |
10 |
Sí |
|
kubelet |
etiquetas de nodos |
Etiquetas para agregar al registrar el nodo en el clúster. La etiqueta se |
Ninguno |
Ninguno |
Sí |
Conmutación por error de un pod de Kubernetes mediante desconexiones de red
El comportamiento que se describe aquí presupone que los pods se ejecutan como despliegues de Kubernetes con la configuración predeterminada y que EKS se utiliza como proveedor de Kubernetes. El comportamiento real puede variar según el entorno, el tipo de desconexión de la red, las aplicaciones, las dependencias y la configuración del clúster. El contenido de esta guía se validó con una aplicación específica, una configuración de clúster y un subconjunto de complementos. Se recomienda encarecidamente probar el comportamiento en su propio entorno y con sus propias aplicaciones antes de pasar a la producción.
Cuando hay desconexiones de red entre los nodos y el plano de control de Kubernetes, el kubelet de cada nodo desconectado no puede comunicarse con el plano de control de Kubernetes. Por lo tanto, el kubelet no puede desalojar los pods de esos nodos hasta que se restablezca la conexión. Esto significa que los pods que se ejecuten en esos nodos antes de la desconexión de la red seguirán ejecutándose durante la desconexión, siempre que no se cierren debido a ningún otro error. En resumen, puede lograr la estabilidad estática durante las desconexiones de red entre los nodos y el plano de control de Kubernetes, pero no puede realizar operaciones de mutación en los nodos o cargas de trabajo hasta que se restablezca la conexión.
Hay cinco escenarios principales que producen diferentes comportamientos de conmutación por error de los pods en función de la naturaleza de la desconexión de la red. En todos los escenarios, el clúster vuelve a estar en buen estado sin la intervención del operador una vez que los nodos se vuelven a conectar al plano de control de Kubernetes. Los escenarios siguientes describen los resultados esperados en función de nuestras observaciones, pero es posible que estos resultados no se apliquen a todas las configuraciones posibles de aplicaciones y clústeres.
Escenario 1: interrupción total del clúster
Resultado esperado: los pods de los nodos inaccesibles no se expulsan y siguen ejecutándose en esos nodos.
Una interrupción total del clúster significa que todos los nodos del clúster están desconectados del plano de control de Kubernetes. En este escenario, el controlador del ciclo de vida de los nodos del plano de control detecta que no se puede acceder a todos los nodos del clúster y cancela cualquier desalojo de los pods.
Los administradores del clúster verán el estado de todos los nodos durante la desconexión. Not Ready El estado de los pods no cambia y no se programa ningún pod nuevo en ningún nodo durante la desconexión y la posterior reconexión.
Escenario 2: Interrupción en toda la zona
Resultado esperado: los pods de los nodos inaccesibles no se expulsan y siguen ejecutándose en esos nodos.
Una interrupción total de la zona significa que todos los nodos de la zona están desconectados del plano de control de Kubernetes. En este escenario, el controlador del ciclo de vida de los nodos del plano de control detecta que no se puede acceder a todos los nodos de la zona y cancela cualquier desalojo del pod.
Los administradores del clúster verán el estado de todos los nodos durante la desconexión. Not Ready El estado de los pods no cambia y no se programa ningún pod nuevo en ningún nodo durante la desconexión y la posterior reconexión.
Escenario 3: Interrupción en la zona mayoritaria
Resultado esperado: los pods de los nodos inaccesibles no se expulsan y siguen ejecutándose en esos nodos.
Una interrupción en la mayoría de las zonas significa que la mayoría de los nodos de una zona determinada están desconectados del plano de control de Kubernetes. Las zonas de Kubernetes se definen mediante nodos con la misma etiqueta. topology.kubernetes.io/zone Si no hay zonas definidas en el clúster, una interrupción mayoritaria significa que la mayoría de los nodos de todo el clúster están desconectados. De forma predeterminada, la mayoría la define el controlador del ciclo de vida del nodounhealthy-zone-threshold, que se establece en el 55% tanto en Kubernetes como en EKS. Como large-cluster-size-threshold se establece en 100 000 en EKS, si no se puede acceder al 55% o más de los nodos de una zona, se cancela el desalojo de los pods (dado que la mayoría de los clústeres son mucho más pequeños que 100 000 nodos).
Los administradores de clústeres verán que la mayoría de los nodos de la zona están en estado Not Ready durante la desconexión, pero el estado de los pods no cambiará y no se reprogramarán en otros nodos.
Tenga en cuenta que el comportamiento anterior solo se aplica a los clústeres de más de tres nodos. En los clústeres de tres nodos o menos, se programa el desalojo de los pods de los nodos inalcanzables y se programa el desalojo de los pods nuevos de los nodos en buen estado.
Durante las pruebas, en ocasiones observamos que los pods se expulsaban exactamente de un nodo inaccesible durante las desconexiones de la red, incluso cuando no se podía acceder a la mayoría de los nodos de la zona. Todavía estamos investigando la posible causa de este comportamiento debido a una posible condición de carrera en el controlador del ciclo de vida de los nodos de Kubernetes.
Escenario 4: Interrupción en una zona minoritaria
Resultado esperado: se expulsan los pods de los nodos inaccesibles y se programan nuevos pods en los nodos disponibles que cumplen los requisitos.
Una interrupción minoritaria significa que un porcentaje menor de nodos de una zona están desconectados del plano de control de Kubernetes. Si no hay zonas definidas en el clúster, una interrupción minoritaria significa que la minoría de nodos de todo el clúster está desconectada. Como se indicó, la minoría se define mediante la unhealthy-zone-threshold configuración de node-lifecycle-controller, que es del 55% de forma predeterminada. En este escenario, si la desconexión de la red dura más de 5 minutos y 40 segundos y node-monitor-grace-period no se puede acceder a menos del default-unreachable-toleration-seconds 55% de los nodos de una zona, se programan nuevos pods en los nodos en buen estado, mientras que los de los nodos inaccesibles se marcan para su desalojo.
Los administradores de clústeres verán los nuevos pods creados en los nodos en buen estado y los de los nodos desconectados se mostrarán como. Terminating Recuerde que, aunque los pods de los nodos desconectados tengan un Terminating estado, no se expulsan por completo hasta que el nodo se vuelva a conectar al plano de control de Kubernetes.
Escenario 5: El nodo se reinicia durante una interrupción de la red
Resultado esperado: los pods de los nodos inaccesibles no se inician hasta que los nodos se vuelven a conectar al plano de control de Kubernetes. La conmutación por error de los pods sigue la lógica descrita en los escenarios 1 a 3, según la cantidad de nodos inaccesibles.
El reinicio de un nodo durante una interrupción de la red significa que se ha producido otro error (como un ciclo de alimentación, un episodio de falta de memoria u otro problema) en un nodo al mismo tiempo que se desconecta la red. Los pods que estaban ejecutándose en ese nodo cuando comenzó la desconexión de la red no se reinician automáticamente durante la desconexión si el kubelet también se ha reiniciado. El kubelet consulta al servidor de la API de Kubernetes durante el inicio para saber qué pods debe ejecutar. Si el kubelet no puede acceder al servidor de API debido a una desconexión de la red, no puede recuperar la información necesaria para iniciar los pods.
En este escenario, las herramientas de solución de problemas locales, como la crictl CLI, no se pueden usar para iniciar los pods de forma manual como medida provisional. Por lo general, Kubernetes elimina los pods fallidos y crea otros nuevos en lugar de reiniciar los pods existentes (consulta #10213
