Explora la documentación y los casos de uso de las redes de GKE

Las herramientas de redes en Google Kubernetes Engine (GKE) abarcan un amplio conjunto de conceptos, incluidos los Pods, los servicios, el DNS, el balanceo de cargas, la seguridad y la administración de direcciones IP. Aunque la documentación explica cada función en detalle, puede ser difícil saber por dónde empezar cuando te enfrentas a un problema del mundo real.

Este documento te ayuda a navegar por la documentación de redes de GKE, ya que vincula los desafíos comunes con las funciones y las secciones que los resuelven. Cada caso de uso presenta una situación, identifica el desafío y te dirige a la documentación pertinente. Este documento está dirigido a arquitectos de la nube, desarrolladores y equipos de operaciones que deben comprender y resolver desafíos comunes de redes en GKE.

Si ya estás familiarizado con los desafíos comunes de redes y prefieres profundizar directamente en los detalles técnicos, explora los siguientes recursos para desarrollar tu conocimiento fundamental sobre las redes de GKE:

Caso de uso: Diseña la base de la red para GKE

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

Desafío: Evita el agotamiento de la dirección IP

Situación: Se espera que la complejidad y el uso de tu aplicación crezcan, por lo que debes diseñar una red que pueda escalarse para controlar 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 el agotamiento.

Solución: Planifica tu esquema de direccionamiento IP para tener en cuenta la cantidad de nodos, Pods y servicios que necesitarás. Este plan incluye elegir rangos de direcciones IP adecuados para cada uno, teniendo en cuenta la densidad de Pods y evitando superposiciones con otras redes. Para obtener más información, consulta Administra la migración de direcciones IP en GKE.

Desafío: Aplica la seguridad de defensa en profundidad

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

Solución: Usa políticas de firewall para los perímetros del clúster. Para obtener más información, consulta Controla la comunicación entre Pods y Services mediante las políticas de red.

Desafío: Enruta el tráfico a diferentes tipos de aplicaciones

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

Solución: Usa balanceadores de cargas internos para backends privados. Para las aplicaciones HTTP(S) públicas, usa la API de Ingress o Gateway. Para obtener más información, consulta Acerca del balanceo de cargas en GKE.

Desafío: Usa herramientas de observabilidad para supervisar y solucionar problemas de cargas de trabajo

Situación: Debes solucionar problemas con el tráfico de red y comprender y supervisar los flujos de tráfico de GKE para diagnosticar problemas de manera eficaz.

Solución: Implementa herramientas de observabilidad para supervisar y solucionar problemas del tráfico de red. Para obtener más información, consulta Observa tu tráfico mediante la observabilidad de GKE Dataplane V2.

Caso de uso: Expón un microservicio nuevo

En este caso de uso, eres un desarrollador que implementa un microservicio nuevo en GKE. Debes hacer que el microservicio sea accesible para otros servicios en el clúster y, más adelante, para clientes externos.

Desafío: Proporciona un extremo estable para la comunicación de Pod a Pod

Situación: Tu aplicación necesita que los Pods se comuniquen con otros Pods, pero las direcciones IP dinámicas que usan los Pods hacen que esta comunicación no sea confiable.

Solución: Crea un servicio de Kubernetes. Un servicio ClusterIP proporciona una dirección IP virtual estable y un nombre de DNS, con balanceo de cargas en los Pods. Para obtener más información, consulta Comprende los servicios de Kubernetes.

Desafío: Expón el servicio para el acceso externo

Situación: Se debe poder acceder al microservicio desde Internet para una demostración.

Solución: Crea un servicio LoadBalancer. GKE aprovisiona un balanceador de cargas de red de transferencia externo regional con una dirección IP pública. Para el tráfico HTTP(S), considera usar Ingress o Gateway, que proporcionan funciones de capa 7. Para obtener más información, consulta Acerca de los servicios LoadBalancer Services.

Desafío: Asigna 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 para un dominio personalizado. Para obtener más información, consulta Configura nombres de dominio con direcciones IP estáticas.

Desafío: Administra el enrutamiento avanzado del tráfico

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

  • Alojar varios sitios web (como api.example.com y shop.example.com) en un solo balanceador de cargas para ahorrar costos
  • Enrutar solicitudes a diferentes servicios según la ruta de URL (por ejemplo, enviar / a la carga de trabajo de frontend y /api/v1 a la carga de trabajo de backend).
  • Proteger tu aplicación con HTTPS mediante la administración de certificados TLS
  • Implementar de forma segura funciones nuevas en etapas mediante versiones canary, en las que envías una pequeña porción de tráfico a una versión nueva antes de una implementación completa

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

Caso de uso: Escala el descubrimiento de servicios para una aplicación en crecimiento

A medida que tu aplicación basada en microservicios crece en tráfico y complejidad, las consultas de DNS entre servicios aumentan de manera significativa. Si bien los desarrolladores deben comprender cómo compilar aplicaciones resilientes en este entorno, los equipos de operaciones y de plataforma suelen ser responsables de implementar soluciones de redes escalables.

Desafío: Habilita la comunicación entre servicios

Situación: Los Pods necesitan una forma confiable de ubicar otros servicios.

Solución: GKE proporciona un servicio DNS dentro del clúster (como kube-dns o Cloud DNS) que resuelve nombres de DNS estables para los servicios, lo que permite una comunicación confiable de Pod a Pod. Para obtener más información, consulta Descubrimiento de servicios y DNS.

Desafío: Mejora el rendimiento del DNS a gran escala

Situación: El alto volumen de consultas causa demoras en la búsqueda.

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

Desafío: Proporciona descubrimiento de servicios en toda la VPC

Situación: Las VMs de Compute Engine necesitan acceder a los servicios dentro del clúster.

Solución: Realiza la integración con Cloud DNS para que los registros DNS del servicio se resuelvan en toda la VPC. Para obtener más información, consulta Usa Cloud DNS para GKE.

Caso de uso: Protege una aplicación de varios niveles

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

Desafío: Aplica reglas de tráfico estrictas

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

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

Desafío: Audita y verifica las políticas de red

Situación: La seguridad requiere pruebas de aplicación y visibilidad.

Solución: Habilita el registro de políticas de red para registrar las conexiones permitidas y rechazadas. Para obtener más información, consulta Usa el registro de políticas de red.

Desafío: Expón un servicio de forma privada a los consumidores

Situación: Un servicio de backend, como una base de datos o una API, debe ser accesible para los consumidores en otras redes de VPC sin exponerlo a Internet público ni lidiar con las complejidades del intercambio de tráfico entre VPC.

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

Caso de uso: Logra una alta disponibilidad en varios clústeres

En este caso de uso, eres un SRE que ejecuta cargas de trabajo para una empresa de comercio electrónico en varios clústeres de GKE en diferentes regiones para mejorar la confiabilidad.

Desafío: Habilita 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 de varios clústeres (MCS) de GKE para crear un nombre de DNS global y enrutar el tráfico automáticamente a backends en buen estado. Para obtener más información, consulta Servicios de varios clústeres.

Desafío: Garantiza la conmutación por error resiliente

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

Solución: MCS proporciona descubrimiento de servicios con reconocimiento del estado, lo que permite a los clientes resolver un solo nombre de DNS en un backend en buen estado en el clúster disponible más cercano. Este enfoque permite la conmutación por error resiliente. Para obtener más información, consulta Servicios de varios clústeres.

Caso de uso: Compila un entorno de GKE seguro y eficiente para varios usuarios

Como parte de un equipo de ingeniería de plataformas, proporcionas clústeres de GKE a varios equipos de aplicaciones. Debes centralizar el control de la red, conservar las direcciones IP y aplicar una seguridad estricta.

Desafío: Centraliza el control de la red

Situación: Varios equipos de aplicaciones necesitan sus propios clústeres, pero las redes deben administrarse de forma centralizada.

Solución: Usa la VPC compartida. Los recursos de redes residen en un proyecto host, pero los clústeres de aplicaciones se ejecutan en proyectos de servicio. Para obtener más información, consulta Configura clústeres con una VPC compartida.

Desafío: Administra de manera eficiente las direcciones IP limitadas

Situación: El espacio de direcciones IP es limitado y debe usarse de manera eficiente.

Solución: Ajusta la cantidad máxima de Pods por nodo y, si es necesario, usa rangos que no sean RFC 1918 para las direcciones IP de Pods. Para obtener más información, consulta Administra la migración de direcciones IP en GKE.

Desafío: Usa un plano de datos moderno y seguro, y aprovisiona clústeres con el nuevo plano de datos

Situaciones:

  • La empresa requiere un alto rendimiento y la aplicación de políticas integrada para admitir cargas de trabajo exigentes y una postura de seguridad de confianza cero. Por ejemplo, es posible que ejecutes microservicios a gran escala que sean sensibles a la latencia de la red o que necesites aplicar límites de seguridad estrictos entre las aplicaciones en un clúster de varios usuarios para cumplir con los requisitos de cumplimiento de reglamentaciones.
  • Los clústeres deben configurarse para usar un plano de datos de redes moderno para obtener un alto rendimiento y seguridad, y deben implementarse dentro de la estructura de red administrada 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 de uso: Observa y soluciona problemas del tráfico

Como SRE, estás investigando por qué un servicio de confirmación de compra no puede conectarse a un servicio de pago.

Desafío: Resuelve problemas de conectividad

Situación: Se descartan paquetes, pero no está claro el motivo.

Solución: Habilita la observabilidad de GKE Dataplane V2. Las métricas como hubble_drop_total confirman que se rechazan los paquetes. Para obtener más información, consulta Soluciona problemas con Hubble.

Desafío: Identifica la causa raíz de los paquetes descartados

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

Solución: Usa la interfaz de línea de comandos o la IU de Hubble para rastrear los flujos. La IU de Hubble proporciona una representación visual del tráfico, en la que se destaca la política mal configurada exacta que rechaza la conexión. Esta visualización permite que el equipo identifique rápidamente la causa raíz del problema y corrija la política. Para obtener más información, consulta Observa tu tráfico mediante la observabilidad de GKE Dataplane V2.

Caso de uso de extremo a extremo: Implementa y escala una aplicación de venta minorista segura

En esta situación de extremo a extremo, un equipo de ingeniería de plataformas compila una plataforma de GKE estandarizada para varios equipos de aplicaciones. El equipo implementa y optimiza una aplicación de venta minorista de tres niveles (frontend, facturación, base de datos). Este proceso incluye proteger, escalar, mejorar el rendimiento de las cargas de trabajo de aprendizaje automático y la integración de dispositivos de seguridad avanzados.

En el siguiente diagrama, se ilustra la arquitectura de extremo a extremo de una aplicación de venta minorista segura de varios niveles implementada en GKE. La arquitectura evoluciona a través de varias fases:

  • Fase 1: Compila una configuración fundamental con la VPC compartida y GKE Dataplane V2.
  • Fase 2: Expón la aplicación con la API de Gateway y los servicios de varios clústeres para obtener alta disponibilidad.
  • Fase 3: Acelera las tareas de AA con gVNIC y las redes de nivel 1.
  • Fase 4: Implementa dispositivos de seguridad avanzados con la compatibilidad con varias redes.
Diagrama que muestra la arquitectura integral de una aplicación minorista segura de varios niveles en GKE, en el que se ilustran los componentes de redes en seis fases de implementación y escalamiento.
Figura 1. Una arquitectura de extremo a extremo para una aplicación de venta minorista segura de varios niveles en GKE, en la que se destacan los componentes clave de redes que se usan en cada fase de implementación y escalamiento. Los detalles de cada fase se describen en las siguientes secciones.

Fase 1: Compila la base de la plataforma

Desafío: Centraliza las redes para varios equipos de aplicaciones y asigna suficientes direcciones IP para controlar el escalamiento.

Solución:

Fase 2: Implementa y protege la aplicación

Desafío: Garantiza una comunicación confiable entre servicios y aplica la seguridad de confianza cero.

Solución:

Fase 3: Expón la aplicación y escálala para el crecimiento

Desafío: Proporciona acceso externo y reduce la latencia de búsqueda de DNS a medida que aumenta el tráfico.

Solución:

Fase 4: Logra una alta disponibilidad y soluciona problemas

Desafío: Garantiza la conmutación por error regional y depura el tráfico descartado.

Solución:

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

Desafío: Elimina los cuellos de botella de la red para el entrenamiento de modelos basados en GPU.

Solución:

  • Habilita gVNIC para obtener un mayor ancho de banda.
  • Configura las redes de nivel 1 en nodos críticos para obtener el máximo rendimiento.

Fase 6: Implementa dispositivos de seguridad avanzados

Desafío: Implementa un firewall y un IDS de terceros con administración independiente y tráfico de plano de datos con latencia ultrabaja.

Solución:

¿Qué sigue?