Asegurar el tráfico entre pods utilizando directivas de red en Azure Kubernetes Service (AKS)

Identificación de clústeres afectados

Para buscar clústeres de AKS con grupos de nodos de Linux mediante Azure Network Policy Manager (NPM), ejecute la consulta de Azure Resource Graph que muestra todos los clústeres de AKS donde agentPool.osType != "Windows" y properties.networkProfile.networkPolicy == "azure".

Instale un motor de directivas de red y cree directivas de red de Kubernetes para controlar el flujo de tráfico entre pods en clústeres de AKS.

Información general sobre la directiva de red

De forma predeterminada, todos los pods de un clúster de AKS pueden enviar y recibir tráfico sin limitaciones. Para mejorar la seguridad, puede definir reglas que controlen el flujo de tráfico.

Una directiva de red es una especificación de Kubernetes que define las directivas de acceso para la comunicación entre pods. Cuando se usan directivas de red, se define un conjunto ordenado de reglas para enviar y recibir tráfico. Las reglas se aplican a una colección de pods que coinciden con uno o varios selectores de etiquetas.

Las reglas de directiva de red se definen como manifiestos de YAML y se pueden incluir en manifiestos más amplios que también crean una implementación o un servicio.

Opciones de directivas de red en AKS

Azure proporciona tres motores de directivas de red para aplicar directivas de red:

• Cilium (para clústeres de AKS mediante Azure CNI Powered by Cilium)
• Azure Network Policy Manager (NPM)
• Calico (una solución de seguridad de red y red de código abierto fundada por Tigera)

Se recomienda usar Cilium, que proporciona una sólida compatibilidad con directivas nativas de Kubernetes, características extendidas, como el filtrado de FQDN y la directiva de nivel 7, y un plan de datos basado en eBPF que ofrece un mejor rendimiento, escalabilidad y seguridad en comparación con las soluciones basadas en iptables.

Para aplicar las directivas especificadas, Azure NPM usa IPTables para Linux y Host Network Service (HNS) ACLPolicies para Windows. Las directivas se traducen en conjuntos de pares de IP permitidas y no permitidas. Después, estos pares se programan como reglas de filtro de IPTable o HNS ACLPolicy.

Diferencias entre los motores de directivas de red: Cilium, Azure NPM y Calico

Limitaciones de Azure Network Policy Manager (Linux)

Azure NPM para Linux tiene las siguientes limitaciones:

• No se admite el escalado más allá de 250 nodos y 20 000 pods . Si intenta escalar más allá de estos límites, puede experimentar errores de memoria insuficiente (OOM). Para mejorar la escalabilidad y la compatibilidad con IPv6, se recomienda usar o actualizar a Azure CNI Powered by Cilium para el motor de directivas de red.
• No se admite IPv6. De lo contrario, es totalmente compatible con las especificaciones de directiva de red en Linux.

Limitaciones de Azure Network Policy Manager (Windows)

Azure NPM para Windows no admite las siguientes características de las especificaciones de directiva de red:

• Puertos con nombre.
• El protocolo de transmisión de control de flujo (SCTP).
• Etiquetas de coincidencia negativa o selectores de espacios de nombres. Por ejemplo, todas las etiquetas excepto debug=true.
• Bloques except de enrutamiento de interdominios sin clases (CIDR) (CIDR con excepciones).

Problemas conocidos con Azure Network Policy Manager

Es posible que se produzcan algunos problemas de conectividad temporales en nuevas conexiones hacia/desde los pods en nodos afectados al editar o eliminar una política de red de tamaño considerable. Alcanzar esta condición de carrera nunca afecta a las conexiones activas.

Si se produce esta condición de carrera para un nodo, el pod de Azure NPM en ese nodo entra en un estado en el que no puede actualizar las reglas de seguridad, lo que podría provocar una conectividad inesperada para nuevas conexiones a o desde pods en el nodo afectado. Para mitigar el problema, el pod de Azure NPM se reinicia automáticamente aproximadamente 15 segundos después de entrar en este estado. Mientras Azure NPM se reinicia en el nodo afectado, elimina todas las reglas de seguridad y, a continuación, vuelve a aplicar las reglas de seguridad para todas las directivas de red. Mientras se vuelven a aplicar todas las reglas de seguridad, existe la posibilidad de que se produzca una conectividad temporal e inesperada para nuevas conexiones a o desde pods en el nodo afectado.

Para limitar la posibilidad de alcanzar esta condición de carrera, puede reducir el tamaño de la directiva de red. Este problema es más probable que se produzca para una directiva de red con varias secciones ipBlock. Es menos probable que una directiva de red con cuatro o menosipBlock secciones alcance el problema.

Servicios y directivas de red del equilibrador de carga

El enrutamiento del servicio Kubernetes para los servicios entrantes y salientes suele implicar la reescritura de las direcciones IP de origen y destino en el tráfico que se está procesando, incluido el tráfico que entra en el clúster desde un LoadBalancer servicio. Este comportamiento de reescritura significa que es posible que las directivas de red no procesen correctamente el tráfico que se recibe o se envía a un servicio externo. Para más información, consulte la documentación de directivas de red de Kubernetes.

Para restringir qué orígenes pueden enviar tráfico a un servicio de equilibrador de carga, use spec.loadBalancerSourceRanges para configurar el bloqueo de tráfico que se aplica antes de que se produzcan reescrituras. Para más información, consulte la documentación del equilibrador de carga estándar de AKS.

Antes de empezar

Es preciso que esté instalada y configurada la versión 2.0.61 de la CLI de Azure u otra versión posterior. Busque la versión con el comando az --version. Si necesita instalarla o actualizarla, vea Instalación de la CLI de Azure.

En lugar de usar una identidad asignada por el sistema, también puede usar una identidad asignada por el usuario. Para más información, consulte Uso de identidades administradas.

Creación de un clúster de AKS con Azure Network Policy Manager (Linux)

1. Establezca variables de entorno para el nombre del grupo de recursos, el nombre del clúster y la ubicación. Reemplace los valores según sea necesario.

   export RESOURCE_GROUP=myResourceGroup
   export CLUSTER_NAME=myAKSCluster
   export LOCATION=eastus
   

2. Cree un clúster de AKS usando az aks create y especifique azure para network-plugin y network-policy.

   az aks create \
       --resource-group $RESOURCE_GROUP \
       --name $CLUSTER_NAME \
       --node-count 1 \
       --network-plugin azure \
       --network-policy azure \
       --generate-ssh-keys
   

   Precaución

   Azure Network Policy Manager (NPM) para nodos de Linux se retirará el 30 de septiembre de 2028. En el caso de las nuevas implementaciones, se recomienda usar Azure CNI Powered by Cilium con la directiva de red de Cilium. Para migrar clústeres existentes, consulte Migración de NPM a directiva de red de Cilium.

Creación de un clúster de AKS con Azure Network Policy Manager (Windows Server 2022 (versión preliminar))

Instalación de la extensión de la CLI de Azure aks-preview

1. Instale la extensión aks-preview mediante el comando az extension add.

   az extension add --name aks-preview
   

2. Actualiza a la última versión de la extensión mediante el comando az extension update.

   az extension update --name aks-preview
   

Registro de la marca de característica WindowsNetworkPolicyPreview

1. Registre la marca de características de WindowsNetworkPolicyPreview mediante el comando az feature register.

   az feature register --namespace "Microsoft.ContainerService" --name "WindowsNetworkPolicyPreview"
   

   Tarda unos minutos en que el estado muestre Registrado.

2. Comprobar el estado del registro mediante el comando az feature show.

   az feature show --namespace "Microsoft.ContainerService" --name "WindowsNetworkPolicyPreview"
   

3. Cuando el estado refleje Registrado, actualice el registro del Microsoft.ContainerService proveedor de recursos mediante el az provider register comando .

   az provider register --namespace Microsoft.ContainerService
   

Creación de credenciales de administrador para contenedores de Windows Server

• Cree un nombre de usuario para usarlo como credenciales de administrador para los contenedores de Windows Server en el clúster. El comando siguiente le solicita un nombre de usuario. Establézcalo en WINDOWS_USERNAME.

  echo "Please enter the username to use as administrator credentials for Windows Server containers on your cluster: " && read WINDOWS_USERNAME
  

Creación del clúster de AKS

1. Establezca variables de entorno para el nombre del grupo de recursos, el nombre del clúster y la ubicación. Reemplace los valores según sea necesario.

   export RESOURCE_GROUP=myResourceGroup
   export CLUSTER_NAME=myAKSCluster
   export LOCATION=eastus
   

2. Cree un clúster de AKS usando az aks create y especifique azure para network-plugin y network-policy.

   az aks create \
       --resource-group $RESOURCE_GROUP \
       --name $CLUSTER_NAME \
       --node-count 1 \
       --windows-admin-username $WINDOWS_USERNAME \
       --network-plugin azure \
       --network-policy azure \
       --generate-ssh-keys
   

Creación de un clúster de AKS con Calico

Cree un clúster de AKS mediante el az aks create comando y especifique --network-plugin azure y --network-policy calico. Especificar --network-policy calico habilita Calico en grupos de nodos de Linux y Windows.

Si planea agregar grupos de nodos de Windows al clúster, incluya los parámetros windows-admin-username y windows-admin-passwordque cumplan los requisitos de contraseña de Windows Server. Para crear credenciales de administrador para contenedores de Windows Server en el clúster, consulte Creación de credenciales de administrador para contenedores de Windows Server.

Instalación de Azure Network Policy Manager o Calico en un clúster existente

• Actualice un clúster existente para instalar Azure NPM o Calico mediante el az aks update comando y especificando azure o calico para el --network-policy parámetro . En el siguiente comando de ejemplo se muestra cómo instalar azure NPM:

  az aks update
      --resource-group $RESOURCE_GROUP \
      --name $CLUSTER_NAME \
      --network-policy azure
  

Actualización de un clúster existente con Azure NPM o Calico a Cilium

Para actualizar un clúster existente a Azure CNI Powered by Cilium, consulte Actualización de un clúster existente a Azure CNI Powered by Cilium

Conexión al clúster de AKS

• Configure kubectl para conectarse al clúster ejecutando el comando az aks get-credentials. Con este comando se descargan las credenciales y se configura la CLI de Kubernetes para usarlas.

  az aks get-credentials --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME
  

Comprobación de la configuración de directivas de red

Para comenzar la comprobación de la directiva de red, creará una aplicación de ejemplo y establecerá reglas de tráfico.

1. Cree un espacio de nombres denominado demo para ejecutar los pods de ejemplo usando el comando kubectl create namespace.

   kubectl create namespace demo
   

2. Cree un pod denominado server para servir en el puerto TCP 80 mediante el comando kubectl run.

   kubectl run server -n demo --image=k8s.gcr.io/e2e-test-images/agnhost:2.33 --labels="app=server" --port=80 --command -- /agnhost serve-hostname --tcp --http=false --port "80"
   

3. Cree un pod denominado client para ejecutar Bash mediante el kubectl run comando .

   kubectl run -it client -n demo --image=k8s.gcr.io/e2e-test-images/agnhost:2.33 --command -- bash
   

   Note

   Si desea programar el cliente o servidor en un nodo determinado, agregue el siguiente bit antes del --command argumento en el comando de creación kubectl run del pod: --overrides='{"spec": { "nodeSelector": {"kubernetes.io/os": "linux|windows"}}}'.

4. En una ventana independiente, obtenga la dirección IP del server pod mediante el kubectl get pod comando .

   kubectl get pod --output=wide -n demo
   

   La salida debería ser similar a la salida de ejemplo siguiente:

   NAME     READY   STATUS    RESTARTS   AGE   IP            NODE             NOMINATED NODE   READINESS GATES
   server   1/1     Running   0          30s   10.224.0.72   akswin22000001   <none>           <none>
   

Prueba de la conectividad con directivas de red

1. Cree un archivo denominado demo-policy.yaml y pegue el siguiente manifiesto de YAML:

   apiVersion: networking.k8s.io/v1
   kind: NetworkPolicy
   metadata:
     name: demo-policy
     namespace: demo
   spec:
     podSelector:
       matchLabels:
         app: server
     ingress:
     - from:
       - podSelector:
           matchLabels:
             app: client
       ports:
       - port: 80
         protocol: TCP
   

2. Aplique el manifiesto de directiva de red mediante el kubectl apply comando .

   kubectl apply –f demo-policy.yaml
   

3. En el shell de cliente, compruebe la conectividad con el servidor mediante el siguiente /agnhost comando:

   /agnhost connect <server-ip>:80 --timeout=3s --protocol=tcp
   

   La conectividad con el tráfico se bloquea porque el servidor está etiquetado con app=server, pero el cliente no está etiquetado. La salida debería ser similar a la salida de ejemplo siguiente:

   TIMEOUT
   

4. Etiqueta el client y comprueba la conectividad con el servidor con el comando kubectl label.

   kubectl label pod client -n demo app=client
   

   Si la conexión se realiza correctamente, no hay ninguna salida.

Migración a Calico autoadministrado

AKS solo admite Calico para las directivas de red estándar de Kubernetes y no prueba otras características. Si quiere pasar a Calico autoadministrado, siga las instrucciones de Tigera en Migración de Calico administrado por Azure a Calico autoadministrado. En la documentación de Tigera se indica que para Calico autoadministrado se usa --network-policy none, igual que en la sección de desinstalación.

Desinstalación de Azure Network Policy Manager o Calico

• Quite Azure Network Policy Manager o Calico de un clúster existente mediante el az aks update comando y especifique none para el --network-policy parámetro .

  az aks update
      --resource-group $RESOURCE_GROUP \
      --name $CLUSTER_NAME \
      --network-policy none
  

Limpieza de recursos

En este artículo, ha creado un espacio de nombres y dos pods, y ha aplicado una directiva de red. Si ya no necesita estos recursos, puede eliminarlos.

• Elimine los recursos mediante el kubectl delete comando .

  kubectl delete namespace demo
  

Contenido relacionado

• Conceptos de red para aplicaciones en Azure Kubernetes Service (AKS)
• Directivas de red de Kubernetes