Usted planifica el CIDR de pods y el CIDR de servicios para un nuevo clúster de GKE, pero una subred existente ya se superpone con un rango. ¿Cuál es la decisión de diseño correcta?

La opción correcta es elegir rangos secundarios que no se superpongan para pods y servicios y asignarlos a la subred. GKE requiere rangos de IP únicos para pods y servicios para evitar conflictos de enrutamiento dentro de la VPC. Al seleccionar rangos secundarios no superpuestos, se asegura que el clúster de GKE pueda operar correctamente sin problemas de conectividad. Las otras opciones son incorrectas: Utilizar reglas de firewall de VPC para traducir el CIDR de servicio en conflicto no es una solución para la superposición de CIDR, ya que los firewalls operan en un nivel diferente y no resuelven el problema de enrutamiento subyacente. Agregar manualmente rutas estáticas que asignen las IP de servicio a la subred superpuesta no es una práctica recomendada y puede llevar a configuraciones complejas e inestables, además de no resolver la superposición fundamental. Dejar que el clúster cree rangos superpuestos no es posible; GKE no realizará NAT automáticamente para resolver conflictos de superposición de IP de servicio, y la superposición causaría fallos en la comunicación.