Pod IP, ClusterIP o balanceador interno para usuarios de VPN
Una Pod IP es enrutable por la VPN hasta que la Pod se reemplaza. Compare el acceso directo a la Pod, ClusterIP y un balanceador interno, y qué le cuesta cada uno.
Con el VPC CNI, una Pod puede tener una dirección del VPC, y un usuario de VPN con la ruta correcta puede alcanzarla directamente. Eso hace que el acceso directo a la Pod parezca la opción más simple, y lo es, hasta que la Pod se reemplaza. La dirección que un usuario recuerda debería pertenecer a la aplicación, no a una réplica. Comparar las tres entradas se reduce a qué objeto posee la dirección y qué debe seguir funcionando cuando la carga de trabajo se mueve.
Elija primero por ciclo de vida y después por lo que la red debe hacer para que la entrada sea alcanzable.
Tres entradas, tres ciclos de vida
Una Pod IP pertenece a una Pod: se asigna con ella y se libera cuando termina. Un ClusterIP pertenece a un Service y es virtual, solo tiene sentido donde existe el enrutamiento de servicios del clúster. Un balanceador interno pertenece a un recurso de nube que el controlador del clúster programa con backends. Esos modelos de propiedad predicen el fallo que obtendrá: una dirección obsoleta, un nombre inalcanzable o un conjunto de backends desactualizado.
Escriba la comparación antes de elegir. Una vez nombrados el propietario y el fallo, la elección suele hacerse sola.
| 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 a la Pod: útil, temporal
El acceso directo es realmente útil para una comprobación controlada: un administrador, una sesión corta, un puerto concreto. Pero es un mal contrato para los usuarios, porque la dirección es un detalle de implementación que cambia en cada despliegue. Y registrar una en un wiki es la forma en que un servicio que funciona se convierte en un rumor.
También invita a reglas amplias. El permiso para que un administrador alcance una Pod no es permiso para cada dirección de la subred del nodo, y lo segundo es lo que suele escribirse.
ClusterIP: limitado al clúster por diseño
Un ClusterIP funciona porque el plano de datos del clúster programa el enrutamiento para él dentro del clúster. Desde un portátil en la VPN la dirección no significa nada a menos que algo la exponga deliberadamente. Un nombre que termina en svc.cluster.local pertenece al DNS del clúster, así que copiarlo a un cliente con otro resolutor produce un nombre que no existe en lugar de un error de enrutamiento.
ClusterIP sigue siendo la entrada correcta para quienes llaman desde dentro del clúster, incluidos otros workloads. Simplemente no es un mecanismo de publicación para usuarios fuera del dominio de enrutamiento del clúster.
Balanceador interno: la ruta publicada
Un balanceador interno le da una dirección privada estable y un nombre al que su propia zona puede apuntar, mientras el controlador mantiene actualizado el conjunto de backends, como describe la guía de balanceo de carga de EKS. Esa es la entrada que sobrevive a un reemplazo normal de Pod sin que nadie edite un documento. Cuesta un recurso de nube, una configuración de controlador y una ruta desde la VPN, y esas son las partes que la gente subestima.
Use el modelo de controlador que el clúster ejecuta realmente. Las anotaciones escritas para una integración no se aplican a otra.
Quién es la dirección de origen
Los grupos de seguridad ven el origen que llega a su frontera, que puede ser el cliente conectado o una dirección traducida según la ruta de VPN y de balanceo de carga. En los nodos basados en EC2, las Pods normales de VPC CNI heredan por defecto los grupos de la ENI del nodo, mientras que las configuraciones admitidas pueden adjuntar grupos específicos de Pod. Escriba reglas para la ruta documentada en lugar de una dirección supuesta del portátil.
Mantenga el listener y la autenticación propios de la aplicación como controles separados. Una regla de red que permite el flujo no es una decisión de autorización y no debe tratarse como tal.
Qué entregar a los usuarios
Dé a los usuarios un nombre de servicio, no una dirección. Publique el nombre en la zona privada, apúntelo a la entrada interna y luego pruebe reemplazando una Pod de backend mientras un cliente mantiene el mismo nombre abierto. Ese ejercicio comprueba la propiedad que importa: llegar a la misma aplicación tras un despliegue rutinario.
Mantenga el acceso directo a la Pod como una excepción operativa documentada con su propio alcance, lejos de las instrucciones para usuarios.