Obtén información sobre la arquitectura de redes de GKE

Las herramientas de redes de Google Kubernetes Engine (GKE) usan y extienden la infraestructura de redes definidas por software (SDN) que proporciona la nube privada virtual (VPC). Las herramientas de redes de GKE permiten 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, en el que cada Pod obtiene su propia dirección IP, para proporcionar direccionamiento IP, balanceo de cargas, 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 Services, con el plano de control en el contexto de las herramientas de redes de GKE, lo que abarca lo siguiente:

  • Cómo interactúan estos componentes dentro de tu VPC
  • Cómo se asignan y administran las direcciones IP
  • Cómo fluye el tráfico hacia el clúster, dentro de él y fuera de é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 conectividad sólida y escalable para todas tus aplicaciones alojadas en contenedores.

La base de la VPC y los rangos de direcciones IP

Dentro de tu VPC, defines subredes, que son rangos de direcciones IP regionales. GKE usa de forma estratégica diferentes rangos de direcciones IP dentro de estas subredes para varios componentes del clúster, a menudo con rangos de direcciones IP de alias de VPC:

  • Rango de direcciones IP de nodo: Es el rango de direcciones IP principal de la subred en la que se implementan los nodos del clúster. Todos tus nodos trabajadores de GKE, que son VMs de Compute Engine, obtienen sus direcciones IP principales de este rango. Estas direcciones IP se usan para la comunicación entre nodos y para las verificaciones de estado de los balanceadores de cargas. La dirección IP del nodo también es el origen del tráfico que se origina en el nodo. En los clústeres nativos de la VPC, el tráfico de los Pods usa la dirección IP del Pod como la dirección de origen, a menos que una función como Cloud NAT traduzca la dirección IP del Pod.
  • Rango de direcciones IP del Pod: Es un rango de direcciones IP secundario dedicado, 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 rango. 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 rango. Estas direcciones IP de Pod se pueden enrutar de forma nativa dentro de tu nube privada virtual. De forma predeterminada, cada nodo obtiene un rango /24, que proporciona 256 direcciones IP. Sin embargo, GKE limita la cantidad máxima de Pods por nodo a 110. Este búfer ayuda a garantizar la disponibilidad de las direcciones IP durante la creación y eliminación rápidas de Pods, lo que también se conoce como deserción. Estas direcciones IP permiten la comunicación directa entre Pods en diferentes nodos sin necesidad de traducción de direcciones de red (NAT).
  • Rango de direcciones IP del Service (ClusterIP): Es un rango de direcciones IP secundario para las direcciones IP virtuales (ClusterIP) asignadas a los Services de Kubernetes. Estas direcciones IP estables se usan solo 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 de clúster, la versión y la fecha de creación. Los nodos trabajadores y los clientes externos, como kubectl, usan esta dirección IP para comunicarse de forma segura con el servidor de la API de Kubernetes. El frontend de GKE (GKFE) proporciona un extremo basado en DNS para cada clúster, lo que ofrece una forma segura y confiable de acceder al plano de control sin administrar directamente las direcciones IP.

Los tres pilares de las herramientas de redes de GKE

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

  • Herramientas de redes de Pods: Es la capa fundamental que define cómo se comunican entre sí los contenedores individuales (Pods) dentro del clúster.
  • Herramientas de redes de Service: Se basa en las herramientas de redes de Pods. Esta capa describe cómo los Services de Kubernetes proporcionan extremos estables para exponer aplicaciones a clientes internos o externos, incluidos el balanceo de cargas y el descubrimiento de servicios.
  • Herramientas de redes del clúster: Es la capa más externa, que abarca cómo se conecta todo tu clúster de GKE al ecosistema de red más amplio, lo que incluye administrar la entrada desde Internet, la salida a servicios externos y la conectividad a los servicios de Google Cloud y los sistemas locales.

Estas capas funcionan juntas para crear un modelo de comunicación integral que admite la conectividad, la seguridad y la escalabilidad internas y externas. En las siguientes secciones, se explora cada pilar en detalle.

Herramientas de redes de pods

Las redes de Pods son la base de toda la comunicación dentro de un clúster de GKE. Define cómo las aplicaciones que se ejecutan dentro de los Pods pueden encontrarse e interactuar entre sí. En Kubernetes, un Pod es la unidad implementable más pequeña y básica. Un Pod actúa como un host lógico para tus aplicaciones. Ejecuta uno o más 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 en el mismo nodo.

Cómo funcionan las herramientas de redes de Pods

Las redes de Pods se establecen a través de una combinación de direcciones IP únicas, dispositivos de red virtuales y complementos especializados que administran la conectividad.

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

  • Asignación de direcciones IP: Cada nodo recibe un grupo de direcciones IP del rango de direcciones IP de Pod para asignarlas a los Pods. GKE reserva una parte de estas direcciones para crear un búfer que ayude a garantizar la disponibilidad de las direcciones IP durante la rotación rápida de Pods (creación y destrucción). Esta reserva es el motivo por el que la cantidad de direcciones IP de Pods asignables por nodo siempre es menor que el tamaño del rango.

  • Espacios de nombres de red y pares de Ethernet virtual (veth): Para facilitar la comunicación, Kubernetes conecta el espacio de nombres de red aislado del Pod con el espacio de nombres de red principal o raíz del nodo. Kubernetes establece esta conexión con un par de Ethernet virtual, o par veth, que actúa como un cable de red virtual. Un extremo del par se coloca dentro del 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 el flujo de paquetes hacia el Pod y desde este.

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

    • CNI de Google: Es la CNI predeterminada para los clústeres nativos de la VPC. El par veth del Pod se conecta al espacio de nombres de red raíz del nodo. Debido a que las direcciones IP de los Pods son direcciones IP de alias que la red de VPC conoce, el enrutamiento estándar de Linux en el nodo dirige el tráfico hacia y desde el Pod.
    • GKE Dataplane V2: Usa programas de eBPF para controlar las herramientas de redes de Pods y, a menudo, omite los puentes de Linux convencionales y los pares veth para administrar directamente los flujos de paquetes dentro del kernel y obtener un mayor rendimiento.
    • Kubenet: Se usa en clústeres no nativos de la VPC. El otro extremo del par de veth se conecta a un dispositivo de puente de Linux llamado cbr0 en el espacio de nombres raíz del nodo. Este puente administra el tráfico entre los Pods en el 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 de veth se conecta al espacio de nombres raíz del nodo y, luego, Calico programa las rutas del host para dirigir el tráfico a los Pods correctos.

Unidad de transmisión máxima (MTU): Determina el tamaño de paquete más grande que se puede enviar a través de una red sin fragmentarse. En GKE, la MTU de la interfaz de un Pod es un parámetro de configuración fundamental que depende del complemento de CNI de GKE que usa el clúster y de la configuración de MTU de la red de VPC subyacente. Una discrepancia en los valores de MTU puede provocar la pérdida de paquetes o la degradación del rendimiento. El valor de MTU de la interfaz del Pod es de 1,460 bytes fijos o se hereda de la interfaz de red principal del nodo, como se muestra en la siguiente tabla.

CNI MTU Uso
CNI de Google 1,460 Es la opción predeterminada para los clústeres nativos de la VPC que usan versiones de GKE anteriores a la 1.26.1.
CNI de Google Heredada Es la opción predeterminada para los clústeres nativos de la VPC que usan las versiones 1.26.1 y posteriores de GKE.
Calico 1,460 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 "Intranodo", Workload Identity Federation for GKE para GKE o las redes de pila doble IPv4/IPv6.

Flujo de comunicación entre Pods

Kubernetes usa un modelo de herramientas de redes plano, 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 en el mismo nodo, la solicitud fluye desde el espacio de nombres de red del primer Pod, a través de su par veth, y hacia el espacio de nombres de red raíz del nodo. Este tráfico permanece dentro del nodo. Según el complemento de CNI que se use, este reenvía el tráfico al par veth del segundo Pod. Por ejemplo, con kubenet, un dispositivo de puente reenvía el tráfico. Con GKE Dataplane V2, los programas de eBPF administran 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. Luego, el tráfico sale de la interfaz de red principal del primer nodo y entra en la red de VPC. Debido a que las direcciones IP de los Pods se pueden enrutar de forma nativa en un clúster de GKE nativo de la VPC, la red de VPC enruta el tráfico directamente al segundo nodo. Luego, el segundo nodo reenvía el tráfico al Pod de destino.

Pods de red de host

Para casos de uso específicos, puedes configurar un Pod con el parámetro de configuración hostNetwork: true. Este parámetro de configuración omite la red de Pods aislada y permite que el Pod comparta el espacio de nombres de red del nodo directamente. 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 de CNI de kubenet, este comportamiento es diferente del de los Pods normales. Los Pods normales requieren NAT para el tráfico saliente, ya que sus direcciones IP no se pueden enrutar directamente en la red de VPC. Por el contrario, las redes nativas de la VPC de GKE hacen que esta traducción sea innecesaria para todos los Pods. Sin embargo, cuando configures Pods con el parámetro de configuración hostNetwork: true, ten cuidado de evitar conflictos de puertos con otros procesos o Pods que se ejecutan en el mismo nodo. En los clústeres que usan la CNI de kubenet, el puente de red virtual cbr0 se crea solo si el nodo tiene Pods que tienen el parámetro de configuración hostNetwork: false.

Herramientas de redes de servicio

Aunque las herramientas de redes de Pods proporcionan la conectividad fundamental entre Pods individuales, no son suficientes para compilar aplicaciones sólidas y escalables. Los Pods son efímeros; se pueden crear, destruir y reprogramar en cualquier momento. Esta situación hace que cambien sus direcciones IP. Las herramientas de redes de Service resuelven este problema, ya que proporcionan una forma estable y confiable de exponer aplicaciones y administrar cómo se comunican, tanto dentro del clúster como con el mundo exterior.

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

Cómo funciona el Acceso privado a servicios

Las herramientas de redes de Service se basan en dos mecanismos clave para enrutar el tráfico desde el extremo estable de un Service hasta sus Pods de backend dinámicos: el descubrimiento de servicios y el balanceo de cargas.

Descubrimiento de servicios: Para que las aplicaciones se encuentren y se comuniquen entre sí, GKE proporciona un servicio de DNS interno (ya sea kube-dns o Cloud DNS). Cuando creas un Service, el servicio de DNS crea automáticamente un registro DNS correspondiente. Este registro permite que las aplicaciones se conecten al Service con su nombre de DNS (por ejemplo, my-app-service) en lugar de tener que conocer su ClusterIP. Aunque kube-dns es la opción predeterminada para los clústeres de Standard, 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 GKE Autopilot. Este servicio es completamente administrado, escalable y de alta disponibilidad. Se integra en las redes de VPC y Cloud Logging, lo que ofrece un mejor rendimiento y observabilidad sin que tengas que administrar los Pods de kube-dns.

Mecanismos de balanceo de cargas: La implementación del balanceo de cargas de Service depende del modo de red de tu clúster de GKE.

  • GKE Dataplane V2: Los clústeres que usan GKE Dataplane V2 (que se basa en Cilium) no usan kube-proxy para el balanceo de cargas de Service. En su lugar, GKE Dataplane V2 usa programas de eBPF que se ejecutan en el kernel de Linux. Estos programas de eBPF son muy eficientes para interceptar el tráfico a las ClusterIP de Service y balancear las cargas del tráfico directamente a los Pods de backend adecuados. Este enfoque genera un mejor rendimiento y se integra de forma estrecha con las capacidades de aplicación de políticas de red de GKE Dataplane V2.

  • kube-proxy (para clústeres sin GKE Dataplane V2): En cada nodo de un clúster de GKE que no usa GKE Dataplane V2, un componente llamado kube-proxy implementa el mecanismo de dirección IP virtual para los Services. kube-proxy supervisa el servidor de la API de Kubernetes para detectar cambios en los objetos Service y Endpoint, y, luego, programa reglas de red en el nodo para interceptar el tráfico destinado a la ClusterIP de un Service.

    kube-proxy puede funcionar en diferentes modos, incluidos los siguientes:

    • Modo iptables: Es el modo predeterminado. kube-proxy agrega y quita reglas de NAT de destino (DNAT) en el subsistema iptables del nodo. Cuando llega tráfico para la ClusterIP de un Service, 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 cargas entre Pods de backend suele ser aleatorio o round-robin.
    • Modo ipvs: Este modo usa el servidor virtual de IP (IPVS) de Linux para el balanceo de cargas de alto rendimiento. kube-proxy configura reglas de IPVS, que pueden controlar una gran cantidad de servicios y proporcionar algoritmos de balanceo de cargas más sofisticados.

Ejemplo de flujo de comunicación interna

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

  1. La aplicación cliente realiza una consulta de DNS para my-server-service.
  2. El servicio de DNS interno del clúster resuelve este nombre en la ClusterIP estable del Service (por ejemplo, 10.0.32.8).
  3. El Pod cliente envía una solicitud a la ClusterIP del Service.
  4. Las reglas iptables en el nodo del cliente, que administra kube-proxy, interceptan esta solicitud.
  5. Estas reglas de 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 en la dirección IP del Pod.
  6. El paquete se enruta a través de la red de Pods plana al Pod 2, que procesa la solicitud.

En los clústeres que usan GKE Dataplane V2, los programas de eBPF controlan la intercepción y el balanceo de cargas del tráfico a la ClusterIP del Service, lo que omite kube-proxy y iptables.

Ejemplo de manifiesto de Service

En el siguiente ejemplo, se muestra un manifiesto de Service. El campo selector especifica qué Pods reciben tráfico según 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

Funciones de las herramientas de redes de servicio

Las herramientas de redes de servicios de GKE ofrecen varias funciones para administrar el flujo de tráfico y exponer aplicaciones, tanto de forma interna como externa.

  • Balanceo de cargas interno y externo. Para los Services a los que se debe acceder solo desde el clúster, kube-proxy (o GKE Dataplane V2) controla el balanceo de cargas de forma interna. Para los Services que deben exponerse a Internet, GKE aprovisiona automáticamente un balanceador de cargas en la nube para distribuir el tráfico externo a los nodos del clúster.
  • Balanceadores de cargas de aplicaciones para el enrutamiento de HTTP(S). Para el tráfico de HTTP(S), GKE usa un balanceador de cargas de capa 7 especializado, el balanceador de cargas de aplicaciones. Este balanceador de cargas se configura con la API de Gateway de Kubernetes, que es el enfoque recomendado para todas las aplicaciones nuevas. El controlador de GKE Gateway es la implementación de Google de la API de Gateway y está diseñado para ser un sucesor más expresivo, flexible y extensible del recurso Ingress. La API de Gateway usa los siguientes recursos para configurar el balanceador de cargas:
    • Puerta de enlace: Define las configuraciones de los objetos de escucha, como los puertos, los protocolos y los nombres de host. Funciona como el punto de entrada para el tráfico.
    • HTTPRoute: Especifica cómo se enruta el tráfico que recibe una puerta de enlace a los servicios. Admite funciones avanzadas, como el enrutamiento basado en rutas de acceso, la coincidencia de encabezados y la división del tráfico.
    • Política: Define cómo debe funcionar la infraestructura subyacente de Google Cloud cuando se adjunta a una puerta de enlace, una ruta o un servicio.
  • Integración de la 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 para la administración, la observabilidad y la seguridad del tráfico. Para obtener una experiencia completamente administrada y compatible, GKE ofrece Cloud Service Mesh, que se basa en Istio.

Redes de clústeres

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

Administra el tráfico entrante

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

Flujo de datos de acceso externo: Cuando un cliente de Internet envía una solicitud a tu aplicación (por lo general, expuesta a través de un Service de tipo LoadBalancer o un recurso Ingress o Gateway), primero llega a un balanceador de cargas de Google Cloud . El balanceador de cargas enruta la solicitud a un nodo en buen estado de tu clúster. El nodo reenvía el tráfico al Pod adecuado. kube-proxy controla este reenvío en los clústeres que no usan GKE Dataplane V2, o los programas de eBPF lo controlan en los clústeres que usan GKE Dataplane V2. El Pod de destino puede estar en el mismo nodo o en uno diferente.

Reglas de firewall: Los clústeres de GKE usan reglas de firewall de VPC para controlar el tráfico entrante. Aunque GKE crea automáticamente algunas reglas de firewall 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 con tus requisitos de seguridad específicos. Estas reglas de firewall de VPC funcionan con las políticas de red de Kubernetes para proporcionar defensa en profundidad controlando el tráfico a nivel de nodo y de Pod.

Optimiza el flujo de tráfico externo: Cuando un balanceador de cargas envía tráfico a un nodo, es posible que este deba reenviar ese tráfico a un Pod en un nodo diferente, lo que requiere saltos de red adicionales. Para evitar esta situación, configura el campo externalTrafficPolicy como Local en el manifiesto de Service. Cuando esta política está activa, el balanceador de cargas usa una verificación de estado para identificar qué nodos tienen Pods en buen estado para el Service de destino. El balanceador de cargas envía tráfico solo a los Pods en buen estado, lo que evita el salto de red adicional. La desventaja es que esta política puede generar una distribución desigual del tráfico si los Pods de backend no se distribuyen de manera uniforme entre los nodos del clúster.

Administra el tráfico saliente

La salida es el tráfico que sale de tu clúster. Para que un clúster de GKE funcione y tus aplicaciones lleguen a los servicios externos, debes administrar varias rutas de conectividad.

Requisitos de conectividad fundamentales: Todos los clústeres de GKE requieren conectividad de salida 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 con Cloud NAT: En los clústeres privados en los que los Pods no tienen direcciones IP públicas, usa Cloud NAT para habilitar el acceso a Internet saliente. Cloud NAT es un servicio administrado 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 los servicios de Google Cloud : Si necesitas permitir que tu clúster se comunique de forma segura con otros servicios de Google Cloud , como Cloud Storage o Cloud SQL, sin atravesar la Internet pública, usa el Acceso privado a Google. Este es un mecanismo de salida importante para los clústeres privados que interactúan con las APIs de Google.

Límites de ancho de banda de salida: GKE no aplica límites de ancho de banda de red predeterminados por Pod o por contenedor para el tráfico de entrada o salida. Debido a que cada nodo de GKE es una VM de Compute Engine, todos los Pods de un nodo comparten los límites de ancho de banda de red que se aplican a ese nodo. La capacidad máxima de salida de un nodo depende del tipo de máquina de la VM, la configuración de red, el destino del tráfico y las cuotas de Google Cloud aplicables. Para obtener más información sobre cómo se calcula el ancho de banda de salida de los nodos y cómo aumentarlo, consulta Ancho de banda de salida máximo por instancia y Aumenta el ancho de banda de red para los clústeres y los nodos.

Conectividad híbrida y de varios clústeres

Para conectar tus clústeres de GKE a la infraestructura local, usa Cloud VPN para túneles encriptados o Cloud Interconnect para conexiones dedicadas de gran ancho de banda. Para habilitar la comunicación entre varios clústeres de GKE, usa los Services 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).

Protege 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 entre sí con libertad. Para proteger el tráfico interno y aplicar el principio de privilegio mínimo, puedes usar NetworkPolicy. Un NetworkPolicy es un recurso de Kubernetes que actúa como un firewall 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 seleccionado de Pods en función de una combinación de etiquetas, rangos de direcciones IP y números de puerto. Cuando creas la primera NetworkPolicy en un espacio de nombres, se rechaza todo el tráfico que no esté permitido de forma explícita por esa política. La aplicación de estas políticas se integra directamente en GKE Dataplane V2 o se controla con el complemento de CNI del clúster, como Calico.

Ejemplo de manifiesto de NetworkPolicy

En el siguiente ejemplo, se muestra un manifiesto de NetworkPolicy. Esta política se aplica a los Pods con la etiqueta app: backend y permite el tráfico de entrada solo desde 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

Protege el acceso externo al clúster

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

Reglas de firewall de VPC

Los clústeres de GKE residen dentro de una red de VPC de Google Cloud y están protegidos por reglas de firewall de VPC que controlan el tráfico hacia y desde los nodos del clúster. Las reglas de firewall de VPC y las políticas de red funcionan en conjunto para proporcionar defensa en profundidad. Los firewalls de VPC operan a nivel de nodo (capa 3 o capa 4) y controlan el tráfico a las VMs. Las políticas de red operan a nivel del Pod (capa 3 o capa 4) y proporcionan un control más detallado sobre el tráfico entre las aplicaciones dentro del clúster.

La creación de reglas de firewall de entrada o salida orientadas a los nodos en tu clúster puede tener efectos negativos. Por ejemplo, aplicar reglas de denegación de salida a los nodos de tu clúster podría interrumpir funciones como NodePort y kubectl exec.

Limita el acceso a los balanceadores de cargas

Cuando expones aplicaciones con un Service o Ingress de Kubernetes, puedes aplicar controles de seguridad adicionales a nivel del balanceador de cargas. Para los balanceadores de cargas externos, considera estas opciones:

  • Si expones un Service con el campo type: LoadBalancer, puedes especificar el campo loadBalancerSourceRanges en el manifiesto del Service. Este campo restringe el acceso al Service solo a los rangos de direcciones IP que definas.

  • Para los balanceadores de cargas de aplicaciones (Ingress), puedes usar servicios de seguridad más avanzados cuando expongas aplicaciones HTTP(S):

    • Google Cloud Armor: Este servicio es un firewall de aplicación web (WAF) que ayuda a proteger tus aplicaciones de ataques DSD y otras amenazas basadas en la Web.
    • Identity-Aware Proxy (IAP): Para obtener un control de acceso detallado, puedes habilitar IAP en tus extremos. IAP verifica la identidad de un usuario y la usa para determinar si se le debe permitir el acceso a la aplicación.

CNI personalizada

GKE ofrece opciones de CNI compatibles de forma nativa, incluidas la CNI de Google predeterminada, Calico y GKE Dataplane V2. Aunque otras CNI personalizadas de terceros podrían funcionar en tu clúster, GKE no las admite de forma oficial. El uso de una CNI personalizada requiere que administres su configuración y soluciones cualquier problema potencial.

Si se detecta una CNI personalizada en tu clúster, GKE proporciona una recomendación en la que se te aconseja quitarla para garantizar una configuración compatible. Para los casos de uso de la malla de servicios, las instalaciones personalizadas de Istio tampoco son compatibles. Te recomendamos que uses Cloud Service Mesh en su lugar.

¿Qué sigue?