Konfigurowanie sieci CNI Azure obsługiwanej przez cilium w Azure Kubernetes Service (AKS)

Wdrażanie i eksplorowanie

Azure CNI Obsługiwane przez Cilium łączy niezawodną płaszczyznę sterowania interfejsu sieci kontenerów Azure (CNI) z płaszczyzną danych Cilium w celu zapewnienia wysokiej wydajności sieci i zabezpieczeń.

Tip

AKS Automatic używa rozwiązania Azure CNI Overlay obsługiwanego przez Cilium jako domyślnej sieci wirtualnej — jest ono wstępnie skonfigurowane w każdym klastrze AKS Automatic i nie wymaga żadnej dodatkowej konfiguracji. Jeśli używasz usługi AKS w warstwie Standardowa i chcesz uzyskać tę konfigurację, wykonaj kroki opisane w tym artykule. Aby uzyskać więcej informacji, zobacz Co to jest Azure Kubernetes Service Automatic?

Azure CNI Obsługiwane przez Cilium zapewnia następujące korzyści dzięki wykorzystaniu programów eBPF załadowanych do jądra systemu Linux i bardziej wydajnej struktury obiektów interfejsu API:

  • Funkcjonalność równoważna istniejącym wtyczkom Azure CNI i Azure CNI Overlay
  • Ulepszony routing usług
  • Bardziej wydajne wymuszanie zasad sieciowych
  • Lepsza obserwacja ruchu klastra
  • Obsługa większych klastrów (więcej węzłów, podów i usług)

Zarządzanie adresami IP (IPAM) za pomocą usługi Azure CNI obsługiwanej przez cilium

Note

Jeśli używasz AKS Automatic, sieć nakładkowa jest opcją domyślną i jest już wstępnie skonfigurowana. Poniższe opcje konfiguracji dotyczą tylko klastrów AKS Standard.

Można użyć Azure CNI obsługiwanej przez cilium z trzema opcjami zarządzania adresami IP (IPAM):

W przypadku większości scenariuszy użyj nakładki Azure CNI. Jeśli potrzebujesz bezpośredniego dostępu do adresów IP podów z połączonych sieci, użyj Azure CNI Pod Subnet. Aby uzyskać więcej informacji, zobacz Wybieranie opcji IPAM dla usługi AKS.

Obsługiwane wersje platform Kubernetes i Cilium

W poniższej tabeli przedstawiono minimalną wersję cilium dla każdej wersji platformy Kubernetes. Te wymagania dotyczą zarówno klastrów AKS Automatic, jak i AKS Standard korzystających z Azure CNI opartego na rozwiązaniu Cilium.

Wersja platformy Kubernetes Minimalna wersja Cilium
1.31 (LTS) 1.16.19
1.32 (LTS) 1.17.18
1.33 (LTS) 1.17.18
1.34 1.18.12
1.35 1.18.12
1.36 1.19.6

Aby uzyskać więcej informacji na temat wersjonowania i osi czasu wydań usługi AKS, zobacz Obsługiwane wersje platformy Kubernetes.

Wymuszanie zasad sieciowych za pomocą funkcji Cilium

Cilium wymusza zasady sieciowe, aby zezwolić lub zablokować ruch między podami. Korzystając z Cilium, nie trzeba instalować osobnego silnika polityki sieciowej, takiego jak Azure Network Policy Manager lub Calico.

Zasady przekierowania lokalnego (LRP)

Lokalna zasada przekierowania (LRP) przekierowuje ruch poda skierowany do adresu IP i portu lub do usługi Kubernetes do poda zaplecza na tym samym węźle.

Funkcja LRP jest obsługiwana przez platformę Kubernetes w wersji 1.29 lub nowszej. Aby LRP współpracowało z usługami Advanced Container Networking Services (ACNS) - filtrowaniem nazw FQDN, etykiety wychodzące polityki sieciowej Cilium muszą być zgodne z etykietami podów pamięci podręcznej DNS w środowisku node-local.

Poniższe CiliumLocalRedirectPolicy przekierowuje ruch DNS wysyłany do usługi kube-dns do podów lokalnej pamięci podręcznej DNS na tym samym węźle. Jeśli klaster używa innej nazwy usługi DNS lub przestrzeni nazw, zaktualizuj elementy serviceName i namespace, tak aby odpowiadały Twojemu klastrowi.

apiVersion: cilium.io/v2
kind: CiliumLocalRedirectPolicy
metadata:
  name: dns-to-nodelocal
  namespace: kube-system
spec:
  redirectFrontend:
    serviceMatcher:
      serviceName: kube-dns
      namespace: kube-system
  redirectBackend:
    localEndpointSelector:
      matchLabels:
        k8s-app: node-local-dns
    toPorts:
      - port: "53"
        name: dns
        protocol: UDP
      - port: "53"
        name: dns-tcp
        protocol: TCP

Poniższy fragment przedstawia selektor etykiet toEndpoints w regule ruchu wychodzącego CiliumNetworkPolicy, który musi odpowiadać etykietom podów lokalnej pamięci podręcznej DNS węzła.

...
- matchLabels:
    io.kubernetes.pod.namespace: kube-system
    k8s-app: node-local-dns

Limitations

Azure CNI obsługiwane przez cilium obecnie ma następujące ograniczenia:

  • Dostępne tylko dla systemu Linux, a nie dla Windows.
  • Zasady sieciowe nie mogą używać ipBlock do zezwalania na dostęp do adresów IP węzłów lub podów. Aby uzyskać szczegółowe informacje i zalecane obejścia, zobacz często zadawane pytania.
  • W przypadku modelu Cilium w wersji 1.16 lub starszej wiele usług Kubernetes nie może używać tego samego portu hosta z różnymi protokołami (na przykład TCP lub UDP) (problem z cilium nr 14287).
  • Zasady sieci nie są stosowane do zasobników korzystających z sieci hosta (spec.hostNetwork: true), ponieważ te zasobniki używają tożsamości hosta zamiast własnych tożsamości.
  • Reguły wychodzącej grupy zabezpieczeń sieciowych (NSG), które blokują dostęp do Internetu lub usług platformy Azure, mogą uniemożliwić eksport dzienników diagnostycznych Cilium. Klienci korzystający z restrykcyjnych zasad dotyczących ruchu wychodzącego powinni zezwolić na ruch wychodzący do tagu usługi Azure Monitor, aby zapewnić prawidłowe zbieranie danych telemetrycznych, diagnostycznych i danych na potrzeby rozwiązywania problemów.
  • Wycinanie punktów końcowych Cilium jest obsługiwane w Kubernetes w wersji 1.32 lub nowszej. Wycinki punktów końcowych Cilium nie obsługują konfiguracji sposobu grupowania punktów końcowych Cilium. Priorytetowa przestrzeń nazw za pośrednictwem cilium.io/ces-namespace nie jest obsługiwana.
  • Cilium używa identyfikatorów Cilium jako unikalnego identyfikatora na potrzeby prowizjonowania punktów końcowych, dlatego obciążenia o dużej zmienności, takie jak zadania Spark, generują dużą liczbę identyfikatorów Cilium. Aby uniknąć przekroczenia limitów tożsamości Cilium (65535), wykluczanie etykiet zadań platformy Spark, takich jak !spark-app-name i !spark-app-selector w mapie konfiguracji Cilium, może znacznie zmniejszyć generowanie tożsamości Cilium. Uzyskaj więcej informacji na temat reguł wykluczania tożsamości Cilium, zapoznając się z oficjalną dokumentacją etykiety Cilium.

Włączanie usług Advanced Container Networking Services w celu obserwowania i zabezpieczeń

Aby uzyskać możliwości, takie jak wgląd w ruch sieciowy oraz funkcje zabezpieczeń, takie jak filtrowanie oparte na w pełni kwalifikowanej nazwie domeny (FQDN) i zasady sieciowe oparte na warstwie 7 w klastrze, rozważ włączenie zaawansowanych usług sieciowych kontenerów w klastrach.

To zalecenie dotyczy zarówno klastrów AKS Automatic, jak i AKS Standard. Jeśli używasz usługi AKS Automatic, podstawowa sieć jest już wstępnie skonfigurowana. Włączenie ACNS umożliwia monitorowanie sieci kontenerów oraz filtrowanie nazw FQDN. Inne funkcje usługi ACNS, w tym zasady sieci L7, szyfrowanie WireGuard, szyfrowanie mTLS i routing hosta eBPF, wymagają dodatkowej konfiguracji. Niektóre funkcje mają również wymagania dotyczące wersji, systemu operacyjnego lub wersji zapoznawczej. Aby uzyskać więcej informacji, zobacz tabelę obsługi funkcji.

Konfiguracja klastra w zależności od trybu klastra AKS

Kroki wymagane do korzystania z Azure CNI opartej na rozwiązaniu Cilium zależą od trybu klastra AKS: AKS Automatic lub AKS Standard.

Automatyczne klastry AKS

Nakładka Azure CNI obsługiwana przez Cilium jest domyślną siecią wirtualną dla klastrów AKS Automatic. Ta konfiguracja jest w pełni zarządzana — nie musisz aprowizować sieci wirtualnej, wybierać wtyczki CNI ani określać płaszczyzny danych. Usługa AKS Automatic wstępnie konfiguruje również usługę LocalDNS, zarządzaną bramę NAT dla ruchu wychodzącego oraz dodatek routingu aplikacji dla ruchu przychodzącego.

Nie są wymagane żadne kroki konfiguracji. Jeśli chcesz dodać zaawansowane funkcje wglądu lub zabezpieczeń w istniejącej sieci, zobacz Advanced Container Networking Services.

Klastry AKS w warstwie Standard

W usłudze AKS Standard usługa Azure CNI oparta na Cilium jest opcjonalną konfiguracją sieciową. Wykonaj kroki opisane w tym artykule, aby utworzyć klaster z płaszczyzną danych Cilium. Możesz wybrać tryb przypisywania adresów IP: nakładka, sieć wirtualna lub podsieć węzła.

Prerequisites

Wymagana wersja Azure CLI różni się w zależności od metody przypisania adresu IP:

Metoda przypisania adresu IP Wymagana wersja Azure CLI
Sieć nakładkowa 2.48.1 lub nowszy
Sieć wirtualna 2.48.1 lub nowszy
Podsieć węzłów 2.69.0 lub nowszy

Uruchom polecenie az --version , aby wyświetlić aktualnie zainstalowaną wersję. Jeśli musisz zainstalować lub uaktualnić, zobacz Install Azure CLI.

  • Zapoznaj się z wymaganiami wstępnymi dotyczącymi sieci AKS CNI. Jeśli nie używasz klastra izolowanego sieci, sieć wirtualna musi zezwalać na łączność wychodzącą z wymaganymi punktami końcowymi. Zakresy adresów nie mogą nakładać się na zarezerwowane zakresy usługi AKS ani połączone sieci, a podsieci węzłów nie mogą być delegowane.
  • Aby korzystać z podsieci zarządzanych przez klienta, tożsamość klastra musi mieć uprawnienia Współautor sieci lub równoważne uprawnienia niestandardowe w podsieciach. Użytkownik tworzący klaster musi mieć uprawnienia do tworzenia wymaganych przypisań ról. Jeśli przypiszesz sieciowe grupy zabezpieczeń do podsieci, upewnij się, że ich reguły zezwalają na wymagany ruch węzłów i podów.

Tworzenie nowego klastra usługi AKS przy użyciu Azure CNI obsługiwanego przez cilium

W poniższych sekcjach używa się polecenia az aks create, aby utworzyć klaster AKS w warstwie Standard i przypisać adresy IP. Jeśli używasz usługi AKS Automatic, ta konfiguracja jest już stosowana — w przypadku sieci nie są wymagane żadne kroki tworzenia klastra.

Opcja 1: Przypisywanie adresów IP z sieci nakładkowej

Użyj następujących poleceń, aby utworzyć klaster z siecią nakładki i Cilium. Zastąp wartości <clusterName>, <resourceGroupName> i <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

Flaga --network-dataplane cilium zastępuje przestarzałą --enable-ebpf-dataplane flagę używaną we wcześniejszych wersjach rozszerzenia interfejsu wiersza polecenia aks-preview.

Opcja 2. Przypisywanie adresów IP z sieci wirtualnej

Uruchom następujące polecenia, aby utworzyć grupę zasobów oraz sieć wirtualną z podsiecią dla węzłów i osobną podsiecią dla podów.

# 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

Utwórz klaster przy użyciu polecenia az aks create, używając --network-dataplane cilium do określenia płaszczyzny danych Cilium. Zastąp wartości dla <clusterName>, <resourceGroupName>, <location>, <subscriptionId> i <vnetName> oraz upewnij się, że wartości --vnet-subnet-id i --pod-subnet-id wskazują na prawidłowe podsieci utworzone w poprzednim kroku.

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

Opcja 3. Przypisywanie adresów IP z podsieci Node

Utwórz klaster przy użyciu podsieci węzła z użyciem płaszczyzny danych Cilium.

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

Często zadawane pytania

Czy usługa Azure CNI obsługiwana przez cilium jest dostępna w klastrach automatycznych usługi AKS?

Yes. Nakładka Azure CNI obsługiwana przez Cilium jest domyślną siecią wirtualną w każdym klastrze AKS Automatic i nie wymaga żadnej konfiguracji. Usługa AKS Automatic wstępnie konfiguruje również usługę LocalDNS oraz zarządzaną bramę NAT dla ruchu wychodzącego. Jeśli potrzebujesz dodatkowych funkcji obserwowalności lub zabezpieczeń, takich jak filtrowanie FQDN, zasady sieciowe L7 lub szyfrowanie WireGuard, możesz włączyć funkcję Advanced Container Networking Services w klastrze AKS Automatic.

Czy mogę używać CiliumNetworkPolicy zasobów niestandardowych zamiast zasobów platformy Kubernetes NetworkPolicy ?

Obsługiwane są wersje L3 i L4 CiliumNetworkPolicy oraz mogą być używane wraz z zasobami platformy Kubernetes NetworkPolicy .

Użytkownicy mogą używać filtrowania FQDN (Fully Qualified Domain Name) i zasad zabezpieczeń warstwy 7 w ramach pakietu funkcji Advanced Container Networking Services.

Czy mogę użyć CiliumClusterwideNetworkPolicy?

Tak, Azure CNI oparte na Cilium obsługuje CiliumClusterwideNetworkPolicy.

Poniższa przykładowa zasada zezwala na ruch przychodzący na porcie TCP 80 do zasobników z etykietą role: backend z zasobników z etykietą role: frontend.

apiVersion: "cilium.io/v2"
kind: CiliumClusterwideNetworkPolicy
metadata:
  name: "l4-rule-ingress-backend-frontend"
spec:
  endpointSelector:
    matchLabels:
      role: backend
  ingress:
    - fromEndpoints:
        - matchLabels:
            role: frontend
      toPorts:
        - ports:
            - port: "80"
              protocol: TCP

Jakie funkcje Cilium obsługuje Azure CNI Powered by Cilium? Które funkcje wymagają usług Advanced Container Networking Services?

Obsługiwana funkcja Bez ACNS Z usługą ACNS Wymagania i konfiguracja
Wycinki punktu końcowego cilium Obsługiwane ✔️ Obsługiwane ✔️ Wymaga platformy Kubernetes w wersji 1.32 lub nowszej.
Zasady sieciowe platformy Kubernetes Obsługiwane ✔️ Obsługiwane ✔️ None.
Zasady przekierowania lokalnego Obsługiwane ✔️ Obsługiwane ✔️ Wymaga platformy Kubernetes w wersji 1.29 lub nowszej.
Zasady sieci Cilium L3/L4 Obsługiwane ✔️ Obsługiwane ✔️ None.
Zasady sieciowe w całym klastrze Cilium Obsługiwane ✔️ Obsługiwane ✔️ None.
Filtrowanie nazw FQDN Niewspierane ❌ Obsługiwane ✔️ Wymaga platformy Kubernetes w wersji 1.29 lub nowszej. Domyślnie włączone z ACNS.
Zasady sieci L7 (HTTP/gRPC/Kafka) Niewspierane ❌ Obsługiwane ✔️ Wymaga platformy Kubernetes 1.29 lub nowszej L7 oraz zaawansowanej opcji zasad sieciowych.
Obserwowanie sieci kontenerów (metryki i dzienniki przepływu) Niewspierane ❌ Obsługiwane ✔️ Włączono za pomocą ACNS.
Szyfrowanie WireGuard Niewspierane ❌ Obsługiwane ✔️ Wymaga jawnej konfiguracji narzędzia WireGuard i portu UDP 51871 między węzłami.
Szyfrowanie mTLS Niewspierane ❌ Obsługiwane w wersji zapoznawczej Wymaga Kubernetes 1.34 lub nowszej wersji, Cilium 1.18 lub nowszej wersji, rejestracji wersji zapoznawczej oraz jawnej konfiguracji mTLS.
Routing eBPF na hoście Niewspierane ❌ Obsługiwane ✔️ Wymaga platformy Kubernetes 1.33 lub nowszej, Azure CLI 2.71 lub nowszej, Azure Linux 3.0 lub Ubuntu 24.04 i jawną BpfVeth konfigurację.

Instrukcje konfiguracji i ograniczenia dotyczące poszczególnych funkcji znajdują się w sekcji Advanced Container Networking Services.

Czy można zmodyfikować ConfigMap Cilium?

Tylko label exclusion jest obsługiwany w przypadku Azure CNI obsługiwanego przez Cilium. Ta ConfigMap istnieje w przestrzeni nazw kube-system jako cilium-config. Dodanie etykiet jest utrwalane w całym klastrze podczas ponownych uruchomień, aktualizacji i rekoncyliacji. Zmiany innych wartości w ConfigMap nie są obsługiwane.

Dlaczego ruch jest blokowany, gdy element NetworkPolicy ma ipBlock, który zezwala na ten adres IP?

Ograniczenie Azure CNI obsługiwane przez Cilium polega na tym, że NetworkPolicyipBlock nie może wybrać adresów IP pod ani węzła.

Na przykład, ten NetworkPolicy ma ipBlock, który zezwala na cały ruch wychodzący do 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.

Nawet przy cidr: 0.0.0.0/0 Cilium blokuje ruch wychodzący do adresów IP podów i węzłów, ponieważ ipBlock nie może wybrać tych adresów.

Aby obejść ten problem, możesz dodać namespaceSelector i podSelector do wybranych zasobników. W tym przykładzie wybierane są wszystkie zasobniki we wszystkich przestrzeniach nazw.

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

Obecnie nie można określić NetworkPolicy przy użyciu ipBlock, aby zezwolić na ruch do adresów IP węzłów.

Czy usługa AKS konfiguruje limity CPU lub pamięci dla składnika Cilium daemonset?

Nie, usługa AKS nie konfiguruje limitów procesora CPU ani pamięci w Cilium, ponieważ Cilium daemonset jest krytycznym składnikiem systemu dla sieci dla podów i egzekwowania polityk sieciowych.

Czy usługa Azure CNI obsługiwana przez cilium używa serwera kube-proxy?

Nie, klastry usługi AKS utworzone za pomocą płaszczyzny danych sieciowych jako Cilium nie używają elementu kube-proxy.

To zachowanie dotyczy wszystkich wersji platformy Kubernetes obsługiwanych przez usługę Azure CNI obsługiwanej przez cilium bez oddzielnego ograniczenia wersji usługi AKS. Uaktualnienie płaszczyzny danych jest obsługiwane tylko w klastrach systemu Linux i wymaga wyłączenia automatycznej aprowizacji węzłów (NAP) podczas aktualizacji.

Jeśli uaktualnisz klastry AKS w konfiguracji Azure CNI Overlay lub Azure CNI z dynamiczną alokacją adresów IP do klastrów AKS działających w oparciu o Azure CNI z technologią Cilium, obciążenia robocze na nowych węzłach są tworzone bez kube-proxy. Obciążenia na istniejących węzłach są również migrowane tak, aby działały bez kube-proxy w ramach tego procesu uaktualniania.

Czy lokalna usługa DNS w AKS jest obsługiwana w usłudze Azure CNI opartej na Cilium?

Tak, zasady sieciowe muszą jawnie zezwalać na ruch wychodzący z poda do adresu IP LocalDNS.

Poniższa zasada zezwala na ruch wychodzący do zakresu CIDR LocalDNS 169.254.10.0/24 na porcie 53 protokołów UDP i TCP oraz do encji host na tych samych portach.

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "allow-azure-dns-egress"
  namespace: default
spec:
  endpointSelector:
    matchLabels: {} # This selects ALL pods in the namespace
  egress:
    - toCIDR:
        - 169.254.10.0/24
      toPorts:
        - ports:
            - port: "53"
              protocol: UDP
            - port: "53"
              protocol: TCP
    - toEntities:
        - host
      toPorts:
        - ports:
            - port: "53"
              protocol: UDP
            - port: "53"
              protocol: TCP

Sieć dual-stack z Azure CNI obsługiwana przez Cilium

Musisz mieć platformę Kubernetes w wersji 1.29 lub nowszej. Dotyczy to zarówno klastrów AKS Automatic, jak i AKS Standard.

Klastry AKS można wdrożyć w trybie dual-stack za pomocą Azure CNI zasilanego przez Cilium. Ta funkcja umożliwia również zarządzanie ruchem IPv6 za pomocą mechanizmu zasad sieciowych Cilium.

Konfigurowanie klastrów nakładek za pomocą interfejsu CNI Azure obsługiwanego przez Cilium

Utwórz klaster z nakładką Azure CNI przy użyciu polecenia az aks create. Pamiętaj, aby użyć argumentu --network-dataplane cilium , aby określić płaszczyznę danych Cilium.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks create \
  --name $clusterName \
  --resource-group $resourceGroup \
  --location $location \
  --network-plugin azure \
  --network-plugin-mode overlay \
  --network-dataplane cilium \
  --ip-families ipv4,ipv6 \
  --generate-ssh-keys

Treści powiązane

Aby uzyskać więcej informacji na temat sieci usługi AKS i usługi AKS Automatic, zobacz następujące zasoby:

  • Last updated on