Em um cluster Kubernetes, se você excluir um nó do servidor API, como o kubelet da máquina correspondente responderá?
Ele envia uma solicitação ao servidor API para recriar o recurso do nó ou desliga e reinicia a máquina?
Em um cluster Kubernetes, se você excluir um nó do servidor API, como o kubelet da máquina correspondente responderá?
Ele envia uma solicitação ao servidor API para recriar o recurso do nó ou desliga e reinicia a máquina?
A partir do código-fonte, quando o kubelet é executado, ele gera uma goroutine para atualizar continuamente o objeto do nó (por meio do servidor API do kubernetes) para corresponder aos próprios dados internos do kubelet. (O kubelet é capaz de criar um objeto de nó quando é inicializado pela primeira vez, mas uma vez que o objeto de nó existe, o kubelet atual não tentará criar novamente o objeto de nó se ele desaparecer.) A sincronização do nó começará a falhar depois que o objeto de nó for obtido. excluído (logs de inundação que seriam visíveis no host usando
journalctl -u kubelet
), mas não tem feedback direto sobre o funcionamento do kubelet.Enquanto isso, o plano de controle responderá ao nó excluído coletando o lixo dos objetos pod órfãos e (por meio de controladores de implantação, etc.) reprogramando-os para outros nós. Como o kubelet também monitora continuamente objetos de pod relevantes, isso irá acioná-lo para encerrar os contêineres correspondentes que estavam em execução no host original (incluindo daemonsets).
Em um cluster dimensionado dinamicamente, o cluster-autoscaler usa APIs do provedor de nuvem para desligar e abandonar máquinas cujos pods foram drenados (e também iniciar novas máquinas conforme necessário). O escalonador automático de cluster pode não estar preparado para lidar quando uma máquina que ele está gerenciando deixa de ser representada por qualquer objeto de nó. Observe que a responsabilidade pela exclusão de nós deve pertencer ao controlador de nuvem, mas o controlador de nó de nuvem não pode recriar o objeto de nó para máquinas que ainda estão em execução (pois não pode dizer se a máquina ainda está executando o kubelet, na verdade, administradores de sistemas poderia ter reaproveitado essa caixa para alguma função não relacionada ao cluster Kubernetes). Conseqüentemente, o hospedeiro zumbi pode ficar ocioso.
Observe que, idealmente, o próprio kubelet pode restaurar e manter o objeto do nó (de modo que a exclusão manual de um objeto do nó, como a exclusão manual de um pod pertencente a uma implantação, não teria efeito duradouro), e o objeto do nó só seria removido quando o kubelet sai normalmente ou o plano de controle perde contato com ele. Mas esse não é o comportamento atual.