Guia de Resolução de Problemas Comuns e Gerenciamento de Nós no Kubernetes

Administrar clusters Kubernetes exige o domínio de certas tarefas de manutenção e a capacidade de diagnosticar falhas de conectividade entre componentes internos. Abaixo, detalhamos procedimentos essenciais para gerenciar o ciclo de vida de nós e resolver erros comuns de configuração.

1. Manutenção de Nós: Evicção e Remoção

Antes de remover fisicamente um servidor ou realizar uma manutenção, é necessário mover as cargas de trabalho (Pods) para outros nós saudáveis.

Para realizar a evicção de todos os Pods de um nó específico:

kubectl drain node-servidor-01 --force --ignore-daemonsets --delete-emptydir-data

Após esvaziar o nó, ele pode ser removido logicamente do cluster:

kubectl delete node node-servidor-01

2. Reintegrando um Nó ao Cluster

Se você precisar adicionar um nó novamente após uma remoção ou falha, o comando padrão do kubeadm é utilizado:

kubeadm join 192.168.1.100:6443 --token abcdef.1234567890abcdef \
--discovery-token-ca-cert-hash sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

Tratamento de Conflitos na Reintegração

Erros durante o join geralmente ocorrem devido a resquícios de instalações anteriores. Para limpar o ambiente e tentar novamente, siga estes passos no nó de trabalho:

  1. Redefina as configurações do kubeadm: ``` kubeadm reset -f
  2. No nó mestre (Control Plane), gere um novo comando de adesão caso o token tenha expirado: ``` kubeadm token create --print-join-command
  3. Remova containers e arquivos de configuração antigos que possam causar conflitos: ``` docker ps -qa | xargs docker rm -f rm -rf /etc/kubernetes/kubelet.conf rm -rf /etc/kubernetes/pki/ca.crt
  4. Reinicie os serviços de runtime e execute o comando join novamente: ``` systemctl restart docker kubelet
    
    

3. Corrigindo Status "Unhealthy" no Scheduler e Controller Manager

Ao executar kubectl get cs (ComponentStatus), é comum encontrar os componentes scheduler e controller-manager com status de erro, apresentando "connection refused" no endereço 127.0.0.1.

Isso geralmente ocorre porque as configurações padrão desativam as portas não seguras. Para resolver, é necessário editar os manifestos estáticos no nó mestre.

Arquivo: /etc/kubernetes/manifests/kube-controller-manager.yaml
Localize a linha que define a porta e comente-a (adicione #):

spec:
  containers:
  - command:
    - kube-controller-manager
    # - --port=0  <-- Comentar esta linha
    - --bind-address=127.0.0.1
    ...

Arquivo: /etc/kubernetes/manifests/kube-scheduler.yaml
Repita o processo para o agenaddor:

spec:
  containers:
  - command:
    - kube-scheduler
    # - --port=0  <-- Comentar esta linha
    - --bind-address=127.0.0.1
    ...

Após as alterações, reinicie o serviço do kubelet para aplicar as mudanças:

systemctl restart kubelet

4. Falha na Recuperação de Imagens em Registros Privados

Quando o Kubernetes não consegue baixar uma imagem devido a erros de autenticação (ErrImagePull ou ImagePullBackOff), é necessário configurar um segredo de registro.

Primeiro, crie o segredo com as credenciais de acesso:

kubectl create secret docker-registry credenciais-registro \
  --docker-server=meu-registro-privado.com \
  --docker-username=usuario-admin \
  --docker-password=senha-segura \
  --docker-email=suporte@empresa.com

Em seguida, referencie este segredo na especificação do seu Pod ou Deployment:

apiVersion: v1
kind: Pod
metadata:
  name: api-servico
spec:
  imagePullSecrets:
    - name: credenciais-registro
  containers:
    - name: app-container
      image: meu-registro-privado.com/projeto/imagem:v1

Tags: kubernetes kubeadm kubectl devops Troubleshooting

Publicado em 6-27 07:10