Pod IP, ClusterIP ou balanceador interno para usuários de VPN
Um Pod IP é roteável pela VPN até o Pod ser substituído. Compare o acesso direto ao Pod, ClusterIP e um balanceador interno, e quanto cada um custa a você.
Com o VPC CNI, um Pod pode ter um endereço da VPC, e um usuário de VPN com a rota correta pode alcançá-lo diretamente. Isso faz o acesso direto ao Pod parecer a opção mais simples, e é mesmo, até o Pod ser substituído. O endereço que um usuário lembra deveria pertencer à aplicação, não a uma réplica. Comparar as três entradas resume-se a qual objeto possui o endereço e o que precisa continuar funcionando quando a carga de trabalho se move.
Escolha primeiro pelo ciclo de vida e depois pelo que a rede precisa fazer para tornar a entrada alcançável.
Três entradas, três ciclos de vida
Um Pod IP pertence a um Pod: é alocado com ele e liberado quando termina. Um ClusterIP pertence a um Service e é virtual, só faz sentido onde existe o roteamento de serviços do cluster. Um balanceador interno pertence a um recurso de nuvem que o controlador do cluster programa com backends. Esses modelos de propriedade preveem a falha que você terá: um endereço obsoleto, um nome inalcançável ou um conjunto de backends desatualizado.
Escreva a comparação antes de escolher. Depois de nomear o proprietário e a falha, a escolha costuma se fazer sozinha.
| Entry | Owner | Failure when the workload moves |
|---|---|---|
| Pod IP | The Pod | Address changes and saved links break |
| ClusterIP | The Service | Virtual address with no meaning outside cluster routing |
| Internal balancer | Cloud resource plus controller | Backends update, but the DNS view is yours to maintain |
Acesso direto ao Pod: útil, temporário
O acesso direto é realmente útil para uma verificação controlada: um administrador, uma sessão curta, uma porta específica. Mas é um contrato ruim para os usuários, porque o endereço é um detalhe de implementação que muda a cada implantação. E registrar um numa wiki é a forma como um serviço que funciona se torna um boato.
Isso também convida a regras amplas. A permissão para um administrador alcançar um Pod não é permissão para cada endereço na sub-rede do nó, e o segundo é o que costuma ser escrito.
ClusterIP: limitado ao cluster por design
Um ClusterIP funciona porque o plano de dados do cluster programa o roteamento para ele dentro do cluster. De um laptop na VPN, o endereço não significa nada a menos que algo o exponha deliberadamente. Um nome que termina em svc.cluster.local pertence ao DNS do cluster, então copiá-lo para um cliente com outro resolvedor produz um nome que não existe em vez de um erro de roteamento.
O ClusterIP continua sendo a entrada correta para quem chama de dentro do cluster, incluindo outras cargas de trabalho. Simplesmente não é um mecanismo de publicação para usuários fora do domínio de roteamento do cluster.
Balanceador interno: o caminho publicado
Um balanceador interno dá a você um endereço privado estável e um nome para o qual sua própria zona pode apontar, enquanto o controlador mantém o conjunto de backends atualizado, como descreve o guia de balanceamento de carga do EKS. Essa é a entrada que sobrevive a uma substituição normal de Pod sem que ninguém edite um documento. Custa um recurso de nuvem, uma configuração de controlador e uma rota a partir da VPN, e são essas as partes que as pessoas subestimam.
Use o modelo de controlador que o cluster realmente executa. Anotações escritas para uma integração não se aplicam a outra.
Quem é o endereço de origem
Os grupos de segurança veem a origem que chega à sua fronteira, e ela pode ser o cliente conectado ou um endereço traduzido, dependendo do caminho de VPN e de balanceamento de carga. Em nós baseados em EC2, os Pods normais do VPC CNI herdam por padrão os grupos da ENI do nó, enquanto configurações suportadas podem anexar grupos específicos de Pod. Escreva regras para o caminho documentado em vez de para um endereço suposto do laptop.
Mantenha o listener e a autenticação próprios da aplicação como controles separados. Uma regra de rede que permite o fluxo não é uma decisão de autorização e não deve ser tratada como tal.
O que entregar aos usuários
Dê aos usuários um nome de serviço, não um endereço. Publique o nome na zona privada, aponte-o para a entrada interna e então teste substituindo um Pod de backend enquanto um cliente mantém o mesmo nome aberto. Esse exercício testa a propriedade que importa: alcançar a mesma aplicação após uma implantação rotineira.
Mantenha o acesso direto ao Pod como uma exceção operacional documentada com seu próprio escopo, bem longe das instruções para usuários.