O que torna um nó do kubernetes insalubre?

Question

Tivemos 4% deAUTO_REPAIR_NODES de eventos (revelados pelo comando gcloud container operations list ) no nosso cluster 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 desbloqueio por serviços de terceiros, causou falha nos serviços executados naquele novo nó.

Percebi que temos " Reparo automático de nó " ativado em nosso cluster do Kubernetes e me senti tentado a desativá-lo, mas antes disso, preciso saber mais sobre a situação.

Minhas perguntas são:

1. Quais são algumas das causas comuns que tornam um nó insalubre em primeiro lugar? Estou ciente deste artigo link que diz " um nó relata um status NotReady 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 tornasse NotReady ?
2. Também estou ciente deste artigo link que menciona a lista completa de nós status: {OutOfDisk, Ready, MemoryPressure, PIDPressure, DiskPressure, NetworkUnavailable, ConfigOK}. Gostaria de saber, se algum de {OutOfDisk, MemoryPressure, PIDPressure, DiskPressure, NetworkUnavailable} se tornar verdadeiro para um nó, esse nó se tornará NotReady?
3. Quais consequências negativas eu poderia obter depois de desabilitar "Reparo automático de nó" no cluster? Estou basicamente me perguntando se poderíamos acabar em uma situação pior do que os nós reparados automaticamente e o IP recém-anexado e não listado na lista de permissões . Depois que a opção "Reparo automático de nó" estiver desativada, os Kubernetes criarão novos pods em outros nós para os pods em execução em um nó não íntegro que teria sido reparado automaticamente?

Answer 1

1. O mestre essencialmente realiza uma verificação de integridade no nó. se o nó não puder responder ou se o nó se declarar NotReady, ele será reparado pelo autorepair do nó. Há também um detector de problema de nó nos nós do GKE que pode detectar problemas no sistema operacional.

2. Qualquer uma das condições mencionadas pode fazer com que o nó entre no NotReady. Existem alguns outros fatores possíveis, como a repetição de erros no nível do sistema operacional.

3. Desativar o reparo automático do nó 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 os pods ou processos, é possível que um nó fique preso em NotReady

Em vez de desativar o reparo automático do nó, recomendamos que você altere sua configuração devido ao requisito de lista branca. Em vez disso, você pode configurar 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 terá que se preocupar mais com os Nodes mudando os IPs.