Configurare Azure CNI con tecnologia Cilium nel servizio Azure Kubernetes

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.

• Hubble è disabilitato.

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

• I servizi Kubernetes con internalTrafficPolicy=Local non sono supportati (problema Cilium n. 17796).

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

• Incompatibile con le identità gestite da pod di Microsoft Entra (aad-pod-identity). Usare invece ID dei carichi di lavoro di Microsoft Entra.

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.

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

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

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

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?

  Le risorse personalizzate CiliumNetworkPolicy non sono ufficialmente supportate. È consigliabile che i clienti usino le risorse Kubernetes NetworkPolicy per configurare i criteri di rete.

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

• Usare un indirizzo IP statico con il bilanciamento del carico del servizio Azure Kubernetes

• Usare un servizio di bilanciamento del carico interno con il servizio Azure Container

• Creare un controller di ingresso di base con connettività di rete esterna