Pojęcia dotyczące sieci wdrażania węzłów usługi AKS

2025-04-09

Dotyczy: usługa AKS w systemie Windows Server

Można wybrać między dwoma modelami przypisywania adresów IP dla architektury sieci dla usługi AKS w systemie Windows Server. Usługa AKS obsługuje kilka opcji wdrażania dla usługi Azure Kubernetes Service (AKS):

Statyczna sieć IP: sieć wirtualna przydziela statyczne adresy IP do serwera interfejsu API klastra Kubernetes, węzłów Kubernetes, bazowych maszyn wirtualnych, modułów równoważenia obciążenia i wszystkich usług Kubernetes uruchamianych na podstawie klastra.
Sieć DHCP: sieć wirtualna przydziela dynamiczne adresy IP węzłom Kubernetes, podstawowym maszynom wirtualnym i modułom równoważenia obciążenia przy użyciu serwera DHCP. Serwer interfejsu API klastra Kubernetes i wszystkie usługi Kubernetes uruchamiane w klastrze są nadal przydzielane statyczne adresy IP.

Uwaga

Architektura sieci wirtualnej zdefiniowana w tym miejscu dla usługi AKS Arc może różnić się od podstawowej architektury sieci fizycznej w centrum danych.

Pula wirtualnych adresów IP

Pula wirtualnych adresów IP (VIP) jest zestawem adresów IP, które są obowiązkowe dla dowolnego wdrożenia w usłudze AKS Arc. Pula adresów VIP to zakres zarezerwowanych adresów IP używanych do przydzielania adresów IP do serwera interfejsu API klastra Kubernetes. Gwarantuje to, że aplikacje w usługach Kubernetes są zawsze dostępne. Należy pamiętać, że niezależnie od modelu sieci wirtualnej i wybranego modelu przypisywania adresów należy podać pulę adresów VIP dla wdrożenia hosta usługi AKS.

Liczba adresów IP w puli adresów VIP zależy od liczby klastrów obciążeń i usług Kubernetes planowanych do wdrożenia.

W zależności od modelu sieci definicja puli adresów VIP różni się w następujący sposób:

Statyczny adres IP: jeśli używasz statycznego adresu IP, upewnij się, że wirtualne adresy IP pochodzą z tej samej podsieci.
DHCP: jeśli sieć jest skonfigurowana przy użyciu protokołu DHCP, skontaktuj się z administratorem sieci, aby wykluczyć zakres adresów IP puli adresów VIP z zakresu DHCP używanego do wdrożenia usługi AKS.

Pula adresów IP VM węzła Kubernetes

Węzły kubernetes są wdrażane jako wyspecjalizowane maszyny wirtualne w usłudze AKS Arc. Usługa AKS przydziela adresy IP tym maszynom wirtualnym w celu umożliwienia komunikacji między węzłami platformy Kubernetes.

Statyczny adres IP: należy określić zakres puli adresów IP maszyny wirtualnej węzła Kubernetes. Liczba adresów IP w tym zakresie zależy od łącznej liczby węzłów Kubernetes, które planujesz użyć do wdrożenia w klastrach Kubernetes na hoście AKS oraz w klastrach obciążenia. Należy pamiętać, że aktualizacje zużywają jeden do trzech dodatkowych adresów IP podczas aktualizacji.
DHCP: nie musisz określać puli maszyn wirtualnych węzłów Kubernetes, ponieważ adresy IP węzłów Kubernetes są dynamicznie przydzielane przez serwer DHCP w sieci.

Sieć wirtualna ze statyczną siecią IP (zalecana)

Ten model sieci tworzy sieć wirtualną, która przydziela adresy IP ze statycznie zdefiniowanej puli adresów do wszystkich obiektów we wdrożeniu. Dodatkową korzyścią korzystania z statycznych sieci IP jest to, że długotrwałe wdrożenia i obciążenia aplikacji są zawsze gwarantowane jako dostępne.

Określ następujące parametry podczas definiowania sieci wirtualnej ze statycznymi konfiguracjami adresów IP:

Ważne

Ta wersja usługi AKS nie zezwala na żadne zmiany konfiguracji sieci po wdrożeniu hosta usługi AKS lub klastra obciążenia. Aby zmienić ustawienia sieci, należy zacząć od nowa, usuwając klastry obciążeń i odinstalowując usługę AKS.

Nazwa: nazwa sieci wirtualnej.
Prefiks adresu: prefiks adresu IP używany dla podsieci.
Brama: adres IP bramy domyślnej dla podsieci.
Serwer DNS: tablica adresów IP wskazująca serwery DNS, które mają być używane dla podsieci. Można podać co najmniej jeden i maksymalnie trzy serwery.
Pula VM węzłów Kubernetes: ciągły zakres adresów IP do wykorzystania dla maszyn wirtualnych węzłów Kubernetes.
Pula wirtualnych adresów IP: ciągły zakres adresów IP używanych dla serwera interfejsu API klastra Kubernetes i usług Kubernetes.

Uwaga

Pula VIP musi być częścią tej samej podsieci co pula maszyn wirtualnych węzłów Kubernetes.
Identyfikator sieci vLAN: identyfikator sieci vLAN dla sieci wirtualnej. Jeśli zostanie pominięta, sieć wirtualna nie zostanie otagowana.

Sieć wirtualna z siecią DHCP

Ten model sieci tworzy sieć wirtualną, która przydziela adresy IP przy użyciu protokołu DHCP do wszystkich obiektów we wdrożeniu.

Podczas definiowania sieci wirtualnej ze statycznymi konfiguracjami adresów IP należy określić następujące parametry:

Nazwa: nazwa sieci wirtualnej.
Pula wirtualnych adresów IP: ciągły zakres adresów IP używanych dla serwera interfejsu API klastra Kubernetes i usług Kubernetes.

Uwaga

Adresy puli adresów VIP muszą znajdować się w tej samej podsieci co zakres DHCP i muszą zostać wykluczone z zakresu DHCP, aby uniknąć konfliktów adresów.
Identyfikator sieci vLAN: identyfikator sieci vLAN dla sieci wirtualnej. W przypadku pominięcia sieć wirtualna nie zostanie otagowana.

Lokalna usługa w chmurze firmy Microsoft

Microsoft On-premises Cloud (MOC) to stos zarządzania, który umożliwia zarządzanie maszynami wirtualnymi w centrum DANYCH SDDC opartym na systemie Windows Server w chmurze. MOC składa się z:

Pojedyncze wystąpienie wysoko dostępnej usługi cloud agent wdrożonej w klastrze. Ten agent działa w dowolnym węźle w klastrze systemu Windows Server i jest skonfigurowany do przełączania w tryb failover do innego węzła.
Uruchamiana node agent na każdym węźle fizycznym.

Aby umożliwić komunikację z MOC, należy podać adres IP CIDR, który będzie używany dla usługi. -cloudserviceCIDR jest parametrem w poleceniu Set-AksHciConfig, używanym do przypisywania adresu IP dla usługi agenta w chmurze oraz umożliwiającym wysoką dostępność tej usługi.

Wybór adresu IP usługi MOC zależy od bazowego modelu sieci używanego przez wdrożenie klastra w systemie Windows Server.

Uwaga

Alokacja adresów IP dla usługi MOC jest niezależna od modelu sieci wirtualnej Kubernetes. Alokacja adresów IP zależy od podstawowej sieci fizycznej oraz od skonfigurowania adresów IP dla węzłów klastra Windows Server w centrum danych.

Węzły klastra systemu Windows Server z trybem alokacji adresu IP opartego na protokole DHCP: Jeśli węzły klastra są przypisane adres IP z serwera DHCP obecnego w sieci fizycznej, nie musisz jawnie podawać adresu IP do usługi MOC, ponieważ usługa MOC otrzymuje również adres IP z serwera DHCP.
Węzły klastra systemu Windows Server ze statycznym modelem alokacji adresów IP: jeśli węzły klastra mają przypisane statyczne adresy IP, należy jawnie podać adres IP dla usługi w chmurze MOC. Adres IP usługi MOC musi znajdować się w tej samej podsieci co adresy IP węzłów klastra systemu Windows Server. Aby jawnie przypisać adres IP dla usługi MOC, użyj parametru -cloudserviceCIDR w poleceniu Set-AksHciConfig . Upewnij się, że w formacie CIDR wprowadzono adres IP, na przykład: 10.11.23.45/16.

Porównanie modeli sieciowych

Zarówno protokół DHCP, jak i statyczny adres IP zapewniają łączność sieciową w ramach wdrożenia Azure Kubernetes Service (AKS) na systemie Windows Server. Jednak istnieją zalety i wady każdej z nich. Na wysokim poziomie mają zastosowanie następujące zagadnienia:

DHCP — nie gwarantuje długotrwałych adresów IP dla niektórych typów zasobów we wdrożeniu usługi AKS. — Obsługuje rozszerzanie zarezerwowanych adresów IP DHCP, jeśli wdrożenie jest większe niż początkowo oczekiwano.

Statyczny adres IP — gwarantuje długotrwałe adresy IP dla wszystkich zasobów we wdrożeniu usługi AKS. — Ponieważ automatyczne rozszerzanie puli adresów IP węzłów Kubernetes nie jest obsługiwane, tworzenie nowych klastrów może nie być możliwe, jeśli wyczerpano pulę adresów IP węzłów Kubernetes.

W poniższej tabeli porównaliśmy alokację adresów IP dla zasobów między statycznymi modelami sieci IP i DHCP:

Możliwość	Statyczny adres IP	DHCP
Serwer interfejsu API klastra Kubernetes	Przypisano statycznie przy użyciu puli VIP.	Przypisano statycznie przy użyciu puli VIP.
Węzły kubernetes (na maszynach wirtualnych)	Przypisano przy użyciu puli adresów IP węzła platformy Kubernetes.	Przypisywane dynamicznie.
Usługi Kubernetes	Przypisano statycznie przy użyciu puli VIP.	Przypisano statycznie przy użyciu puli VIP.
Maszyna wirtualna HAProxy do równoważenia obciążenia	Przypisano przy użyciu puli adresów IP węzła platformy Kubernetes.	Przypisywane dynamicznie.
Lokalna usługa chmurowa na miejscu firmy Microsoft	Zależy od konfiguracji sieci fizycznej dla węzłów klastra systemu Windows Server.	Zależy od konfiguracji sieci fizycznej dla węzłów klastra systemu Windows Server.
Basen VIP	Obowiązkowy	Obowiązkowy
Pula adresów IP VM węzła Kubernetes	Obowiązkowy	Niewspierane

Minimalne rezerwacje adresów IP dla wdrożenia usługi AKS

Niezależnie od modelu wdrażania liczba zarezerwowanych adresów IP pozostaje taka sama. W tej sekcji opisano liczbę adresów IP, które należy zarezerwować na podstawie modelu wdrażania usługi AKS Arc.

Minimalna rezerwacja adresu IP

Co najmniej należy zarezerwować następującą liczbę adresów IP dla wdrożenia:

Typ klastra	Węzeł płaszczyzny sterowania	Węzeł procesu roboczego	W przypadku operacji aktualizacji	Moduł równoważenia obciążenia
Host usługi AKS	Jeden adres IP	N/A	Dwa adresy IP	N/A
Klaster obciążeń	Jeden adres IP na węzeł	Jeden adres IP na węzeł	5 adresów IP	Jeden adres IP

Należy również zarezerwować następującą liczbę adresów IP dla puli adresów VIP:

Typ zasobu	Liczba adresów IP
Serwer interfejsu API klastra	1 na klaster
Usługi Kubernetes	1 na usługę
Usługi aplikacji	1 na zaplanowaną usługę

Jak widać, liczba wymaganych adresów IP jest zmienna w zależności od architektury wdrożenia usługi AKS oraz liczby usług uruchamianych w klastrze Kubernetes. Zalecamy zarezerwowanie co najmniej 256 adresów IP (/24 podsieci) dla wdrożenia.

Przewodnik po przykładowym wdrożeniu

Jane jest administratorem IT, która dopiero zaczyna pracę z usługą AKS na Windows Server. Chce wdrożyć dwa klastry Kubernetes: klaster Kubernetes A i klaster Kubernetes B w klastrze systemu Windows Server. Chce również uruchomić aplikację do głosowania na szczycie klastra. Ta aplikacja ma trzy wystąpienia interfejsu użytkownika front-end uruchomionymi w dwóch klastrach i jedno wystąpienie bazy danych backend.

Klaster Kubernetes A ma 3 węzły płaszczyzny sterowania i 5 węzłów roboczych.
Klaster Kubernetes B ma 1 węzeł płaszczyzny sterowania i 3 węzły robocze.
3 instancje interfejsu użytkownika front-end (port 443).
1 wystąpienie bazy danych zaplecza (port 80).

Na podstawie poprzedniej tabeli musi ona zarezerwować:

3 adresy IP hosta usługi AKS (jeden adres IP dla węzła płaszczyzny sterowania i dwa adresy IP na potrzeby uruchamiania operacji aktualizacji).
3 adresy IP węzłów płaszczyzny sterowania w klastrze A (jeden adres IP na węzeł płaszczyzny sterowania).
5 adresów IP węzłów procesu roboczego w klastrze A (jeden adres IP na węzeł procesu roboczego).
6 adresów IP dodatkowo dla klastra A (pięć adresów IP na potrzeby uruchamiania operacji aktualizacji i 1 adres IP dla modułu równoważenia obciążenia).
1 adresy IP węzłów płaszczyzny sterowania w klastrze B (jeden adres IP na węzeł płaszczyzny sterowania).
3 adresy IP węzłów procesu roboczego w klastrze B (jeden adres IP na węzeł procesu roboczego).
6 adresów IP dodatkowo dla klastra B (pięć adresów IP na potrzeby uruchamiania operacji aktualizacji i 1 adres IP dla modułu równoważenia obciążenia).
2 adresy IP dla serwerów interfejsu API klastra Kubernetes (jeden adres IP dla klastra Kubernetes).
3 adresy IP usługi Kubernetes (jeden adres IP na wystąpienie interfejsu użytkownika frontonu, ponieważ wszystkie używają tego samego portu. Baza danych zaplecza może używać dowolnego z trzech adresów IP, o ile będzie używać innego portu).

Jak wyjaśniono wcześniej, jane wymaga łącznie 32 adresów IP do wdrożenia klastra. W związku z tym Jane powinna zarezerwować podsieć /26 dla jej sieci wirtualnej.

Dzielenie zarezerwowanych adresów IP na podstawie modelu statycznej sieci IP

Chociaż łączna liczba zarezerwowanych adresów IP pozostaje taka sama, model wdrażania określa sposób dzielenia tych adresów IP między grupy adresów IP. Model statycznej sieci IP ma dwie pule adresów IP:

Pula adresów IP maszyny wirtualnej węzła Kubernetes: dla maszyn wirtualnych węzłów Kubernetes i maszyny wirtualnej równoważnika obciążenia. Ta pula adresów IP zawiera również adres IP wymagany do uruchamiania operacji aktualizacji.
Pula wirtualnych adresów IP: dla serwera interfejsu API Kubernetes i usług Kubernetes.

W tym przykładzie Jane musi dodatkowo podzielić te adresy IP między pule adresów VIP i pule adresów IP węzłów Kubernetes.

5 (dwa dla serwera API klastra Kubernetes, i trzy dla usług Kubernetes) z 32 adresów IP dla jej puli adresów VIP.
27 (wszystkie adresy IP węzłów platformy Kubernetes, podstawowych maszyn wirtualnych, maszyn wirtualnych równoważnika obciążenia i operacje aktualizacji) dla puli adresów IP węzłów platformy Kubernetes.

Dzielenie zarezerwowanych adresów IP na podstawie modelu sieci DHCP

Chociaż łączna liczba zarezerwowanych adresów IP pozostaje taka sama, model wdrażania określa, w jaki sposób te adresy IP są podzielone między grupy adresów IP. Zgodnie z opisem w poprzedniej sekcji model sieci DHCP ma jeden zakres adresów IP:

Pula wirtualnych adresów IP: dla serwera interfejsu API Kubernetes i usług Kubernetes

Praca z poprzednim przykładem:

Jane musi zarezerwować łącznie 32 adresy IP lub podsieć /26 na serwerze DHCP.
Musi wykluczyć 5 adresów IP (dwa dla serwera interfejsu API klastra Kubernetes i trzy dla usług Kubernetes) z zakresu 32 adresów IP DHCP dla jej puli VIP.

Kontrolery ruchu przychodzącego

Podczas wdrażania klastra HAProxydocelowego tworzony jest zasób modułu równoważenia obciążenia. Moduł równoważenia obciążenia jest skonfigurowany do dystrybucji ruchu do podów w usłudze na danym porcie. Moduł równoważenia obciążenia działa tylko w warstwie 4, co oznacza, że usługa nie zna rzeczywistej aplikacji; tzn. nie może podejmować żadnych dodatkowych zagadnień dotyczących routingu.

Kontrolery Ingress działają w warstwie 7 i mogą używać bardziej inteligentnych reguł do dystrybucji ruchu aplikacyjnego. Typowym zastosowaniem kontrolera ruchu przychodzącego jest kierowanie ruchu HTTP do różnych aplikacji na podstawie przychodzącego adresu URL.

Następne kroki

W tym artykule opisano niektóre pojęcia dotyczące sieci wdrażania węzłów usługi AKS w systemie Windows Server. Aby uzyskać więcej informacji, zobacz następujące artykuły: