Controla la comunicación entre Pods y Services mediante las políticas de red

Autopilot Estándar

---

En esta página, se explica cómo controlar la comunicación entre los servicios y los Pods 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 extremo o servicio fuera del clúster mediante las políticas de red de nombre de dominio completamente calificado (FQDN). Para obtener más información, consulta Controla la comunicación entre Pods y Services mediante FQDN.

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

La aplicación de políticas de red te permite crear políticas de red de Kubernetes en tu clúster. De forma predeterminada, todos los pods dentro de un clúster pueden comunicarse entre sí con libertad. Las políticas de red crean reglas de firewall a nivel de los Pods que determinan qué Pods y servicios pueden acceder entre sí dentro del clúster.

La definición de políticas de red te ayuda a habilitar estrategias como la defensa en profundidad cuando el clúster entrega una aplicación de varios niveles. Por ejemplo, puedes crear una política de red para asegurarte de que un servicio de frontend vulnerable en la aplicación no pueda comunicarse directamente con un servicio de facturación o contabilidad en varios niveles inferiores.

La política de red también le facilita a la aplicación alojar datos de varios usuarios de manera simultánea. Por ejemplo, puedes proporcionar instancia múltiple segura si defines un modelo de instancia por espacio de nombres. En este modelo, las reglas de la política de red pueden garantizar que los pods y los Services en un espacio de nombres determinado no puedan acceder a otros pods o Services en otro espacio de nombres.

Nota: Para que la aplicación de políticas de red funcione de forma correcta, GKE implementa Pods en los nodos que tienen permisos de RBAC elevados, como la capacidad de aplicar parches a todas las implementaciones y actualizar el estado de los nodos. Estos permisos son necesarios para que GKE aplique tus políticas de red en función de tu configuración.

Antes de comenzar

Antes de comenzar, asegúrate de haber realizado las siguientes tareas:

• Habilita la API de Google Kubernetes Engine.
Habilitar la API de Google Kubernetes Engine
• Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI. Si ya instalaste gcloud CLI, ejecuta gcloud components update para obtener la versión más reciente.
  Nota: Para las instalaciones de gcloud CLI existentes, asegúrate de configurar las propiedades compute/region y compute/zone. Cuando configuras las ubicaciones predeterminadas, puedes evitar errores en gcloud CLI como el siguiente: One of [--zone, --region] must be supplied: Please specify location.

Requisitos y limitaciones

Los siguientes requisitos y limitaciones se aplican a los clústeres de Autopilot y Standard:

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

Los siguientes requisitos y limitaciones solo se aplican a los clústeres Standard:

• Debes permitir la salida al servidor de metadatos si usas la política de red con la federación de identidades para cargas de trabajo para GKE.
• Habilitar la aplicación de la política de red aumenta el espacio en memoria del proceso kube-system en casi 128 MB, y requiere unos 300 millicores de CPU. Esto significa que, si habilitas las políticas de red para un clúster existente, es posible que debas aumentar el tamaño del clúster con el fin de continuar ejecutando las cargas de trabajo programadas.
• Cuando se habilita la aplicación de políticas de red, se requiere que los nodos se vuelvan a crear. Si tu clúster tiene un período de mantenimiento activo, los nodos no se vuelven a crear de manera automática hasta el siguiente período de mantenimiento. Si prefieres, puedes actualizar tu clúster de manera manual en cualquier momento.
• El tamaño mínimo recomendado de clúster para ejecutar la aplicación de la política de red es de tres instancias e2-medium.
• La política de red no es compatible con los clústeres cuyos nodos son instancias f1-micro o g1-small, ya que los requisitos de recursos son demasiado altos.

Para obtener más información sobre tipos de máquinas de nodo y recursos asignables, consulta Arquitectura del clúster estándar: nodos.

Precaución: De forma predeterminada, cuando habilitas la aplicación de políticas de red en tu clúster, también habilitas la aplicación en los nodos del clúster y podría causar una interrupción en los Pods implementados de forma manual. Para obtener más información, consulta Pods implementados de forma manual sin programar.

Habilita la aplicación de políticas de red

La aplicación de políticas de red está habilitada de forma predeterminada para los clústeres de Autopilot, por lo que puedes pasar a Crea una política de red.

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

La aplicación de la política 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.

Nota: Si habilitas o inhabilitas la aplicación de la política de red para un clúster existente, GKE vuelve a crear de forma automática toda la configuración de grupo de nodos de ese clúster antes de que el clúster pueda ejecutar el proceso de política de red. Para obtener más información, consulta Advertencias y limitaciones.

gcloud

1. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

   At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

2. Para habilitar la aplicación de políticas de red durante la creación de un clúster nuevo, ejecuta el siguiente comando:

   gcloud container clusters create CLUSTER_NAME --enable-network-policy
   

   Reemplaza CLUSTER_NAME por el nombre del clúster nuevo.

   Para habilitar la aplicación de políticas de red en un clúster existente, realiza las siguientes tareas:

   1. Ejecuta el siguiente comando para habilitar el complemento:

      gcloud container clusters update CLUSTER_NAME --update-addons=NetworkPolicy=ENABLED
      

      Reemplaza CLUSTER_NAME por el nombre del clúster.

   2. Ejecuta el siguiente comando para habilitar la aplicación de políticas de red en tu clúster, lo que ocasionará que se vuelvan a crear los grupos de nodos del clúster con la aplicación de políticas de red habilitada:

      gcloud container clusters update CLUSTER_NAME --enable-network-policy
      

Consola

Para habilitar la aplicación de políticas de red durante la creación de un clúster nuevo, sigue los siguientes pasos:

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

   Ir a Google Kubernetes Engine

2. Haz clic en Crear.

3. En el diálogo Crear clúster, para GKE Standard, haz clic en Configurar.

4. Configura tu clúster como lo elegiste.

5. En el panel de navegación, en Clúster, haz clic en Herramientas de redes.

6. Selecciona la casilla de verificación Habilitar política de red.

7. Haz clic en Crear.

Para habilitar la aplicación de políticas de red en un clúster existente, sigue estos pasos:

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

   Ir a Google Kubernetes Engine

2. En la lista de clústeres, haz clic en el nombre del clúster que deseas modificar.

3. En Herramientas de redes, en el campo Política de red, haz clic en Editar política de red.

4. Selecciona la casilla de verificación Habilitar la política de red en la instancia principal y haz clic en Guardar cambios.

5. Espera a que se apliquen los cambios y, a continuación, vuelve a hacer clic en Editar política de red.

6. Selecciona la casilla de verificación Habilitar la política de red en los nodos.

7. Haz clic en Guardar cambios.

API

Para habilitar la aplicación de políticas de red, sigue estos pasos:

1. Especifica el objeto networkPolicy dentro del objeto cluster que proporcionas a projects.zones.clusters.create o projects.zones.clusters.update.

2. El objeto networkPolicy requiere una enumeración que especifique qué proveedor de políticas de red usar y un valor booleano que determine si se debe habilitar la política de red. Si habilitas la política de red, pero no estableces el proveedor, los comandos create y update muestran un error.

Inhabilita la aplicación de políticas de red en un clúster estándar

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

Advertencia: Inhabilitar la aplicación de la política de red es una operación perjudicial. Todos los nodos del clúster se vuelven a crear según el proceso de actualización de nodos de GKE.

gcloud

1. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

   At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

2. Para inhabilitar la aplicación de políticas de red, realiza las siguientes tareas:

   1. Inhabilita la aplicación de políticas de red en tu clúster:

   gcloud container clusters update CLUSTER_NAME --no-enable-network-policy
   

   Reemplaza CLUSTER_NAME por el nombre del clúster.

   Después de ejecutar este comando, GKE vuelve a crear los grupos de nodos del clúster con la aplicación de políticas de red inhabilitada.

3. Verifica que todos los nodos se hayan recreado:

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

   Si la operación se realiza de forma correcta, el resultado es similar al siguiente:

   No resources found
   

   Si el resultado es similar al siguiente, debes esperar a que GKE termine de actualizar los grupos de nodos:

   NAME                                             STATUS                     ROLES    AGE     VERSION
   gke-calico-cluster2-default-pool-bd997d68-pgqn   Ready,SchedulingDisabled   <none>   15m     v1.22.10-gke.600
   gke-calico-cluster2-np2-c4331149-2mmz            Ready                      <none>   6m58s   v1.22.10-gke.600
   

   Cuando inhabilitas la aplicación de la política de red, es posible que GKE no actualice los nodos de inmediato si el clúster tiene un período de mantenimiento o una exclusión configurados. Para obtener más información, consulta El clúster tarda en actualizarse.

4. Una vez que todos los nodos se vuelvan a crear, inhabilita el complemento:

   gcloud container clusters update CLUSTER_NAME --update-addons=NetworkPolicy=DISABLED
   

Consola

Para inhabilitar la aplicación de políticas de red en un clúster existente, sigue estos pasos:

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

   Ir a Google Kubernetes Engine

2. En la lista de clústeres, haz clic en el nombre del clúster que deseas modificar.

3. En Herramientas de redes, en el campo Política de red, haz clic en Editar política de red.

4. Desactiva la casilla de verificación Habilitar la política de red en los nodos y haz clic en Guardar cambios.

5. Espera a que se apliquen los cambios y, a continuación, vuelve a hacer clic en Editar política de red.

6. Desmarca la casilla de verificación Habilitar la política de red en la instancia principal.

7. Haz clic en Guardar cambios.

API

Para inhabilitar la aplicación de políticas de red en un clúster existente, haz lo siguiente:

1. Actualiza tu clúster para usar networkPolicy.enabled: false con la API de setNetworkPolicy.

2. Verifica que todos los nodos se vuelvan a crear mediante gcloud CLI:

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

   Si la operación se realiza de forma correcta, el resultado es similar al siguiente:

   No resources found
   

   Si el resultado es similar al siguiente, debes esperar a que GKE termine de actualizar los grupos de nodos:

   NAME                                             STATUS                     ROLES    AGE     VERSION
   gke-calico-cluster2-default-pool-bd997d68-pgqn   Ready,SchedulingDisabled   <none>   15m     v1.22.10-gke.600
   gke-calico-cluster2-np2-c4331149-2mmz            Ready                      <none>   6m58s   v1.22.10-gke.600
   

   Cuando inhabilitas la aplicación de la política de red, es posible que GKE no actualice los nodos de inmediato si el clúster tiene un período de mantenimiento o una exclusión configurados. Para obtener más información, consulta El clúster tarda en actualizarse.

3. Actualiza tu clúster para usar update.desiredAddonsConfig.NetworkPolicyConfig.disabled: true con la API de updateCluster.

Crear una política de red

Puedes crear una política de red con la API de política de red de Kubernetes.

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

• Descripción general de la política de red
• Declara la política de red

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

Si usas la política de red con la federación de identidades para cargas de trabajo para GKE, debes permitir la salida a las siguientes direcciones IP para que los Pods puedan comunicarse con el servidor de metadatos de GKE.

• Para los clústeres que ejecutan la versión 1.21.0-gke.1000 y posteriores de GKE, permite la salida a 169.254.169.252/32 en el puerto 988.
• Para los clústeres que ejecutan versiones de GKE anteriores a la 1.21.0-gke.1000, permite la salida a 127.0.0.1/32 en el puerto 988.
• Para los clústeres que ejecutan GKE Dataplane V2, permite la salida a 169.254.169.254/32 en el puerto 80.

Si no permites la salida a estas direcciones IP y puertos, es posible que experimentes interrupciones durante las actualizaciones automáticas.

Migra de Calico a GKE Dataplane V2

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

• No puedes usar una dirección IP de Pod o Service en el campo ipBlock.cidr de un manifiesto 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 especificas un protocolo, también debes especificar un puerto. Por ejemplo, la siguiente configuración no es válida:

  ingress:
  - ports:
    - protocol: TCP
  

Trabaja con balanceadores de cargas de aplicaciones

Cuando se aplica un Ingress a un Service para compilar un balanceador de cargas de aplicaciones, debes configurar la política de red que se aplica a los Pods detrás de ese Service para permitir los rangos de IP de verificación de estado del balanceador de cargas de aplicaciones adecuados.. Si usas un balanceador de cargas de aplicaciones interno, también debes configurar la política de red para permitir la subred de solo proxy.

Si no usas el balanceo de cargas nativo del contenedor con grupos de extremos de red, los puertos de nodos para un Service podrían reenviar conexiones a Pods en otros nodos, a menos que no puedan hacerlo debido a la configuración de externalTrafficPolicyen Local en la definición de Service. Si externalTrafficPolicy no está configurado en Local, la política de red también debe permitir las conexiones de otras IP de nodo en el clúster.

Inclusión de rangos de IP de pod en reglas ipBlock

Para controlar el tráfico de pods específicos, siempre selecciona los pods según sus espacios de nombres o etiquetas de pod mediante los campos namespaceSelector y podSelector en tus reglas de entrada o salida de NetworkPolicy. No uses el campo ipBlock.cidr para seleccionar de forma intencional los rangos de direcciones IP del pod, que son efímeros por naturaleza. El proyecto de Kubernetes no define de forma explícita el comportamiento del campo ipBlock.cidr cuando incluye rangos de direcciones IP del pod. Especificar rangos CIDR amplios en este campo, como 0.0.0.0/0 (que incluyen los rangos de direcciones IP del pod), puede tener resultados inesperados en diferentes implementaciones de NetworkPolicy.

En las siguientes secciones, se describe cómo las diferentes implementaciones de NetworkPolicy en GKE evalúan los rangos de direcciones IP que especificas en el campo ipBlock.cidr, y cómo eso puede afectar los rangos de direcciones IP de pods que se incluyen inherentemente en amplios rangos de CIDR. Comprender el comportamiento diferente entre las implementaciones te ayudará a 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 del pod nunca está cubierto por una regla ipBlock. Por lo tanto, incluso si defines una regla amplia como cidr: '0.0.0.0/0', no incluirá tráfico del pod. Esto es útil, ya que te permite, por ejemplo, permitir que los pods en un espacio de nombres reciban tráfico de Internet, sin permitir también el tráfico de pods. Para incluir también tráfico de pods, selecciona Pods de forma explícita con un pod adicional o un selector de espacio de nombres en las definiciones de la regla de entrada o salida de NetworkPolicy.

Comportamiento de ipBlock en Calico

Para la implementación de Calico de NetworkPolicy, las reglas ipBlock sí abarcan el tráfico de pods. Con esta implementación, para configurar un rango de CIDR amplio sin permitir el tráfico de pods, excluye de forma explícita el rango de CIDR del pod del clúster, como se muestra 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 rango de direcciones IPv4 del pod de tu clúster, por ejemplo, 10.95.0.0/17. Si tienes varios rangos de IP, estos se pueden incluir de forma individual en la matriz, por ejemplo, ['10.95.0.0/17', '10.108.128.0/17'].

Soluciona problemas

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

Los Pods en clústeres de GKE que usan Private Service Connect pueden experimentar un problema de comunicación con el plano de control si la salida del Pod a la dirección IP interna del plano de control está restringida en la red de salida. políticas.

Para mitigar este problema:

1. Busca si tu clúster usa Private Service Connect. Para obtener más información, consulta Clústeres públicos con Private Service Connect. En los clústeres que usan Private Service Connect, cada plano de control se asigna a una dirección IP interna de la subred del nodo del clúster.

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
   

   Reemplaza CLUSTER_NAME por el nombre del clúster.

   Con este comando, se recupera el privateEndpoint del clúster especificado.

   Consola

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

      Ir a Google Kubernetes Engine

   2. En el panel de navegación, en Clústeres, haz clic en el clúster cuya dirección IP interna deseas encontrar.

   3. En Conceptos básicos del clúster, navega a Internal endpoint y encontrarás la dirección IP interna.

   Una vez que puedas ubicar privateEndpoint o 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 Crea una política de red.

El clúster tarda en actualizarse

Cuando habilitas o inhabilitas la aplicación de la política de red en un clúster existente, es posible que GKE no actualice los nodos de inmediato si el clúster tiene una exclusión o un período de mantenimiento configurado.

Puedes actualizar de forma manual un grupo de nodos si configuras la marca --cluster-version en la misma versión de GKE que el plano de control está ejecutando. Debes usar Google Cloud CLI para realizar esta operación. Si deseas obtener más información, consulta Advertencias para los períodos de mantenimiento.

Pods implementados de forma manual no programados

Cuando habilitas la aplicación de políticas de red en el plano de control del clúster existente, GKE cancela cualquier Pod de nodo de calico o ip-masquerade-agent que hayas implementado de forma manual.

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

Si configuraste una exclusión o un período de mantenimiento, esto podría causar 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

No se aplica la política de red

Si una NetworkPolicy no se aplica, puedes solucionar el problema mediante los siguientes pasos:

1. Confirma que la aplicación de políticas de red esté habilitada. El comando que uses 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 el resultado está vacío, 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 el resultado está vacío, la aplicación de la política de red no está habilitada.

2. Verifica las etiquetas del Pod:

   kubectl describe pod POD_NAME
   

   Reemplaza POD_NAME con el nombre del pod.

   El resultado es similar a este:

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

3. Confirma que las etiquetas de la política coincidan con las etiquetas del Pod:

   kubectl describe networkpolicy
   

   El resultado es similar a este:

   PodSelector: app=store
   

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

4. Verifica si hay políticas de red que seleccionen tus cargas de trabajo:

   kubectl get networkpolicy
   

   Si el resultado está vacío, no se creó ninguna NetworkPolicy en el espacio de nombres y no hay nada que seleccione tus cargas de trabajo. Si el resultado no está vacío, verifica si la política selecciona tus cargas de trabajo:

   kubectl describe networkpolicy
   

   El resultado es similar a este:

   ...
   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

Terminación del Pod del StatefulSet con Calico

Los clústeres de GKE con la política de red Calico habilitada pueden experimentar un problema en el que un pod StatefulSet descarta las conexiones existentes cuando se borra el pod. Después de que un pod ingresa al estado Terminating, no se respeta la configuración terminationGracePeriodSeconds en la especificación del pod y provoca interrupciones en otras aplicaciones que tengan una conexión existente con el pod StatefulSet. Para obtener más información sobre este problema, consulta Problema 4710 de Calico.

Este problema afecta a las siguientes versiones de GKE:

• 1.18
• 1.19 a 1.19.16-gke.99
• 1.20 a 1.20.11-gke.1299
• 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 superior
• 1.20.11-gke.1300 o superior
• 1.21.4-gke.1500 o superior

Pod atascado en el estado containerCreating

Puede haber una situación en la que los clústeres de GKE con la política de red Calico habilitada puedan experimentar un problema en el que los pods se atascan en el estado containerCreating.

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

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

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

¿Qué sigue?

• Sigue el instructivo de políticas de red.

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

• Implementa enfoques comunes para restringir el tráfico mediante políticas de red

• Usar el registro de políticas de red

• Usa estadísticas de seguridad para explorar otras formas de endurecer tu infraestructura.