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:
- Redefina as configurações do kubeadm: ```
kubeadm reset -f
- No nó mestre (Control Plane), gere um novo comando de adesão caso o token tenha expirado: ```
kubeadm token create --print-join-command
- 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
- Reinicie os serviços de runtime e execute o comando
joinnovamente: ``` 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