Udostępnij za pośrednictwem


Konfigurowanie usługi Azure CNI obsługiwanej przez cilium w usłudze Azure Kubernetes Service (AKS)

Usługa Azure CNI obsługiwana przez cilium łączy niezawodną płaszczyznę sterowania interfejsu CNI platformy Azure z płaszczyzną danych Cilium w celu zapewnienia wysokiej wydajności sieci i zabezpieczeń.

Dzięki wykorzystaniu programów eBPF załadowanych do jądra systemu Linux i bardziej wydajnej struktury obiektów interfejsu API usługa Azure CNI obsługiwana przez cilium zapewnia następujące korzyści:

  • 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, zasobników i usług)

Zarządzanie adresami IP (IPAM) przy użyciu usługi Azure CNI obsługiwanej przez cilium

Rozwiązanie Azure CNI Obsługiwane przez cilium można wdrożyć przy użyciu dwóch różnych metod przypisywania adresów IP zasobników:

  • Przypisywanie adresów IP z sieci nakładki (podobnie jak tryb nakładki usługi Azure CNI)

  • Przypisywanie adresów IP z sieci wirtualnej (podobnie jak istniejąca sieć CNI platformy Azure z dynamicznym przypisaniem adresu IP zasobnika)

Jeśli nie masz pewności, którą opcję wybrać, przeczytaj "Wybieranie modelu sieciowego do użycia".

Wymuszanie zasad sieciowych

Cilium wymusza zasady sieciowe, aby zezwalać na ruch między zasobnikami lub blokować go. W przypadku modelu Cilium nie trzeba instalować oddzielnego aparatu zasad sieciowych, takiego jak Menedżer zasad sieciowych lub Calico.

Ograniczenia

Usługa Azure CNI obsługiwana przez aplikację Cilium ma obecnie następujące ograniczenia:

  • Dostępne tylko dla systemu Linux, a nie dla systemu Windows.

  • Wymuszanie zasad Cilium L7 jest wyłączone.

  • Zasady sieciowe nie mogą używać ipBlock do zezwalania na dostęp do adresów IP węzłów lub zasobników. Zobacz często zadawane pytania, aby uzyskać szczegółowe informacje i zalecane obejście.

  • 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 #14287).

  • Zasady sieciowe mogą być wymuszane na pakietach odpowiedzi, gdy zasobnik łączy się z samym sobą za pośrednictwem adresu IP klastra usług (problem z cilium #19406).

  • 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 tożsamości poszczególnych.

Wymagania wstępne

  • Interfejs wiersza polecenia platformy Azure w wersji 2.48.1 lub nowszej. Uruchom polecenie az --version , aby wyświetlić aktualnie zainstalowaną wersję. Jeśli konieczna będzie instalacja lub uaktualnienie, zobacz Instalowanie interfejsu wiersza polecenia platformy Azure.

  • Jeśli używasz szablonów usługi ARM lub interfejsu API REST, wersja interfejsu API usługi AKS musi mieć wartość 2022-09-02-preview lub nowszą.

Uwaga

Poprzednie wersje interfejsu API usługi AKS (2022-09-02preview do 2023-01-02preview) używały pola networkProfile.ebpfDataplane=cilium. Wersje interfejsu API usługi AKS od 2023-02-02wersja zapoznawcza używają pola networkProfile.networkDataplane=cilium , aby włączyć usługę Azure CNI Obsługiwane przez cilium.

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

Opcja 1. Przypisywanie adresów IP z sieci nakładki

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

Uwaga

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 i sieć wirtualną z podsiecią dla węzłów i podsieci dla zasobnikó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 --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

Często zadawane pytania

  • Czy mogę dostosować konfigurację cilium?

    Nie, usługa AKS zarządza konfiguracją cilium i nie można jej modyfikować. Zalecamy, aby klienci, którzy wymagają większej kontroli, używają sieci CNI usługi AKS BYO i ręcznie instalują cilium.

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

    CiliumNetworkPolicy zasoby niestandardowe są częściowo obsługiwane. Klienci mogą używać filtrowania nazw FQDN w ramach pakietu funkcji Advanced Container Networking Services .

    W tym CiliumNetworkPolicy przykładzie pokazano przykładowy wzorzec dopasowania dla usług, które pasują do określonej etykiety.

    apiVersion: "cilium.io/v2"
    kind: CiliumNetworkPolicy
    metadata:
      name: "example-fqdn"
    spec:
      endpointSelector:
        matchLabels:
          foo: bar
      egress:
      - toFQDNs:
        - matchPattern: "*.example.com"
    
  • Dlaczego ruch jest blokowany, gdy NetworkPolicy obiekt ma identyfikator ipBlock zezwalający na adres IP?

    Ograniczenie usługi Azure CNI obsługiwanej przez cilium polega na tym, że NetworkPolicynie ipBlock można wybrać adresów IP zasobnika ani węzła.

    Na przykład ma to NetworkPolicy wartość ipBlock , która zezwala na cały ruch wychodzący do 0.0.0.0/0elementu :

    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.
    

    Jednak po zastosowaniu tej NetworkPolicy funkcji cilium zablokuje ruch wychodzący do zasobnika i adresów IP węzłów, mimo że adresy IP znajdują się w ciDR ipBlock .

    Aby obejść ten problem, możesz dodać namespaceSelector zasobniki i podSelector wybrać je. Poniższy przykład wybiera 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: {}
    

    Uwaga

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

  • Czy usługa AKS konfiguruje limity procesora CPU lub pamięci w 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 zasobników i wymuszania zasad sieciowych.

  • Czy usługa Azure CNI obsługiwana przez rozwiązanie Cilium korzysta z usługi Kube-Proxy?

    Nie, klastry usługi AKS utworzone za pomocą planu danych sieciowych jako Cilium nie używają serwera Kube-Proxy. Jeśli klastry usługi AKS znajdują się w nakładce usługi Azure CNI lub usłudze Azure CNI z dynamiczną alokacją adresów IP i są uaktualniane do klastrów usługi AKS z uruchomioną usługą Azure CNI obsługiwaną przez cilium, nowe obciążenia węzłów są tworzone bez serwera kube-proxy. Starsze obciążenia są również migrowane do uruchamiania bez serwera kube-proxy w ramach tego procesu uaktualniania.

Następne kroki

Dowiedz się więcej o sieci w usłudze AKS w następujących artykułach: