1) O “cérebro” do cluster: controle central, API e etcd

Kubernetes é, essencialmente, um sistema de controle baseado em estado desejado.
Você declara o que quer (manifests), e o cluster trabalha para que o estado real converja para o desejado.
Para isso, existe um caminho claro: API Server → persistência (etcd) → control loops.

Quando você aplica um manifest, o kube-apiserver grava a intenção no etcd.
Em seguida, os controladores reagem a mudanças e executam operações até o estado real bater com o desejado.
Esse modelo é o que torna Kubernetes previsível em larga escala — desde que você entenda os limites do sistema.

2) Do manifesto ao Pod: reconciliadores, Deployment e a cadeia de objetos

Uma das partes mais importantes para “dominar” Kubernetes é saber como os objetos se encadeiam.
O resultado final do seu manifest geralmente não é um único recurso; é uma malha de controladores produzindo
outros recursos.

Ao reconciliar, Kubernetes compara spec vs status.
Quando existe divergência, ações são tomadas:
criar recursos, atualizar campos, deletar objetos antigos e promover mudanças conforme a estratégia.

Isso evita o erro comum de tratar “sintomas” no Pod sem verificar por que o control loop não está convergindo.
Kubernetes não “decide aleatoriamente”; ele tenta consistentemente atingir o estado declarado.

3) Rede no Kubernetes: Service, kube-proxy e conectividade

A rede é frequentemente o ponto onde a teoria vira dor.
A base: Kubernetes cria um modelo em que Pods são efêmeros, mas o acesso precisa ser estável.
É aí que o Service entra.

Para “dominar” o assunto, foque nos três níveis:

• Identificação: Service abstrai seleção de Pods (labels).
• Roteamento: kube-proxy/CNI define como o tráfego chega nos endpoints.
• Resolução: DNS traduz nomes para endereços do Service.

Outro ponto crítico: readiness/liveness probes influenciam endpoints.
Normalmente, somente Pods ready entram no conjunto efetivo de endpoints para o Service.
Resultado: parece “conectividade” quando na verdade é estado do Pod.

4) Escalonamento e persistência: nós, recursos e storage

Escalonar é escolher o destino.
Persistir é garantir que o “não efêmero” continue existindo apesar do ciclo de vida dos Pods.
Para ambos, você precisa entender como Kubernetes decide e como os recursos são representados.

Uma arquitetura madura depende de decisões explícitas:
como você quer que o escalonamento respeite zonas/regiões, como quer que recursos sejam distribuídos
e qual estratégia de storage atende a consistência e recuperação exigidas.

E, ao diagnosticar, lembre: falhas de agendamento raramente são “misteriosas”.
Procure por eventos (constraints, falta de recursos, taints) e pelo status dos controladores que tentam reconciliar.

Exemplo prático: Service + Deployment com readiness e requests/limits

Abaixo um manifest curto que mostra três decisões arquiteturais:
Service estável para tráfego, readiness para endpoints corretos
e requests/limits para escalonamento previsível.

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 2
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
        - name: api
          image: minha-registry/minha-api:1.0.0
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: 200m
              memory: 256Mi
            limits:
              cpu: 500m
              memory: 512Mi
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 10

# service.yaml
apiVersion: v1
kind: Service
metadata:
  name: api
spec:
  selector:
    app: api
  ports:
    - name: http
      port: 80
      targetPort: 8080
  type: ClusterIP

Como isso se conecta à arquitetura:
o Service depende de labels; o conjunto de endpoints depende de readiness;
o Scheduler depende de requests/limits para decidir onde os Pods irão ficar.