Tivemos quatro AUTO_REPAIR_NODESeventos (revelados pelo comando gcloud container operations list) em nosso cluster do GKE durante o último mês. A consequência do reparo automático do nó é que o nó é recriado e anexado a um novo IP externo, e o novo IP externo, que não estava na lista de permissões de serviços de terceiros, eventualmente causou falha nos serviços em execução naquele novo nó.
Percebi que temos "Reparo automático de nós" ativado em nosso cluster Kubernetes e me senti tentado a desativá-lo, mas antes de fazer isso, preciso saber mais sobre a situação.
Minhas perguntas são:
- Quais são algumas das causas comuns que tornam um nó insalubre? Estou ciente deste artigohttps://cloud.google.com/kubernetes-engine/docs/how-to/node-auto-repair#node_repair_processque diz: "um nó relata umNão está prontostatus em verificações consecutivas durante o limite de tempo determinado "acionaria o reparo automático. Mas o que poderia fazer com que um nó se tornasseNão está pronto?
- Também estou ciente deste artigohttps://kubernetes.io/docs/concepts/architecture/nodes/#node-statusque menciona a lista completa de status do nó: {OutOfDisk, Ready, MemoryPressure, PIDPressure, DiskPressure, NetworkUnavailable, ConfigOK}. Eu me pergunto, se algum dos {OutOfDisk, MemoryPressure, PIDPressure, DiskPressure, NetworkUnavailable} se tornar verdadeiro para um nó, esse nó se tornará NotReady?
- Que consequências negativas eu poderia obter depois de desabilitar o "Reparo automático de nós" no cluster?Basicamente, estou me perguntando se poderíamos acabar em uma situação pior do que nós reparados automaticamente e IP recém-conectados e não incluídos na lista de permissões. Depois que o "Reparo automático de nó" for desativado, para os pods que estão sendo executados em um nó não íntegro que teria sido reparado automaticamente, o Kubernetes criaria novos pods em outros nós?
Responder1
O mestre essencialmente realiza uma verificação de integridade do nó. se o nó não puder responder ou se declarar NotReady, ele será reparado pelo reparo automático do nó. Há também um detector de problemas de nó nos nós do GKE que pode detectar problemas no sistema operacional.
Qualquer uma das condições mencionadas pode fazer com que o nó entre em NotReady. Existem também alguns outros fatores possíveis, como a repetição de erros no nível do sistema operacional.
Desativar o reparo automático de nós pode fazer com que os nós fiquem NotReady e permaneçam assim. Embora em muitas ocasiões o nó tente resolver o problema eliminando pods ou processos, é possível que um nó fique preso no NotReady
Em vez de desabilitar o reparo automático de nós, recomendo alterar sua configuração devido ao requisito de lista de permissões. Em vez disso, você podeconfigurar um gateway NAT para todo o tráfego de saída do GKE; você pode atribuir um IP estático ao NAT e apenas se preocupar em colocar esse IP na lista de permissões. Você não precisará mais se preocupar com a mudança de IP dos nós.