Conocer la arquitectura de redes de GKE

Autopilot Standard

La red de Google Kubernetes Engine (GKE) usa y amplía la infraestructura de redes definidas por software (SDN) que proporciona la nube privada virtual (VPC). La red de GKE permite que tus componentes se comuniquen dentro de un clúster de Kubernetes y con servicios y redes externos. El modelo de redes de GKE se basa en el principio de redes de Kubernetes, según el cual cada pod tiene su propia dirección IP, para proporcionar direcciones IP, balanceo de carga, resolución de DNS y aplicación de políticas de red. En este documento se explica cómo interactúan los componentes principales, como los nodos, los pods y los servicios, con el plano de control en el contexto de las redes de GKE. Se tratan los siguientes temas:

• Cómo interactúan estos componentes en tu VPC
• Cómo se asignan y gestionan las direcciones IP
• Cómo fluye el tráfico hacia el clúster, dentro de él y desde él

Arquitectura de una red de GKE

Una red de GKE se basa en la nube privada virtual (VPC) de Google Cloud. Esta base proporciona una conectividad sólida y escalable para todas tus aplicaciones contenerizadas.

La base de la VPC y los intervalos de direcciones IP

En tu VPC, defines subredes, que son intervalos de direcciones IP regionales. GKE usa estratégicamente diferentes intervalos de direcciones IP en estas subredes para varios componentes del clúster. A menudo, usa intervalos de direcciones IP con alias de VPC:

• Intervalo de direcciones IP de los nodos: es el intervalo de direcciones IP principal de la subred en la que se implementan los nodos del clúster. Todos tus nodos de trabajador de GKE, que son VMs de Compute Engine, obtienen sus direcciones IP principales de este intervalo. Estas direcciones IP se usan para la comunicación entre nodos y para las comprobaciones de estado de los balanceadores de carga. La dirección IP del nodo también es la fuente del tráfico que se origina en el propio nodo. En los clústeres nativos de VPC, el tráfico de los pods usa la dirección IP del pod como dirección de origen, a menos que la dirección IP del pod se traduzca mediante una función como Cloud NAT.
• Intervalo de direcciones IP de pods: un intervalo de direcciones IP secundario específico, a menudo un bloque CIDR más grande, que se encuentra dentro de tu subred. Cada nodo recibe un grupo de direcciones IP de este intervalo. GKE asigna estas direcciones IP a los pods que se ejecutan en ese nodo. Cada pod de tu clúster obtiene su dirección IP única de este intervalo. Estas direcciones IP de Pod se pueden enrutar de forma nativa en tu nube privada virtual. De forma predeterminada, cada nodo obtiene un intervalo /24, que proporciona 256 direcciones IP. Sin embargo, GKE limita el número máximo de pods por nodo a 110. Este búfer ayuda a asegurar la disponibilidad de direcciones IP durante la creación y eliminación rápidas de pods, también conocidas como churn. Estas direcciones IP permiten la comunicación directa entre pods de diferentes nodos sin necesidad de traducción de direcciones de red (NAT).
• Intervalo de direcciones IP de servicio (ClusterIP): intervalo de direcciones IP secundario para las direcciones IP virtuales (ClusterIPs) asignadas a los servicios de Kubernetes. Estas direcciones IP estables solo se usan para la comunicación dentro del clúster.
• Dirección IP del plano de control: cada plano de control tiene una dirección IP pública o interna, según el tipo, la versión y la fecha de creación del clúster. Los nodos de trabajo y los clientes externos, como kubectl, usan esta dirección IP para comunicarse de forma segura con el servidor de la API de Kubernetes. GKE Frontend (GKFE) proporciona un endpoint basado en DNS para cada clúster, lo que ofrece una forma segura y fiable de acceder al plano de control sin gestionar directamente las direcciones IP.

Los tres pilares de las redes de GKE

La red de GKE consta de tres pilares interconectados, cada uno de los cuales representa una capa de comunicación distinta. Este marco te ayuda a entender cómo se comunican tus aplicaciones dentro del clúster y con redes externas:

• Red de pods: la capa fundamental que define cómo se comunican entre sí los contenedores individuales (pods) dentro del clúster.
• Redes de servicios: esta capa, basada en las redes de pods, describe cómo los servicios de Kubernetes proporcionan endpoints estables para exponer aplicaciones a clientes internos o externos, incluido el balanceo de carga y el descubrimiento de servicios.
• Redes de clústeres: la capa más externa, que abarca cómo se conecta todo el clúster de GKE al ecosistema de redes más amplio, incluida la gestión del tráfico entrante de Internet, el tráfico saliente a servicios externos y la conectividad a servicios de Google Cloud y sistemas locales.

Estas capas trabajan juntas para crear un modelo de comunicación integral que admita la conectividad interna y externa, la seguridad y la escalabilidad. En las siguientes secciones se analiza cada pilar en detalle.

Redes de pods

La red de pods es la base de toda la comunicación dentro de un clúster de GKE. Define cómo pueden encontrar e interactuar entre sí las aplicaciones que se ejecutan en los pods. En Kubernetes, un pod es la unidad desplegable más pequeña y básica. Un pod actúa como host lógico de tus aplicaciones. Ejecuta uno o varios contenedores que comparten recursos de red. Cuando se programa un pod en un nodo, Kubernetes crea un espacio de nombres de red dedicado para él en el kernel de Linux del nodo, lo que aísla su red de otros pods del mismo nodo.

Cómo funciona la red de pods

La red de pods se establece mediante una combinación de direcciones IP únicas, dispositivos de red virtual y complementos especializados que gestionan la conectividad.

Interfaz de red de contenedores (CNI): GKE usa complementos de CNI para implementar y gestionar la red de pods. En los clústeres nativos de VPC, el valor predeterminado es Google CNI. Otras opciones son kubenet (para clústeres que no son nativos de VPC), Calico y GKE Dataplane V2 (que se basa en Cilium). Estos complementos se encargan de conectar los pods a la red y de aplicar las políticas de red.

• Asignación de direcciones IP: cada nodo recibe un grupo de direcciones IP del intervalo de direcciones IP de pods para asignarlas a los pods. GKE reserva una parte de estas direcciones para crear un búfer que asegure la disponibilidad de direcciones IP durante la rotación rápida de pods (creación y destrucción). Por eso, el número de direcciones IP de pods asignables por nodo siempre es inferior al tamaño del intervalo.

• Espacios de nombres de red y pares Ethernet virtuales (veth): para facilitar la comunicación, Kubernetes conecta el espacio de nombres de red aislado del pod al espacio de nombres de red principal o raíz del nodo. Kubernetes establece esta conexión mediante un par Ethernet virtual o par veth, que actúa como un cable de red virtual. Un extremo del par se coloca en el espacio de nombres del pod y aparece como eth0. El otro extremo se conecta a un puente de red o directamente a la pila de red del nodo en el espacio de nombres raíz del nodo, lo que permite que los paquetes fluyan hacia y desde el pod.

  El método de conexión específico depende del complemento CNI que use tu clúster:

  • CNI de Google: es el CNI predeterminado de los clústeres nativos de VPC. El par veth del pod se conecta al espacio de nombres de red raíz del nodo. Como las direcciones IP de los pods son direcciones IP de alias que conoce la red de VPC, el enrutamiento estándar de Linux en el nodo dirige el tráfico hacia y desde el pod.
  • Dataplane V2 de GKE: usa programas eBPF para gestionar la red de pods y, a menudo, omite los puentes y los pares veth convencionales de Linux para gestionar directamente los flujos de paquetes en el kernel y, así, mejorar el rendimiento.
  • Kubenet se usa en clústeres que no son nativos de VPC. El otro extremo del par veth se conecta a un dispositivo de puente Linux llamado cbr0 en el espacio de nombres raíz del nodo. Este puente gestiona el tráfico entre los pods del mismo nodo y usa NAT para el tráfico que sale del nodo.
  • Calico: cuando la política de red está habilitada con Calico, el otro extremo del par veth se conecta al espacio de nombres raíz del nodo y Calico programa las rutas de host para dirigir el tráfico a los pods correctos.

Unidad máxima de transmisión (MTU): determina el tamaño máximo del paquete que se puede enviar a través de una red sin fragmentarse. En GKE, el MTU de la interfaz de un pod es un ajuste fundamental que depende del plugin CNI de GKE que utilice el clúster y de los ajustes de MTU de la red de VPC subyacente. Si los valores de MTU no coinciden, se pueden perder paquetes o el rendimiento puede verse afectado. El valor de MTU de la interfaz de Pod es de 1460 bytes o se hereda de la interfaz de red principal del nodo, como se muestra en la siguiente tabla.

CNI	MTU	Uso
CNI de Google	1460	Valor predeterminado de los clústeres nativos de VPC que usan versiones de GKE anteriores a la 1.26.1.
CNI de Google	Heredada	Valor predeterminado de los clústeres nativos de VPC que usan las versiones 1.26.1 y posteriores de GKE.
Calico	1460	Se usa cuando la política de red está habilitada (--enable-network-policy).
GKE Dataplane V2	Heredada	Se usa cuando GKE Dataplane V2 está habilitado (--enable-dataplane-v2).
netd	Heredada	Se usa cuando se habilitan funciones como la visibilidad de `Intranode`, Workload Identity Federation for GKE para GKE o la red de doble pila IPv4/IPv6.

En los clústeres que ejecutan versiones anteriores a la 1.26.1, al habilitar funciones como `Intranode visibility`, Workload Identity Federation para GKE o la red de doble pila IPv4/IPv6, el MTU de los pods se hereda de la interfaz principal del nodo.

Flujo de comunicación entre pods

Kubernetes usa un modelo de red plana en el que cada pod tiene una dirección IP única y enrutable. Este modelo ayuda a garantizar una conectividad fluida entre los pods.

Comunicación dentro del mismo nodo

Cuando un pod envía tráfico a otro pod del mismo nodo, la solicitud fluye desde el espacio de nombres de red del primer pod, a través de su par veth, hasta el espacio de nombres de red raíz del nodo. Este tráfico permanece en el nodo. En función del complemento CNI que se utilice, el complemento CNI reenvía el tráfico al par veth del segundo pod. Por ejemplo, con kubenet, un dispositivo puente reenvía el tráfico. Con GKE Dataplane V2, los programas eBPF gestionan el flujo de paquetes directamente.

Comunicación entre diferentes nodos

Cuando un pod de un nodo envía tráfico a un pod de otro nodo, el tráfico fluye al espacio de nombres de red raíz del primer nodo. A continuación, el tráfico sale de la interfaz de red principal del primer nodo y entra en la red de VPC. Como las direcciones IP de los pods se pueden enrutar de forma nativa en un clúster de GKE nativo de VPC, la red de VPC enruta el tráfico directamente al segundo nodo. El segundo nodo reenvía el tráfico al pod de destino.

Pods de red de host

En casos prácticos específicos, puedes configurar un pod con el ajuste hostNetwork: true. Este ajuste omite la red de pods aislada y permite que el pod comparta directamente el espacio de nombres de red del nodo. Con este acceso directo, el pod usa la dirección IP del nodo y puede comunicarse con todos los demás pods sin necesidad de NAT. En los clústeres que usan el complemento CNI kubenet, este comportamiento es diferente al de los pods normales. Los pods normales requieren NAT para el tráfico saliente porque sus direcciones IP no se pueden enrutar directamente en la red de VPC. Por el contrario, la red nativa de VPC de GKE hace que esta traducción sea innecesaria para todos los pods. Sin embargo, al configurar pods con el ajuste hostNetwork: true, ten cuidado para evitar conflictos de puertos con otros procesos o pods que se ejecuten en el mismo nodo. En los clústeres que usan el kubenet CNI, el puente de red virtual cbr0 se crea solo si el nodo tiene pods que tienen el ajuste hostNetwork: false.

Redes de servicios

Aunque la red de pods proporciona la conectividad fundamental entre los pods individuales, no es suficiente para crear aplicaciones sólidas y escalables. Los pods son efímeros: se pueden crear, destruir y reprogramar en cualquier momento. Esta situación provoca que sus direcciones IP cambien. La red de servicios resuelve este problema proporcionando una forma estable y fiable de exponer aplicaciones y gestionar cómo se comunican, tanto dentro del clúster como con el mundo exterior.

Un servicio de Kubernetes es una abstracción que define un conjunto lógico de pods y una política para acceder a ellos. Los servicios usan etiquetas para agrupar varios pods relacionados en una sola unidad lógica. Cuando creas un servicio, Kubernetes le asigna una dirección IP virtual estable, conocida como ClusterIP, de un grupo de direcciones reservadas para los servicios. Esta ClusterIP, junto con un nombre de DNS asociado, permanece constante durante todo el ciclo de vida del servicio, lo que proporciona un endpoint coherente que otras aplicaciones pueden usar para conectarse a los pods.

Cómo funciona la creación de redes de servicios

La red de servicios se basa en dos mecanismos clave para enrutar el tráfico desde el punto final estable de un servicio a sus pods de backend dinámicos: el descubrimiento de servicios y el balanceo de carga.

Descubrimiento de servicios: para que las aplicaciones se encuentren y se comuniquen entre sí, GKE proporciona un servicio DNS interno (kube-dns o Cloud DNS). Cuando creas un servicio, el servicio DNS crea automáticamente un registro DNS correspondiente. Este registro permite que las aplicaciones se conecten al servicio mediante su nombre de DNS (por ejemplo, my-app-service) en lugar de tener que conocer su ClusterIP. Aunque kube-dns es el valor predeterminado de los clústeres Estándar, Cloud DNS para GKE es la solución recomendada para la mayoría de los entornos de producción. También es la única solución compatible con los clústeres de Autopilot de GKE. Este servicio está totalmente gestionado, es escalable y tiene una alta disponibilidad. Se integra con las redes VPC y Cloud Logging, lo que ofrece un mejor rendimiento y observabilidad sin que tengas que gestionar los pods de kube-dns.

Mecanismos de balanceo de carga: la implementación del balanceo de carga de servicios depende del modo de red de tu clúster de GKE.

• GKE Dataplane V2: los clústeres que usan GKE Dataplane V2 (basado en Cilium) no usan kube-proxy para el balanceo de carga de servicios. En su lugar, GKE Dataplane V2 usa programas eBPF que se ejecutan en el kernel de Linux. Estos programas eBPF son muy eficientes a la hora de interceptar el tráfico a los ClusterIPs de los servicios y de balancear la carga directamente al tráfico de los pods de backend adecuados. Este enfoque ofrece un mejor rendimiento y está estrechamente integrado con las funciones de aplicación de políticas de red de GKE Dataplane V2.

• kube-proxy (para clústeres sin GKE Dataplane V2): en todos los nodos de un clúster de GKE que no use GKE Dataplane V2, un componente llamado kube-proxy implementa el mecanismo de dirección IP virtual para los servicios. kube-proxy monitoriza el servidor de la API de Kubernetes para detectar cambios en los servicios y los endpoints. Después, programa reglas de red en el nodo para interceptar el tráfico destinado a la ClusterIP de un servicio.

  kube-proxy puede funcionar en diferentes modos, entre los que se incluyen los siguientes:

  • Modo iptables: es el modo predeterminado. kube-proxy añade y elimina reglas de traducción de direcciones de red de destino (DNAT) en el subsistema iptables del nodo. Cuando llega tráfico a la ClusterIP de un servicio, estas reglas realizan una traducción de NAT y cambian la dirección IP de destino a uno de los pods de backend en buen estado. El balanceo de carga entre los pods de backend suele ser aleatorio o rotatorio.
  • Modo ipvs: este modo usa el servidor virtual de IP (IPVS) de Linux para el balanceo de carga de alto rendimiento. kube-proxy configura reglas de IPVS, que pueden gestionar un gran número de servicios y proporcionar algoritmos de balanceo de carga más sofisticados.

Ejemplo de flujo de comunicación interno

En la siguiente lista se describe cómo fluye una solicitud de un pod de cliente a un pod de servidor mediante un servicio en un clúster que no usa Dataplane V2 de GKE:

1. La aplicación cliente hace una consulta DNS para my-server-service.
2. El servicio DNS interno del clúster resuelve este nombre en la ClusterIP estable del servicio (por ejemplo, 10.0.32.8).
3. El pod del cliente envía una solicitud a la ClusterIP del servicio.
4. Las reglas de iptables en el nodo del cliente, que gestiona kube-proxy, interceptan esta solicitud.
5. Estas reglas iptables realizan DNAT y seleccionan uno de los pods de backend en buen estado para my-server-service (por ejemplo, el pod 2 con la dirección IP 10.4.0.3). Las reglas también reescriben la dirección IP de destino del paquete a la dirección IP del pod.
6. El paquete se enruta a través de la red plana de pods hasta el pod 2, que procesa la solicitud.

En los clústeres que usan Dataplane V2 de GKE, los programas eBPF gestionan la interceptación y el balanceo de carga del tráfico a la IP del clúster de servicio, lo que evita kube-proxy y iptables.

Manifiesto de servicio de ejemplo

En el siguiente ejemplo se muestra un manifiesto de servicio. El campo selector especifica qué pods reciben tráfico en función de sus etiquetas.

apiVersion: v1
kind: Service
metadata:
  name: my-server-service
spec:
  selector:
    app: my-server # This should match the labels on your server Pods
  ports:
  - protocol: TCP
    port: 80 # The port the Service exposes
    targetPort: 8080 # The port the containers in the Pods are listening on

Características de las redes de servicios

La red de servicios de GKE ofrece varias funciones para gestionar el flujo de tráfico y exponer aplicaciones, tanto interna como externamente.

• Balanceo de carga interno y externo: para los servicios a los que solo se debe acceder desde el clúster, kube-proxy (o GKE Dataplane V2) gestiona el balanceo de carga internamente. En el caso de los servicios que deben exponerse a Internet, GKE aprovisiona automáticamente un balanceador de carga en la nube para distribuir el tráfico externo a los nodos del clúster.
• Balanceadores de carga de aplicaciones para el enrutamiento HTTP(S): para el tráfico HTTP(S), GKE usa un balanceador de carga de capa 7 especializado, el balanceador de carga de aplicaciones. Para configurar este balanceador de carga, usa la API Gateway de Kubernetes, que es el método recomendado para todas las aplicaciones nuevas. El controlador de GKE Gateway es la implementación de Google de la API Gateway y se ha diseñado para ser un sucesor más expresivo, flexible y extensible del recurso Ingress. Gateway API usa los siguientes recursos para configurar el balanceador de carga:
  • Pasarela: define configuraciones de escucha, como puertos, protocolos y nombres de host. Funciona como punto de entrada del tráfico.
  • HTTPRoute: especifica cómo se enruta a los servicios el tráfico que recibe una puerta de enlace. Es compatible con funciones avanzadas, como el enrutamiento basado en rutas, la coincidencia de encabezados y la división del tráfico.
  • Política: define cómo debe funcionar la infraestructura subyacente Google Cloud . Para ello, se adjunta a una puerta de enlace, una ruta o un servicio.
• Integración de malla de servicios para arquitecturas de microservicios complejas.GKE admite tecnologías de malla de servicios. Una malla de servicios es una capa de infraestructura opcional que proporciona funciones avanzadas de gestión del tráfico, observabilidad y seguridad. Para disfrutar de una experiencia totalmente gestionada y con asistencia, GKE ofrece Cloud Service Mesh, que se basa en Istio.

Redes de clúster

Las redes de clúster son la capa más externa de las redes de GKE. Se centra en cómo interactúa todo tu clúster de Kubernetes con recursos y redes externos, incluido cómo acceden los clientes de Internet a tus aplicaciones, cómo acceden tus pods a APIs externas y cómo se conecta tu clúster a centros de datos locales. La red de clústeres se basa en la infraestructura de VPC de Google Cloud.

Gestionar el tráfico entrante

La entrada es el tráfico que accede a tu clúster desde el exterior. GKE usa varias funciones integradas Google Cloud para gestionar y proteger este tráfico.

Flujo de datos de acceso externo: cuando un cliente de Internet envía una solicitud a tu aplicación (normalmente expuesta a través de un servicio de tipo LoadBalancer o un recurso Ingress o Gateway), primero llega a un Google Cloud balanceador de carga. El balanceador de carga dirige la solicitud a un nodo en buen estado de tu clúster. El nodo reenvía el tráfico al pod correspondiente. kube-proxy gestiona este reenvío en los clústeres que no usan GKE Dataplane V2, o bien los programas eBPF lo gestionan en los clústeres que sí lo usan. El pod de destino puede estar en el mismo nodo o en otro.

Reglas de cortafuegos: los clústeres de GKE usan reglas de cortafuegos de VPC para controlar el tráfico entrante. Aunque GKE crea automáticamente algunas reglas de cortafuegos predeterminadas para las operaciones esenciales del clúster, como permitir que el plano de control llegue a los nodos, puedes definir reglas personalizadas para cumplir tus requisitos de seguridad específicos. Estas reglas de cortafuegos de VPC funcionan con las políticas de red de Kubernetes para proporcionar una defensa en profundidad controlando el tráfico tanto a nivel de nodo como de pod.

Optimizar el flujo de tráfico externo: cuando un balanceador de carga envía tráfico a un nodo, es posible que el nodo tenga que reenviar ese tráfico a un pod de otro nodo, lo que requiere saltos de red adicionales. Para evitar esta situación, asigna el valor Local al campo externalTrafficPolicy en el archivo de manifiesto del servicio. Cuando esta política está activa, el balanceador de carga usa una comprobación del estado para identificar qué nodos tienen pods en buen estado para el servicio de destino. El balanceador de carga solo envía tráfico a los pods en buen estado, lo que evita el salto de red adicional. La contrapartida es que esta política puede provocar una distribución desigual del tráfico si tus pods de backend no están distribuidos de forma uniforme entre los nodos de tu clúster.

Gestionar el tráfico saliente

El tráfico de salida es el que sale de tu clúster. Para que un clúster de GKE funcione y tus aplicaciones puedan acceder a servicios externos, debes gestionar varias rutas de conectividad.

Requisitos de conectividad fundamentales: todos los clústeres de GKE requieren conectividad saliente a los dominios *.googleapis.com, *.gcr.io y *.pkg.dev. La conectividad saliente a la dirección IP del plano de control también debe funcionar correctamente. Acceso a Internet para pods mediante Cloud NAT: en clústeres privados en los que los pods no tienen direcciones IP públicas, usa Cloud NAT para habilitar el acceso a Internet de salida. Cloud NAT es un servicio gestionado que permite que los pods se conecten a Internet para realizar tareas como descargar actualizaciones o acceder a APIs externas sin exponerlos a conexiones entrantes.

Conectividad a Google Cloud servicios: si necesitas permitir que tu clúster se comunique de forma segura con otros Google Cloud servicios, como Cloud Storage o Cloud SQL, sin atravesar Internet público, usa el acceso privado de Google. Se trata de un mecanismo de salida importante para los clústeres privados que interactúan con las APIs de Google.

Conectividad híbrida y entre clústeres

Para conectar tus clústeres de GKE a la infraestructura on-premise, usa Cloud VPN para crear túneles cifrados o Cloud Interconnect para establecer conexiones dedicadas de gran ancho de banda. Para habilitar la comunicación entre varios clústeres de GKE, usa los servicios de varios clústeres, que facilitan el descubrimiento de servicios y el flujo de tráfico entre diferentes clústeres, regiones o proyectos.

Controles de seguridad de red

Para proteger tu clúster y las aplicaciones que se ejecutan en él, GKE proporciona varias capas de controles de seguridad para el tráfico interno (este-oeste) y externo (norte-sur).

Proteger el tráfico interno (este-oeste) con políticas de red

De forma predeterminada, todos los pods de un clúster de GKE pueden comunicarse libremente entre sí. Para proteger el tráfico interno y aplicar el principio de los mínimos privilegios, puede usar NetworkPolicy. Una NetworkPolicy es un recurso de Kubernetes que actúa como cortafuegos para tus pods, ya que controla el tráfico de red entre ellos. Los recursos NetworkPolicy te permiten definir reglas para restringir el tráfico de entrada y salida de un grupo de pods seleccionado en función de una combinación de etiquetas, intervalos de direcciones IP y números de puerto. Cuando creas el primer NetworkPolicy en un espacio de nombres, se deniega todo el tráfico que no esté permitido explícitamente por esa política. La aplicación de estas políticas está integrada directamente en GKE Dataplane V2 o se gestiona mediante el complemento CNI del clúster, como Calico.

Ejemplo de manifiesto NetworkPolicy

En el siguiente ejemplo se muestra un manifiesto NetworkPolicy. Esta política se aplica a los pods con la etiqueta app: backend y solo permite el tráfico entrante de los pods que tienen la etiqueta app: frontend en el puerto TCP 6379.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 6379

Proteger el acceso externo al clúster

Controlar el tráfico que entra y sale de tu clúster es fundamental para proteger tus aplicaciones frente a amenazas externas.

Reglas de cortafuegos de VPC

Los clústeres de GKE se encuentran en una Google Cloud red de VPC y están protegidos por reglas de cortafuegos de VPC que controlan el tráfico hacia los nodos del clúster y desde ellos. Las reglas de cortafuegos de VPC y las políticas de red funcionan conjuntamente para proporcionar una defensa en profundidad. Los cortafuegos de VPC funcionan a nivel de nodo (capa 3 o capa 4) y controlan el tráfico a las propias máquinas virtuales. Las políticas de red operan a nivel de pod (capa 3 o capa 4) y proporcionan un control más granular sobre el tráfico entre las aplicaciones del clúster.

Crear reglas de cortafuegos de entrada o salida dirigidas a nodos de tu clúster puede tener efectos adversos. Por ejemplo, si aplicas reglas de denegación de salida a los nodos de tu clúster, podrían dejar de funcionar funciones como NodePort y kubectl exec.

Limitar el acceso a los balanceadores de carga

Cuando expones aplicaciones mediante un servicio o un recurso Ingress de Kubernetes, puedes aplicar controles de seguridad adicionales a nivel del balanceador de carga. En el caso de los balanceadores de carga externos, puedes usar estas opciones:

• Si expones un servicio mediante el campo type: LoadBalancer, puedes especificar el campo loadBalancerSourceRanges en el manifiesto del servicio. Este campo restringe el acceso al servicio únicamente a los intervalos de direcciones IP que definas.

• En el caso de los balanceadores de carga de aplicaciones (Ingress), puedes usar servicios de seguridad más avanzados al exponer aplicaciones HTTP(S):

  • Google Cloud Armor: este servicio es un cortafuegos de aplicaciones web (WAF) que ayuda a proteger tus aplicaciones frente a ataques DDoS y otras amenazas web.
  • Identity-Aware Proxy (IAP): para un control de acceso pormenorizado, puedes habilitar IAP en tus endpoints. IAP verifica la identidad de un usuario y la usa para determinar si se le debe permitir acceder a la aplicación.

Siguientes pasos

• Consulta cómo crear un clúster nativo de VPC.
• Consulta más información sobre GKE Dataplane V2.
• Implementa políticas de red para proteger la comunicación entre pods.
• Descubre diferentes formas de exponer aplicaciones mediante servicios y configurar Ingress con la API Gateway.