Condividi tramite

Configurare Azure CNI con tecnologia Cilium nel servizio Azure Kubernetes

  • Articolo

Azure CNI con tecnologia Cilium combina il solido piano di controllo di Azure CNI con il piano dati di Cilium per offrire funzionalità di rete e sicurezza ad alte prestazioni.

Grazie all'uso di programmi eBPF caricati nel kernel Linux e una struttura di oggetti API più efficiente, Azure CNI con tecnologia Cilium offre i vantaggi seguenti:

  • Funzionalità equivalenti ai plug-in di Azure CNI e Azure CNI Overlay esistenti

  • Miglioramento del routing dei servizi

  • Applicazione dei criteri di rete più efficiente

  • Migliore osservabilità del traffico del cluster

  • Supporto per cluster di dimensioni maggiori (più nodi, pod e servizi)

Gestione indirizzi IP (IPAM) con Azure CNI con tecnologia Cilium

Azure CNI con tecnologia Cilium può essere distribuito usando due diversi metodi per l'assegnazione di indirizzi IP pod:

  • Assegnare indirizzi IP da una rete di sovrimpressione (simile alla modalità Azure CNI Overlay)

  • Assegnare indirizzi IP da una rete virtuale (simile ad Azure CNI esistente con assegnazione IP pod dinamica)

Se non si è certi dell'opzione da selezionare, leggere "Scegliere il modello di rete da usare".

Imposizione dei criteri di rete

Cilium applica i criteri di rete per consentire o negare il traffico tra i pod . Con Cilium non è necessario installare un motore di criteri di rete separato, ad esempio Azure Network Policy Manager o Calico.

Limiti

Azure CNI con tecnologia Cilium presenta attualmente le limitazioni seguenti:

  • Disponibile solo per Linux e non per Windows.

  • L'applicazione dei criteri Cilium L7 è disabilitata.

  • I criteri di rete non possono usare ipBlock per consentire l'accesso agli indirizzi IP dei nodi o dei pod. Per informazioni dettagliate e soluzioni alternative consigliate, vedere le domande frequenti.

  • Più servizi Kubernetes non possono usare la stessa porta host con protocolli diversi (ad esempio TCP o UDP) (problema Cilium #14287).

  • I criteri di rete possono essere applicati ai pacchetti di risposta quando un pod si connette a se stesso tramite l'IP del cluster del servizio (problema Cilium n. 19406).

  • I criteri di rete non vengono applicati ai pod che usano la rete host (spec.hostNetwork: true) perché questi pod usano l'identità host anziché avere identità singole.

Prerequisiti

  • Interfaccia della riga di comando di Azure 2.48.1 o versione successiva. Eseguire az --version per verificare la versione attualmente installata. Se è necessario eseguire l'installazione o l'aggiornamento, vedere Installare l'interfaccia della riga di comando di Azure.

  • Se si usano modelli ARM o l'API REST, la versione dell'API del servizio Azure Kubernetes deve essere 2022-09-02-preview o successiva.

Nota

Versioni precedenti dell'API del servizio Azure Kubernetes (da 2022-09-02preview a 2023-01-02preview) usavano il campo networkProfile.ebpfDataplane=cilium. Le versioni dell'API del servizio Azure Kubernetes da 2023-02-02preview usano il campo networkProfile.networkDataplane=cilium per abilitare Azure CNI con tecnologia Cilium.

Creare un nuovo cluster del servizio Azure Kubernetes con Azure CNI con tecnologia Cilium

Opzione 1: Assegnare indirizzi IP da una rete in sovrimpressione

Usare i comandi seguenti per creare un cluster con una rete di sovrimpressione e Cilium. Sostituire i valori per <clusterName>, <resourceGroupName> e <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

Nota

Il flag --network-dataplane cilium sostituisce il flag deprecato --enable-ebpf-dataplane usato nelle versioni precedenti dell'estensione dell'interfaccia della riga di comando aks-preview.

Opzione 2: Assegnare indirizzi IP da una rete virtuale

Eseguire i comandi seguenti per creare un gruppo di risorse e una rete virtuale con una subnet per i nodi e una subnet per i pod.

# 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

Creare il cluster usando --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

Aggiornare un cluster esistente ad Azure CNI basato su Cilium

Nota

È possibile aggiornare un cluster esistente ad Azure CNI con tecnologia Cilium se il cluster soddisfa i criteri seguenti:

Nota

Quando si abilita Cilium in un cluster con un motore di criteri di rete diverso (Azure NPM o Calico), il motore dei criteri di rete verrà disinstallato e sostituito con Cilium. Per altre informazioni, vedere Disinstallare Azure Network Policy Manager o Calico.

Avviso

Il processo di aggiornamento attiva la ricreazione simultanea di ogni pool di nodi. L'aggiornamento di ogni pool di nodi separatamente non è supportato. Eventuali interruzioni della rete del cluster sono simili a un aggiornamento dell'immagine del nodo o all'aggiornamento della versione di Kubernetes in cui pere ogni nodo in un pool di nodi viene ricreata l'immagine. Cilium inizierà ad applicare i criteri di rete solo dopo che tutti i nodi sono stati ricreati.

Per eseguire l'aggiornamento, è necessaria l'interfaccia della riga di comando di Azure versione 2.52.0 o successiva. Eseguire az --version per verificare la versione attualmente installata. Se è necessario eseguire l'installazione o l'aggiornamento, vedere Installare l'interfaccia della riga di comando di Azure.

Usare il comando seguente per aggiornare un cluster esistente ad Azure CNI con tecnologia Cilium. Sostituire i valori per <clusterName> e <resourceGroupName>:

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

Nota

Dopo aver abilitato Azure CNI con tecnologia Cilium in un cluster del servizio Azure Kubernetes, non è possibile disabilitarlo. Se si vuole usare un piano dati di rete diverso, è necessario creare un nuovo cluster del servizio Azure Kubernetes.

Domande frequenti

  • È possibile personalizzare la configurazione di Cilium?

    No, il servizio Azure Kubernetes gestisce la configurazione Cilium e non può essere modificata. È consigliabile che i clienti che richiedono un maggiore controllo usino AKS BYO CNI e installino Cilium manualmente.

  • È possibile usare risorse personalizzate CiliumNetworkPolicy anziché risorse Kubernetes NetworkPolicy?

    CiliumNetworkPolicy le risorse personalizzate sono parzialmente supportate. I clienti possono usare il filtro FQDN come parte del bundle di funzionalità Advanced Container Networking Services .

    In questo CiliumNetworkPolicy esempio viene illustrato un modello di corrispondenza di esempio per i servizi che corrispondono all'etichetta specificata.

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

  • Perché il traffico viene bloccato quando NetworkPolicy ha un oggetto ipBlock che consente l'indirizzo IP?

    Una limitazione di Azure CNI con tecnologia Cilium è che NetworkPolicy di ipBlock non può selezionare gli indirizzi IP dei pod o dei nodi.

    Ad esempio, NetworkPolicy ha un oggetto ipBlock che consente a tutti i dati in uscita di 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.

    Tuttavia, quando questo NetworkPolicy viene applicato, Cilium bloccherà l'uscita agli indirizzi IP di pod e nodi anche se gli indirizzi IP si trovano all'interno del CIDR ipBlock.

    Come soluzione alternativa, è possibile aggiungere namespaceSelector e podSelector per selezionare i pod. L'esempio seguente seleziona tutti i pod in tutti gli spazi dei nomi:

    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

    Attualmente non è possibile specificare un oggetto NetworkPolicy con ipBlock per consentire il traffico verso gli indirizzi IP del nodo.

  • Il servizio Azure Kubernetes configura limiti di CPU o memoria in Cilium daemonset?

    No, il servizio Azure Kubernetes non configura limiti di CPU o memoria in Cilium daemonset perché Cilium è un componente di sistema critico per la rete dei pod e l'applicazione dei criteri di rete.

  • Azure CNI con tecnologia Cilium usa Kube-Proxy?

    No, i cluster del servizio Azure Kubernetes creati con il piano dati di rete come Cilium non usano Kube-Proxy. Se i cluster del servizio Azure Kubernetes si trovano in Azure CNI Overlay o Azure CNI con allocazione dinamica dell’IP e vengono aggiornati ai cluster del servizio Azure Kubernetes che eseguono Azure CNI con tecnologia Cilium, i nuovi nodi vengono creati senza kube-proxy. La migrazione dei carichi di lavoro meno recenti viene eseguita anche senza kube-proxy come parte di questo processo di aggiornamento.

Passaggi successivi

Per altre informazioni sulla rete in servizio Azure Kubernetes, vedere gli articoli seguenti: