Orquestração de Contêineres Question #019e3a4f

Quando um nó falha no Kubernetes, quaisquer pods comuns em execução nesse nó são considerados perdidos. O ReplicationController, ReplicaSet ou Deployment que gerencia o pod detecta a discrepância entre o número desejado e real de réplicas. Em seguida, ele agenda um novo pod em um nó saudável. No entanto, o novo pod não é idêntico ao original; ele recebe um novo UID (identificador único) e, tipicamente, um novo endereço IP. O UID do pod original não é reutilizado.

Como Funciona

• Os controladores do Kubernetes monitoram continuamente o estado do cluster através do API server.
• Quando um nó falha, o kubelet nesse nó para de reportar, e o status do nó é atualizado para NotReady ou Unknown após um tempo limite (padrão de 40 segundos).
• O controller manager então detecta que o número de pods em execução para um determinado ReplicaSet está abaixo da contagem desejada.
• Ele cria um novo pod em um nó diferente, atribuindo um novo UID. O UID do pod antigo é mantido no etcd até que o objeto pod seja deletado (o que ocorre após um período de graça de falha de nó, tipicamente 5 minutos).

Por que a Resposta Correta está Certa

• A afirmação "Um novo pod quase idêntico, mas com UID diferente, é agendado em outro nó" é precisa porque o Kubernetes garante a autocura criando um pod substituto com um novo UID. O pod é "quase idêntico" porque usa a mesma imagem de contêiner, variáveis de ambiente e montagens de volume, mas sua identidade (UID) e identidade de rede (IP) mudam.

Por que as Respostas Incorretas estão Erradas

• "Um novo pod com o mesmo UID é agendado em outro nó após algum tempo" está incorreto porque o Kubernetes nunca reutiliza um UID de pod. Cada pod recebe um UID único gerado pelo API server.
• "Por padrão, um pod só pode ser agendado no mesmo nó quando o nó falha" é falso. Um nó com falha está indisponível, então o pod não pode ser agendado lá. O Kubernetes agenda o substituto em um nó diferente.
• "Um novo pod é agendado em um nó diferente apenas se configurado explicitamente" está incorreto. Esse comportamento é automático para pods gerenciados por controladores (Deployments, ReplicaSets, StatefulSets). Apenas pods estáticos ou pods criados diretamente sem um controlador não seriam reagendados automaticamente.