Oficina de probes, Services e isolamento | CKAD: aplicações Kubernetes em produção

1. Separar fase de arranque e serviço

A aplicação pode estar em execução e ainda não estar pronta para tráfego. Com startupProbe configurada, liveness e readiness aguardam o sucesso do arranque segundo os seus atrasos configurados. Depois, readiness controla elegibilidade para tráfego normal e a sua falha isolada não manda reiniciar o container. Num exercício com restartCount zero, readiness 503 e liveness 200, não inventes uma causa única. O processo responde a uma verificação, mas falta perceber o contrato de prontidão. Pode haver dependência indisponível, configuração inválida ou outra condição da aplicação; recolhe evidência antes de alterar probes.

2. Ler a execução certa

Num Pod com api e exporter, os logs de api não explicam necessariamente o restart de exporter. Identifica namespace, Pod, container e execução atual ou anterior. O comando com -c exporter --previous procura os logs da instância anterior, quando disponíveis. Não assumes que --previous é um arquivo completo de todos os restarts. Conserva o momento observado, eventos e configuração relevante, sem registar segredos. Para a equipa L3, este enquadramento reduz escalamentos sem contexto: a pergunta útil é que hipótese os logs permitem confirmar, e não apenas se foi possível obter alguma saída.

3. Seguir seleção, porta e prontidão

Um Service pode selecionar os Pods certos e continuar sem um caminho funcional. Primeiro compara labels e selector. Depois compara targetPort: web com os nomes de portas declarados pelo Pod. Se apenas existe http: 8080, a referência web é incoerente. Finalmente observa prontidão e o processo que escuta. No caso composto, corrigir o nome da porta não explica a readiness 503. Trata os dois achados e volta a ensaiar a função do cliente. O exercício assume um Service normal, sem publicação de endereços não prontos; essa condição evita generalizar o comportamento a configurações deliberadamente diferentes.

4. Ler AND e OR na estrutura YAML

A intenção “clientes de pagamentos” exige duas condições: namespace com team=payments e Pod com role=client. No mesmo elemento from, namespaceSelector e podSelector selecionam a interseção. Em elementos separados, tornam-se alternativas: todos os Pods dos namespaces selecionados, ou os Pods role=client do namespace da política. Testa mentalmente quatro origens: cliente em payments, debug em payments, cliente local e debug fora. A diferença não é estética de indentação; altera quem recebe acesso. Usa o fragmento abaixo como objeto de leitura e justifica cada resultado antes de olhar para a explicação.

5. Compor políticas e testar exclusões

NetworkPolicies aplicáveis juntam permissões por direção. Uma política default deny inicia isolamento, mas outra política pode permitir um fluxo; criar mais um default deny não revoga o allow. Revê todas as políticas relevantes. Para uma ligação atravessar Pods isolados, a saída da origem e a entrada do destino precisam de permitir o percurso. Neste exercício, o CNI aplica NetworkPolicy, os fluxos são novos e não há hostNetwork ou extensões de prioridade do fornecedor. Regista essas hipóteses. Um teste positivo mostra um acesso permitido; testes negativos com origens próximas ajudam a detetar um selector excessivamente abrangente.

6. Fechar o diagnóstico por camadas

Entrega uma pequena matriz de evidência: seleção de Pods, porta resolvida, estado Ready, permissões de rede e função do cliente. Distingue o que foi lido no manifest, calculado num modelo e observado num cluster. A oficina local não envia pacotes nem valida o CNI. O laboratório prático deverá confirmar uma origem permitida, uma origem excluída e comportamento após a mudança, usando namespace e contexto autorizados. O gestor técnico pode então relacionar a alteração com critérios de aceitação e rollback. Encerrar apenas porque um endpoint respondeu pode deixar um segundo defeito ou uma exposição indevida por resolver.

# Fragment: NetworkPolicy ingress rule, TCP 8443
from:
  - namespaceSelector:
      matchLabels:
        team: payments
    podSelector:
      matchLabels:
        role: client
ports:
  - protocol: TCP
    port: 8443

# Read-only inspection plan for an authorized lab
kubectl logs reconcile-7 -n funds -c exporter --previous
kubectl get service ledger -n ledger -o yaml
kubectl get networkpolicy -n ledger -o yaml

NA PRÁTICA

role=debug em team=payments passa pelo namespaceSelector separado; falha a interseção com role=client no mesmo elemento.

Armadilhas comuns

Liveness como prontidão; porta do Service como targetPort; dois peers como interseção; deny como prioridade; teste positivo como isolamento.

Tópicos relacionados: Deployments e recuperação · Serviços e políticas de rede

Leva esta ideia contigo

Analisa cada camada e valida tanto o acesso pretendido como as exclusões.

Criar conta

Referência: Network Policies · CKAD Kubernetes v1.37