Udostępnij za pośrednictwem

Używanie sieci kubenet z własnymi zakresami adresów IP w usłudze Azure Kubernetes Service (AKS)

  • Artykuł

Klastry usługi AKS używają rozwiązania kubenet i domyślnie tworzą sieć wirtualną i podsieć platformy Azure. W przypadku sieci kubenet węzły uzyskują adresy IP z podsieci sieci wirtualnej platformy Azure. Zasobniki uzyskują adresy IP z przestrzeni adresowej, która jest logicznie różna od podsieci sieci wirtualnej platformy Azure, używanej przez węzły. Translator adresów sieciowych (NAT) jest następnie skonfigurowany, aby zasobniki mogły uzyskiwać dostęp do zasobów w sieci wirtualnej platformy Azure. Źródłowy adres IP ruchu to translator adresów sieciowych do podstawowego adresu IP węzła. Takie podejście znacznie zmniejsza liczbę adresów IP, które należy zarezerwować w przestrzeni sieciowej, aby zasobniki były używane.

Za pomocą interfejsu sieci kontenera platformy Azure (CNI) każdy zasobnik pobiera adres IP z podsieci i może być dostępny bezpośrednio. Te adresy IP muszą być planowane z wyprzedzeniem i unikatowe w przestrzeni sieciowej. Każdy węzeł ma parametr konfiguracji dla maksymalnej liczby zasobników, które obsługuje. Równoważna liczba adresów IP na węzeł jest następnie zarezerwowana z góry dla tego węzła. Takie podejście wymaga większego planowania i często prowadzi do wyczerpania adresów IP lub konieczności ponownego kompilowania klastrów w większej podsieci w miarę wzrostu zapotrzebowania aplikacji. Maksymalną liczbę zasobników można skonfigurować w węźle w czasie tworzenia klastra lub podczas tworzenia nowych pul węzłów. Jeśli nie określisz maxPods podczas tworzenia nowych pul węzłów, otrzymasz wartość domyślną 110 dla rozwiązania kubenet.

W tym artykule pokazano, jak używać sieci kubenet do tworzenia i używania podsieci sieci wirtualnej dla klastra usługi AKS. Aby uzyskać więcej informacji na temat opcji i zagadnień dotyczących sieci, zobacz Pojęcia dotyczące sieci dla platform Kubernetes i AKS.

Wymagania wstępne

  • Sieć wirtualna klastra usługi AKS musi zezwalać na wychodzącą łączność z Internetem.
  • Nie twórz więcej niż jednego klastra usługi AKS w tej samej podsieci.
  • Klastry usługi AKS nie mogą używać 169.254.0.0/16zakresu 172.31.0.0/16172.30.0.0/16192.0.2.0/24 adresów usługi Kubernetes, zakresu adresów zasobnika ani zakresu adresów sieci wirtualnej klastra. Nie można zaktualizować zakresu po utworzeniu klastra.
  • Tożsamość klastra używana przez klaster usługi AKS musi mieć co najmniej rolę Współautor sieci w podsieci w sieci wirtualnej. Interfejs wiersza polecenia ułatwia automatyczne ustawianie przypisania roli. Jeśli używasz szablonu usługi ARM lub innych klientów, musisz ręcznie ustawić przypisanie roli. Musisz również mieć odpowiednie uprawnienia, takie jak właściciel subskrypcji, aby utworzyć tożsamość klastra i przypisać mu uprawnienia. Jeśli chcesz zdefiniować rolę niestandardową zamiast korzystać z wbudowanej roli Współautor sieci, potrzebne są następujące uprawnienia:
    • Microsoft.Network/virtualNetworks/subnets/join/action
    • Microsoft.Network/virtualNetworks/subnets/read

Ostrzeżenie

Aby korzystać z pul węzłów systemu Windows Server, należy użyć usługi Azure CNI. Model sieci kubenet nie jest dostępny dla kontenerów systemu Windows Server.

Zanim rozpoczniesz

Potrzebny jest interfejs wiersza polecenia platformy Azure w wersji 2.0.65 lub nowszej, zainstalowany i skonfigurowany. Uruchom polecenie az --version, aby dowiedzieć się, jaka wersja jest używana. Jeśli konieczna będzie instalacja lub uaktualnienie, zobacz Instalowanie interfejsu wiersza polecenia platformy Azure.

Omówienie sieci kubenet z własną podsiecią

W wielu środowiskach zdefiniowano sieci wirtualne i podsieci z przydzielonymi zakresami adresów IP i używasz tych zasobów do obsługi wielu usług i aplikacji. Aby zapewnić łączność sieciową, klastry usługi AKS mogą używać rozwiązania kubenet (sieci podstawowej) lub usługi Azure CNI (sieć zaawansowana).

W przypadku rozwiązania kubenet tylko węzły otrzymują adres IP w podsieci sieci wirtualnej. Zasobniki nie mogą komunikować się bezpośrednio ze sobą. Zamiast tego routing zdefiniowany przez użytkownika (UDR) i przekazywanie ip obsługują łączność między zasobnikami między węzłami. Konfiguracja tras zdefiniowanych przez użytkownika i przekierowywanie adresów IP jest tworzona i domyślnie utrzymywana przez usługę AKS, ale jeśli chcesz, możesz przenieść własną tabelę tras na potrzeby niestandardowego zarządzania trasami . Można również wdrożyć zasobniki za usługą, która odbiera przypisany adres IP i równoważy ruch dla aplikacji. Na poniższym diagramie pokazano, jak węzły usługi AKS odbierają adres IP w podsieci sieci wirtualnej, ale nie zasobniki:

Model sieci Kubenet z klastrem usługi AKS

pomoc techniczna platformy Azure maksymalnie 400 tras w trasach zdefiniowanych przez użytkownika, więc nie można mieć klastra usługi AKS większego niż 400 węzłów. Węzły wirtualne usługi AKS i zasady sieci platformy Azure nie są obsługiwane w usłudze kubenet. Zasady sieci Calico są obsługiwane.

W przypadku usługi Azure CNI każdy zasobnik odbiera adres IP w podsieci IP i może komunikować się bezpośrednio z innymi zasobnikami i usługami. Klastry mogą być tak duże, jak określony zakres adresów IP. Należy jednak zaplanować zakres adresów IP z wyprzedzeniem, a wszystkie adresy IP są używane przez węzły usługi AKS na podstawie maksymalnej liczby zasobników, które mogą obsługiwać. Zaawansowane funkcje sieci i scenariusze, takie jak węzły wirtualne lub zasady sieciowe (azure lub Calico) są obsługiwane w usłudze Azure CNI.

Ograniczenia i zagadnienia dotyczące rozwiązania kubenet

Uwaga

Niektóre zasobniki systemowe, takie jak konnectivity w klastrze, używają adresu IP węzła hosta, a nie adresu IP z przestrzeni adresowej nakładki. Zasobniki systemowe będą używać tylko adresu IP węzła, a nie adresu IP z sieci wirtualnej.

Dostępność i wyczerpanie adresów IP

Typowym problemem z usługą Azure CNI jest to, że przypisany zakres adresów IP jest zbyt mały, aby dodać więcej węzłów podczas skalowania lub uaktualniania klastra. Zespół ds. sieci może również nie być w stanie wydać wystarczająco dużego zakresu adresów IP, aby obsługiwać oczekiwane wymagania aplikacji.

W ramach naruszenia zabezpieczeń można utworzyć klaster usługi AKS, który używa rozwiązania kubenet i łączyć się z istniejącą podsiecią sieci wirtualnej. Takie podejście umożliwia węzłom odbieranie zdefiniowanych adresów IP bez konieczności wcześniejszego zarezerwowania dużej liczby adresów IP dla potencjalnych zasobników, które mogą być uruchamiane w klastrze. Dzięki rozwiązaniu kubenet można użyć znacznie mniejszego zakresu adresów IP i obsługiwać duże klastry i wymagania aplikacji. Na przykład z zakresem adresów IP /27 w podsieci można uruchomić klaster 20–25 węzłów z wystarczającą ilością miejsca do skalowania lub uaktualniania. Ten rozmiar klastra może obsługiwać maksymalnie 2200–2750 zasobników (domyślnie maksymalnie 110 zasobników na węzeł). Maksymalna liczba zasobników na węzeł, które można skonfigurować za pomocą usługi kubenet w usłudze AKS, wynosi 250.

Następujące podstawowe obliczenia porównują różnicę w modelach sieciowych:

  • kubenet: prosty zakres adresów IP /24 może obsługiwać maksymalnie 251 węzłów w klastrze. Każda podsieć sieci wirtualnej platformy Azure rezerwuje pierwsze trzy adresy IP dla operacji zarządzania. Ta liczba węzłów może obsługiwać maksymalnie 27 610 zasobników z domyślnym maksymalnie 110 zasobnikami na węzeł.
  • Azure CNI: Ten sam podstawowy zakres podsieci /24 może obsługiwać tylko maksymalnie osiem węzłów w klastrze. Ta liczba węzłów może obsługiwać maksymalnie 240 zasobników z domyślnym maksymalnie 30 zasobnikami na węzeł.

Uwaga

Te wartości maksymalne nie uwzględniają operacji uaktualniania ani skalowania. W praktyce nie można uruchomić maksymalnej liczby węzłów, które obsługuje zakres adresów IP podsieci. Należy pozostawić niektóre adresy IP dostępne do skalowania lub uaktualniania operacji.

Komunikacja równorzędna sieci wirtualnych i połączenia usługi ExpressRoute

Aby zapewnić łączność lokalną, metody sieci kubenet i Azure-CNI mogą używać komunikacji równorzędnej sieci wirtualnych platformy Azure lub połączeń usługi ExpressRoute. Starannie zaplanuj zakresy adresów IP, aby zapobiec nakładaniu się i niepoprawnemu routingowi ruchu. Na przykład wiele sieci lokalnych używa zakresu adresów 10.0.0.0/8 anonsowanego za pośrednictwem połączenia usługi ExpressRoute. Zalecamy utworzenie klastrów usługi AKS w podsieciach sieci wirtualnej platformy Azure poza tym zakresem adresów, takich jak 172.16.0.0/16.

Wybieranie modelu sieciowego do użycia

Poniższe zagadnienia pomagają określić, kiedy każdy model sieciowy może być najbardziej odpowiedni:

Użyj rozwiązania kubenet , gdy:

  • Masz ograniczoną przestrzeń adresową IP.
  • Większość komunikacji zasobnika znajduje się w klastrze.
  • Nie potrzebujesz zaawansowanych funkcji usługi AKS, takich jak węzły wirtualne lub usługa Azure Network Policy.

Użyj usługi Azure CNI , gdy:

  • Masz dostępną przestrzeń adresową IP.
  • Większość komunikacji zasobnika dotyczy zasobów spoza klastra.
  • Nie chcesz zarządzać trasami zdefiniowanymi przez użytkownika na potrzeby łączności zasobników.
  • Potrzebujesz zaawansowanych funkcji usługi AKS, takich jak węzły wirtualne lub usługa Azure Network Policy.

Aby uzyskać więcej informacji, które pomogą Ci zdecydować, który model sieciowy ma być używany, zobacz Porównanie modeli sieciowych i ich zakresu pomocy technicznej.

Tworzenie sieci wirtualnej i podsieci

  1. Utwórz grupę zasobów przy użyciu az group create polecenia .

    az group create --name myResourceGroup --location eastus

  2. Jeśli nie masz istniejącej sieci wirtualnej i podsieci do użycia, utwórz te zasoby sieciowe przy użyciu az network vnet create polecenia . Następujące przykładowe polecenie tworzy sieć wirtualną o nazwie myAKSVnet z prefiksem adresu 192.168.0.0/16 i podsieci o nazwie myAKSSubnet z prefiksem adresu 192.168.1.0/24:

    az network vnet create \
    --resource-group myResourceGroup \
    --name myAKSVnet \
    --address-prefixes 192.168.0.0/16 \
    --subnet-name myAKSSubnet \
    --subnet-prefix 192.168.1.0/24 \
    --location eastus

  3. Pobierz identyfikator zasobu podsieci przy użyciu az network vnet subnet show polecenia i zapisz go jako zmienną o nazwie SUBNET_ID do późniejszego użycia.

    SUBNET_ID=$(az network vnet subnet show --resource-group myResourceGroup --vnet-name myAKSVnet --name myAKSSubnet --query id -o tsv)

Tworzenie klastra usługi AKS w sieci wirtualnej

Tworzenie klastra usługi AKS przy użyciu tożsamości zarządzanych przypisanych przez system

Uwaga

W przypadku korzystania z tożsamości przypisanej przez system interfejs wiersza polecenia platformy Azure przyznaje rolę Współautor sieci tożsamości przypisanej przez system po utworzeniu klastra. Jeśli używasz szablonu usługi ARM lub innych klientów, musisz zamiast tego użyć tożsamości zarządzanej przypisanej przez użytkownika.

  • Utwórz klaster usługi AKS z tożsamościami zarządzanymi przypisanymi przez system przy użyciu az aks create polecenia .

    az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --network-plugin kubenet \
    --service-cidr 10.0.0.0/16 \
    --dns-service-ip 10.0.0.10 \
    --pod-cidr 10.244.0.0/16 \
    --vnet-subnet-id $SUBNET_ID \
    --generate-ssh-keys

    Parametry wdrożenia:

    • --service-cidr jest opcjonalny. Ten adres służy do przypisywania usług wewnętrznych w klastrze usługi AKS jako adresu IP. Ten zakres adresów IP powinien być przestrzenią adresową, która nie jest używana w innym miejscu w środowisku sieciowym, w tym zakresy sieci lokalnych, jeśli łączysz się lub planujesz nawiązać połączenie, sieci wirtualne platformy Azure przy użyciu usługi Express Route lub połączenia sieci VPN typu lokacja-lokacja. Wartość domyślna to 10.0.0.0/16.
    • --dns-service-ip jest opcjonalny. Adres powinien być adresem .10 zakresu adresów IP usługi. Wartość domyślna to 10.0.0.10.
    • --pod-cidr jest opcjonalny. Ten adres powinien być dużą przestrzenią adresową, która nie jest używana w innym miejscu w środowisku sieciowym. Ten zakres obejmuje wszystkie lokalne zakresy sieci, jeśli łączysz się lub planujesz nawiązać połączenie, sieci wirtualne platformy Azure przy użyciu usługi Express Route lub połączenia sieci VPN typu lokacja-lokacja. Wartość domyślna to 10.244.0.0/16.
      • Ten zakres adresów musi być wystarczająco duży, aby pomieścić liczbę węzłów, które mają zostać przeskalowane w górę. Nie można zmienić tego zakresu adresów po wdrożeniu klastra.
      • Zakres adresów IP zasobnika służy do przypisywania przestrzeni adresowej /24 do każdego węzła w klastrze. W poniższym przykładzie węzeł --pod-cidr z 10.244.0.0/16 przypisuje pierwszy węzeł 10.244.0.0/24, drugi węzeł 10.244.1.0/24, a trzeci węzeł 10.244.2.0/24.
      • W miarę skalowania lub uaktualniania klastra platforma Azure nadal przypisuje zakres adresów IP zasobnika do każdego nowego węzła.

Tworzenie klastra usługi AKS z tożsamością zarządzaną przypisaną przez użytkownika

Tworzenie tożsamości zarządzanej

  • Utwórz tożsamość zarządzaną przy użyciu az identity polecenia . Jeśli masz istniejącą tożsamość zarządzaną, znajdź identyfikator podmiotu az identity show --ids <identity-resource-id> zabezpieczeń przy użyciu polecenia .

    az identity create --name myIdentity --resource-group myResourceGroup

    Dane wyjściowe powinny przypominać następujące przykładowe dane wyjściowe:

    {                                  
  "clientId": "<client-id>",
  "clientSecretUrl": "<clientSecretUrl>",
  "id": "/subscriptions/<subscriptionid>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity", 
  "location": "westus2",
  "name": "myIdentity",
  "principalId": "<principal-id>",
  "resourceGroup": "myResourceGroup",                       
  "tags": {},
  "tenantId": "<tenant-id>",
  "type": "Microsoft.ManagedIdentity/userAssignedIdentities"
}

Dodawanie przypisania roli dla tożsamości zarządzanej

Jeśli używasz interfejsu wiersza polecenia platformy Azure, rola zostanie automatycznie dodana i możesz pominąć ten krok. Jeśli używasz szablonu usługi ARM lub innych klientów, musisz użyć identyfikatora głównego tożsamości zarządzanej klastra do wykonania przypisania roli.

  • Pobierz identyfikator zasobu sieci wirtualnej przy użyciu az network vnet show polecenia i zapisz go jako zmienną o nazwie VNET_ID.

    VNET_ID=$(az network vnet show --resource-group myResourceGroup --name myAKSVnet --query id -o tsv)

  • Przypisz tożsamość zarządzaną dla uprawnień współautora sieci klastra usługi AKS w sieci wirtualnej przy użyciu az role assignment create polecenia i podaj< identyfikator principalId>.

    az role assignment create --assignee <control-plane-identity-principal-id> --scope $VNET_ID --role "Network Contributor"

# Example command
az role assignment create --assignee 22222222-2222-2222-2222-222222222222 --scope "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myAKSVnet" --role "Network Contributor"

Uwaga

Wypełnienie uprawnienia do tożsamości zarządzanej klastra używanej przez platformę Azure może potrwać 60 minut.

Tworzenie klastra AKS

  • Utwórz klaster usługi AKS przy użyciu az aks create polecenia i podaj identyfikator zasobu tożsamości zarządzanej płaszczyzny sterowania dla argumentu assign-identity w celu przypisania tożsamości zarządzanej przypisanej przez użytkownika.

    az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --node-count 3 \
    --network-plugin kubenet \
    --vnet-subnet-id $SUBNET_ID \
    --assign-identity <identity-resource-id> \
    --generate-ssh-keys

Podczas tworzenia klastra usługi AKS tworzona jest automatycznie sieciowa grupa zabezpieczeń i tabela tras. Te zasoby sieciowe są zarządzane przez płaszczyznę sterowania usługi AKS. Sieciowa grupa zabezpieczeń jest automatycznie skojarzona z wirtualnymi kartami sieciowymi w węzłach. Tabela tras jest automatycznie skojarzona z podsiecią sieci wirtualnej. Reguły sieciowej grupy zabezpieczeń i tabele tras są automatycznie aktualizowane podczas tworzenia i uwidaczniania usług.

Korzystanie z własnej podsieci i tabeli routingu za pomocą wtyczki kubenet

W przypadku rozwiązania kubenet tabela tras musi istnieć w podsieciach klastra. Usługa AKS obsługuje dodawanie własnej istniejącej podsieci i tabeli tras. Jeśli podsieć niestandardowa nie zawiera tabeli tras, usługa AKS utworzy dla Ciebie i doda reguły w całym cyklu życia klastra. Jeśli niestandardowa podsieć zawiera tabelę tras podczas tworzenia klastra, usługa AKS potwierdza istniejącą tabelę tras podczas operacji klastra i dodaje/aktualizuje reguły odpowiednio dla operacji dostawcy usług w chmurze.

Ostrzeżenie

Reguły niestandardowe można dodawać/aktualizować w niestandardowej tabeli tras. Jednak reguły są dodawane przez dostawcę chmury Kubernetes, który nie może zostać zaktualizowany ani usunięty. Reguły, takie jak 0.0.0.0/0 , muszą zawsze istnieć w danej tabeli tras i mapować je na cel bramy internetowej, takie jak urządzenie WUS lub inna brama ruchu wychodzącego. Zachowaj ostrożność podczas aktualizowania reguł.

Dowiedz się więcej o konfigurowaniu niestandardowej tabeli tras.

Sieć Kubenet wymaga zorganizowanych reguł tabeli tras w celu pomyślnego kierowania żądań. Ze względu na ten projekt tabele tras muszą być starannie utrzymywane dla każdego klastra, który się na nim opiera. Wiele klastrów nie może współużytkować tabeli tras, ponieważ przepływy CIDR zasobników z różnych klastrów mogą nakładać się, co powoduje nieoczekiwane i uszkodzone scenariusze routingu. Podczas konfigurowania wielu klastrów w tej samej sieci wirtualnej lub przydzielania sieci wirtualnej każdemu klastrowi należy wziąć pod uwagę następujące ograniczenia:

  • Przed utworzeniem klastra usługi AKS należy skojarzyć niestandardową tabelę tras z podsiecią.
  • Po utworzeniu klastra nie można zaktualizować skojarzonego zasobu tabeli tras. Jednak reguły niestandardowe można modyfikować w tabeli tras.
  • Każdy klaster usługi AKS musi używać pojedynczej, unikatowej tabeli tras dla wszystkich podsieci skojarzonych z klastrem. Nie można ponownie użyć tabeli tras z wieloma klastrami ze względu na możliwość nakładania się reguł CIDR zasobników i reguł routingu powodującego konflikt.
  • W przypadku tożsamości zarządzanej przypisanej przez system jest obsługiwana tylko udostępnianie własnej podsieci i tabeli tras za pośrednictwem interfejsu wiersza polecenia platformy Azure, ponieważ interfejs wiersza polecenia platformy Azure automatycznie dodaje przypisanie roli. Jeśli używasz szablonu usługi ARM lub innych klientów, musisz użyć tożsamości zarządzanej przypisanej przez użytkownika, przypisać uprawnienia przed utworzeniem klastra i upewnić się, że tożsamość przypisana przez użytkownika ma uprawnienia zapisu do niestandardowej podsieci i niestandardowej tabeli tras.
  • Używanie tej samej tabeli tras z wieloma klastrami usługi AKS nie jest obsługiwane.

Uwaga

Podczas tworzenia i używania własnej sieci wirtualnej i tabeli tras z wtyczką sieci kubenet należy skonfigurować tożsamość zarządzaną przypisaną przez użytkownika dla klastra. Przy użyciu tożsamości zarządzanej przypisanej przez system nie można pobrać identyfikatora tożsamości przed utworzeniem klastra, co powoduje opóźnienie podczas przypisywania roli.

Tożsamości zarządzane przypisane przez system i przypisane przez użytkownika są obsługiwane podczas tworzenia i używania własnej sieci wirtualnej oraz tabeli tras z wtyczką sieci platformy Azure. Zdecydowanie zalecamy używanie tożsamości zarządzanej przypisanej przez użytkownika na potrzeby scenariuszy BYO.

Dodawanie tabeli tras z tożsamością zarządzaną przypisaną przez użytkownika do klastra usługi AKS

Po utworzeniu niestandardowej tabeli tras i skojarzeniu jej z podsiecią w sieci wirtualnej można utworzyć nowy klaster usługi AKS określający tabelę tras z tożsamością zarządzaną przypisaną przez użytkownika. Musisz użyć identyfikatora podsieci, w którym planujesz wdrożyć klaster usługi AKS. Ta podsieć musi być również skojarzona z niestandardową tabelą tras.

  1. Pobierz identyfikator podsieci przy użyciu az network vnet subnet list polecenia .

    az network vnet subnet list --resource-group myResourceGroup --vnet-name myAKSVnet [--subscription]

  2. Utwórz klaster usługi AKS z niestandardową podsiecią wstępnie skonfigurowaną przy użyciu tabeli tras przy użyciu az aks create polecenia i podając wartości parametrów --vnet-subnet-id i --assign-identity .

    az aks create \
    --resource-group myResourceGroup \
    --name myManagedCluster \
    --vnet-subnet-id mySubnetIDResourceID \
    --assign-identity controlPlaneIdentityResourceID \
    --generate-ssh-keys

Następne kroki

W tym artykule pokazano, jak wdrożyć klaster usługi AKS w istniejącej podsieci sieci wirtualnej. Teraz możesz rozpocząć tworzenie nowych aplikacji przy użyciu programu Helm lub wdrażanie istniejących aplikacji przy użyciu programu Helm.