Partage via

Configurer Azure CNI alimenté par Cilium dans AKS (Azure Kubernetes Service)

  • Article

Azure CNI alimenté par Cilium combine le plan de contrôle robuste d’Azure CNI avec le plan de données de Cilium pour fournir une mise en réseau et une sécurité hautes performances.

En utilisant des programmes eBPF chargés dans le noyau Linux et une structure d’objet API plus efficace, Azure CNI Powered by Cilium offre les avantages suivants :

  • Fonctionnalités équivalentes aux plug-ins de superposition Azure CNI et Azure CNI existants

  • Routage amélioré des services

  • Application plus efficace de la stratégie réseau

  • Meilleure observabilité du trafic de cluster

  • Prise en charge de clusters plus volumineux (plus de nœuds, de pods et de services)

Gestion des adresses IP (IPAM) avec Azure CNI Powered by Cilium

Azure CNI Powered by Cilium peut être déployé à l’aide de deux méthodes différentes pour l’attribution d’adresses IP de pod :

  • Affecter des adresses IP à partir d’un réseau de superposition (similaire au mode de superposition Azure CNI)

  • Affecter des adresses IP à partir d’un réseau virtuel (similaire à une instance Azure CNI existante avec affectation d’adresses IP de Pod Dynamique)

Si vous n'êtes pas sûr de quelle option choisir, lisez « Choix d’un modèle de mise en réseau à utiliser ».

Application de la stratégie réseau

Cilium applique des stratégies réseau pour autoriser ou refuser le trafic entre les pods. Avec Cilium, vous n’avez pas besoin d’installer un moteur de stratégie réseau distinct, tel qu’Azure Network Policy Manager ou Calico.

Limites

Azure CNI Powered by Cilium présente actuellement les limitations suivantes :

  • Disponible uniquement pour Linux et non pour Windows.

  • L’application de la stratégie Cilium L7 est désactivée.

  • Les stratégies réseau ne peuvent pas utiliser ipBlock pour autoriser l’accès aux adresses IP de nœud ou de pod. Consultez forum aux questions pour plus d’informations et pour une solution de contournement recommandée.

  • Plusieurs services Kubernetes ne peuvent pas utiliser le même port hôte avec des protocoles différents (par exemple, TCP ou UDP) (problème Cilium #14287).

  • Les stratégies réseau peuvent être appliquées sur les paquets de réponse lorsqu’un pod se connecte à lui-même via l’adresse IP du cluster de service (problème Cilium #19406).

  • Les stratégies réseau ne sont pas appliquées aux pods qui utilisent la mise en réseau d’hôtes (spec.hostNetwork: true) car ces pods utilisent l’identité de l’hôte et n’ont pas d’identités individuelles.

Prérequis

  • Azure CLI, version 2.48.1 ou ultérieure. Exécutez az --version pour vérifier la version installée. Si vous devez installer ou mettre à niveau, voir Installer Azure CLI.

  • Si vous utilisez des modèles ARM ou l’API REST, la version de l’API AKS doit être 2022-09-02-preview ou une version ultérieure.

Notes

Les précédentes versions de l’API AKS (de 2022-09-02préview à 2023-01-02preview) utilisaient le champ networkProfile.ebpfDataplane=cilium. Les versions de l’API AKS à partir de 2023-02-02preview utilisent le champ networkProfile.networkDataplane=cilium pour activer Azure CNI alimenté par Cilium.

Créer un nouveau cluster AKS avec Azure CNI alimenté par Cilium

Option 1 : Affecter des adresses IP à partir d’un réseau de superposition

Exécutez les commandes suivantes pour créer un cluster avec un réseau de superposition et Cilium. Remplacez les valeurs de <clusterName>, <resourceGroupName> et <location>.

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

Remarque

L’indicateur --network-dataplane cilium remplace l’indicateur déconseillé --enable-ebpf-dataplane utilisé dans les versions antérieures de l’extension CLI aks-preview.

Option 2 : Affecter des adresses IP à partir d’un réseau virtuel

Exécutez les commandes suivantes pour créer un groupe de ressources et un réseau virtuel avec un sous-réseau pour les nœuds et un sous-réseau pour les pods.

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

# 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

Créez le cluster à l’aide de --network-dataplane cilium :

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

Mettre à jour un cluster existant vers Azure CNI avec Cilium

Remarque

Vous pouvez mettre à jour un cluster existant vers Azure CNI avec Cilium si le cluster répond aux critères suivants :

Remarque

Lors de l’activation de Cilium dans un cluster avec un autre moteur de stratégie réseau (Azure NPM ou Calico), le moteur de stratégie réseau est désinstallé et remplacé par Cilium. Pour plus d’informations, consultez Désinstaller Azure Network Policy Manager ou Calico .

Avertissement

Le processus de mise à niveau déclenche la réimage de chaque pool de nœuds simultanément. La mise à niveau de chaque pool de nœuds séparément n’est pas prise en charge. Toutes les interruptions de mise en réseau de cluster sont similaires à une mise à niveau d’image de nœud ou à une mise à niveau de version de Kubernetes où chaque nœud d’un pool de nœuds est réimagé. Cilium ne commencera à appliquer les stratégies réseau qu’une fois que tous les nœuds auront été réinscrits.

Pour effectuer la mise à niveau, vous aurez besoin d’Azure CLI version 2.52.0 ou ultérieure. Exécutez az --version pour vérifier la version installée. Si vous devez installer ou mettre à niveau, voir Installer Azure CLI.

Utilisez la commande suivante pour mettre à niveau un cluster existant vers Azure CNI avec Cilium. Remplacez les valeurs de <clusterName> et <resourceGroupName> :

az aks update --name <clusterName> --resource-group <resourceGroupName> \
  --network-dataplane cilium

Remarque

Après avoir activé Azure CNI avec Cilium sur un cluster AKS, vous ne pouvez pas le désactiver. Si vous souhaitez utiliser un autre plan de données réseau, vous devez créer un nouveau cluster AKS.

Forum aux questions

  • Puis-je personnaliser la configuration de Cilium ?

    Non, la configuration Cilium est gérée par AKS ne peut pas être modifiée. Nous recommandons aux clients qui ont besoin de plus de contrôle d’utiliser AKS BYO CNI et d’installer Cilium manuellement.

  • Puis-je utiliser des ressources personnalisées CiliumNetworkPolicy au lieu de ressources NetworkPolicy Kubernetes ?

    Les ressources personnalisées CiliumNetworkPolicy sont partiellement prises en charge. Les clients peuvent utiliser le filtrage de nom de domaine complet dans le cadre du pack de fonctionnalités Services avancés de mise en réseau de conteneurs.

    Cet exemple de CiliumNetworkPolicy montre un exemple de modèle de correspondance pour les services qui correspondent à l’étiquette spécifiée.

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

  • Pourquoi le trafic est-il bloqué lorsque le NetworkPolicy a un ipBlock qui autorise l’adresse IP ?

    Une limitation d’Azure CNI optimisée par Cilium est qu’un NetworkPolicy's ipBlock ne peut pas sélectionner des adresses IP de pod ou de nœud.

    Par exemple, cette NetworkPolicy a un ipBlock qui permet à toutes les sorties de 0.0.0.0/0:

    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.

    Toutefois, lorsque cette NetworkPolicy est appliquée, Cilium bloque la sortie aux adresses IP de pod et de nœud, même si les adresses IP se trouvent dans le CIDR ipBlock .

    Pour contourner ce problème, vous pouvez ajouter namespaceSelector et podSelector pour sélectionner des pods. L’exemple ci-dessous sélectionne tous les pods dans tous les espaces de noms :

    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: {}

    Remarque

    Il n’est actuellement pas possible de spécifier une NetworkPolicy avec un ipBlock pour autoriser le trafic vers les adresses IP de nœud.

  • Est-ce qu’AKS configure des limites de processeur ou de mémoire sur Cilium daemonset?

    Non, AKS ne configure pas de limites de processeur ou de mémoire sur Cilium daemonset parce que Cilium est un composant système critique pour la mise en réseau des pods et la mise en application d’une stratégie réseau.

  • Est-ce que Azure CNI généré par Cilium utilise Kube-Proxy ?

    Non, les clusters AKS créés avec le plan de données réseau en tant que Cilium n’utilisent pas Kube-Proxy. Si les clusters AKS se trouvent sur la superposition Azure CNI ou Azure CNI avec allocation d’adresses IP dynamiques et sont mis à niveau vers des clusters AKS exécutant Azure CNI généré par Cilium, de nouvelles charges de travail de nœuds sont créées sans kube-proxy. Les charges de travail plus anciennes sont également migrées pour s’exécuter sans kube-proxy dans le cadre de ce processus de mise à niveau.

Étapes suivantes

Pour plus d’informations sur la mise en réseau dans AKS, consultez les articles suivants :