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

Artykuł
02/23/2024

Dotyczy: usługa AKS w usłudze Azure Stack HCI 22H2, AKS w systemie Windows Server

Można wybrać między dwoma modelami przypisywania adresów IP dla architektury sieci dla usługi AKS włączonej przez usługę Azure Arc. Usługa AKS obsługuje kilka opcji wdrażania dla 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 do węzłów Kubernetes, podstawowych maszyn wirtualnych i modułów 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 tutaj 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 osiągalne. Należy pamiętać, że niezależnie od wybranego modelu sieci wirtualnej i wybranego modelu przypisania 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 w usłudze Azure Stack HCI.

Pula adresów IP maszyny wirtualnej 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 do tych maszyn wirtualnych, aby umożliwić komunikację między węzłami platformy Kubernetes.

Statyczny adres IP: musisz określić zakres puli adresów IP maszyny wirtualnej węzła Kubernetes. Liczba adresów IP w tym zakresie zależy od całkowitej liczby węzłów Kubernetes, których planujesz użyć do wdrożenia na hoście usługi AKS i w klastrach Kubernetes obciążenia. Należy pamiętać, że aktualizacje używają jednego 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ą zaletą korzystania z sieci statycznych adresów IP jest to, że długotrwałe wdrożenia i obciążenia aplikacji są zawsze osiągalne.

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 do użycia dla podsieci.
Brama: adres IP bramy domyślnej dla podsieci.
Serwer DNS: tablica adresów IP wskazująca serwery DNS do użycia dla podsieci. Można podać co najmniej jeden i maksymalnie trzy serwery.
Pula maszyn wirtualnych węzłów Kubernetes: ciągły zakres adresów IP używanych 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 adresów VIP musi być częścią tej samej podsieci co pula maszyn wirtualnych węzła Kubernetes.
Identyfikator sieci vLAN: identyfikator sieci vLAN dla sieci wirtualnej. W przypadku pominięcia sieć wirtualna nie zostanie oznaczona.

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:

Ważne

W tej wersji usługi AKS nie można zmienić konfiguracji sieci po wdrożeniu hosta usługi AKS lub klastra obciążenia. Jedynym sposobem zmiany ustawień sieci jest rozpoczęcie od nowa przez usunięcie klastrów obciążeń i odinstalowanie usługi AKS.

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ą być 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 oznaczona.

Lokalna usługa w chmurze firmy Microsoft

Chmura lokalna firmy Microsoft (MOC) to stos zarządzania, który umożliwia zarządzanie maszynami wirtualnymi w usłudze Azure Stack HCI i centrum SDDC opartym na systemie Windows Server w chmurze. MOC składa się z:

Pojedyncze wystąpienie usługi o wysokiej dostępności cloud agent wdrożone w klastrze. Ten agent działa w dowolnym węźle w klastrze usługi Azure Stack HCI lub Windows Server i jest skonfigurowany do przełączania w tryb failover do innego węzła.
Uruchomione node agent w każdym węźle fizycznym usługi Azure Stack HCI.

Aby włączyć komunikację z moc, należy podać adres IP CIDR, który ma być używany dla usługi. Jest -cloudserviceCIDR to parametr w Set-AksHciConfig poleceniu używanym do przypisywania adresu IP do usługi agenta w chmurze i włączania wysokiej dostępności usługi agenta w chmurze.

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

Uwaga

Alokacja adresów IP dla usługi MOC jest niezależna od modelu sieci wirtualnej Kubernetes. Alokacja adresu IP jest zależna od podstawowej sieci fizycznej, a adresy IP skonfigurowane dla węzłów klastra usługi Azure Stack HCI lub Windows Server w centrum danych.

Węzły klastra usługi Azure Stack HCI i systemu Windows Server z trybem alokacji adresów IP oparte na protokole DHCP: Jeśli węzły usługi Azure Stack HCI są przypisane do adresu IP z serwera DHCP obecnego w sieci fizycznej, nie musisz jawnie podać adresu IP do usługi MOC, ponieważ usługa MOC otrzymuje również adres IP z serwera DHCP.
Węzły klastra Azure Stack HCI i Windows Server ze statycznym modelem alokacji adresów IP: Jeśli węzły klastra są przypisane statycznymi adresami IP, musisz 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 usługi Azure Stack HCI i Windows Server. Aby jawnie przypisać adres IP dla usługi MOC, użyj parametru -cloudserviceCIDR w poleceniu Set-AksHciConfig . Upewnij się, że adres IP został wprowadzony w formacie CIDR, na przykład: "10.11.23.45/16".

Porównanie modeli sieciowych

Protokół DHCP i statyczny adres IP zapewniają łączność sieciową w usłudze AKS we wdrożeniu usługi Azure Stack HCI i Windows Server. Istnieją jednak zalety i wady dla każdego z nich. Na wysokim poziomie obowiązują 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 będzie 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ła Kubernetes nie jest obsługiwane, możesz nie być w stanie utworzyć nowych klastrów, jeśli wyczerpano pulę adresów IP węzła Kubernetes.

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

Możliwość	Statyczny adres IP	DHCP
Serwer interfejsu API klastra Kubernetes	Przypisano statycznie przy użyciu puli adresów VIP.	Przypisano statycznie przy użyciu puli adresów VIP.
Węzły kubernetes (na maszynach wirtualnych)	Przypisano przy użyciu puli adresów IP węzła Kubernetes.	Przypisane dynamicznie.
Usługi Kubernetes	Przypisano statycznie przy użyciu puli adresów VIP.	Przypisano statycznie przy użyciu puli adresów VIP.
Maszyna wirtualna modułu równoważenia obciążenia haProxy	Przypisano przy użyciu puli adresów IP węzła Kubernetes.	Przypisane dynamicznie.
Lokalna usługa w chmurze firmy Microsoft	Zależy od konfiguracji sieci fizycznej dla węzłów klastra azure Stack HCI i Windows Server.	Zależy od konfiguracji sieci fizycznej dla węzłów klastra azure Stack HCI i Windows Server.
Pula adresów VIP	Obowiązkowy	Obowiązkowy
Pula adresów IP maszyny wirtualnej węzła Kubernetes	Obowiązkowy	Nieobsługiwane

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	NA	Dwa adresy IP	NA
Klaster obciążeń	Jeden adres IP na węzeł	Jeden adres IP na węzeł	5 adresów IP	Jeden adres IP

Ponadto należy 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 planowaną usługę

Jak widać, liczba wymaganych adresów IP jest zmienna w zależności od architektury wdrożenia usługi AKS i 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óry dopiero zaczyna się od usługi AKS włączonej przez usługę Azure Arc. Chce wdrożyć dwa klastry Kubernetes: klaster Kubernetes A i klaster Kubernetes B w klastrze Azure Stack HCI. Chce również uruchomić aplikację do głosowania na szczycie klastra. Ta aplikacja ma trzy wystąpienia interfejsu użytkownika frontonu działającego w dwóch klastrach i jedno wystąpienie bazy danych zaplecza.

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 wystąpienia interfejsu użytkownika frontonu (port 443).
1 wystąpienie bazy danych zaplecza (port 80).

Na podstawie poprzedniej tabeli musi 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 do 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 do 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 na klaster 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. Jane powinna zatem 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, jak te adresy IP są podzielone 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 modułu równoważenia 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 interfejsu API klastra Kubernetes i trzy dla usług Kubernetes) z 32 adresów IP dla puli adresów VIP.
27 (wszystkie adresy IP węzłów platformy Kubernetes i podstawowych maszyn wirtualnych, maszyn wirtualnych modułu równoważenia obciążenia i operacji aktualizacji) dla puli adresów IP węzłów Kubernetes.

Dzielenie zarezerwowanych adresów IP na podstawie modelu sieci DHCP

Chociaż całkowita liczba zarezerwowanych adresów IP pozostaje taka sama, model wdrażania określa, jak 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 swoim serwerze DHCP.
Musi wykluczyć 5 (dwa dla serwera interfejsu API klastra Kubernetes i trzy dla usług Kubernetes) z zakresu DHCP 32 adresów IP dla jej puli adresów 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 zasobnikó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; tj. nie może podjąć żadnych dodatkowych zagadnień dotyczących routingu.

Kontrolery ruchu przychodzącego działają w warstwie 7 i mogą używać bardziej inteligentnych reguł do dystrybucji ruchu aplikacji. 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 na potrzeby wdrażania węzłów usługi AKS w usłudze Azure Stack HCI. Aby uzyskać więcej informacji, zobacz następujące artykuły: