DevOpsQuest
0 XP
Módulo 8 · Kubernetes e Helm

Arquitetura do cluster e o loop de reconciliação

Intermediário 45 min+25 XPKindkubectl

Objetivos desta aula

  • Entender control plane e nós
  • Criar um cluster local
  • Navegar recursos com kubectl

Kubernetes funciona por reconciliação: você declara o estado desejado no API server, o etcd guarda, os controllers comparam com o real e agem até convergir. Entender isso explica por que apagar um pod à mão o faz voltar — o Deployment quer três réplicas e o controller obedece a essa vontade, não à sua.

No control plane estão API server, etcd, scheduler e controller manager; em cada nó, kubelet (executa e reporta), container runtime e kube-proxy (rede de serviços). Diagnóstico começa sempre por eventos e status, que refletem o que os controllers viram.

Kind cria um cluster completo em containers Docker, ideal para aprender e para CI. Comece dominando kubectl get/describe/logs/exec e o uso de namespaces — a maior parte do trabalho diário está nesses cinco comandos.

1. Por que Kubernetes existe

Rodar um contêiner é fácil; rodar centenas, em várias máquinas, reiniciando os que caem, distribuindo carga e trocando versões sem parar o serviço, não é. O Kubernetes é um orquestrador: você descreve o estado desejado e ele trabalha sem parar para que a realidade fique igual à descrição.

2. Control plane: o cérebro

  • kube-apiserver: a única porta de entrada; tudo (kubectl, controllers, kubelet) conversa com ele
  • etcd: banco chave-valor com todo o estado do cluster — faça backup
  • kube-scheduler: escolhe em qual nó cada Pod vai rodar
  • kube-controller-manager: roda os controllers (Deployment, ReplicaSet, Node…)

3. Nós de trabalho: os músculos

Cada nó roda o kubelet (garante que os contêineres do Pod estão de pé), o container runtime (containerd) e o kube-proxy ou um CNI com eBPF (regras de rede dos Services).

4. O loop de reconciliação

Todo controller faz o mesmo ciclo: observar o estado atual → comparar com o desejado → agir para diminuir a diferença → repetir. Se você apaga um Pod de um Deployment com 3 réplicas, o ReplicaSet percebe que há 2 e cria outro. Isso é o que torna o sistema auto-curável.

5. Declarativo vs imperativo

kubectl run é imperativo ("faça isto agora"). kubectl apply -f é declarativo ("quero que seja assim"). Em produção use sempre declarativo e versionado em Git — é a base do GitOps do próximo módulo.

6. Namespaces e contexto

Namespaces separam times e ambientes dentro do cluster (quota, RBAC, nomes). Sempre confira o contexto com kubectl config current-context antes de um comando destrutivo — aplicar em produção achando que é dev é um erro clássico.

7. Checagem final

Você deve explicar o caminho de um kubectl apply até o contêiner rodar: apiserver grava no etcd → scheduler escolhe nó → kubelet do nó puxa a imagem e inicia o contêiner.

Na prática

Cluster local com Kind e navegação

bash

cat > kind.yaml <<'EOF'
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
  - role: control-plane
    kubeadmConfigPatches:
      - |
        kind: InitConfiguration
        nodeRegistration:
          kubeletExtraArgs:
            node-labels: "ingress-ready=true"
    extraPortMappings:
      - { containerPort: 80, hostPort: 80 }
      - { containerPort: 443, hostPort: 443 }
  - role: worker
EOF

kind create cluster --name cloudshop --config kind.yaml
kubectl cluster-info
kubectl get nodes -o wide
kubectl create namespace cloudshop
kubectl config set-context --current --namespace=cloudshop

kubectl get all
kubectl api-resources | head -20
kubectl explain deployment.spec.strategy
kubectl get events --sort-by=.lastTimestamp | tail -20

Explorando o cluster pela primeira vez

bash

kind create cluster --name cloudshop     # cluster local em Docker
kubectl get nodes -o wide                  # nós, versão e IPs
kubectl get pods -n kube-system            # componentes do control plane
kubectl api-resources | head               # tipos de objeto que o cluster conhece
kubectl explain deployment.spec.replicas   # documentação de qualquer campo
# Veja a reconciliação acontecer:
kubectl create deployment web --image=nginx --replicas=3
kubectl delete pod -l app=web --wait=false
kubectl get pods -l app=web -w             # novos Pods aparecem sozinhos

Por que isso importa

Sem o modelo de reconciliação na cabeça, você briga com o cluster em vez de operá-lo.

Erro comum

Deletar pods esperando que fiquem deletados, sem alterar o Deployment.

Dica de produção

Use namespaces por ambiente/equipe desde o início; migrar depois é trabalhoso.

Alerta de segurança

kubeconfig é credencial de cluster: proteja com permissão 600 e nunca comite.

Pergunta de entrevista

Explique o que acontece entre kubectl apply e o pod rodando.

Glossário

reconciliação
Ciclo contínuo que aproxima o estado real do estado declarado.
kubelet
Agente em cada nó que executa containers e reporta status ao control plane.
etcd
Banco chave-valor distribuído que guarda todo o estado do cluster.
kubelet
Agente em cada nó que executa e vigia os contêineres dos Pods.
Reconciliação
Ciclo contínuo de comparar estado desejado e atual e corrigir a diferença.
Namespace
Divisão lógica do cluster para isolar nomes, permissões e quotas.

Conexão com o CloudShop

Criar o cluster local onde o CloudShop será migrado.

Quiz da aula

  1. 1. Você apaga um pod gerenciado por Deployment. O que acontece?

  2. 2. Você apaga manualmente um Pod de um Deployment com 3 réplicas. O que acontece?

  3. 3. Qual componente decide em qual nó um Pod vai rodar?

Minhas anotações

Salvo automaticamente neste navegador.

AnteriorPróxima