Consultar la documentación y los casos prácticos de las redes de GKE

Las redes en Google Kubernetes Engine (GKE) abarcan un amplio conjunto de conceptos, como pods, servicios, DNS, balanceo de carga, seguridad y gestión de direcciones IP. Aunque la documentación explica cada función en detalle, puede resultar difícil saber por dónde empezar cuando te enfrentas a un problema real.

Este documento le ayuda a consultar la documentación de redes de GKE vinculando los problemas habituales con las funciones y secciones que los resuelven. Cada caso práctico presenta una situación, identifica el problema y te dirige a la documentación pertinente. Este documento está dirigido a arquitectos de nube, desarrolladores y equipos de operaciones que deben comprender y resolver problemas de red habituales en GKE.

Si ya conoces los problemas de red habituales y prefieres profundizar directamente en los detalles técnicos, consulta los siguientes recursos para adquirir conocimientos básicos sobre las redes de GKE:

Caso práctico: diseñar la base de la red para GKE

En este caso práctico, eres un arquitecto de la nube que necesita diseñar una base de red escalable, segura y fiable para una nueva plataforma de GKE.

Reto: evitar el agotamiento de las direcciones IP

Situación: se espera que la complejidad y el uso de tu aplicación aumenten, por lo que debes diseñar una red que pueda escalarse para gestionar el aumento del tráfico y admitir el crecimiento de pods, servicios y nodos. También debes planificar la asignación de direcciones IP para evitar que se agoten.

Solución: Planifica tu esquema de direccionamiento IP para tener en cuenta el número de nodos, pods y servicios que necesitarás. Este plan incluye la elección de los intervalos de direcciones IP adecuados para cada uno, teniendo en cuenta la densidad de los pods y evitando las superposiciones con otras redes. Para obtener más información, consulta Gestionar la migración de direcciones IP en GKE.

Reto: aplicar la seguridad de defensa en profundidad

Situación: necesitas proteger los perímetros de tu clúster y aplicar reglas de confianza cero y de pod a pod.

Solución: usa políticas de cortafuegos para los perímetros de clústeres. Para obtener más información, consulta Controlar la comunicación entre pods y servicios mediante políticas de red.

Reto: dirigir el tráfico a diferentes tipos de aplicaciones

Situación: necesitas asegurarte de que otros servicios y usuarios puedan acceder a diferentes tipos de aplicaciones, como backends privados y aplicaciones HTTP(S) públicas.

Solución: Usa balanceadores de carga internos para las back-ends privadas. En el caso de las aplicaciones HTTP(S) públicas, usa Ingress o la API Gateway. Para obtener más información, consulta Información sobre el balanceo de carga en GKE.

Reto: usar herramientas de observabilidad para monitorizar y solucionar problemas de cargas de trabajo

Situación: debes solucionar problemas con el tráfico de red y necesitas comprender y monitorizar los flujos de tráfico de GKE para diagnosticar los problemas de forma eficaz.

Solución: implementa herramientas de observabilidad para monitorizar y solucionar problemas de tráfico de red. Para obtener más información, consulta Monitorizar el tráfico con la observabilidad de GKE Dataplane V2.

Caso práctico: exponer un nuevo microservicio

En este caso práctico, eres un desarrollador que va a implementar un nuevo microservicio en GKE. Debes hacer que el microservicio sea accesible para otros servicios del clúster y, más adelante, para clientes externos.

Reto: proporcionar un endpoint estable para la comunicación entre pods

Situación: tu aplicación necesita que los pods se comuniquen entre sí, pero las direcciones IP dinámicas que usan los pods hacen que esta comunicación no sea fiable.

Solución: crea un servicio de Kubernetes. Un servicio ClusterIP proporciona una dirección IP virtual y un nombre de DNS estables, con balanceo de carga entre los pods. Para obtener más información, consulta Información sobre los servicios de Kubernetes.

Reto: exponer el servicio para el acceso externo

Situación: el microservicio debe ser accesible desde Internet para una demostración.

Solución: crea un servicio LoadBalancer. GKE aprovisiona un balanceador de carga de red de paso a través externo regional con una dirección IP pública. Para el tráfico HTTP(S), te recomendamos que uses Ingress o Gateway, que proporcionan funciones de capa 7. Para obtener más información, consulta el artículo Acerca de los servicios LoadBalancer.

Reto: asignar una URL permanente y fácil de usar

Situación: el servicio necesita un nombre de dominio estable para los clientes.

Solución: reserva una dirección IP estática y configura el DNS de un dominio personalizado. Para obtener más información, consulta Configurar nombres de dominio con direcciones IP estáticas.

Reto: gestionar el enrutamiento avanzado del tráfico

Situación: a medida que tu aplicación crece, necesitas un control más sofisticado sobre cómo se enruta el tráfico. Por ejemplo, puede que tengas que hacer lo siguiente:

  • Aloja varios sitios web (como api.example.com y shop.example.com) en un solo balanceador de carga para ahorrar costes.
  • Dirige las solicitudes a diferentes servicios en función de la ruta de la URL (por ejemplo, envía / a la carga de trabajo de frontend y /api/v1 a la carga de trabajo de backend).
  • Protege tu aplicación con HTTPS gestionando certificados TLS.
  • Implementa nuevas funciones de forma segura por fases mediante lanzamientos Canary, en los que envías una pequeña parte del tráfico a una nueva versión antes de completar el lanzamiento.

Solución: usa la API Gateway. La implementación de la API Gateway de GKE proporciona una forma potente y estandarizada de gestionar este tipo de tráfico de norte a sur, y admite funciones avanzadas como el enrutamiento basado en rutas, la coincidencia de encabezados y la división del tráfico. Para obtener más información, consulta el artículo Acerca de la API Gateway.

Caso práctico: escalado del descubrimiento de servicios para una aplicación en crecimiento

A medida que tu aplicación basada en microservicios aumente en tráfico y complejidad, las consultas de DNS entre servicios aumentarán significativamente. Aunque los desarrolladores deben saber cómo crear aplicaciones resilientes en este entorno, los equipos de operaciones y de la plataforma suelen ser los responsables de implementar soluciones de redes escalables.

Reto: habilitar la comunicación entre servicios

Situación: los pods necesitan una forma fiable de localizar otros servicios.

Solución: GKE proporciona un servicio de DNS en clúster (como kube-dns o Cloud DNS) que resuelve nombres de DNS estables para los servicios, lo que permite una comunicación fiable entre pods. Para obtener más información, consulta Detección de servicios y DNS.

Reto: mejorar el rendimiento del DNS a gran escala

Situación: un volumen de consultas elevado provoca retrasos en las búsquedas.

Solución: habilita NodeLocal DNSCache. Cada nodo almacena en caché las consultas DNS de forma local, lo que reduce la latencia. Para obtener más información, consulta la descripción general de la configuración de NodeLocal DNSCache.

Reto: proporcionar descubrimiento de servicios en toda la VPC

Situación: las máquinas virtuales de Compute Engine necesitan acceder a los servicios del clúster.

Solución: integra Cloud DNS para que los registros DNS de servicio se resuelvan en toda la VPC. Para obtener más información, consulta Usar Cloud DNS para GKE.

Caso práctico: proteger una aplicación multinivel

En este caso práctico, formas parte de un equipo de ingeniería de plataformas que está desplegando una aplicación de tres niveles (frontend, facturación y base de datos) y debes aplicar una comunicación de confianza cero.

Reto: aplicar normas de tráfico estrictas

Situación: solo deben comunicarse entre sí servicios específicos.

Solución: habilita la aplicación de la política de red y aplica las políticas de default deny. A continuación, define reglas de permiso explícitas (por ejemplo, el frontend permite el tráfico a la facturación y la facturación permite el tráfico a la base de datos). Para obtener más información, consulta Configurar políticas de red para aplicaciones.

Reto: auditar y verificar las políticas de red

Situación: la seguridad requiere pruebas de cumplimiento y visibilidad.

Solución: habilita el registro de la política de red para registrar las conexiones permitidas y denegadas. Para obtener más información, consulta Usar el registro de la política de red.

Reto: exponer un servicio de forma privada a los consumidores

Situación: un servicio backend, como una base de datos o una API, debe ser accesible para los consumidores de otras redes de VPC sin exponerlo a Internet ni tener que lidiar con las complejidades del peering de VPC.

Solución: usa Private Service Connect para publicar el servicio. Los consumidores pueden crear un endpoint de PSC en su propia VPC para acceder a tu servicio de forma privada y segura. Para obtener más información, consulta Exponer servicios con Private Service Connect.

Caso práctico: conseguir una alta disponibilidad en varios clústeres

En este caso práctico, eres un ingeniero de fiabilidad de sitios (SRE) que ejecuta cargas de trabajo para una empresa de comercio electrónico en varios clústeres de GKE de diferentes regiones para mejorar la fiabilidad.

Reto: habilitar la comunicación entre clústeres

Situación: los servicios de un clúster deben descubrir y llamar a los servicios de otro.

Solución: usa los servicios multiclúster (MCS) de GKE para crear un nombre de DNS global y enrutar el tráfico automáticamente a los back-ends en buen estado. Para obtener más información, consulta Servicios multiclúster.

Reto: asegurar una conmutación por error resistente

Situación: si un servicio regional deja de estar disponible, el tráfico debe redirigirse automáticamente.

Solución: MCS proporciona un descubrimiento de servicios que tiene en cuenta el estado, lo que permite a los clientes resolver un único nombre de DNS en un backend en buen estado del clúster disponible más cercano. Este enfoque permite una conmutación por error resistente. Para obtener más información, consulta Servicios multiclúster.

Caso práctico: crear un entorno de GKE multitenant seguro y eficiente

Como miembro de un equipo de ingeniería de plataformas, proporcionas clústeres de GKE a varios equipos de aplicaciones. Necesitas centralizar el control de la red, conservar las direcciones IP y aplicar medidas de seguridad estrictas.

Reto: centralizar el control de la red

Situación: varios equipos de aplicaciones necesitan sus propios clústeres, pero la red debe gestionarse de forma centralizada.

Solución: usa VPC compartida. Los recursos de red se encuentran en un proyecto host, pero los clústeres de aplicaciones se ejecutan en proyectos de servicio. Para obtener más información, consulta Configurar clústeres con VPC compartida.

Reto: gestionar de forma eficiente las direcciones IP limitadas

Situación: el espacio de direcciones IP es limitado y debe usarse de forma eficiente.

Solución: ajusta el número máximo de pods por nodo y, si es necesario, usa intervalos que no sean RFC 1918 para las direcciones IP de los pods. Para obtener más información, consulta Gestionar la migración de direcciones IP en GKE.

Reto: usar un plano de datos moderno y seguro, y aprovisionar clústeres con el nuevo plano de datos

Situaciones:

  • Las empresas necesitan un alto rendimiento y una aplicación de políticas integrada para admitir cargas de trabajo exigentes y una postura de seguridad de confianza cero. Por ejemplo, puede que estés ejecutando microservicios a gran escala que sean sensibles a la latencia de la red o que necesites aplicar límites de seguridad estrictos entre aplicaciones en un clúster multiinquilino para cumplir los requisitos de cumplimiento normativo.
  • Los clústeres deben configurarse para usar un plano de datos de red moderno que ofrezca un alto rendimiento y seguridad, y deben desplegarse en la estructura de red gestionada de forma centralizada de la organización.

Solución: usa GKE Dataplane V2, que se basa en eBPF y proporciona un alto rendimiento y la aplicación de políticas de red integrada. Para obtener más información, consulta GKE Dataplane V2.

Caso práctico: observar y solucionar problemas de tráfico

Como ingeniero de fiabilidad de sitios, estás investigando por qué un servicio de tramitación de la compra no puede conectarse a un servicio de pago.

Reto: resolver problemas de conectividad

Situación: se pierden paquetes, pero no se sabe por qué.

Solución: habilita la observabilidad de GKE Dataplane V2. Métricas como hubble_drop_total confirman que se han denegado los paquetes. Para obtener más información, consulta Solucionar problemas con Hubble.

Reto: identificar la causa principal de los paquetes perdidos

Situación: después de confirmar que se están descartando paquetes de red (por ejemplo, con hubble_drop_total), identifica qué política de red específica está bloqueando el tráfico entre servicios.

Solución: utiliza la interfaz de línea de comandos o la interfaz de usuario de Hubble para monitorizar los flujos. La interfaz de usuario de Hubble proporciona una representación visual del tráfico y destaca la política mal configurada que deniega la conexión. Esta visualización permite al equipo identificar rápidamente la causa principal del problema y corregir la política. Para obtener más información, consulta Monitorizar el tráfico con la observabilidad de GKE Dataplane V2.

Caso práctico integral: implementar y escalar una aplicación de comercio segura

En este caso práctico completo, un equipo de ingeniería de plataformas crea una plataforma de GKE estandarizada para varios equipos de aplicaciones. El equipo implementa y optimiza una aplicación de comercio minorista de tres niveles (frontend, facturación y base de datos). Este proceso incluye proteger, escalar y mejorar el rendimiento de las cargas de trabajo de aprendizaje automático, así como integrar dispositivos de seguridad avanzados.

En el siguiente diagrama se muestra la arquitectura integral de una aplicación de comercio minorista multinivel segura desplegada en GKE. La arquitectura evoluciona en varias fases:

  • Fase 1: crea una configuración básica con VPC compartida y GKE Dataplane V2.
  • Fase 2: expón la aplicación mediante la API Gateway y los servicios multiclúster para conseguir una alta disponibilidad.
  • Fase 3: acelera las tareas de aprendizaje automático usando gVNIC y la red de nivel 1.
  • Fase 4: implementa dispositivos de seguridad avanzados mediante la compatibilidad con varias redes.
Diagrama que muestra la arquitectura integral de una aplicación de comercio minorista multinivel segura en GKE, que ilustra los componentes de red en seis fases de implementación y escalado.
Imagen 1. Arquitectura integral de una aplicación de comercio minorista segura y multinivel en GKE, en la que se destacan los componentes de red clave que se usan en cada fase de implementación y escalado. En las siguientes secciones se describen los detalles de cada fase.

Fase 1: Crear la base de la plataforma

Reto: centralizar la red de varios equipos de aplicaciones y asignar suficientes direcciones IP para gestionar el escalado.

Solución:

Fase 2: Desplegar y proteger la aplicación

Reto: garantizar una comunicación fiable entre servicios y aplicar la seguridad de confianza cero.

Solución:

Fase 3: Publicar la aplicación y escalarla para crecer

Reto: proporcionar acceso externo y reducir la latencia de las peticiones de DNS a medida que aumenta el tráfico.

Solución:

Fase 4: Conseguir una alta disponibilidad y solucionar problemas

Reto: asegurar la conmutación por error regional y depurar el tráfico perdido.

Solución:

Fase 5: Acelerar las cargas de trabajo de aprendizaje automático

Reto: eliminar los cuellos de botella de la red para entrenar modelos basados en GPU.

Solución:

  • Habilita gVNIC para obtener un mayor ancho de banda.
  • Configura la red de nivel 1 en los nodos críticos para maximizar el rendimiento.

Fase 6: Implementar dispositivos de seguridad avanzada

Reto: implementar un cortafuegos y un IDS de terceros con gestión independiente y tráfico de plano de datos con latencia ultrabaja.

Solución:

Siguientes pasos