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.
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
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 KubernetesNetworkPolicy
?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 oggettoipBlock
che consente l'indirizzo IP?Una limitazione di Azure CNI con tecnologia Cilium è che
NetworkPolicy
diipBlock
non può selezionare gli indirizzi IP dei pod o dei nodi.Ad esempio,
NetworkPolicy
ha un oggettoipBlock
che consente a tutti i dati in uscita di0.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 CIDRipBlock
.Come soluzione alternativa, è possibile aggiungere
namespaceSelector
epodSelector
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
conipBlock
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:
Azure Kubernetes Service