Pod IP, ClusterIP ou balanceador interno para usuarios de VPN
Unha Pod IP é encamiñable pola VPN ata que a Pod se substitúe. Compare o acceso directo á Pod, ClusterIP e un balanceador interno, e o que lle custa cada un.
Co VPC CNI, unha Pod pode ter un enderezo do VPC, e un usuario de VPN coa ruta correcta pode alcanzala directamente. Iso fai que o acceso directo á Pod pareza a opción máis simple, e séqueo, ata que a Pod se substitúe. O enderezo que un usuario lembra debería pertencer á aplicación, non a unha réplica. Comparar as tres entradas redúcese a que obxecto posúe o enderezo e que debe seguir funcionando cando a carga de traballo se move.
Elixa primeiro por ciclo de vida e despois polo que a rede debe facer para que a entrada sexa alcanzable.
Tres entradas, tres ciclos de vida
Unha Pod IP pertence a unha Pod: asígnase con ela e libérase cando remata. Un ClusterIP pertence a un Service e é virtual, só ten sentido onde existe o encamiñamento de servizos do clúster. Un balanceador interno pertence a un recurso de nube que o controlador do clúster programa con backends. Eses modelos de propiedade predín o fallo que obterá: un enderezo obsoleto, un nome inalcanzable ou un conxunto de backends desactualizado.
Escriba a comparación antes de elixir. Unha vez nomeados o propietario e o fallo, a elección adoita facerse soa.
| 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 |
Acceso directo á Pod: útil, temporal
O acceso directo é realmente útil para unha comprobación controlada: un administrador, unha sesión curta, un porto concreto. Pero é un mal contrato para os usuarios, porque o enderezo é un detalle de implementación que cambia en cada despregamento. E rexistrar un nun wiki é a forma en que un servizo que funciona se converte nun rumor.
Tamén convida a regras amplas. O permiso para que un administrador alcance unha Pod non é permiso para cada enderezo da subrede do nodo, e o segundo é o que adoita escribirse.
ClusterIP: limitado ao clúster por deseño
Un ClusterIP funciona porque o plano de datos do clúster programa o encamiñamento para el dentro do clúster. Desde un portátil na VPN o enderezo non significa nada a menos que algo o expoña deliberadamente. Un nome que remata en svc.cluster.local pertence ao DNS do clúster, así que copialo a un cliente con outro resolvedor produce un nome que non existe en lugar dun erro de encamiñamento.
ClusterIP segue a ser a entrada correcta para quen chama desde dentro do clúster, incluídos outros workloads. Simplemente non é un mecanismo de publicación para usuarios fóra do dominio de encamiñamento do clúster.
Balanceador interno: a ruta publicada
Un balanceador interno dá un enderezo privado estable e un nome ao que a súa propia zona pode apuntar, mentres o controlador mantén actualizado o conxunto de backends, como describe a guía de balanceo de carga de EKS. Esa é a entrada que sobrevive a unha substitución normal de Pod sen que ninguén edite un documento. Custa un recurso de nube, unha configuración de controlador e unha ruta desde a VPN, e esas son as partes que a xente subestima.
Use o modelo de controlador que o clúster executa realmente. As anotacións escritas para unha integración non se aplican a outra.
Quen é o enderezo de orixe
Os grupos de seguridade ven a orixe que chega á súa fronteira, que pode ser o cliente conectado ou un enderezo traducido segundo a ruta de VPN e de balanceo de carga. Nos nodos baseados en EC2, as Pods normais de VPC CNI herdan por defecto os grupos da ENI do nodo, mentres que as configuracións admitidas poden anexar grupos específicos de Pod. Escriba regras para a ruta documentada en lugar dun enderezo suposto do portátil.
Manteña o listener e a autenticación propios da aplicación como controis separados. Unha regra de rede que permite o fluxo non é unha decisión de autorización e non debe tratarse como tal.
Que entregar aos usuarios
Dea aos usuarios un nome de servizo, non un enderezo. Publique o nome na zona privada, apúnteo á entrada interna e despois probe substituíndo unha Pod de backend mentres un cliente mantén o mesmo nome aberto. Ese exercicio comproba a propiedade que importa: chegar á mesma aplicación tras un despregamento rutineiro.
Manteña o acceso directo á Pod como unha excepción operativa documentada co seu propio alcance, lonxe das instrucións para usuarios.