APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Um Service separa consumidores das mudanças de Pods, mas precisa de backends coerentes. Quando usa um selector, compara esse selector com os labels reais e observa os EndpointSlices correspondentes. Pods Ready com labels diferentes podem deixar o Service sem destinos. DNS resolver o nome para ClusterIP não demonstra que esses destinos existem. O nome curto de um Service é interpretado no contexto de DNS do cliente; para atravessar namespaces, usa um nome qualificado apropriado. Num cluster com domínio cluster.local, database.payments.svc.cluster.local identifica o Service database em payments. Confirma sempre o domínio efetivo em vez de assumir que todos os clusters usam o mesmo.
Aplicação guiada
Distingue acesso interno de publicação externa. ClusterIP por si não cria um caminho da Internet; a exposição deve seguir requisitos e controlos aprovados. NetworkPolicy precisa de implementação que a aplique. Quando origem e destino estão isolados nas direções relevantes, egress da origem e ingress do destino têm de permitir a ligação. Uma regra num lado não cria a outra. Numa release bancária fictícia, evita resolver falta de backends abrindo a rede ou alargando selectors a Pods de teste. Reconstitui origem, namespace, nome, Service, selector, endpoints e políticas. Depois da correção declarada, confirma a transação funcional e que destinos não autorizados continuam inacessíveis.
Se selector app=funds não encontra Pods app=funds-v2, corrige a correspondência aprovada e verifica backends; não edites primeiro um EndpointSlice gerido.
Armadilhas comuns
DNS como prova de serviço; porta 443 como publicação; selector demasiado amplo; NetworkPolicy sem plugin; autorização só num lado.
Tópicos relacionados: Dados persistentes e acessos proporcionais · Entrega, GitOps e diagnóstico de releases
Cada etapa do caminho precisa de evidência própria e de uma fronteira de acesso explícita.
Referência: Services · KCNA current four-domain curriculum; edition date unconfirmed