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

Las 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 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 direcciones IP, balanceo de cargas, resolución de DNS y aplicación de políticas de red. En este documento, se explica cómo los componentes principales, como los nodos, los Pods y los servicios, interactúan con el plano de control en el contexto de las redes de GKE, y se abordan los siguientes temas:

  • 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 estratégicamente 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 la fuente 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 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 del 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 direcciones IP durante la creación y eliminación rápidas de Pods, también conocidas como rotación. Estas direcciones IP permiten la comunicación directa entre los Pods en diferentes nodos sin necesidad de traducción de direcciones de red (NAT).
  • Rango de direcciones IP de 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 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. 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:

  • Red de Pods: Es 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 extremos estables para exponer aplicaciones a clientes internos o externos, incluido el balanceo de cargas y el descubrimiento de servicios.
  • Redes de clústeres: Es la capa más externa y abarca cómo se conecta todo tu clúster de GKE al ecosistema de redes más amplio, incluida la administración de la entrada desde Internet, la salida a servicios externos y la conectividad a servicios de Google Cloud y sistemas locales.

Estas capas trabajan en conjunto para crear un modelo de comunicación integral que admite conectividad interna y externa, seguridad y escalabilidad. 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 redes de Pods

La red de Pod se establece 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. En el caso de los clústeres nativos de la VPC, el CNI predeterminado es el 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 de 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 asignar a los Pods. GKE reserva una parte de estas direcciones para crear un búfer que garantice la disponibilidad de direcciones IP durante la rotación rápida de Pods (creación y destrucción). Esta reserva es la razón por la 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 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 realiza 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 el CNI predeterminado para los clústeres nativos de VPC. El par veth del Pod se conecta al espacio de nombres de red raíz del nodo. Dado que las direcciones IP de los Pods son direcciones IP de alias conocidas por la red de VPC, el enrutamiento estándar de Linux en el nodo dirige el tráfico hacia y desde el Pod.
    • GKE Dataplane V2: Utiliza programas eBPF para controlar las redes de Pods y, a menudo, omite los puentes y los pares veth convencionales de Linux para administrar directamente los flujos de paquetes dentro del kernel y lograr 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 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 de veth se conecta al espacio de nombres raíz del nodo y, luego, Calico programa rutas de 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 crítico que depende del complemento de CNI de GKE que usa el clúster y la configuración de MTU de la red de VPC subyacente. Una discrepancia en los valores de la 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 el valor predeterminado para los clústeres nativos de la VPC que usan versiones de GKE anteriores a la 1.26.1.
CNI de Google Heredada Es el valor predeterminado 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 `Intranode`, la federación de identidades para cargas de trabajo para GKE o las redes de pila doble IPv4/IPv6.

Flujo de comunicación entre Pods

Kubernetes usa un modelo 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 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 en un nodo envía tráfico a un Pod en otro nodo, el tráfico fluye hacia el 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.

Cómo alojar Pods de red

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 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 de CNI de kubenet, este comportamiento es diferente del 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, 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 ejecuten en el mismo nodo. En los clústeres que usan el CNI de kubenet, el puente de red virtual cbr0 solo se crea si el nodo tiene Pods que tienen el parámetro de configuración hostNetwork: false.

Herramientas de redes de servicio

Si bien las redes de Pods proporcionan la conectividad fundamental entre los Pods individuales, no son suficientes para crear aplicaciones sólidas y escalables. Los Pods son efímeros, por lo que se pueden crear, destruir y reprogramar en cualquier momento. Esta situación hace que cambien sus direcciones IP. Las redes de servicios 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 servicios 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, desde un grupo de direcciones reservadas para los Services. Este 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 funcionan las herramientas de redes de servicio

Las redes de servicios se basan en dos mecanismos clave para enrutar el tráfico desde el extremo estable de un servicio a 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 DNS interno (kube-dns o Cloud DNS). Cuando creas un Service, el servicio DNS crea automáticamente un registro DNS correspondiente. Este registro permite que las aplicaciones se conecten al servicio usando su nombre de DNS (por ejemplo, my-app-service) en lugar de tener que conocer su ClusterIP. Aunque kube-dns es el valor predeterminado para 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 GKE Autopilot. Este servicio es completamente administrado, escalable y con alta disponibilidad. Se integra con las redes de VPC y Cloud Logging, lo que ofrece un mejor rendimiento y observabilidad sin necesidad de que administres los Pods de kube-dns.

Mecanismos de balanceo de cargas: La implementación del balanceo de cargas de servicios depende del modo de redes 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 cambio, GKE Dataplane V2 usa programas eBPF que se ejecutan en el kernel de Linux. Estos programas de eBPF son muy eficientes para interceptar el tráfico a los ClusterIPs de servicio y balancear la carga del tráfico directamente a los Pods de backend adecuados. Este enfoque genera un mejor rendimiento y se integra estrechamente 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 Servicios. 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 objeto Service.

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

    • Modo iptables: Este 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 un ClusterIP de 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. Por lo general, el balanceo de cargas entre los Pods de backend es aleatorio o rotativo.
    • Modo ipvs: Este modo usa el servidor virtual 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 desde un Pod cliente a un Pod servidor a través de 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 DNS interno del clúster resuelve este nombre en la ClusterIP estable del servicio (por ejemplo, 10.0.32.8).
  3. El Pod cliente envía una solicitud al ClusterIP del servicio.
  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 a la dirección IP del Pod.
  6. El paquete se enruta a través de la red plana de Pods 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 dirección IP del clúster del servicio, 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 Service Networking

Las redes de servicio 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 servicios a los que solo se necesita acceder desde el clúster, kube-proxy (o GKE Dataplane V2) controla el balanceo de cargas de forma interna. En el caso de los Services que deben exponerse a Internet, GKE aprovisiona automáticamente un balanceador de cargas de 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 especializado de capa 7, 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 configuraciones de objetos de escucha, como puertos, protocolos y nombres de host. Funciona como punto de entrada para el tráfico.
    • HTTPRoute: Especifica cómo se enruta el tráfico que recibe una Gateway a los Services. 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 de Google Cloud cuando 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 para la administración del tráfico, la observabilidad y la seguridad. Para una experiencia completamente administrada y compatible, GKE ofrece Cloud Service Mesh, que se basa en Istio.

Redes de clústeres

Las herramientas de redes del clúster son la capa más externa de las herramientas de 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 acceden a tus aplicaciones, cómo tus Pods acceden a APIs externas y cómo tu clúster se conecta a centros de datos locales. La red del clúster se basa en la infraestructura de VPC de Google Cloud.

Administrar el tráfico entrante

El tráfico de entrada es el tráfico que ingresa a tu clúster desde el mundo exterior. GKE usa varias Google Cloud funciones integradas 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 servicio de tipo LoadBalancer o un recurso de Ingress o Gateway), primero llega a un balanceador de cargas 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 apropiado. kube-proxy controla este reenvío en los clústeres que no usan GKE Dataplane V2, o bien los programas 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. Si bien 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 satisfacer tus requisitos de seguridad específicos. Estas reglas de firewall de VPC funcionan con las políticas de red de Kubernetes para proporcionar una defensa en profundidad, ya que controlan el tráfico a nivel del nodo y del Pod.

Optimización del flujo de tráfico externo: Cuando un balanceador de cargas envía tráfico a un nodo, es posible que el nodo deba reenviar ese tráfico a un Pod en un nodo diferente, lo que requiere saltos de red adicionales. Para evitar esta situación, establece el campo externalTrafficPolicy en 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 puedan acceder a servicios externos, debes administrar 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 con Cloud NAT: En clústeres privados en los que los Pods no tienen direcciones IP públicas, usa Cloud NAT para habilitar el acceso saliente a Internet. 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 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 la Internet pública, usa el Acceso privado de Google. Este es un mecanismo de salida importante para los clústeres privados que interactúan con las APIs de Google.

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 alto 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 en 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).

Protección del 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 privilegio mínimo, puedes usar NetworkPolicy. Una NetworkPolicy es un recurso de Kubernetes que actúa como 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 el primer 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 está integrada directamente en GKE Dataplane V2 o la controla 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 amenazas externas.

Reglas de firewall de VPC

Los clústeres de GKE residen dentro de una red de Google Cloud VPC 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 una defensa en profundidad. Los firewalls de VPC operan a nivel del nodo (capa 3 o capa 4) y controlan el tráfico hacia 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 que segmentan nodos en tu clúster puede tener efectos adversos. 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 servicio o un Ingress de Kubernetes, puedes aplicar controles de seguridad adicionales a nivel del balanceador de cargas. En el caso de los balanceadores de cargas externos, considera estas opciones:

  • Si expones un Service con el campo type: LoadBalancer, puedes especificar el campo loadBalancerSourceRanges en tu manifiesto de Service. Este campo restringe el acceso al Servicio 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 expones 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 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.

¿Qué sigue?