¿Qué hace que un nodo de Kubernetes no esté en buen estado?

Question

Hemos experimentado 4 AUTO_REPAIR_NODESeventos (revelados por el comando gcloud container operations list) en nuestro clúster de GKE durante el último mes. La consecuencia de la reparación automática del nodo es que el nodo se recrea y se le adjunta una nueva IP externa, y la nueva IP externa, que no estaba incluida en la lista blanca de servicios de terceros, eventualmente provocó fallas en los servicios que se ejecutan en ese nuevo nodo.

Me di cuenta de que tenemos "Reparación automática de nodos" habilitado en nuestro clúster de Kubernetes y sentí la tentación de desactivarlo, pero antes de hacerlo, necesito saber más sobre la situación.

Mis preguntas son:

1. ¿Cuáles son algunas de las causas comunes que hacen que un ganglio no esté sano en primer lugar? Estoy al tanto de este artículohttps://cloud.google.com/kubernetes-engine/docs/how-to/node-auto-repair#node_repair_processque dice, "un nodo informa unNo está listoestado en controles consecutivos por encima del umbral de tiempo dado" desencadenaría la reparación automática. Pero, ¿qué podría causar que un nodo se convierta enNo está listo?
2. También estoy al tanto de este artículo.https://kubernetes.io/docs/concepts/architecture/nodes/#node-statusque menciona la lista completa del estado del nodo: {OutOfDisk, Ready, MemoryPressure, PIDPressure, DiskPressure, NetworkUnavailable, ConfigOK}. Me pregunto, si algo de {OutOfDisk, MemoryPressure, PIDPressure, DiskPressure, NetworkUnavailable} se vuelve verdadero para un nodo, ¿ese nodo se convertiría en NotReady?
3. ¿Qué consecuencias negativas podría tener después de desactivar la "Reparación automática de nodos" en el clúster?Básicamente me pregunto si podríamos terminar en una situación peor que la de los nodos reparados automáticamente y las IP recién conectadas y no incluidas en la lista blanca.. Una vez que se deshabilita la "Reparación automática de nodos", para los pods que se ejecutan en un nodo en mal estado que se habría reparado automáticamente, ¿Kubernetes crearía nuevos pods en otros nodos?

Answer 1

1. Básicamente, el maestro realiza una verificación de estado del nodo. Si el nodo no puede responder, o si el nodo se declara No listo, será reparado mediante la reparación automática del nodo. También hay un detector de problemas de nodo en los nodos de GKE que puede detectar problemas en el sistema operativo.

2. Cualquiera de las condiciones mencionadas puede hacer que el nodo entre en NotReady. También existen otros factores posibles, como la repetición de errores a nivel del sistema operativo.

3. Desactivar la reparación automática de nodos puede hacer que los nodos pasen a NotReady y permanezcan así. Aunque en muchas ocasiones el nodo intentará solucionar el problema eliminando pods o procesos, es posible que un nodo se atasque en NotReady.

En lugar de deshabilitar la reparación automática de nodos, recomendaría cambiar su configuración debido al requisito de inclusión en la lista blanca. En cambio, puedesconfigurar una puerta de enlace NAT para todo el tráfico saliente de GKE; puede asignar una IP estática a la NAT y solo preocuparse por incluir esa IP en la lista blanca. Ya no tendrá que preocuparse de que los Nodos cambien de IP.