Freigeben über

Konfigurieren von Azure CNI Powered by Cilium in Azure Kubernetes Service (AKS)

  • Artikel

Azure CNI Powered by Cilium kombiniert die robuste Steuerungsebene von Azure CNI mit der Datenebene von Cilium, um Hochleistungsnetzwerke und Sicherheit bereitzustellen.

Durch die Verwendung von in den Linux-Kernel geladen en eBPF-Programmen und einer effizienteren API-Objektstruktur bietet Azure CNI Powered by Cilium die folgenden Vorteile:

  • Funktionalität, die vorhandenen Azure CNI- und Azure CNI Overlay-Plug-Ins entspricht

  • Verbessertes Dienstrouting

  • Effizientere Erzwingung von Netzwerkrichtlinien

  • Verbesserte Überwachung des Clusterdatenverkehrs

  • Unterstützung für größere Cluster (mehr Knoten, Pods und Dienste)

IP-Adressverwaltung (IPAM) mit Azure CNI Powered by Cilium

Azure CNI Powered by Cilium kann mit zwei verschiedenen Methoden zur Zuweisung von Pod-IPs bereitgestellt werden:

  • Zuweisen von IP-Adressen aus einem Überlagerungsnetzwerk (ähnlich dem Azure CNI Overlay-Modus)

  • Zuweisen von IP-Adressen aus einem virtuellen Netzwerk (ähnlich vorhandener Azure CNI mit dynamischer Pod-IP-Zuordnung)

Wenn Sie sich nicht sicher sind, welche Option Sie auswählen sollen, lesen Sie Auswählen des zu verwendenden Netzwerkmodells.

Netzwerkrichtlinienerzwingung

Cilium erzwingt Netzwerkrichtlinien, um Datenverkehr zwischen Pods zuzulassen oder zu verweigern. Mit Cilium müssen Sie kein separates Netzwerkrichtlinienmodul wie Azure Network Policy Manager oder Calico installieren.

Einschränkungen

Azure CNI powered by Cilium weist derzeit die folgenden Einschränkungen auf:

  • Nur für Linux und nicht für Windows verfügbar.

  • Die Cilium L7-Richtlinienerzwingung ist deaktiviert.

  • Hubble ist deaktiviert.

  • Netzwerkrichtlinien können ipBlock nicht verwenden, um Zugriff auf Knoten- oder Pod-IP-Adressen zuzulassen. Weitere Informationen und empfohlene Problemumgehung finden Sie unter Häufig gestellte Fragen.

  • Derselbe Hostport kann nicht von mehreren Kubernetes-Diensten mit verschiedenen Protokollen (z. B. TCP oder UDP) verwendet werden (Cilium-Problem #14287).

  • Netzwerkrichtlinien können für Antwortpakete erzwungen werden, wenn sich ein Pod über Dienstcluster-IP (Cilium-Problem #19406) mit sich selbst verbindet.

  • Netzwerkrichtlinien werden nicht auf Pods mit Hostnetzwerken (spec.hostNetwork: true) angewendet, da diese Pods die Hostidentität verwenden, anstatt einzelne Identitäten zu haben.

Voraussetzungen

  • Azure CLI, Version 2.48.1 oder höher. Führen Sie az --version aus, um die derzeit installierte Version anzuzeigen. Informationen zum Durchführen einer Installation oder eines Upgrades finden Sie bei Bedarf unter Installieren der Azure CLI.

  • Wenn Sie ARM-Vorlagen oder die REST-API verwenden, muss die AKS-API-Version 2022-09-02-preview oder höher sein.

Hinweis

In früheren AKS-API-Versionen (2022-09-02preview bis 2023-01-02preview) wurde das Feld „networkProfile.ebpfDataplane=cilium“ verwendet. AKS-API-Versionen seit 2023-02-02preview verwenden das Feld „networkProfile.networkDataplane=cilium“, um Azure CNI Powered by Cilium zu aktivieren.

Erstellen eines neuen AKS-Clusters mit Azure CNI Powered by Cilium

Option 1: Zuweisen von IP-Adressen aus einem Überlagerungsnetzwerk

Führen Sie die folgenden Befehle aus, um einen Cluster mit einem Überlagerungsnetzwerk und Cilium zu erstellen. Ersetzen Sie die Werte für <clusterName>, <resourceGroupName> und <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

Hinweis

Das --network-dataplane cilium-Flag ersetzt das veraltete --enable-ebpf-dataplane-Flag, das in früheren Versionen der aks-preview CLI-Erweiterung verwendet wurde.

Option 2: Zuweisen von IP-Adressen aus einem virtuellen Netzwerk

Führen Sie die folgenden Befehle aus, um eine Ressourcengruppe und ein virtuelles Netzwerk mit einem Subnetz für Knoten und einem Subnetz für Pods zu erstellen.

# 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

Erstellen Sie den Cluster unter Verwendung von --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

Aktualisieren eines Clusters auf Azure CNI Powered by Cilium

Hinweis

Sie können einen vorhandenen Cluster auf Azure CNI Powered by Cilium aktualisieren, wenn der Cluster die folgenden Kriterien erfüllt:

Hinweis

Wenn Sie Cilium in einem Cluster mit einem anderen Netzwerkrichtlinienmodul (Azure NPM oder Calico) aktivieren, wird das Netzwerkrichtlinienmodul deinstalliert und durch Cilium ersetzt. Weitere Details finden Sie unter Deinstallieren von Azure Network Policy Manager oder Calico.

Warnung

Durch den Upgradeprozess wird gleichzeitig für jeden Knotenpool das Durchführen eines Reimagings ausgelöst. Ein separates Upgrade jedes Knotenpools wird nicht unterstützt. Alle Unterbrechungen des Clusternetzwerks ähneln einem Knotenimageupgrade oder einem Kubernetes-Versionsupgrade, bei dem für jeden Knoten in einem Knotenpool ein Reimaging durchgeführt wird. Cilium beginnt erst mit der Erzwingung von Netzwerkrichtlinien, nachdem alle Knoten neu imageiert wurden.

Zum Durchführen des Upgrades benötigen Sie die Azure CLI-Version 2.52.0 oder höher. Führen Sie az --version aus, um die derzeit installierte Version anzuzeigen. Informationen zum Durchführen einer Installation oder eines Upgrades finden Sie bei Bedarf unter Installieren der Azure CLI.

Verwenden Sie den folgenden Befehl, um ein Upgrade eines vorhandenen Clusters auf Azure CNI Powered by Cilium durchzuführen. Ersetzen Sie die Werte für <clusterName> und <resourceGroupName>:

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

Hinweis

Nachdem Sie Azure CNI Powered by Cilium in einem AKS-Cluster aktiviert haben, können Sie es nicht mehr deaktivieren. Wenn Sie eine andere Netzwerkdatenebene verwenden möchten, müssen Sie einen neuen AKS-Cluster erstellen.

Häufig gestellte Fragen

  • Kann ich die Cilium-Konfiguration anpassen?

    Nein, die Cilium-Konfiguration wird von AKS verwaltet und kann nicht geändert werden. Wir empfehlen Kunden, die mehr Kontrolle benötigen, AKS BYO CNI zu verwenden und Cilium manuell zu installieren.

  • Kann ich benutzerdefinierte CiliumNetworkPolicy-Ressourcen anstelle von Kubernetes-NetworkPolicy-Ressourcen verwenden?

    CiliumNetworkPolicy benutzerdefinierte Ressourcen werden teilweise unterstützt. Kunden können die FQDN-Filterung als Teil des Funktionspakets Erweiterte Container Netzwerkdienste verwenden.

    Dieses CiliumNetworkPolicy Beispiel veranschaulicht ein Muster für die Suche nach Diensten, die der angegebenen Bezeichnung entsprechen.

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

  • Warum wird Datenverkehr blockiert, wenn die NetworkPolicy einen ipBlock enthält, der IP-Adressen zulässt?

    Eine Einschränkung von Azure CNI Powered by Cilium besteht darin, dass ein der NetworkPolicy zugehöriger ipBlock keine Pod- oder Knoten-IPs auswählen kann.

    Diese NetworkPolicy hat z. B. eine Eigenschaft ipBlock, die den gesamten ausgehenden Datenverkehr an 0.0.0.0/0 zulässt:

    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.

    Wenn diese NetworkPolicy jedoch angewendet wird, blockiert Cilium den ausgehenden Datenverkehr an Pod- und Knoten-IPs, obwohl sich die IP-Adressen innerhalb des ipBlock CIDR befinden.

    Als Problemumgehung können Sie für die Auswahl von Pods namespaceSelector und podSelector hinzufügen. Im folgenden Beispiel werden alle Pods in allen Namespaces ausgewählt:

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

    Hinweis

    Es ist zurzeit nicht möglich, einer NetworkPolicy mit einem ipBlock Knoten-IPs anzugeben, der Datenverkehr zu Knoten-IPs zulässt.

  • Konfiguriert AKS CPU- oder Arbeitsspeicherlimits für das Cilium daemonset?

    Nein, AKS konfiguriert keine CPU- oder Arbeitsspeicherlimits für das Cilium daemonset, da Cilium eine wichtige Systemkomponente für Pod-Netzwerke und das Erzwingen von Netzwerkrichtlinien ist.

  • Verwendet Azure CNI Powered by Cilium Kube-Proxy?

    Nein, mit einer Netzwerkdatenebene wie Cilium erstellte AKS-Cluster verwenden keinen Kube-Proxy. Wenn sich die AKS-Cluster in Azure CNI Overlay oder Azure CNI mit dynamischer IP-Zuordnung befinden und auf Azure CNI Powered by Cilium ausführende AKS-Cluster aktualisiert werden, werden neue Knotenworkloads ohne Kube-Proxy erstellt. Im Rahmen dieses Upgradevorgangs werden auch ältere Workloads zur Ausführung ohne Kube-Proxy migriert.

Nächste Schritte

Weitere Informationen zu Netzwerken in AKS finden Sie in den folgenden Artikeln: