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

Artykuł
11/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ę Arc. 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 na potrzeby wdrożenia lokalnego usługi AKS na platformie Azure.

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 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 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 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ą zaletą korzystania z sieci statycznych adresów IP jest to, że długotrwałe wdrożenia i obciążenia aplikacji są zawsze 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 maszyn wirtualnych węzłów kubernetes: ciągły zakres adresów IP, które mają być używane 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łó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 na lokalnej i opartej na systemie Windows Server usłudze SDDC na platformie Azure. 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 klastra lokalnego platformy Azure lub systemu Windows Server i jest skonfigurowany do przełączania w tryb failover do innego węzła.
Uruchomione node agent na każdym lokalnym węźle fizycznym platformy Azure.

Aby umożliwić 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 dla usługi MOC zależy od bazowego modelu sieci używanego przez wdrożenie klastra na platformie Azure Local 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 Local lub Windows Server w centrum danych.

Węzły klastra lokalnego platformy Azure i systemu Windows Server z trybem alokacji adresów IP opartego na protokole DHCP: Jeśli węzły lokalne platformy Azure są przypisane z serwera DHCP obecnego w sieci fizycznej, nie musisz jawnie podawać adresu IP do usługi MOC, ponieważ usługa MOC odbiera również adres IP z serwera DHCP.
Węzły klastra lokalnego platformy Azure i systemu Windows Server ze statycznym modelem alokacji adresów IP: jeśli węzły klastra są 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 usługi Azure Local i 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

Protokół DHCP i statyczny adres IP zapewniają łączność sieciową w usłudze AKS we wdrożeniu usługi Azure Local i 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 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 platformy Kubernetes.	Przypisywane 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 platformy Kubernetes.	Przypisywane dynamicznie.
Lokalna usługa w chmurze firmy Microsoft	Zależy od konfiguracji sieci fizycznej dla węzłów klastra lokalnego platformy Azure i systemu Windows Server.	Zależy od konfiguracji sieci fizycznej dla węzłów klastra lokalnego platformy Azure i systemu Windows Server.
Pula adresów VIP	Obowiązkowy	Obowiązkowy
Pula adresów IP maszyny wirtualnej węzła kubernetes	Obowiązkowy	Nieobsługiwany

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 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ó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 lokalnym platformy Azure. Chce również uruchomić aplikację do głosowania na szczycie klastra. Ta aplikacja ma trzy wystąpienia interfejsu użytkownika frontonu uruchomionego 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 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 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 jej puli adresów VIP.
27 (wszystkie adresy IP węzłów platformy Kubernetes i bazowych maszyn wirtualnych, maszyn wirtualnych modułu równoważenia 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 (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; tzn. nie może podejmować ż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 wdrażania węzłów usługi AKS na platformie Azure Lokalnie. Aby uzyskać więcej informacji, zobacz następujące artykuły:

Udostępnij za pośrednictwem