Conceito e mecanismo
Um Service oferece um ponto de acesso e, quando usa selector, seleciona Pods pelos labels. Os EndpointSlices correspondentes ajudam a observar os destinos disponíveis. Confirma selector, readiness e portas antes de alterar exposição. port é a porta oferecida pelo Service; targetPort é o destino no backend. DNS de Services inclui nome, namespace e domínio do cluster, pelo que um nome curto pode resolver de forma diferente noutro namespace. Ingress e Gateway API descrevem encaminhamento, mas precisam de implementações compatíveis que observem recursos e configurem o data plane. Criar YAML não instala automaticamente o controller.
Aplicação guiada
NetworkPolicy exige um plugin que aplique as regras. A seleção de Pods e namespaces deve ser lida com atenção à estrutura YAML: os dois seletores na mesma entrada restringem em conjunto, enquanto entradas distintas representam alternativas permitidas. Políticas são aditivas e o caminho pode exigir egress da origem e ingress do destino. Ao introduzir default deny, inventaria DNS e outras dependências. A arquitetura DNS pode incluir cache local, pelo que não deves copiar IPs e labels de outro cluster sem confirmar. Valida acessos permitidos e recusados para demonstrar que o controlo está efetivamente aplicado.
Num exemplo com domínio cluster.local, api.fundos.svc.cluster.local identifica o Service api em fundos. Usa kubectl get endpointslices -n fundos e compara os destinos com labels e readiness dos Pods.
Armadilhas comuns
Mudar para NodePort para corrigir selector; confundir port com targetPort; assumir enforcement pela criação da Policy; instalar qualquer controller sem validar compatibilidade.
Tópicos relacionados: Volumes e ciclo de vida dos dados · Diagnosticar workloads com evidência
Confirma intenção, implementação e tráfego observado em cada camada.
Referência: Services · CKA Kubernetes v1.35