Google PCNE: GKE, contenedores y redes de aplicaciones — Guía de estudio

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

Forma parte de la Google Professional Cloud Network Engineer — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Google, o realiza tests cronometrados en ExamRoll.io.

Descripción general

Google Kubernetes Engine (GKE) se integra estrechamente con las redes de Google Cloud. Diseñar para la fiabilidad y la seguridad requiere comprender el direccionamiento IP nativo de la VPC, los planos de control privados, el egreso, el tráfico norte-sur y este-oeste, la aplicación de políticas y las construcciones multiclúster. Esta sección proporciona orientación de diseño, razonamiento operativo y modos de fallo comunes para la red de contenedores y aplicaciones en Google Cloud.

Arquitectura IP de GKE y clústeres privados

Clústeres nativos de VPC

• Usan IPs de alias con dos rangos secundarios en una subred de VPC: uno para Pods (PodCIDR) y otro para Services (ServiceCIDR). Esto evita el SNAT basado en iptables en los nodos, permite el balanceo de carga nativo de contenedores con NEGs y escala mejor que los clústeres basados en rutas.
• Pautas de dimensionamiento:
  • Pods: asigna PodsPerNode × MaxNodes, más un margen de maniobra (20–30 %). Por ejemplo, 10 nodos actuales × 20 Pods + un crecimiento a 100 × 200 sugiere un rango de Pods /17; los Services a menudo caben en un /21 para más de 2000 servicios.
  • Services: cada ClusterIP consume una IP; ten en cuenta un margen de maniobra para las migraciones de headless a ClusterIP y para los complementos (add-ons).
• Modos de fallo:
  • Agotamiento de IPs de Pod: los Pods permanecen en estado Pending o aparecen errores de CNI/IPAM; escala el rango secundario de Pods o reduce el número máximo de pods por nodo y, a continuación, vuelve a crear los nodos.
  • Agotamiento de IPs de Service: los nuevos Services no pueden asignar un ClusterIP; expande el rango secundario de Service.
  • Superposición de rangos de alias: la creación del clúster falla o se producen agujeros negros de enrutamiento; valida que no haya superposición con otras subredes o VPCs en peering.

Clústeres privados, acceso al plano de control y egreso de nodos

• Los clústeres privados restringen el endpoint del plano de control a una dirección privada RFC1918 accesible solo desde tu VPC a través de peering de productor. Los nodos no requieren IPs externas.
• Para los operadores, elige:
  • Solo endpoint privado: el plano de control es accesible desde las subredes de la VPC y las redes conectadas. Usa un bastión o Cloud Shell con Private Service Connect para acceder a él.
  • Endpoint público con Authorized Networks: expone el plano de control en una IP pública protegida por CIDRs de origen específicos. Esto es conveniente pero aumenta la exposición; úsalo solo con un alcance de CIDR estricto y controles de identidad de administrador sólidos.
• Egreso de nodos:
  • Para los nodos sin IPs externas, proporciona egreso hacia internet a través de Cloud NAT. Esto permite actualizaciones del sistema operativo, la descarga de imágenes de contenedor desde registros externos y el acceso a APIs de socios, manteniendo la privacidad de los nodos.
  • Para acceder a las APIs de Google y a Artifact/Container Registry sin IPs externas, habilita Private Google Access (PGA) en las subredes de los nodos. PGA resuelve y enruta el tráfico de las APIs/registros de Google al borde de la red de Google sin IPs de origen públicas. Se prefiere PGA para la descarga de imágenes; combínalo con Cloud NAT si también se requiere egreso a destinos que no son de Google.
  • Si envías el tráfico 0.0.0.0/0 a través de un firewall de terceros, habilita igualmente PGA y añade rutas estáticas para los rangos VIP de las APIs de Google hacia la puerta de enlace de internet predeterminada para omitir el firewall para los servicios de Google.

Escalado y solución de problemas de IP

• Supervisa el consumo de IPs de alias a nivel del rango secundario de la subred. Si la presión sobre las IPs aumenta:
  • Aumenta los tamaños de los rangos secundarios (añade rangos más grandes, vuelve a crear el clúster o migra las cargas de trabajo según sea necesario).
  • Ajusta el max-pods-per-node para equilibrar el uso de IPs por nodo frente a la fragmentación de la programación.
  • Depura los Services abandonados; los Services headless no asignan ClusterIPs, pero convertirlos a ClusterIP consumirá IPs.
• Planifica el crecimiento multirregional con rangos secundarios que no se superpongan para evitar tener que reasignar IPs al usar Shared VPCs, VPC Peering o servicios multiclúster.

Ingress, Gateway API, Services y políticas

Services y balanceadores de carga

• Tipos de Service:
  • ClusterIP: acceso solo dentro del clúster; el tráfico este-oeste utiliza kube-proxy o dataplane v2.
  • NodePort: asigna un puerto en cada nodo; utilizado por muchos balanceadores de carga como backend, pero evita exponerlo directamente en internet.
  • LoadBalancer: aprovisiona un balanceador de carga en la nube. Los balanceadores de carga L4 externos o internos admiten TCP/UDP; la afinidad de sesión ClientIP proporciona persistencia (stickiness) entre múltiples protocolos cuando es necesario.
• El balanceo de carga nativo de contenedores utiliza Network Endpoint Groups (NEGs) para que el balanceador de carga apunte directamente a las IP:puertos de los Pods, mejorando la señalización de estado y reduciendo los saltos de nodo. Para GKE, utiliza GKE Pod NEGs (GCE_POD). Otros tipos de NEG incluyen VM_IP_PORT, Internet FQDN y PSC.
• GKE Ingress y Gateway API:
  • Ingress es estable para el tráfico norte-sur de HTTP(S) con el balanceador de carga HTTP(S) externo global de Google o el balanceador de carga HTTP(S) interno regional. El controlador programa automáticamente las comprobaciones de estado y las reglas de firewall para patrones estándar.
  • Gateway API proporciona un modelo más expresivo con Gateways y HTTPRoutes/TCPRoutes. Admite configuraciones multi-tenant, enrutamiento avanzado y una especificación consistente entre entornos. Elige Gateway API para asegurar la compatibilidad futura; utiliza Ingress donde la simplicidad y la compatibilidad son importantes.

Restricción de clientes y comprobaciones de estado

• La restricción de clientes a rangos de origen específicos se puede hacer en L4 con reglas de firewall de VPC que apuntan a las instancias de backend o en L7 con políticas de Cloud Armor en los balanceadores de carga HTTP(S).
• Permite siempre los rangos de origen del comprobador de estado de Google (Google health checker) hacia los destinos de backend o los Pods para que las comprobaciones de estado pasen. En algunas implementaciones, GKE crea automáticamente reglas k8s-fw; si agregas reglas restrictivas, mantén permisos explícitos (allows) para los rangos del comprobador de estado.
• Enfoque de ejemplo para backends L4: etiqueta los nodos con “application” y crea una regla de firewall de permiso (allow) para tcp:NodePort desde los CIDR de cliente permitidos y los rangos de comprobación de estado de Google, y una regla de denegación (deny) de mayor prioridad para todas las demás fuentes con registro (logging) para observar las caídas de paquetes.

Políticas de red y dataplane v2

• Habilita Kubernetes NetworkPolicy y utiliza GKE Dataplane V2 para una aplicación de políticas basada en eBPF, mejorando el rendimiento y la fidelidad en comparación con los motores basados en iptables.
• Postura de base:
  • Deniega por defecto el egreso y el ingreso para los namespaces; permite explícitamente los flujos de Pod a Pod y de Pod a Service.
  • Usa selectores de namespace y pod (podSelectors) para crear niveles de servicio (frontend, backend, datos) y permite solo las direcciones y puertos mínimos necesarios.
• Comunicación segura entre servicios:
  • Para un modelo de confianza cero (zero trust) dentro del clúster, la mejor manera de implementar mTLS es a través de una malla de servicios (service mesh); NetworkPolicy maneja L3/L4 y no puede autenticar identidades.
  • Para el tráfico norte-sur, asocia Cloud Armor a los balanceadores de carga HTTP(S) para WAF, limitación de velocidad (rate limiting) y modo de vista previa (preview) para probar una denegación sobre atacantes sospechosos sin interrumpir a los usuarios.

Modos de fallo y contrapartidas

• Demasiadas NetworkPolicies o políticas demasiado amplias pueden causar caídas de paquetes inesperadas; valida con despliegues por etapas (staged rollouts), registro (logging) y herramientas de explicación de políticas.
• Depender de NodePort junto con reglas de firewall externas es frágil; prefiere los balanceadores de carga gestionados y los Pod NEGs.
• Gateway API ofrece funcionalidades más ricas, pero requiere madurez del controlador y familiaridad por parte del equipo; valida funcionalidades como el enrutamiento basado en encabezados o el paso a través de mTLS (mTLS passthrough) para cada canal de lanzamiento (release channel).

Multiclúster, malla de servicios e identidad

Servicios multiclúster y redes de flota (fleet)

• Registra los clústeres en una flota (fleet) para usar Multi-Cluster Services (MCS) para el descubrimiento de servicios y el balanceo de cargas entre clústeres. Exporta los servicios de cada clúster; los clientes resuelven un único nombre DNS respaldado por endpoints en todos los clústeres.
• Patrones de tráfico entre clústeres:
  • Misma VPC, diferentes subredes: el tráfico fluye sobre direcciones privadas RFC1918 con costo y latencia óptimos.
  • Diferentes VPC: conéctalas con VPC Peering para una conectividad privada y simple sin transitividad, o usa Cloud VPN/Cloud Router si las organizaciones son distintas o se requiere cifrado a través de internet. Para una administración centralizada, Shared VPC expone solo las subredes necesarias a los proyectos de servicio.
• Modos de fallo:
  • Los CIDR superpuestos bloquean el enrutamiento; asegúrate de que no haya superposición entre PodCIDR y ServiceCIDR antes de usar peering o VPN.
  • Problemas de DNS de horizonte dividido (split-horizon) pueden romper la resolución entre clústeres; valida las rutas de búsqueda y los dominios de stub.

Malla de servicios, tráfico este-oeste y observabilidad

• Despliega una malla de servicios como Anthos Service Mesh para:
  • mTLS con una identidad de carga de trabajo (workload) robusta, políticas de tráfico (reintentos, tiempos de espera, detección de valores atípicos) y división de tráfico.
  • Políticas consistentes para el tráfico este-oeste entre clústeres con federación de malla o topologías multiprimarias.
  • Telemetría enriquecida: señales doradas por carga de trabajo, trazas de solicitudes y auditorías de políticas.
• Compensaciones:
  • Los sidecars aumentan la sobrecarga de recursos; los modos ambient o sin sidecar pueden reducir el costo, pero valida la paridad de características.
  • La malla añade dependencias del plano de control; diseña para planos de control de alta disponibilidad (HA) y degradación controlada.

Identidad de carga de trabajo (Workload Identity), secretos y privilegio mínimo

• Usa Workload Identity para mapear Cuentas de Servicio de Kubernetes (KSA) a cuentas de servicio de Google (GSA), eliminando claves de larga duración. Anota la KSA con el correo electrónico de la GSA y otorga roles de IAM mínimos a la GSA.
• Gestión de secretos:
  • Prefiere usar Secret Manager con el controlador CSI para montar secretos en tiempo de ejecución; elimina los Secrets de Kubernetes en texto plano para datos sensibles o cífralos en reposo con CMEK si se conservan.
  • Otorga acceso con privilegio mínimo a los secretos y buckets en la GSA. Evita roles a nivel de proyecto; acota los permisos a roles a nivel de recurso como storage.objectViewer cuando sea aplicable.

Consideraciones de diseño para una plataforma resiliente y segura

• Clústeres regionales para alta disponibilidad; distribuye los nodos entre zonas. Para el tráfico norte-sur, usa el balanceo de cargas global de HTTP(S) para la latencia más baja para usuarios globales.
• Conectividad del plano de control: elige planos de control privados; evita la exposición pública a menos que sea estrictamente necesario con Authorized Networks.
• Salida (Egress): nodos sin IP externas junto con Cloud NAT y Private Google Access (PGA) equilibran la seguridad y la funcionalidad.
• Observabilidad: habilita los registros del firewall, VPC Flow Logs y la telemetría de la malla para diagnosticar rápidamente caídas de políticas o picos de latencia.

Escenario de problema práctico

Contoso Retail opera dos clústeres regionales privados de GKE en us-east1 y europe-west1. Requisitos: sin IP externas en los nodos, entrada (ingress) segura limitada a los CIDR corporativos, disponibilidad global para un servicio de tienda online (storefront), obtención de imágenes sin exposición a internet y conmutación por error (failover) entre clústeres para la capa de API. Anteriormente, sufrieron un agotamiento de IP de Pods durante un pico de tráfico.

Enfoque

1. Diseñar subredes nativas de VPC con rangos secundarios generosos.

   • Justificación: Asignar un rango /17 para Pods y un rango /21 para Servicios por región para cubrir 100 nodos × 200 Pods/nodo y 1500 servicios con un 20-30 % de margen. Esto previene la recurrencia del agotamiento de IP de Pods y evita la reasignación de IP durante el crecimiento.

2. Crear clústeres privados con endpoints privados para el plano de control.

   • Justificación: Limita la exposición del plano de control a la VPC. Los operadores se conectan a través de un bastión en una subred de gestión. Esto reduce la superficie de ataque en comparación con los endpoints públicos con Authorized Networks.

3. Habilitar Cloud NAT y Private Google Access en las subredes de los nodos.

   • Justificación: Los nodos no tienen IP externas, pero aun así necesitan descargar imágenes de Artifact Registry y acceder a los repositorios de paquetes y del sistema operativo. PGA garantiza el acceso a las API de Google sin IP de origen públicas; Cloud NAT gestiona el tráfico de salida (egress) no dirigido a Google según sea necesario.

4. Implementar un Ingress global HTTP(S) usando Gateway API con NEGs de Pods.

   • Justificación: Una única VIP de anycast global reduce la latencia para los usuarios de todo el mundo. Los NEGs de Pods de GKE envían verificaciones de estado (health checks) directamente a los Pods y mejoran la detección de fallos. Gateway API proporciona una separación clara entre los Gateways de infraestructura y las Routes propiedad de la aplicación.

5. Restringir el acceso de clientes y permitir las verificaciones de estado.

   • Justificación: Adjuntar una política de Cloud Armor para permitir solo los CIDR corporativos, con una denegación por defecto y un modo de vista previa (preview) para evaluar nuevos bloqueos de forma segura. Además, asegurarse de que las reglas de firewall de la VPC permitan los rangos de origen de las verificaciones de estado de Google hacia los NEGs del backend para que las verificaciones de estado se mantengan en verde.

6. Aplicar NetworkPolicy con GKE Dataplane V2.

   • Justificación: Denegar por defecto el tráfico de entrada (ingress) y salida (egress) por namespace; permitir solo los puertos de frontend a backend y de backend a base de datos. Dataplane V2 aplica las políticas de manera eficiente con eBPF, reduciendo el radio de impacto (blast radius) en caso de que un Pod sea comprometido.

7. Habilitar Multi-Cluster Services en toda la flota (fleet).

   • Justificación: Exportar el servicio de API en ambas regiones y publicar un único DNS. Los clientes conmutan por error automáticamente a los endpoints saludables entre los clústeres. Dado que ambos clústeres están en la misma VPC con subredes regionales, el tráfico entre regiones se mantiene privado e incurre en una sobrecarga mínima.

8. Adoptar una malla de servicios para la seguridad y observabilidad del tráfico este-oeste.

   • Justificación: Forzar mTLS entre servicios, añadir presupuestos de reintentos/tiempos de espera y obtener métricas y trazas por ruta. La política a nivel de malla complementa a NetworkPolicy: NetworkPolicy controla la alcanzabilidad en L3/L4; la malla autentica y autoriza las identidades de los servicios en L7.

9. Fortalecer las identidades de las cargas de trabajo y los secretos.

   • Justificación: Mapear las KSA a GSA con permisos muy acotados a través de Workload Identity; otorgar solo los roles necesarios, como storage.objectViewer para los recuperadores de informes. Entregar las credenciales a través del CSI de Secret Manager para evitar secretos estáticos en los manifiestos.

10. Implementar barreras de protección (guardrails) para la capacidad y el registro.

    • Justificación: Establecer max-pods-per-node cuidadosamente para equilibrar el uso de IP. Monitorear la utilización del rango secundario y los VPC Flow Logs. Crear una regla de firewall explícita de alta prioridad que deniegue todo (deny-all) con registro en la etiqueta de la aplicación para detectar tráfico de cliente no deseado, preservando al mismo tiempo las rutas permitidas.

Este diseño da como resultado clústeres privados por defecto con acceso norte-sur controlado, conmutación por error multiclúster resiliente, identidad basada en el principio de privilegio mínimo y un plano de datos que escala sin el agotamiento recurrente de IP.

← Enrutamiento · Todos los dominios · Observabilidad de red →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →

Explorar Google →