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

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.

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.

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

Se aplican los siguientes requisitos y limitaciones:

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.

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.

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:

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.

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.

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.

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:

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

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:

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.

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

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