Pojęcia dotyczące sieci wdrażania węzłów usługi AKS
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 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 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 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 agentwdrożone w klastrze. Ten agent działa w dowolnym węźle w klastrze azure Stack HCI lub Windows Server i jest skonfigurowany do przełączania w tryb failover do innego węzła. - Uruchomione
node agentw każdym węźle fizycznym usługi Azure Stack HCI.
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 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 opartego na protokole DHCP: Jeśli węzły rozwiązania Azure Stack HCI mają przypisany adres 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 mają przypisane statyczne adresy 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
-cloudserviceCIDRw poleceniuSet-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 rozwiązania Azure Stack HCI 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 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ł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 Azure Stack HCI. 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 w usłudze Azure Stack HCI. Aby uzyskać więcej informacji, zobacz następujące artykuły: