Configuración de Azure CNI con tecnología de Cilium en Azure Kubernetes Service (AKS)

Azure CNI con tecnología de Cilium combina el sólido plano de control de Azure CNI con el plano de datos de Cilium para proporcionar seguridad y redes de alto rendimiento.

Al usar programas eBPF cargados en el kernel de Linux y una estructura de objetos de API más eficaz, Azure CNI con tecnología de Cilium proporciona las siguientes ventajas:

• Funcionalidad equivalente a los complementos de superposición de Azure CNI y Azure CNI existentes

• Enrutamiento de servicio mejorado

• Aplicación de directivas de red más eficiente

• Mejor observabilidad del tráfico del clúster

• Compatibilidad con clústeres más grandes (más nodos, pods y servicios)

Administración de direcciones IP (IPAM) con Azure CNI con tecnología de Cilium

Azure CNI con tecnología de Cilium se puede implementar mediante dos métodos diferentes para asignar direcciones IP de pod:

• Asignación de direcciones IP desde una red superpuesta (similar al modo de superposición de Azure CNI)

• Asignación de direcciones IP desde una red virtual (similar a la asignación existente de Azure CNI con direcciones IP de pod dinámicas)

Si no está seguro de qué opción seleccionar, lea "Elección de un modelo de red que se va a usar".

Aplicación de la directiva de red

Cilium aplica directivas de red para permitir o denegar el tráfico entre pods. Con Cilium, no es necesario instalar un motor de directivas de red independiente, como Azure Network Policy Manager o Calico.

Limitaciones

Actualmente, Azure CNI con tecnología de Cilium tiene las siguientes limitaciones:

• Solo está disponible para Linux y no para Windows.

• La aplicación de directivas L7 de Cilium está deshabilitada.

• Las directivas de red no pueden usar ipBlock para permitir el acceso a direcciones IP de nodo o pod. Consulte las Preguntas más frecuentes para obtener más información y soluciones alternativas recomendadas.

• Varios servicios de Kubernetes no pueden usar el mismo puerto de host con protocolos diferentes (por ejemplo, TCP o UDP) (problema de Cilium n.º 14287).

• Las directivas de red se pueden aplicar en los paquetes de respuesta cuando un pod se conecta a sí mismo a través de la dirección IP del clúster de servicio (problema de Cilium n.º 19406).

• Las directivas de red no se aplican a los pods mediante redes de host (spec.hostNetwork: true) porque estos pods usan la identidad de host en lugar de tener identidades individuales.

Requisitos previos

• CLI de Azure, versión 2.48.1 o posterior. Ejecute az --version para ver la versión instalada actualmente. Si necesita instalarla o actualizarla, vea Instalación de la CLI de Azure.

• Si usa plantillas de ARM o la API de REST, la versión de la API de AKS debe ser 2022-09-02-preview o posterior.

Nota

Las versiones anteriores de la API de AKS (2022-09-02preview a 2023-01-02preview) usaron el campo networkProfile.ebpfDataplane=cilium. Las versiones de la API de AKS desde 2023-02-02preview usan el campo networkProfile.networkDataplane=cilium para habilitar Azure CNI con tecnología de Cilium.

Creación de un nuevo clúster de AKS con Azure CNI con tecnología de Cilium

Opción 1: asignación de direcciones IP desde una red superpuesta

Use los comandos siguientes para crear un clúster con una red de superposición y Cilium. Reemplace los valores de <clusterName>, <resourceGroupName> y <location>:

Azure CLI

az aks create \
    --name <clusterName> \
    --resource-group <resourceGroupName> \
    --location <location> \
    --network-plugin azure \
    --network-plugin-mode overlay \
    --pod-cidr 192.168.0.0/16 \
    --network-dataplane cilium \
    --generate-ssh-keys

Nota

La marca --network-dataplane cilium sustituye a la marca --enable-ebpf-dataplane en desuso usada en versiones anteriores de la extensión CLI aks-preview.

Opción 2: asignación de direcciones IP desde una red virtual

Ejecute los comandos siguientes para crear un grupo de recursos y una red virtual con una subred para nodos y una subred para pods.

Azure CLI

# Create the resource group
az group create --name <resourceGroupName> --location <location>

Azure CLI

# Create a virtual network with a subnet for nodes and a subnet for pods
az network vnet create --resource-group <resourceGroupName> --location <location> --name <vnetName> --address-prefixes <address prefix, example: 10.0.0.0/8> -o none
az network vnet subnet create --resource-group <resourceGroupName> --vnet-name <vnetName> --name nodesubnet --address-prefixes <address prefix, example: 10.240.0.0/16> -o none
az network vnet subnet create --resource-group <resourceGroupName> --vnet-name <vnetName> --name podsubnet --address-prefixes <address prefix, example: 10.241.0.0/16> -o none

Creación del clúster mediante --network-dataplane cilium:

Azure CLI

az aks create \
    --name <clusterName> \
    --resource-group <resourceGroupName> \
    --location <location> \
    --max-pods 250 \
    --network-plugin azure \
    --vnet-subnet-id /subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/virtualNetworks/<vnetName>/subnets/nodesubnet \
    --pod-subnet-id /subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/virtualNetworks/<vnetName>/subnets/podsubnet \
    --network-dataplane cilium \
    --generate-ssh-keys

Preguntas más frecuentes

• ¿Puedo personalizar la configuración de Cilium?

  No, AKS administra la configuración de Cilium y no se puede modificar. Se recomienda que los clientes que requieran más control usen AKS BYO CNI e instalen Cilium manualmente.

• ¿Puedo usar recursos CiliumNetworkPolicy personalizados en lugar de recursos NetworkPolicy de Kubernetes ?

  Los recursos personalizados CiliumNetworkPolicy no se admiten oficialmente. Los clientes pueden usar el filtrado de FQDN como parte de la agrupación de características de servicios avanzados de redes de contenedores.

  En este ejemplo de CiliumNetworkPolicy se muestra un patrón de coincidencia de ejemplo para los servicios que coinciden con la etiqueta especificada.

  YAML

  apiVersion: "cilium.io/v2"
  kind: CiliumNetworkPolicy
  metadata:
    name: "example-fqdn"
  spec:
    endpointSelector:
      matchLabels:
        foo: bar
    egress:
    - toFQDNs:
      - matchPattern: "*.example.com"
  

• ¿Por qué se bloquea el tráfico cuando el NetworkPolicy tiene un ipBlock que permite la dirección IP?

  Una limitación de Azure CNI Powered by Cilium es que un NetworkPolicy 's ipBlock no puede seleccionar direcciones IP de pod o nodo.

  Por ejemplo, este NetworkPolicy tiene un ipBlock que permite que todas las salidas 0.0.0.0/0:

  YAML

  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: example-ipblock
  spec:
    podSelector: {}
    policyTypes:
      - Egress
    egress:
      - to:
        - ipBlock:
            cidr: 0.0.0.0/0 # This will still block pod and node IPs.
  

  Sin embargo, cuando se aplica este NetworkPolicy, Cilium bloqueará la salida a direcciones IP de pod y nodo, aunque las direcciones IP se encuentren dentro del CIDR de ipBlock.

  Como solución alternativa, puede agregar namespaceSelector y podSelector para seleccionar pods. En el ejemplo siguiente se seleccionan todos los pods de todos los espacios de nombres:

  YAML

  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: example-ipblock
  spec:
    podSelector: {}
    policyTypes:
      - Egress
    egress:
      - to:
        - ipBlock:
            cidr: 0.0.0.0/0
        - namespaceSelector: {}
        - podSelector: {}
  

  Nota

  Actualmente no es posible especificar un NetworkPolicy con un ipBlock para permitir el tráfico a direcciones IP de nodo.

• ¿Configura AKS límites de CPU o memoria en daemonset de Cilium?

  No, AKS no configura límites de CPU ni de memoria en el daemonset de Cilium porque Cilium es un componente crítico del sistema para las redes de pods y la aplicación de directivas de red.

• ¿Azure CNI con tecnología Cilium utiliza Kube-Proxy?

  No, los clústeres de AKS creados con un plano de datos de red como Cilium no usan Kube-Proxy. Si los clústeres de AKS están en Azure CNI Overlay o Azure CNI con asignación de IP dinámica y se actualizan a clústeres de AKS que ejecutan Azure CNI con tecnología de Cilium, se crean nuevas cargas de trabajo de nodos sin kube-proxy. Las cargas de trabajo anteriores también se migran para ejecutarse sin kube-proxy como parte de este proceso de actualización.

Pasos siguientes

Más información acerca de las redes en AKS en los siguientes artículos:

• Actualizar los modos IPAM de Azure Kubernetes Service (AKS) y tecnología de plano de datos.

• Uso de una dirección IP estática con el equilibrador de carga de Azure Kubernetes Service (AKS)

• Uso de un equilibrador de carga interno con Azure Container Service (AKS)

• Creación de un controlador de entrada básico con conectividad de red externa