Wdrażanie klastra Kubernetes w niestandardowej sieci wirtualnej w usłudze Azure Stack Hub

Artykuł
01/23/2025

Klaster Kubernetes można wdrożyć przy użyciu aparatu usługi Azure Kubernetes Service (AKS) w niestandardowej sieci wirtualnej. W tym artykule opisano sposób znajdowania potrzebnych informacji w sieci wirtualnej. Artykuł zawiera kroki dotyczące obliczania adresów IP używanych przez klaster, ustawianie wartości w modelu interfejsu API oraz ustawianie tabeli tras i grupy zabezpieczeń sieci.

Klaster Kubernetes w Azure Stack Hub z wykorzystaniem silnika AKS korzysta z wtyczki sieciowej kubenet. Silnik AKS na platformie Azure Stack Hub obsługuje również wtyczkę sieciową Azure CNI.

Aby zapoznać się z omówieniem wtyczki sieci kubenet na platformie Azure, zobacz Używanie sieci kubenet z własnymi zakresami adresów IP w usłudze Azure Kubernetes Service (AKS).
Aby zapoznać się z omówieniem wtyczki sieci azure CNI na platformie Azure, zobacz Konfigurowanie sieci CNI platformy Azure w usłudze Azure Kubernetes Service (AKS).

Zagadnienia dotyczące tworzenia niestandardowej sieci wirtualnej

Niestandardowa sieć wirtualna musi znajdować się w tej samej subskrypcji co wszystkie inne składniki klastra Kubernetes.
Pula węzłów płaszczyzny sterowania i pula węzłów agenta muszą znajdować się w tej samej sieci wirtualnej. Węzły można wdrożyć w różnych podsieciach w tej samej sieci wirtualnej.
Podsieć klastra Kubernetes musi korzystać z zakresu adresów IP, który znajduje się w zakresie adresów IP niestandardowej sieci wirtualnej. Zobacz Pobierz blok adresów IP.
Należy wziąć pod uwagę, że zalecany rozmiar podsieci węzłów zależy od typu używanej wtyczki sieciowej. Ogólnie rzecz biorąc, usługa Azure CNI wymaga większej liczby adresów IP dla podsieci obsługującej pule węzłów agenta niż kubenet. Zobacz następujące przykłady kubenet i Azure CNI.
Przestrzeni adresowej 169.254.0.0/16 nie można używać w przypadku niestandardowych sieci wirtualnych dla klastrów Kubernetes.

Tworzenie niestandardowej sieci wirtualnej

Musisz mieć niestandardową sieć wirtualną w wystąpieniu usługi Azure Stack Hub. Aby uzyskać więcej informacji, zobacz Szybki start: tworzenie sieci wirtualnej przy użyciu witryny Azure Portal.

Utwórz nową podsieć w sieci wirtualnej. Podczas wdrażania klastra musisz uzyskać identyfikator zasobu podsieci i zakres adresów IP, który jest używany w modelu interfejsu API:

Otwórz portal użytkowników usługi Azure Stack Hub w wystąpieniu usługi Azure Stack Hub.
Wybierz pozycję Wszystkie zasoby.
Wprowadź nazwę sieci wirtualnej w polu wyszukiwania.
Wybierz pozycję Podsieci+ Podsieci, aby dodać podsieć>.
Dodaj nazwę i zakres adresów przy użyciu notacji CIDR. Wybierz przycisk OK.
Wybierz pozycję Właściwości w bloku Sieci wirtualne. Skopiuj identyfikator zasobu, a następnie dodaj element /subnets/<nameofyoursubnect>. Używasz tej wartości jako wartości dla klucza vnetSubnetId w modelu API dla swojego klastra. Identyfikator zasobu dla podsieci używa następującego formatu: /subscriptions/SUB_ID/resourceGroups/RG_NAME/providers/Microsoft.Network/virtualNetworks/VNET_NAME/subnets/SUBNET_NAME.
Wybierz pozycję Podsieci w bloku Sieci wirtualne. Wybierz nazwę podsieci, na przykład control-plane-sn. Nie kojarzyj podsieci z sieciową grupą zabezpieczeń.
W bloku podsieci zanotuj zakres adresów (BLOK CIDR) każdej podsieci.

Zagadnienia dotyczące wybierania przestrzeni adresowej

Podczas tworzenia niestandardowej sieci wirtualnej należy określić przestrzeń adresów IP sieci i zakres adresów IP dla każdej podsieci. Podczas wybierania przestrzeni adresowych i zakresów do użycia w klastrze Kubernetes należy wziąć pod uwagę następujące czynniki:

Nakładające się przestrzenie adresowe mogą powodować konflikty adresów IP lub błędy komunikacji. Aby zmniejszyć ryzyko nakładania się adresów IP, wybierz unikatową przestrzeń adresową dla nowej sieci wirtualnej.
Przestrzenie adresowe w 10/8zakresach , 172.16/12i 192.168/16 często są używane dla sieci prywatnych i mogą być używane przez istniejącą infrastrukturę centrum danych. Jeśli aplikacje Kubernetes używają zasobów w centrum danych, zmniejsz ryzyko starć, wybierając przestrzeń adresową dla niestandardowej sieci wirtualnej, która różni się od przestrzeni adresowej centrum danych.
Zalecamy użycie dedykowanej podsieci dla klastra Kubernetes.
Jeśli używasz wielu istniejących sieci wirtualnych, rozważ użycie różnych przestrzeni adresowych w każdej sieci, jeśli zamierzasz używać peeringu sieci wirtualnych. Nakładające się przestrzenie adresowe mogą osłabić zdolność do włączania peeringu.

Pobieranie bloków adresów IP

Aparat AKS obsługuje wdrażanie w istniejącej sieci wirtualnej. Po wdrożeniu w istniejącej sieci wirtualnej klaster używa bloków kolejnych adresów dla węzłów agenta, węzłów płaszczyzny sterowania, usług klastra i kontenerów (zasobników). Każdy blok adresów można przetłumaczyć na podsieć w sieci wirtualnej. Wszystkie bloki adresów we wdrożeniu klastra muszą być częścią ogólnej przestrzeni adresowej sieci wirtualnej. Wybranie bloków adresów spoza przestrzeni adresowej sieci wirtualnej może spowodować problemy z łącznością.

Podczas konfigurowania klastra Kubernetes wymagane jest co najmniej trzy bloki adresów:

Blok adresów węzłów: blok adresu używany do przypisywania adresów do węzłów klastra. Ta wartość może być pojedynczym blokiem adresów dla wszystkich węzłów klastra lub może być oddzielnymi blokami (podsieciami) dla warstwy kontrolnej i grup agentów. Podczas wybierania zakresu adresów dla tego bloku należy wziąć pod uwagę liczbę węzłów w klastrze. W przypadku sieci CNI platformy Azure węzły i kontenery pobierają swoje adresy z tego samego bloku adresów, dlatego uwzględniają liczbę kontenerów, które mają zostać wdrożone w klastrze podczas wybierania zakresu adresów podczas korzystania z usługi Azure CNI.
Blok adresów usług: blok adresu, z którego usługi wdrożone w klastrze Kubernetes uzyskują adres klastra. Podczas wybierania zakresu adresów dla tego bloku należy wziąć pod uwagę maksymalną liczbę usług, które mają być uruchamiane w klastrze.
Blok adresów klastra: blok adresu, z którego zasobniki uzyskują adres klastra. Podczas wybierania zakresu adresów dla tego bloku należy wziąć pod uwagę maksymalną liczbę zasobników, które mają być uruchamiane w klastrze. Jak wspomniano wcześniej, w przypadku usługi Azure CNI bloki adresów klastra i węzłów są takie same.

Oprócz bloków adresów w przypadku węzłów płaszczyzny sterowania należy ustawić jeszcze dwie wartości. Musisz znać liczbę adresów IP, które mają być zarezerwowane dla klastra, oraz pierwszy kolejny statyczny adres IP w przestrzeni IP podsieci. Aparat AKS wymaga zakresu do 16 nieużywanych adresów IP w przypadku korzystania z wielu węzłów płaszczyzny sterowania. Klaster używa jednego adresu IP dla każdej płaszczyzny sterowania do maksymalnie pięciu węzłów płaszczyzny sterowania. Aparat usługi AKS wymaga również kolejnego 10 adresu IP po ostatnim węźle płaszczyzny sterowania dla rezerwacji adresów IP przestrzeni nad głową. Na koniec inny adres IP jest używany przez system równoważenia obciążenia po węzłach płaszczyzny sterowania i rezerwacji zapasu, co daje łącznie 16 adresów IP. Podczas umieszczenia bloku adresów IP podsieć wymaga następujących alokacji istniejących adresów IP:

Pierwsze cztery adresy IP i ostatni adres IP są zarezerwowane i nie można ich używać w żadnej podsieci platformy Azure.
Bufor 16 adresów IP powinien pozostać otwarty.
Wartość pierwszego adresu IP klastra powinna znajdować się na końcu przestrzeni adresowej, aby uniknąć konfliktów adresów IP. Jeśli to możliwe, przypisz firstConsecutiveStaticIP właściwość do adresu IP pod koniec dostępnej przestrzeni adresowej IP w podsieci.

Na przykład w przypadku klastra z trzema węzłami płaszczyzny sterowania, jeśli używasz podsieci z adresami 256, na przykład 10.100.0.0/24, musisz ustawić pierwszy kolejny statyczny adres IP przed 239. W poniższej tabeli przedstawiono adresy i zagadnienia:

Zakres dla podsieci /24	Liczba	Uwaga
172.100.0.0 - 172.100.0.3	100	Zarezerwowane w podsieci platformy Azure.
172.100.0.224-172.100.0.238	14	Liczba adresów IP dla klastra zdefiniowanego przez aparat usługi AKS. 3 adresy IP dla 3 węzłów płaszczyzny sterowania 10 adresów IP dla miejsca pracy 1 adres IP modułu równoważenia obciążenia
172.100.0.238 - 172.100.0.254	16	16 Bufor adresów IP.
172.100.0.255	1	Zarezerwowane w podsieci platformy Azure.

W tym przykładzie właściwość firstConsecutiveStaticIP jest 172.100.0.224.

W przypadku większych podsieci, na przykład /16 z ponad 60 tysiącami adresów, może być niepraktyczne przypisywanie statycznych adresów IP na końcu przestrzeni sieciowej. Ustaw zakres statycznych adresów IP klastra z dala od pierwszych 24 adresów w przestrzeni adresów IP, aby klaster mógł być odporny podczas oświadczeń adresów.

Przykład bloków adresów kubenet

W poniższym przykładzie można zobaczyć, jak te różne zagadnienia wypełniają przestrzeń adresową w sieci wirtualnej dla klastra przy użyciu wtyczki sieci kubenet z dedykowanymi podsieciami dla węzła płaszczyzny sterowania i pul węzłów agenta z trzema węzłami na pulę.

Przestrzeń adresowa sieci wirtualnej: 10.100.0.0/16.

Blok adresowy (podsieć)	CIDR	Zakres adresów IP	Liczba adresów IP (dostępna)
Blok węzłów płaszczyzny sterowania	10.100.0.0/24	10.100.0.0 - 10.100.0.255	255 – 4 zarezerwowane = 251
Blok węzłów agenta	10.100.1.0/24	10.100.1.0 - 10.100.1.255	255 – 4 zarezerwowane = 251
Blok usług	10.100.16.0/20	10.100.16.0 - 10.100.31.255	4096 – 5 zarezerwowane = 4091
Blok klastra	10.100.128.0/17	10.100.128.0 - 10.100.255.255	32 768 – 5 zarezerwowanych = 32 763

W tym przykładzie właściwość firstConsecutiveStaticIP jest 10.100.0.239.

Przykład bloków adresów CNI platformy Azure

W poniższym przykładzie można zobaczyć, jak te różne zagadnienia wypełniają przestrzeń adresową w sieci wirtualnej dla klastra przy użyciu wtyczki sieci Azure CNI z dedykowanymi podsieciami dla płaszczyzny sterowania i pul węzłów agenta z trzema węzłami na pulę.

Przestrzeń adresowa sieci wirtualnej: 172.24.0.0/16.

Uwaga

Jeśli w twoim środowisku zakres publicznych adresów IP znajduje się w ciągu CIDR10.0.0.0/8, użyj rozwiązania kubenet jako wtyczki sieciowej.

Blok adresowy (podsieć)	CIDR	Zakres adresów IP	Liczba adresów IP (dostępna)
Blok węzłów płaszczyzny sterowania	172.24.0.0/24	172.24.0.0 - 172.24.0.255	255 – 4 zarezerwowane = 251
Węzły agentów i blok klastra	172.24.128.0/17	172.24.128.0 - 172.24.255.255	32 768 – 5 zarezerwowanych = 32 763
Blok usług	172.24.16.0/20	172.24.16.0 - 172.24.31.255	4096 – 5 zarezerwowane = 4091

W tym przykładzie firstConsecutiveStaticIP właściwość to 172.24.0.239.

Aktualizowanie modelu interfejsu API

Zaktualizuj model interfejsu API używany do wdrażania klastra z aparatu AKS w niestandardowej sieci wirtualnej.

W masterProfileustaw następujące wartości:

Pole	Przykład	opis
vnetSubnetId	`/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MDBN-K8S/providers/Microsoft.Network/virtualNetworks/MDBN-K8S/subnets/control-plane-sn`	Określ identyfikator ścieżki usługi Azure Resource Manager podsieci. Ta wartość mapuje blok adresowy węzłów płaszczyzny sterowania.
firstConsecutiveStaticIP	10.100.0.239	Przypisz do właściwości konfiguracji adres IP zbliżony do `firstConsecutiveStaticIP` końca dostępnej przestrzeni adresowej IP w żądanej podsieci. `firstConsecutiveStaticIP` dotyczy tylko puli węzłów płaszczyzny sterowania.

W obszarze agentPoolProfile ustaw następujące wartości:

Pole	Przykład	opis
vnetSubnetId	`/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MDBN-K8S/providers/Microsoft.Network/virtualNetworks/MDBN-K8S/subnets/agents-sn`	Określ identyfikator ścieżki usługi Azure Resource Manager podsieci. Ta wartość odpowiada blokowi adresów węzłów agenta.

W pliku orchestratorProfile znajdź polecenie kubernetesConfig i ustaw następującą wartość:

Pole	Przykład	opis
clusterSubnet	`10.100.128.0/17`	Podsieć IP używana do przydzielania adresów IP dla interfejsów sieciowych zasobnika. Ta wartość odpowiada blokowi adresowemu klastra. Podsieć musi znajdować się w przestrzeni adresowej sieci wirtualnej. Po włączeniu usługi Azure CNI wartość domyślna to 10.240.0.0/12. Bez usługi Azure CNI wartość domyślna to 10.244.0.0/16. Użyj /16 zamiast /24 podsieci. Jeśli używasz /24, ta podsieć jest przypisana tylko do jednego węzła. Drugi węzeł nie otrzymuje przypisanej sieci POD, ponieważ wyczerpano przestrzeń adresów IP, więc nie jest gotowy w klastrze.
serviceCidr	`10.100.16.0/20`	Podsieć IP używana do przydzielania adresów IP dla usług wdrożonych w klastrze. Ta wartość odpowiada blokowi usług klastra.
dnsServiceIP	`10.100.16.10`	Adres IP, który ma zostać przypisany do usługi DNS klastra. Adres musi pochodzić z podsieci serviceCidr. Tę wartość należy ustawić podczas określania wartości serviceCidr. Wartość domyślna to adres 10 podsieci serviceCidr.

Jeśli na przykład używasz rozwiązania kubenet:
Z przestrzenią adresową sieciową10.100.0.0/16, w której znajduje się podsieć control-plane-sn i jest 10.100.0.0/24agents-sn10.100.1.0/24

"masterProfile": {
  ...
  "vnetSubnetId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MDBN-K8S/providers/Microsoft.Network/virtualNetworks/MDBN-K8S/subnets/control-plane-sn",
  "firstConsecutiveStaticIP": "10.100.0.239",
  ...
},
...
"agentPoolProfiles": [
  {
    ...
    "vnetSubnetId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MDBN-K8S/providers/Microsoft.Network/virtualNetworks/MDBN-K8S/subnets/agents-sn",
    ...
  },
    ...
"kubernetesConfig": [
  {
    ...
    "clusterSubnet": "10.100.128.0/17",
    "serviceCidr": "10.100.16.0/20",
    "dnsServiceIP" : "10.100.16.10",

    ...
  },

Jeśli na przykład używasz usługi Azure CNI z sieciową przestrzenią adresową 172.24.0.0/16, w której podsieć dla control-plane-sn jest 172.24.0.0/24, a k8s-sn jest 172.24.128.0/17:

"masterProfile": {
  ...
  "vnetSubnetId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MDBN-K8S/providers/Microsoft.Network/virtualNetworks/MDBN-K8S/subnets/control-plane-sn",
  "firstConsecutiveStaticIP": "172.24.0.239",
  ...
},
...
"agentPoolProfiles": [
  {
    ...
    "vnetSubnetId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MDBN-K8S/providers/Microsoft.Network/virtualNetworks/MDBN-K8S/subnets/k8s-sn",
    ...
  },
    ...
"kubernetesConfig": [
  {
    ...
    "clusterSubnet": "172.24.128.0/17",
    "serviceCidr": "172.24.16.0/20",
    "dnsServiceIP" : "172.24.16.10",
    ...
  },

Wdrażanie klastra

Po dodaniu wartości do modelu interfejsu API, klaster można wdrożyć z maszyny klienckiej przy użyciu polecenia deploy w AKS Engine. Aby uzyskać instrukcje, zobacz Wdrażanie klastra Kubernetes.

Ustawianie tabeli tras

Jeśli używasz rozwiązania kubenet, na przykład networkPlugin: kubenet w obiekcie konfiguracji modelu interfejsu kubernetesConfig API. Po wdrożeniu klastra wróć do sieci wirtualnej w portalu użytkowników usługi Azure Stack. Ustaw zarówno tabelę tras, jak i sieciową grupę zabezpieczeń w bloku podsieci. Po pomyślnym wdrożeniu klastra w niestandardowej sieci wirtualnej pobierz identyfikator zasobu tabeli tras z bloku Network w grupie zasobów klastra.

Otwórz portal użytkowników usługi Azure Stack Hub w wystąpieniu usługi Azure Stack Hub.
Wybierz pozycję Wszystkie zasoby.
Wprowadź nazwę sieci wirtualnej w polu wyszukiwania.
Wybierz pozycję Podsieci, a następnie wybierz nazwę podsieci zawierającej klaster.
Wybierz pozycję Tabela tras, a następnie wybierz tabelę tras dla klastra.
Upewnij się, że jest to wykonywane dla każdej podsieci określonej w modelu interfejsu API, w tym podsieci masterProfile .