Partager via


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

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 ne savez pas quelle option sélectionner, lisez « Choix d’un modèle réseau à utiliser ».

Versions

Version de Kubernetes Version minimale de Cilium
1.27 (LTS) 1.13.18
1.28 (Fin de vie) 1.13.18
1.29 1.14.19
1.30 (LTS) 1.14.19
1,31 1.16.6
1.32 1.17.0

Pour plus d’informations sur les chronologies de version et de mise en production AKS, consultez versions Kubernetes prises en charge .

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.

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

  • Pour les versions 1.16 ou antérieures de Cilium, plusieurs services Kubernetes ne peuvent pas utiliser le même port hôte avec différents protocoles (par exemple, TCP ou UDP) (problème Cilium #14287).

  • Les stratégies réseau ne sont pas appliquées aux pods à l’aide de la mise en réseau hôte (spec.hostNetwork: true) car ces pods utilisent l’identité hôte au lieu d’avoir des identités individuelles.

  • Les tranches de point de terminaison Cilium sont prises en charge dans Kubernetes version 1.32 et ultérieure. Les tranches de point de terminaison Cilium ne permettent pas de configurer la manière dont les point de terminaison Cilium sont regroupés. Les espaces de noms prioritaires via cilium.io/ces-namespace ne sont pas pris en charge.

Considérations

Pour obtenir des fonctionnalités telles que l’observabilité dans votre trafic réseau et les fonctionnalités de sécurité telles que le nom de domaine complet (FQDN) basé sur le filtrage et les stratégies réseau de couche 7 sur votre cluster, envisagez d’activer les services Advanced Container Networking sur vos clusters.

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

Notes

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

Option 3 : Affecter des adresses IP à partir du sous-réseau de nœud

Notes

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

Créez un cluster à l’aide d’un sous-réseau de nœuds avec un plan de données Cilium :

az aks create \
    --name <clusterName> \
    --resource-group <resourceGroupName> \
    --location <location> \
    --network-plugin azure \
    --network-dataplane cilium \
    --generate-ssh-keys

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 clients peuvent utiliser le filtrage FQDN et les stratégies de couche 7 dans le cadre de l’offre groupée de fonctionnalités Advanced Container Networking Services .

  • Puis-je utiliser ClusterwideCiliumNetworkPolicy?

    La fonction ClusterwideCiliumNetworkPolicy n'est pas prise en charge.

  • Quelles fonctionnalités Cilium sont prises en charge dans Azure Managed CNI ? Parmi celles-ci, lesquelles nécessitent Advanced Container Networking Services ?

    Fonctionnalité prise en charge sans ACNS avec ACNS
    Tranches de point de terminaison Cilium ✔️ ✔️
    Stratégies réseau K8s ✔️ ✔️
    Stratégies réseau Cilium L3/L4 ✔️ ✔️
    Filtrage des noms de domaine complets ✔️
    Stratégies réseau L7 (HTTP/gRPC/Kafka) ✔️
    Observabilité du réseau de conteneurs (Métriques et journaux de flux) ✔️
  • 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 d’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 ce NetworkPolicy est appliqué, Cilium bloque les sorties vers les IP des pods et des nœuds, même si les IP se trouvent dans le CIDR ipBlock.

    Pour contourner ce problème, vous pouvez ajouter namespaceSelector et podSelector pour sélectionner des pods. Cet exemple prend en compte tous les pods des différents 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: {}
    

    Notes

    Il n’est actuellement pas possible de spécifier un 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 :