Controlar la comunicación entre pods y servicios mediante políticas de red

En esta página se explica cómo controlar la comunicación entre los pods y los servicios de tu clúster mediante la aplicación de políticas de red de GKE.

También puedes controlar el tráfico de salida de los pods a cualquier endpoint o servicio fuera del clúster mediante políticas de red de nombre de dominio completo (FQDN). Para obtener más información, consulta Controlar la comunicación entre pods y servicios mediante FQDNs.

Acerca de la aplicación de la política de red de GKE

La implementación obligatoria de la política de red te permite crear políticas de red de Kubernetes en tu clúster. De forma predeterminada, todos los pods de un clúster pueden comunicarse entre sí libremente. Las políticas de red crean reglas de cortafuegos a nivel de pod que determinan qué pods y servicios pueden acceder entre sí dentro de tu clúster.

Definir una política de red te ayuda a habilitar funciones como la defensa en profundidad cuando tu clúster sirve una aplicación de varios niveles. Por ejemplo, puedes crear una política de red para asegurarte de que un servicio de frontend vulnerado de tu aplicación no pueda comunicarse directamente con un servicio de facturación o contabilidad que se encuentre varios niveles más abajo.

La política de red también puede facilitar que tu aplicación aloje datos de múltiples usuarios de forma simultánea. Por ejemplo, puedes proporcionar propiedad múltiple segura definiendo un modelo de propietario por espacio de nombres. En dicho modelo, las reglas de la política de red pueden garantizar que los pods y los servicios de un espacio de nombres determinado no puedan acceder a otros pods o servicios en un espacio de nombres diferente.

Antes de empezar

Antes de empezar, asegúrate de que has realizado las siguientes tareas:

• Habilita la API de Google Kubernetes Engine.
Habilitar la API de Google Kubernetes Engine
• Si quieres usar Google Cloud CLI para esta tarea, instálala y, a continuación, inicialízala. Si ya has instalado la gcloud CLI, obtén la versión más reciente ejecutando gcloud components update.

Requisitos y limitaciones

Los siguientes requisitos y limitaciones se aplican tanto a los clústeres Autopilot como a los estándar:

• Debes permitir el tráfico saliente al servidor de metadatos.
• Si especificas un campo endPort en una política de red de un clúster que tiene habilitado GKE Dataplane V2, es posible que no surta efecto a partir de la versión 1.22 de GKE. Para obtener más información, consulta Los intervalos de puertos de la política de red no se aplican. En los clústeres de Autopilot, GKE Dataplane V2 siempre está habilitado.

Los siguientes requisitos y limitaciones solo se aplican a los clústeres estándar:

• Debes permitir la salida al servidor de metadatos si usas una política de red con Workload Identity Federation para GKE.
• Si habilitas la aplicación de políticas de red, la huella de memoria del proceso kube-system aumentará en unos 128 MB y se necesitarán unos 300 milinúcleos de CPU. Esto significa que, si habilitas las políticas de red en un clúster, es posible que tengas que aumentar el tamaño del clúster para seguir ejecutando las cargas de trabajo programadas.
• Para habilitar la implementación obligatoria de la política de red, es necesario volver a crear los nodos. Si tu clúster tiene una ventana de mantenimiento activa, los nodos no se volverán a crear automáticamente hasta la siguiente ventana de mantenimiento. Si lo prefieres, puedes actualizar tu clúster manualmente en cualquier momento.
• El tamaño mínimo obligatorio del clúster para ejecutar la aplicación de la política de red es de tres instancias e2-medium o una instancia de tipo de máquina con más de 1 vCPU asignable. Consulta los problemas conocidos de GKE para obtener más información.
• La política de red no se admite en clústeres cuyos nodos sean instancias f1-micro o g1-small, ya que los requisitos de recursos son demasiado altos.
• Cilium o Calico no gestionan los pods que definen hostNetwork: true, y las políticas de red no pueden regir estos pods.

Para obtener más información sobre los tipos de máquinas de los nodos y los recursos asignables, consulta el artículo Arquitectura de clúster estándar: nodos.

Habilitar la implementación obligatoria de la política de red

La implementación obligatoria de la política de red está habilitada de forma predeterminada en los clústeres de Autopilot, por lo que puedes ir directamente a la sección Crear una política de red.

Puedes habilitar la aplicación de políticas de red en Estándar mediante la CLI de gcloud, la consola de Trusted Cloud o la API de GKE.

La aplicación de políticas de red está integrada en GKE Dataplane V2. No es necesario habilitar la aplicación de la política de red en los clústeres que usan GKE Dataplane V2.

Para aplicar este cambio, es necesario volver a crear los nodos, lo que puede provocar interrupciones en las cargas de trabajo en ejecución. Para obtener información sobre este cambio concreto, busca la fila correspondiente en la tabla Cambios manuales que recrean los nodos mediante una estrategia de actualización de nodos y respetando las políticas de mantenimiento. Para obtener más información sobre las actualizaciones de nodos, consulta Planificar interrupciones de actualizaciones de nodos.

Inhabilitar la implementación obligatoria de la política de red en un clúster estándar

Puedes inhabilitar la aplicación de la política de red mediante la CLI de gcloud, la Trusted Cloud consola o la API de GKE. No puedes inhabilitar la aplicación de la política de red en clústeres de Autopilot ni en clústeres que usen GKE Dataplane V2.

Para aplicar este cambio, es necesario volver a crear los nodos, lo que puede provocar interrupciones en las cargas de trabajo en ejecución. Para obtener información sobre este cambio concreto, busca la fila correspondiente en la tabla Cambios manuales que recrean los nodos mediante una estrategia de actualización de nodos y respetando las políticas de mantenimiento. Para obtener más información sobre las actualizaciones de nodos, consulta Planificar interrupciones de actualizaciones de nodos.

Crear una política de red

Puedes crear una política de red mediante la API Network Policy de Kubernetes.

Para obtener más información sobre cómo crear una política de red, consulta los siguientes temas en la documentación de Kubernetes:

• Resumen de la política de la red
• Declarar la política de red

Política de red y federación de identidades de cargas de trabajo para GKE

Si usas la política de red con Workload Identity Federation para GKE, debes permitir la salida a las siguientes direcciones IP para que tus pods puedan comunicarse con el servidor de metadatos de GKE.

• En los clústeres que ejecutan la versión 1.21.0-gke.1000 de GKE o una posterior, permite el tráfico saliente a 169.254.169.252/32 en el puerto 988.
• En los clústeres que ejecuten versiones de GKE anteriores a la 1.21.0-gke.1000, permite el tráfico saliente a 127.0.0.1/32 en el puerto 988.
• En los clústeres que ejecutan GKE Dataplane V2, permite el tráfico saliente a 169.254.169.254/32 en el puerto 80.

Si no permites el tráfico saliente a estas direcciones IP y puertos, es posible que se produzcan interrupciones durante las actualizaciones automáticas.

Migrar de Calico a GKE Dataplane V2

Si migras tus políticas de red de Calico a GKE Dataplane V2, ten en cuenta las siguientes limitaciones:

• No puedes usar una dirección IP de Pod o de Service en el campo ipBlock.cidr de un manifiesto de NetworkPolicy. Debes hacer referencia a las cargas de trabajo mediante etiquetas. Por ejemplo, la siguiente configuración no es válida:

  - ipBlock:
      cidr: 10.8.0.6/32
  

• No puedes especificar un campo ports.port vacío en un manifiesto NetworkPolicy. Si especifica un protocolo, también debe especificar un puerto. Por ejemplo, la siguiente configuración no es válida:

  ingress:
  - ports:
    - protocol: TCP
  

Trabajar con balanceadores de carga de aplicaciones

Cuando se aplica un objeto Ingress a un servicio para crear un balanceador de carga HTTP(S), debes asegurarte de que tu política de red permita el tráfico de los intervalos de direcciones IP de comprobación del estado del balanceador de carga de aplicaciones HTTP(S).

Si no usas el balanceo de carga nativo de contenedores con grupos de puntos finales de red, los puertos de nodo de un servicio pueden reenviar conexiones a pods de otros nodos, a menos que se lo impidas configurando externalTrafficPolicy en Local en la definición del servicio. Si externalTrafficPolicy no está definido como Local, la política de red también debe permitir las conexiones de otras direcciones IP de nodos del clúster.

Inclusión de intervalos de IPs de pods en reglas ipBlock

Para controlar el tráfico de Pods específicos, selecciona siempre los Pods por su espacio de nombres o las etiquetas de los Pods mediante los campos namespaceSelector y podSelector en las reglas de entrada o salida de NetworkPolicy. No uses el campo ipBlock.cidr para seleccionar intencionadamente intervalos de direcciones IP de pods, que son efímeros por naturaleza. El proyecto de Kubernetes no define explícitamente el comportamiento del campo ipBlock.cidr cuando incluye intervalos de direcciones IP de pods. Si especificas intervalos CIDR amplios en este campo, como 0.0.0.0/0 (que incluye los intervalos de direcciones IP de los pods), es posible que se produzcan resultados inesperados en diferentes implementaciones de NetworkPolicy.

En las siguientes secciones se describe cómo evalúan las diferentes implementaciones de NetworkPolicy en GKE los intervalos de direcciones IP que especifiques en el campo ipBlock.cidr y cómo puede afectar a los intervalos de direcciones IP de los pods que se incluyen de forma inherente en intervalos CIDR amplios. Si conoces las diferencias de comportamiento entre las implementaciones, podrás prepararte para los resultados cuando migrate a otra implementación.

Comportamiento de ipBlock en GKE Dataplane V2

Con la implementación de NetworkPolicy de GKE Dataplane V2, el tráfico de los pods nunca se cubre con una regla ipBlock. Por lo tanto, aunque defina una regla general como cidr: '0.0.0.0/0', no incluirá el tráfico de pódcasts. Esto es útil porque te permite, por ejemplo, permitir que los pods de un espacio de nombres reciban tráfico de Internet sin permitir también el tráfico de los pods. Para incluir también el tráfico de pods, selecciona los pods explícitamente mediante un selector de pods o de espacio de nombres adicional en las definiciones de reglas de entrada o salida de la NetworkPolicy.

Comportamiento de ipBlock en Calico

En la implementación de NetworkPolicy de Calico, las reglas ipBlock sí cubren el tráfico de pods. Con esta implementación, para configurar un intervalo CIDR amplio sin permitir el tráfico de pods, excluye explícitamente el intervalo CIDR de pods del clúster, como en el siguiente ejemplo:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-non-pod-traffic
spec:
  ingress:
  - from:
    - ipBlock:
      cidr: '0.0.0.0/0'
      except: ['POD_IP_RANGE']

En este ejemplo, POD_IP_RANGE es el intervalo de direcciones IPv4 de los pods de tu clúster, por ejemplo, 10.95.0.0/17. Si tienes varios intervalos de IP, puedes incluirlos individualmente en la matriz. Por ejemplo, ['10.95.0.0/17', '10.108.128.0/17'].

Controlar el comportamiento de la política de red con externalTrafficPolicy

El ajuste externalTrafficPolicy de tu servicio influye en la forma en que Kubernetes aplica las políticas de red. Este ajuste determina la dirección IP de origen que ven tus pods para el tráfico entrante, lo que puede afectar a la forma en que Kubernetes evalúa las reglas de NetworkPolicy.

externalTrafficPolicy tiene dos valores posibles:

• Cluster: Cuando externalTrafficPolicy se define como Cluster, el pod de destino ve la dirección IP de origen como la dirección IP del nodo en el que se recibe inicialmente el tráfico. Si tienes una NetworkPolicy que deniega el tráfico en función de las direcciones IP del cliente, pero no incluye las direcciones IP del nodo remoto, puede que bloquee sin querer el tráfico externo de los clientes externos especificados en las reglas de la política. Para evitarlo, crea una política que permita el tráfico de todos los nodos del clúster. Sin embargo, esta política permitirá el tráfico de cualquier cliente externo.

• Local: Cuando externalTrafficPolicy se define como Local, el pod ve la dirección IP de origen como la dirección IP del cliente original. De esta forma, se puede controlar de forma más granular con las políticas de red, ya que puedes definir reglas basadas en las direcciones IP de los clientes.

Solución de problemas

Los pods no pueden comunicarse con el plano de control en clústeres que usan Private Service Connect

Los pods de los clústeres de GKE que usan Private Service Connect pueden tener problemas de comunicación con el plano de control si el tráfico de salida del pod a la dirección IP interna del plano de control está restringido en las políticas de red de salida.

Para mitigar este problema, sigue estos pasos:

1. Confirma que tu clúster usa Private Service Connect. En los clústeres que usan Private Service Connect, si usas la marca master-ipv4-cidr al crear la subred, GKE asigna a cada plano de control una dirección IP interna de los valores que hayas definido en master-ipv4-cidr. De lo contrario, GKE usa la subred de nodos del clúster para asignar una dirección IP interna a cada plano de control.

2. Configura la política de salida de tu clúster para permitir el tráfico a la dirección IP interna del plano de control.

   Para encontrar la dirección IP interna del plano de control, sigue estos pasos:

   gcloud

   Para buscar privateEndpoint, ejecuta el siguiente comando:

   gcloud container clusters describe CLUSTER_NAME
   

   Sustituye CLUSTER_NAME por el nombre del clúster.

   Este comando obtiene el privateEndpoint del clúster especificado.

   Consola

   1. Ve a la página Google Kubernetes Engine en la Trusted Cloud consola.

      Ir a Google Kubernetes Engine

   2. En el panel de navegación, vaya a Clústeres y haga clic en el clúster cuya dirección IP interna quiera encontrar.

   3. En Información básica del clúster, ve a Internal endpoint, donde se indica la dirección IP interna.

   Una vez que hayas localizado el privateEndpoint o el Internal endpoint, configura la política de salida de tu clúster para permitir el tráfico a la dirección IP interna del plano de control. Para obtener más información, consulta el artículo Crear una política de red.

El clúster tarda en actualizarse

Cuando habilitas o inhabilitas la implementación obligatoria de la política de red en un clúster, es posible que GKE no actualice los nodos inmediatamente si el clúster tiene una ventana o exclusión de mantenimiento configurada.

Puedes actualizar manualmente un grupo de nodos definiendo la marca --cluster-version en la misma versión de GKE que ejecuta el plano de control. Debes usar Google Cloud CLI para realizar esta operación. Para obtener más información, consulta las advertencias sobre las ventanas de mantenimiento.

Pods desplegados manualmente sin programar

Cuando habilitas la aplicación de políticas de red en el plano de control de un clúster, GKE desprograma los pods de nodo ip-masquerade-agent o calico que hayas desplegado manualmente.

GKE no vuelve a programar estos pods hasta que se habilite la aplicación de la política de red en los nodos del clúster y se vuelvan a crear los nodos.

Si has configurado una ventana de mantenimiento o una exclusión, esto podría provocar una interrupción prolongada.

Para minimizar la duración de esta interrupción, puedes asignar manualmente las siguientes etiquetas a los nodos del clúster:

• node.kubernetes.io/masq-agent-ds-ready=true
• projectcalico.org/ds-ready=true

La política de red no tiene efecto

Si una NetworkPolicy no tiene efecto, puedes solucionar el problema siguiendo estos pasos:

1. Confirma que la aplicación de la política de red está habilitada. El comando que utilices dependerá de si tu clúster tiene habilitado GKE Dataplane V2.

   Si tu clúster tiene habilitado GKE Dataplane V2, ejecuta el siguiente comando:

   kubectl -n kube-system get pods -l k8s-app=cilium
   

   Si la salida está vacía, la aplicación de la política de red no está habilitada.

   Si tu clúster no tiene habilitado GKE Dataplane V2, ejecuta el siguiente comando:

   kubectl get nodes -l projectcalico.org/ds-ready=true
   

   Si la salida está vacía, la aplicación de la política de red no está habilitada.

2. Comprueba las etiquetas del pod:

   kubectl describe pod POD_NAME
   

   Sustituye POD_NAME por el nombre del pod.

   El resultado debería ser similar al siguiente:

   Labels:        app=store
                  pod-template-hash=64d9d4f554
                  version=v1
   

3. Confirma que las etiquetas de la política coinciden con las etiquetas del pod:

   kubectl describe networkpolicy
   

   El resultado debería ser similar al siguiente:

   PodSelector: app=store
   

   En este resultado, las etiquetas app=store coinciden con las etiquetas app=store del paso anterior.

4. Comprueba si hay alguna política de red que seleccione tus cargas de trabajo:

   kubectl get networkpolicy
   

   Si la salida está vacía, no se ha creado ninguna NetworkPolicy en el espacio de nombres y no se ha seleccionado ninguna carga de trabajo. Si la salida no está vacía, comprueba si la política selecciona tus cargas de trabajo:

   kubectl describe networkpolicy
   

   El resultado debería ser similar al siguiente:

   ...
   PodSelector:     app=nginx
   Allowing ingress traffic:
      To Port: <any> (traffic allowed to all ports)
      From:
         PodSelector: app=store
   Not affecting egress traffic
   Policy Types: Ingress
   

Problemas conocidos

Finalización de pods de StatefulSet con Calico

Es posible que los clústeres de GKE con la política de red Calico habilitada experimenten un problema en el que un pod de StatefulSet abandona las conexiones existentes cuando se elimina el pod. Cuando un pod entra en el estado Terminating, no se respeta la configuración terminationGracePeriodSeconds en la especificación del pod y se producen interrupciones en otras aplicaciones que tienen una conexión con el pod de StatefulSet. Para obtener más información sobre este problema, consulta Calico issue #4710 (Problema de Calico n.º 4710).

Este problema afecta a las siguientes versiones de GKE:

• 1.18
• 1.19 a 1.19.16-gke.99
• De 1.20 a 1.20.11-gke.1299
• De 1.21 a 1.21.4-gke.1499

Para mitigar este problema, actualiza tu plano de control de GKE a una de las siguientes versiones:

• 1.19.16-gke.100 o versiones posteriores
• 1.20.11-gke.1300 o versiones posteriores
• 1.21.4-gke.1500 o versiones posteriores

El pod se ha quedado en el estado containerCreating

Puede darse el caso de que los clústeres de GKE con la política de red Calico habilitada tengan problemas y los pods se queden en el estado containerCreating.

En la pestaña Eventos del pod, verá un mensaje similar al siguiente:

plugin type="calico" failed (add): ipAddrs is not compatible with
configured IPAM: host-local

Para mitigar este problema, usa ipam local del host para Calico en lugar de calico-ipam en los clústeres de GKE.

Siguientes pasos

• Sigue el tutorial sobre políticas de red.

• Lee la documentación de Kubernetes sobre las políticas de red.

• Implementar enfoques habituales para restringir el tráfico mediante políticas de red.

• Usar el almacenamiento de registros de políticas de red

• Usa las estadísticas de seguridad para descubrir otras formas de reforzar tu infraestructura.