Exposição, Gateway e resolução de nomes

Escolher e observar o caminho de exposição

ClusterIP fornece um endpoint de serviço no cluster. NodePort acrescenta uma porta em endereços de nós elegíveis segundo a implementação e configuração; não abre por si só firewalls externos. LoadBalancer depende de uma implementação que provisione o balanceador, e o estado pode ficar pendente enquanto essa dependência não for satisfeita.

Não imponhas a mesma arquitetura a todos os fornecedores: algumas implementações encaminham diretamente para Pods. Em qualquer opção, liga selector, EndpointSlices, portas, readiness e caminho do cliente. O sucesso por Pod IP elimina algumas hipóteses, mas não demonstra funcionamento pelo endpoint público.

Ingress e Gateway como contratos com um controller

Um Ingress precisa de um controller que interprete a sua classe e regras. Em Gateway API, identifica GatewayClass, Gateway, listener e Route. Compara metadata.generation com observedGeneration antes de usar as condições como evidência atual.

Accepted, ResolvedRefs e Programmed respondem a perguntas diferentes; uma condição favorável não prova que um cliente conclui a operação. Lê também condições por listener ou por parent da Route. Se não há estado atualizado, verifica a relação de ownership e o controller responsável antes de mudar o backend.

A versão dos CRDs e as capacidades da implementação também limitam o que pode ser configurado.

Autorizar referências entre namespaces

Uma HTTPRoute em shop que referencia um Service em payments precisa da autorização correspondente no namespace do destino através de ReferenceGrant. O proprietário de payments limita origem, tipo e destino permitidos. Dar permissão RBAC ao autor para criar a Route não substitui esse consentimento.

A associação Route–Gateway usa outro mecanismo, incluindo allowedRoutes no listener; não troques os dois contratos. Uma referência válida também não cria autorização de rede nem prova que o backend responde. O objetivo é permitir a relação necessária e observar a sua resolução, sem ampliar o acesso entre equipas por conveniência.

DNS: distinguir o domínio da falha

Compara uma consulta ao nome completo de um Service e outra a um nome externo a partir do mesmo Pod. Se a primeira funciona e a segunda falha, investiga encaminhamento upstream, configuração e conectividade do DNS, mantendo a hipótese alinhada com a evidência.

Se ambas falham, começa pela configuração DNS do Pod, Service de DNS, EndpointSlices e políticas do caminho. Um nome curto depende do namespace e search list. Nos logs de CoreDNS, erros de autorização a Services ou EndpointSlices sugerem um problema diferente de timeout para o resolver externo.

Evita publicar consultas sensíveis desnecessariamente quando recolhes logs.

Armadilhas comuns

Confundir endereço publicado com serviço funcional; ler condições antigas; usar RBAC para substituir ReferenceGrant; atribuir qualquer falha DNS ao nome do Service.