Architektura sieci dla usługi AKS w środowisku lokalnym platformy Azure

W tym scenariuszu przedstawiono sposób projektowania i implementowania pojęć sieciowych dotyczących wdrażania węzłów usługi Azure Kubernetes Service (AKS) w klastrach usługi AKS.

Ten artykuł zawiera zalecenia dotyczące projektowania sieci dla węzłów Kubernetes i kontenerów Kubernetes. Jest to część zestawu wskazówek dotyczących linii bazowej architektury dwóch artykułów. Zapoznaj się z zaleceniami dotyczącymi architektury punktu odniesienia tutaj.

Architektura

Na poniższej ilustracji przedstawiono architekturę sieci dla usługi Azure Kubernetes Service w klastrach centrów danych platformy Azure lokalnych lub Windows Server 2019/2022:

Pobierz plik programu Visio z tą architekturą.

Scenariusz składa się z następujących składników i możliwości:

• Azure Stack HCI, wersja 22H2, to rozwiązanie klastra infrastruktury hiperkonwergentnej (HCI), które hostuje zwirtualizowane obciążenia systemów Windows i Linux oraz ich magazyn w hybrydowym środowisku lokalnym. Wystąpienie lokalne platformy Azure jest implementowane jako klaster 2–4 węzłów.
• Klaster trybu failover centrów danych systemu Windows Server 2019/2022 to grupa niezależnych komputerów, które współpracują ze sobą w celu zwiększenia dostępności i skalowalności ról klastrowanych.
• azure Kubernetes Service w lokalnej platformy Azure to lokalna implementacja usługi Azure Kubernetes Service (AKS), która automatyzuje uruchamianie konteneryzowanych aplikacji na dużą skalę.
• domena usługi Active Directory Services to hierarchiczna struktura, która przechowuje informacje o obiektach w sieci. Zapewnia ona rozwiązanie tożsamości i dostępu dla tożsamości skojarzonych z użytkownikami, komputerami, aplikacjami lub innymi zasobami, które znajdują się w granicach zabezpieczeń.
• Klaster zarządzania znany również jako host usługi AKS jest odpowiedzialny za wdrażanie wielu klastrów obciążeń i zarządzanie nimi. Klaster zarządzania używa 1 adresu IP z puli węzłów, ale należy zarezerwować kolejne 2 adresy IP dla operacji aktualizacji. Klaster zarządzania korzysta również z jednego adresu IP z puli adresów VIP.
• Klaster obciążenia to wysoce dostępne wdrożenie platformy Kubernetes przy użyciu maszyn wirtualnych z systemem Linux na potrzeby uruchamiania składników płaszczyzny sterowania Kubernetes oraz węzłów roboczych systemu Linux i/lub Windows.
  • Płaszczyzna sterowania. Działa w dystrybucji systemu Linux i zawiera składniki serwera interfejsu API do interakcji z interfejsem API Kubernetes i rozproszonym magazynem par klucz-wartość itp., do przechowywania wszystkich konfiguracji i danych klastra. Używa jednego adresu IP z puli węzłów i jednego adresu IP z puli adresów VIP.
  • Moduł równoważenia obciążenia. Działa na maszynie wirtualnej z systemem Linux i zapewnia usługi o zrównoważonym obciążeniu dla klastra obciążeń. Używa jednego adresu IP z puli węzłów i jednego adresu IP z puli adresów VIP.
  • Węzły robocze. Uruchom polecenie w systemie operacyjnym Windows lub Linux, który hostuje konteneryzowane aplikacje. Używa ona adresów IP z puli węzłów, ale należy zaplanować co najmniej 3 więcej adresów IP na potrzeby operacji aktualizacji.
  • Zasoby platformy Kubernetes. Zasobniki reprezentują pojedyncze wystąpienie aplikacji, które zwykle mają mapowanie 1:1 z kontenerem, ale niektóre zasobniki mogą zawierać wiele kontenerów. Wdrożenia reprezentują co najmniej jeden identyczny zasobnik. Zasobniki i wdrożenia są logicznie grupowane w przestrzeń nazw, która kontroluje dostęp do zarządzania zasobami. Używają one 1 adresu IP na zasobnik z puli adresów VIP.
• Azure Arc to oparta na chmurze usługa, która rozszerza model zarządzania oparty na usłudze Azure Resource Manager na zasoby spoza platformy Azure, w tym maszyny wirtualne, klastry Kubernetes i konteneryzowane bazy danych.
• Azure Policy to oparta na chmurze usługa, która ocenia zasoby platformy Azure i zasoby lokalne za pośrednictwem integracji z usługą Azure Arc, porównując właściwości z dostosowywalnymi regułami biznesowymi.
• Azure Monitor to oparta na chmurze usługa, która maksymalizuje dostępność i wydajność aplikacji i usług, zapewniając kompleksowe rozwiązanie do zbierania, analizowania i działania na podstawie danych telemetrycznych z chmury i środowisk lokalnych.
• Microsoft Defender dla Chmury to ujednolicony system zarządzania zabezpieczeniami infrastruktury, który wzmacnia poziom zabezpieczeń centrów danych i zapewnia zaawansowaną ochronę przed zagrożeniami w ramach obciążeń hybrydowych w chmurze i lokalnie.

Składniki

• Klaster trybu failover centrum danych systemu Windows Server 2019/2022
• Azure Kubernetes Service (AKS)
• Centrum administracyjne systemu Windows
• Subskrypcja platformy Azure
• Azure Arc
• Azure role-based access control (RBAC) (Kontrola dostępu oparta na rolach na platformie Azure)
• Azure Monitor
• Microsoft Defender dla Chmury

Szczegóły scenariusza

Przypadki użycia tego scenariusza opisano w pierwszym artykule z serii Architektura linii bazowej.

Sieć węzłów kubernetes

Głównym zagadnieniem w projekcie sieci dla usługi AKS w usłudze Azure Local jest wybranie modelu sieciowego, który zapewnia wystarczające adresy IP. Usługa AKS w usłudze Azure Local używa sieci wirtualnej do przydzielania adresów IP do zasobów węzła Kubernetes. Można użyć dwóch modeli przypisywania adresów IP:

• Statyczna sieć IP jest bardziej przewidywalna, ale zwiększa nakład pracy na początkową konfigurację.
• Sieć protokołu DHCP (Dynamic Host Configuration Protocol) korzysta z dynamicznej alokacji adresów IP i mniejszego nakładu pracy, ale należy uważać, aby nie wyczerpać dostępnej puli adresów IP. Należy również zarządzać rezerwacjami i zakresami wykluczeń dla pul wirtualnych adresów IP i niektórych zasobów obejmujących cały klaster, takich jak usługa agenta w chmurze.

Oba modele przypisania muszą planować adresy IP dla:

• Pula wirtualnych adresów IP
• Pula adresów IP maszyny wirtualnej węzła kubernetes

Pula wirtualnych adresów IP

Wirtualna pula adresów IP to zestaw adresów IP, które są obowiązkowe dla dowolnego wdrożenia usługi AKS w środowisku lokalnym platformy Azure. Zaplanuj liczbę adresów IP w wirtualnej puli adresów IP na podstawie liczby klastrów obciążeń i usług Kubernetes. Pula wirtualnych adresów IP udostępnia adresy IP dla następujących typów zasobów:

• Agent chmury wymaga pływającego adresu IP z wirtualnej puli adresów IP.

• Składnik serwera interfejsu API działający wewnątrz maszyny wirtualnej wirtualnego urządzenia Kubernetes (KVA) używa adresu IP z wirtualnej puli adresów IP. Serwer interfejsu API jest składnikiem płaszczyzny sterowania platformy Kubernetes, która uwidacznia interfejs API platformy Kubernetes. Serwer interfejsu API to fronton płaszczyzny sterowania platformy Kubernetes. KVA to maszyna wirtualna z systemem Mariner Linux i hostuje klaster Kubernetes. Adres IP jest zmienny i jest również używany dla każdej innej maszyny wirtualnej KVA wdrożonej w usłudze AKS w usłudze Azure Local. Maszyna wirtualna KVA hostuje również usługę równoważenia obciążenia wirtualnego adresu IP platformy Kubernetes.

• Zaplanuj adresowanie IP dla liczby maszyn wirtualnych płaszczyzny sterowania wdrożonych na serwerach docelowych, ponieważ zużywają również więcej adresów IP z wirtualnej puli adresów IP. Zagadnienia zostały opisane w następnej sekcji.

• Klaster docelowy zawiera maszynę wirtualną modułu równoważenia obciążenia, która jest haProxy i jest właścicielem wirtualnej puli adresów IP dla klastra docelowego. Ta maszyna wirtualna uwidacznia wszystkie usługi Kubernetes za pośrednictwem wirtualnej puli adresów IP.

• Aplikacje uruchamiane w zasobnikach Kubernetes używają adresów IP z wirtualnej puli adresów IP.

• Moduł równoważenia obciążenia haProxy jest wdrażany jako wyspecjalizowana maszyna wirtualna i może służyć do równoważenia obciążenia żądań przychodzących w wielu punktach końcowych. Używają one adresów IP z wirtualnej puli adresów IP i należy zaplanować adresowanie IP dla każdego klastra obciążenia.

Pula adresów IP maszyny wirtualnej węzła kubernetes

Węzły kubernetes są wdrażane jako maszyny wirtualne w usłudze AKS we wdrożeniu lokalnym platformy Azure. Upewnij się, że planujesz liczbę adresów IP zgodnie z całkowitą liczbą węzłów kubernetes i uwzględnij co najmniej trzy kolejne adresy IP używane podczas procesu uaktualniania. W przypadku konfiguracji statycznego adresu IP należy określić zakres puli adresów IP maszyny wirtualnej węzła Kubernetes. Nie jest to konieczne w przypadku alokacji DHCP. Zaplanuj dodatkowe adresy IP dla:

• Maszyna wirtualna KVA używa również większej liczby adresów IP dla platformy Kubernetes z puli adresów IP maszyny wirtualnej węzła Kubernetes. Zaplanuj dodanie adresów IP podczas procesu aktualizacji, ponieważ maszyna wirtualna KVA używa tego samego wirtualnego adresu IP dla usługi interfejsu API, ale wymaga oddzielnego adresu IP od puli adresów IP maszyny wirtualnej węzła Kubernetes.
• Maszyny wirtualne płaszczyzny sterowania używają jednego adresu IP z puli adresów IP maszyny wirtualnej węzła Kubernetes dla usługi serwera interfejsu API. Te maszyny wirtualne hostuje również agenta usługi Azure ARC, który łączy się z witryną Azure Portal na potrzeby zarządzania.
• Węzły w puli węzłów (Linux lub Windows) będą używać adresów IP z puli adresów IP przydzielonej dla maszyny wirtualnej węzła Kubernetes.

Lokalna usługa w chmurze firmy Microsoft

Planowanie zakresu adresów IP dla chmury lokalnej firmy Microsoft (MOC), która umożliwia stos zarządzania, dzięki czemu maszyny wirtualne na platformie Azure Lokalne są zarządzane w chmurze. Alokacja adresów IP dla usługi MOC znajduje się w podstawowej sieci fizycznej, a adresy IP skonfigurowane dla węzłów klastra lokalnego platformy Azure znajdują się w centrum danych. Adresy IP dla fizycznych węzłów usługi Azure Local można skonfigurować w jednym z następujących elementów:

• Węzły klastra lokalnego platformy Azure z trybem alokacji adresów IP opartym na protokole DHCP. Usługa MOC pobiera adres IP z usługi DHCP przedstawionej w sieci fizycznej.
• Węzły klastra lokalnego platformy Azure z statycznym modelem alokacji adresów IP. Adres IP usługi w chmurze MOC musi być jawnie określony jako zakres adresów IP w formacie classless Inter-Domain Routing (CIDR) i musi znajdować się w tej samej podsieci co adresy IP węzłów klastra lokalnego platformy Azure.

Moduł równoważenia obciążenia w usłudze AKS w usłudze Azure Local

W przypadku małego wdrożenia można użyć wbudowanego modułu równoważenia obciążenia wdrożonego jako maszyna wirtualna z systemem Linux, która używa haProxy + KeepAlive do wysyłania ruchu do usług aplikacji wdrożonych w ramach klastra usługi AKS. Moduł równoważenia obciążenia haProxy konfiguruje zasobniki jako punkty końcowe w module równoważenia obciążenia. Ładuje on równoważenie żądań do serwera interfejsu API Kubernetes i zarządza ruchem do usług aplikacji.

Możesz również użyć niestandardowego modułu równoważenia obciążenia do zarządzania ruchem do usług. Niestandardowy moduł równoważenia obciążenia zapewnia dodatkową elastyczność wdrażania i zapewnia, że usługa AKS w usłudze Azure Local działa wraz z istniejącymi wdrożeniami, takimi jak wdrożenia programowalnej sieci komputerowej (SDN), które korzystają z modułów równoważenia obciążenia. W przypadku niestandardowych modułów równoważenia obciążenia adres IP kube-virtual udostępnia klastry Kubernetes z wirtualnym adresem IP i modułem równoważenia obciążenia zarówno dla płaszczyzny sterowania, jak i usług Kubernetes Services typu LoadBalancer. Usługa kube-virtual IP jest automatycznie wdrażana w każdym węźle procesu roboczego.

Usługa AKS w usłudze Azure Local obsługuje również użycie modułu równoważenia obciążenia z systemem MetalLB lub innych modułów równoważenia obciążenia opartych na systemie operacyjnym Kubernetes w celu równoważenia ruchu przeznaczonego dla usług w klastrze obciążenia. MetalLB to implementacja modułu równoważenia obciążenia dla klastrów Kubernetes bez systemu operacyjnego przy użyciu standardowych protokołów routingu, takich jak protokół BGP protokołu border gateway. Może działać zarówno z dodatkami sieciowymi Calico, jak i Flannel, ale należy się upewnić, że zakres wirtualnych adresów IP podany podczas instalacji usługi AKS na platformie Azure Local nie nakłada się na zakres adresów IP zaplanowany dla niestandardowego modułu równoważenia obciążenia.

Wdrażanie tego scenariusza

Wdrażanie kontrolera ruchu przychodzącego

Rozważ zaimplementowanie kontrolera ruchu przychodzącego na potrzeby zakończenia protokołu TLS, odwracalnego serwera proxy lub konfigurowalnego routingu ruchu. Kontrolery ruchu przychodzącego działają w warstwie 7 i mogą używać inteligentnych reguł do dystrybucji ruchu aplikacji. Zasoby ruchu przychodzącego usług Kubernetes są używane do skonfigurowania zasad ruchu przychodzącego oraz tras dla poszczególnych usług Kubernetes. Podczas definiowania kontrolera ruchu przychodzącego można skonsolidować reguły routingu ruchu do pojedynczego zasobu, który działa w ramach klastra.

Użyj kontrolera ruchu przychodzącego, aby uwidocznić usługi za pośrednictwem zewnętrznych adresów URL. Ruch przychodzący uwidacznia trasy HTTP i HTTPS spoza klastra do usług w klastrze. Routing ruchu jest kontrolowany przez reguły zdefiniowane w zasobie ruchu przychodzącego. Reguły HTTP ruchu przychodzącego zawierają następujące informacje:

• Opcjonalny host. Jeśli nie podasz informacji o hoście, reguła zostanie zastosowana do całego przychodzącego ruchu HTTP.
• Lista ścieżek, które ma skojarzone zaplecze zdefiniowane z service.name i service.port.name lub service.port.number.
• Zaplecze, które zapewnia kombinację nazw usług i portów.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hello-world
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    kubernetes.io/ingress.class: "nginx"
spec:
  rules:
  - host: test.example.com
     http:
       paths:
       - path: /hello-world
          pathType: Prefix
          backend:
            service:
              name: hello-world
              port:
                 number: 8080

Użyj kontrolera ruchu przychodzącego, aby zrównoważyć ruch między różnymi zapleczami aplikacji. Ruch jest podzielony i wysyłany do różnych punktów końcowych i wdrożeń usługi na podstawie informacji o ścieżce.

Aby kierować ruch HTTP do wielu nazw hostów na tym samym adresie IP, możesz użyć innego zasobu ruchu przychodzącego dla każdego hosta. Ruch przechodzący przez adres IP modułu równoważenia obciążenia jest kierowany na podstawie nazwy hosta i ścieżki podanej w regule ruchu przychodzącego.

Pojęcia dotyczące sieci kontenerów w usłudze Azure Kubernetes Service (AKS) w usłudze Azure Local

Platforma Kubernetes udostępnia warstwę abstrakcji sieci wirtualnej, dzięki czemu aplikacje oparte na kontenerach mogą komunikować się wewnętrznie lub zewnętrznie. Składnik kube-proxy działa w każdym węźle i może zapewnić bezpośredni dostęp do usługi, dystrybuować ruch przy użyciu równoważenia obciążenia lub używać kontrolerów ruchu przychodzącego do bardziej złożonego routingu aplikacji. Platforma Kubernetes używa usług do logicznego grupowania zestawu zasobników i zapewniania łączności sieciowej. Dostępne są następujące usługi Kubernetes:

• Adres IP klastra: ta usługa tworzy wewnętrzny adres IP dla aplikacji tylko wewnętrznych.
• NodePort: ta usługa tworzy mapowanie portów w węźle bazowym, co sprawia, że aplikacja jest bezpośrednio dostępna za pomocą adresu IP węzła i portu.
• LoadBalancer: usługi Kubernetes można uwidaczniać zewnętrznie przy użyciu reguł modułu równoważenia obciążenia lub kontrolera ruchu przychodzącego.
• ExternalName:. Ta usługa używa określonego wpisu DNS dla aplikacji Kubernetes.

Sieci Kubernetes

W usłudze AKS na platformie Azure Lokalnie klaster można wdrożyć przy użyciu jednego z następujących modeli sieciowych:

• Sieć Calico projektu. Jest to domyślny model sieci dla usługi AKS w usłudze Azure Local i oparty na sieci typu open source, która zapewnia zabezpieczenia sieci dla kontenerów, maszyn wirtualnych i natywnych obciążeń opartych na hoście. Zasady sieci Calico można stosować w dowolnym rodzaju punktach końcowych, takich jak zasobniki, kontenery, maszyny wirtualne lub interfejsy hosta. Każda zasada składa się z reguł sterujących ruchem przychodzącym i wychodzącym przy użyciu akcji, które mogą zezwalać, blokować, rejestrować lub przekazywać ruch między źródłowymi i docelowymi punktami końcowymi. Calico może używać rozszerzonego filtru pakietów Berkeley (eBPF) lub potoku sieci jądra systemu Linux na potrzeby dostarczania ruchu. Calico jest również obsługiwane w systemie Windows przy użyciu usługi sieci hosta (HNS) do tworzenia przestrzeni nazw sieciowych na punkt końcowy kontenera. W modelu sieci kubernetes każdy zasobnik uzyskuje własny adres IP współużytkowany między kontenerami w tym zasobniku. Zasobniki komunikują się w sieci przy użyciu adresów IP zasobnika, a izolacja jest definiowana przy użyciu zasad sieciowych. Calico używa wtyczek CNI (Container Network Interface) do dodawania lub usuwania zasobników do i z sieci zasobników Kubernetes oraz wtyczek CNI IPAM (Zarządzanie adresami IP) do przydzielania i wydawania adresów IP.
• Sieć nakładki flannel. Platforma Flannel tworzy warstwę sieci wirtualnej, która nakłada sieć hosta. Sieć nakładki używa hermetyzacji pakietów sieciowych w istniejącej sieci fizycznej. Platforma Flannel upraszcza Zarządzanie adresami IP (IPAM), obsługuje ponowne używanie adresów IP między różnymi aplikacjami i przestrzeniami nazw oraz zapewnia logiczne oddzielenie sieci kontenerów od sieci nakładki używanej przez węzły Kubernetes. Izolacja sieci jest osiągana przy użyciu wirtualnej sieci lokalnej (VXLAN, Virtual eXtensible Local Area Network), protokołu hermetyzacji, który zapewnia łączność centrum danych przy użyciu tunelowania w celu rozciągnięcia połączeń warstwy 2 przez podstawową sieć warstwy 3. Platforma Flannel jest obsługiwana zarówno przez kontenery systemu Linux, jak i kontenery systemu Windows przy użyciu wtyczki CNI platformy Flannel.

Projekt sieci lokalnej platformy Azure

Ogólny projekt sieci obejmuje planowanie działań związanych z platformą Azure Local.

Najpierw zacznij od zaplanowania sprzętu i instalacji platformy Azure Local. Możesz kupić zintegrowane systemy od partnera sprzętowego firmy Microsoft ze wstępnie zainstalowanym systemem operacyjnym Azure Stack HCI lub kupić zweryfikowane węzły i zainstalować system operacyjny samodzielnie. Usługa Azure Local jest przeznaczona jako host wirtualizacji, dlatego role serwera Kubernetes muszą działać wewnątrz maszyn wirtualnych.

Wymagania dotyczące sieci fizycznej dla usługi Azure Local

Firma Microsoft nie certyfikowa przełączników sieciowych, ale ma pewne wymagania, które dostawca sprzętu musi spełnić:

• Standardowa: IEEE 802.1Q definiujący wirtualną sieć lokalną (VLAN).
• Standardowa: IEEE 802.1Qbb definiujący sterowanie przepływem priorytetu (PFC).
• Standardowa: IEEE 802.1Qaz definiujący rozszerzony wybór transmisji (ETS).
• Standardowa: IEEE 802.1AB definiujący protokół odnajdywania topologii warstwy łącza (LLTD).

Wymagania dotyczące sieci hosta dla platformy Azure Local

Rozważ użycie karty sieciowej, która uzyskała certyfikat Centrum danych zdefiniowanego programowo (SDDC) systemu Windows Server z kwalifikacją Standardowa lub Premium Additional Qualification (AQ).

Upewnij się, że karta sieciowa obsługuje:

• Dynamic Virtual Machine Multi-Queue (Dynamic VMMQ or d.VMMQ) to inteligentna technologia po stronie odbieranej do automatycznego dostrajania przetwarzania ruchu sieciowego do rdzeni procesora CPU.
• Zdalny bezpośredni dostęp do pamięci (RDMA) to odciążanie stosu sieciowego do karty sieciowej. Umożliwia to obejście ruchu magazynu SMB w celu obejścia systemu operacyjnego do przetwarzania.
• Funkcja RDMA gościa umożliwia wykonywanie obciążeń SMB dla maszyn wirtualnych w celu uzyskania tych samych korzyści związanych z używaniem funkcji RDMA na hostach.
• Switch Embedded Teaming (SET) to technologia tworzenia zespołu oparta na oprogramowaniu.

Rozważ użycie usługi Network ATC, która zapewnia kontrolę opartą na intencji, aby uprościć konfigurację sieci hosta.

Usługa AKS w usłudze Azure Local wymaga niezawodnego połączenia sieciowego o wysokiej przepustowości i małych opóźnieniach między każdym węzłem serwera. Upewnij się, że co najmniej jedna karta sieciowa jest dostępna i dedykowana do zarządzania klastrem. Sprawdź również, czy przełączniki fizyczne w sieci są skonfigurowane tak, aby zezwalały na ruch w dowolnych sieciach VLAN, których będziesz używać.

Przełącznik wirtualny

Usługa Azure Local upraszcza projektowanie sieci przez skonfigurowanie przełącznika wirtualnego, który może być używany do klasyfikacji sieci. Wirtualna karta sieciowa (vNIC) może zostać umieszczona w różnych sieciach VLAN dla hostów w celu zapewnienia różnych przepływów ruchu dla następujących sieci:

• Sieć zarządzania. Sieć zarządzania jest częścią sieci północno-południowej i jest używana do komunikacji hosta.
• Sieć obliczeniowa. Sieć obliczeniowa jest częścią sieci północno-południowej i jest używana na potrzeby ruchu maszyn wirtualnych. Użyj funkcji Quality of Service (QOS), wirtualizacji we/wy pojedynczego katalogu głównego (SR-IOV) i wirtualnego bezpośredniego dostępu do pamięci zdalnej (vRDMA), aby dostosować wydajność sieci na podstawie zapotrzebowania.
• Sieć magazynu. Sieć magazynu jest częścią sieci east-west i wymaga rdMA z zalecaną przepływnością 10 GB+. Jest on używany do migracji na żywo maszyn wirtualnych.
• Sieć gościa maszyny wirtualnej.

Ruch wschodnio-zachodni z korzyścią dla ruchu RDMA

Ruch sieciowy wschód-zachód reprezentuje komunikację między hostami i nie ujawnia żadnego dostępu zewnętrznego. Ruch pozostaje w obrębie przełącznika Top of Rack (ToR) i granicy warstwy 2. Obejmuje on następujące typy ruchu:

• Pulsy klastra i komunikacja między węzłami
• [SMB] Warstwa magistrali magazynu
• [SMB] Udostępniony wolumin klastra
• [SMB] Ponowne kompilowanie magazynu

Ruch północno-południowy

North-South ruch jest ruchem zewnętrznym, który dociera do usługi AKS w wystąpieniu lokalnym platformy Azure. Możesz zaplanować ruch dla zakresu usług platformy Azure, które umożliwiają monitorowanie, rozliczenia i zarządzanie zabezpieczeniami za pośrednictwem integracji usługi Azure ARC. Ruch północno-południowy ma następujące cechy:

• Ruch przepływa z przełącznika ToR do kręgosłupa lub z kręgosłupa do przełącznika ToR.
• Ruch opuszcza stojak fizyczny lub przekracza granicę warstwy 3 (IP).
• Ruch obejmuje zarządzanie (Program PowerShell, Centrum administracyjne systemu Windows), obliczenia (maszyna wirtualna) i ruch klastra rozproszonego między lokacjami.
• Używa przełącznika Ethernet do łączności z siecią fizyczną.

Usługa AKS na platformie Azure Lokalna może używać kilku opcji wdrażania sieci klastra:

• Konwergentna sieć łącząca wiele intencji sieciowych (MGMT, Compute, Storage). Jest to zalecane wdrożenie dla więcej niż trzech węzłów fizycznych i wymaga, aby wszystkie fizyczne karty sieciowe zostały podłączone do tych samych przełączników ToR. ROCEv2 jest zdecydowanie zalecane.
• Wdrożenie bez przełączników używa komunikacji północno-południowej jako zespołu sieciowego, łącząc sieci obliczeniowe i sieciowe.
• Wdrożenie hybrydowe jako kombinacja obu wdrożeń.

Zalecenia

Poniższe zalecenia dotyczą większości scenariuszy. Postępuj zgodnie z zaleceniami, chyba że masz określone wymaganie, które je zastępuje.

Zalecenia dotyczące sieci

Głównym problemem w projekcie sieci dla usługi AKS w usłudze Azure Local jest wybranie modelu sieciowego, który zapewnia wystarczającą liczbę adresów IP dla klastra Kubernetes oraz jego usług i aplikacji.

• Rozważ zaimplementowanie statycznych adresów IP, aby umożliwić usłudze AKS w usłudze Azure Local kontrolowanie przypisania adresu IP.

• Należy prawidłowo wymiarować zakresy adresów IP, dzięki czemu masz wystarczającą ilość wolnych adresów IP dla puli węzłów Kubernetes i dla wirtualnej puli adresów IP. Upewnij się, że pula wirtualnych adresów IP jest wystarczająco duża, aby zawsze, gdy uaktualniasz, możesz użyć uaktualnień stopniowego, które wymagają większej liczby adresów IP. Możesz zaplanować następujące elementy:

  • Adresowanie/nazwy hosta dla ustawień serwera proxy
  • Adresy IP docelowej płaszczyzny sterowania klastra
  • Adresy IP dla usługi Azure ARC
  • Adresy IP do skalowania poziomego węzłów procesu roboczego i płaszczyzny sterowania w klastrach docelowych

• Pula wirtualnych adresów IP powinna być wystarczająco duża, aby obsługiwać wdrażanie usług aplikacji, które wymagają łączności z routerem zewnętrznym.

• Zaimplementuj kalifornijską sieć CNI, aby zapewnić rozszerzone zasady sieciowe do kontrolowania komunikacji zasobnika i aplikacji.

• Upewnij się, że fizyczne węzły klastra (HCI lub Windows Server) znajdują się w tym samym stojaku i są podłączone do tych samych przełączników tor.

• Wyłącz protokół IPv6 na wszystkich kartach sieciowych.

• Upewnij się, że istniejący przełącznik wirtualny i jego nazwa są takie same we wszystkich węzłach klastra.

• Sprawdź, czy wszystkie podsieci zdefiniowane dla klastra są routingowe między sobą i z Internetem.

• Upewnij się, że istnieje łączność sieciowa między hostami lokalnymi platformy Azure i maszynami wirtualnymi dzierżawy.

• Włącz dynamiczne aktualizacje DNS w środowisku DNS, aby umożliwić usłudze AKS w usłudze Azure Local zarejestrowanie ogólnej nazwy klastra agenta w chmurze w systemie DNS na potrzeby odnajdywania.

• Rozważ zaimplementowanie klasyfikacji ruchu sieciowego według jego kierunku:

  • North-South ruch jest ruchem lokalnym i resztą sieci platformy Azure,
    • Zarządzanie
    • Compute
    • Ruch klastra rozproszonego między lokacjami
  • East-West ruchu w ramach usługi Azure Local:
    • Ruch magazynu, w tym migracja na żywo między węzłami w tym samym klastrze.
    • Przełącznik Ethernet lub połączenie bezpośrednie.

Modele ruchu magazynu

• Użyj wielu podsieci i sieci VLAN, aby oddzielić ruch magazynu w usłudze Azure Local.
• Rozważ zaimplementowanie alokacji przepustowości ruchu różnych typów ruchu.

Kwestie wymagające rozważenia

Platforma Microsoft Azure Well-Architected Framework to zestaw wskazówek, które są przestrzegane w tym scenariuszu. Poniższe zagadnienia zostały uwzględnione w kontekście tych zestawów.

Niezawodność

• Wbudowana odporność związana z obliczeniami zdefiniowanymi programowo przez firmę Microsoft (klaster trybu failover węzłów funkcji Hyper-V), magazynem (Miejsca do magazynowania bezpośredniej odporności zagnieżdżonej) i siecią (sieć zdefiniowana programowo).
• Rozważ wybranie przełącznika sieciowego obsługującego standardy branżowe i zapewnienie niezawodnej komunikacji między węzłami. Następujące standardy obejmują:
  • Standardowa: IEEE 802.1Q
  • Standard IEEE 802.1Qbb
  • Standard IEEE 802.1 Qas
  • Standardowa IEEE 802.1 AB
• Rozważ zaimplementowanie wielu hostów w klastrze zarządzania i w klastrze Kubernetes, aby spełnić minimalny poziom dostępności obciążeń.
• Usługa AKS na platformie Azure Lokalna używa klastra trybu failover i migracji na żywo w celu zapewnienia wysokiej dostępności i odporności na uszkodzenia. Migracja na żywo to funkcja funkcji Hyper-V, która umożliwia przezroczyste przenoszenie uruchomionych maszyn wirtualnych z jednego hosta funkcji Hyper-V do innego bez postrzeganego przestoju.
• Upewnij się, że usługi, do których odwołuje się sekcja Architektura , są obsługiwane w regionie, w którym wdrożono usługę Azure Arc.

Zabezpieczenia

• Zabezpieczanie ruchu między zasobnikami przy użyciu zasad sieciowych w usłudze AKS w usłudze Azure Local.
• Serwer interfejsu API w usłudze AKS w usłudze Azure Local zawiera urząd certyfikacji, który podpisuje certyfikaty komunikacji z serwera interfejsu API Kubernetes do kubelet.
• Użyj logowania jednokrotnego (SSO) firmy Microsoft, aby utworzyć bezpieczne połączenie z serwerem interfejsu API Kubernetes.
• Kontrola dostępu oparta na rolach platformy Azure umożliwia zarządzanie dostępem do platformy Kubernetes z obsługą usługi Azure Arc na platformie Azure i w środowiskach lokalnych przy użyciu tożsamości firmy Microsoft Entra. Aby uzyskać więcej informacji, zobacz Use Azure RBAC for Kubernetes Authorization (Używanie kontroli dostępu opartej na rolach platformy Azure na potrzeby autoryzacji na platformie Kubernetes).

Optymalizacja kosztów

• Skorzystaj z kalkulatora cen platformy Azure, aby oszacować koszty usług używanych w architekturze. Inne najlepsze rozwiązania opisano w sekcji optymalizacji kosztów w witrynie Microsoft Azure Well-Architected Framework.
• Rozważ zaimplementowanie hiperwątkowego na komputerze fizycznym, aby zoptymalizować koszt, ponieważ usługa AKS w lokalnej jednostce rozliczeniowej platformy Azure jest rdzeniem wirtualnym.
• Funkcje płaszczyzny sterowania usługi Azure Arc są zapewniane bez dodatkowych kosztów. Obejmuje to obsługę organizacji zasobów za pośrednictwem grup zarządzania i tagów platformy Azure oraz kontroli dostępu za pośrednictwem kontroli dostępu opartej na rolach platformy Azure. Usługi platformy Azure używane w połączeniu z serwerami z obsługą usługi Azure Arc generują koszty zgodnie z ich użyciem.
• W przypadku opłacalności można użyć zaledwie dwóch węzłów klastra z tylko czterema dyskami i 64 gigabajtami (GB) pamięci na węzeł. Aby jeszcze bardziej zminimalizować koszty, można użyć bez przełączania połączeń między węzłami, eliminując w ten sposób potrzebę nadmiarowego przełącznika urządzeń.

Doskonałość operacyjna

• Uproszczone zarządzanie przy użyciu Centrum administracyjnego systemu Windows. Windows Admin Center to interfejs użytkownika umożliwiający tworzenie usługi AKS i zarządzanie nią w usłudze Azure Local. Można go zainstalować na maszynie wirtualnej z systemem Windows 10/11 lub Windows Server, która musi być zarejestrowana na platformie Azure i znajdują się w tej samej domenie co klaster usługi Azure Local lub Windows Server Datacenter.
• Integracja z usługą Azure Arc lub szeregiem usług platformy Azure, które zapewniają więcej możliwości zarządzania, konserwacji i odporności (Azure Monitor, Azure Backup).
• Jeśli klaster Kubernetes jest dołączony do usługi Azure Arc, możesz zarządzać klastrem Kubernetes przy użyciu usługi GitOps. Aby zapoznać się z najlepszymi rozwiązaniami dotyczącymi łączenia hybrydowego klastra Kubernetes z usługą Azure Arc, zobacz scenariusz hybrydowego zarządzania i wdrażania klastrów Kubernetes w usłudze Azure Arc.
• Platforma lokalna platformy Azure pomaga również uprościć sieć wirtualną dla usługi AKS w wystąpieniach lokalnych platformy Azure, zapewniając "podstawową" sieć w sposób wysoce dostępny.

Efektywność wydajności

• Użyj lokalnego certyfikowanego sprzętu platformy Azure w celu zwiększenia czasu pracy i wydajności aplikacji, uproszczonego zarządzania i operacji oraz niższego całkowitego kosztu posiadania.
• Magazyn: Miejsca do magazynowania Direct
  • Konfiguracja woluminu (zagnieżdżone dublowanie dwukierunkowe a zagnieżdżone parzystość przyspieszana przez dublowanie)
  • Konfiguracja dysku (buforowanie, warstwy)
• Upewnij się, że węzły klastra znajdują się fizycznie w tym samym stojaku i są podłączone do tych samych przełączników tor.
• Planowanie rezerwacji adresów IP w celu skonfigurowania hostów usługi AKS, klastrów obciążeń, serwerów interfejsu API klastra, usług Kubernetes Services i usług aplikacji. Firma Microsoft zaleca rezerwowanie co najmniej 256 adresów IP dla wdrożenia usługi AKS na platformie Azure Lokalnie.
• Rozważ zaimplementowanie kontrolera ruchu przychodzącego, który działa w warstwie 7 i używa bardziej inteligentnych reguł do dystrybucji ruchu aplikacji.
• Używanie przyspieszania procesora graficznego (GPU) w przypadku dużych obciążeń.

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Autorzy zabezpieczeń:

• Lisa DenBeste | Menedżer programu zarządzania projektami
• Kenny Harder | Project Manager
• Mike Kostersitz | Główny kierownik programu
• Meg Olsen | Główny
• Nate Waters | Menedżer marketingu produktu

Inni współautorzy:

• Walter Oliver | Starszy menedżer programu

Następne kroki

• Omówienie usługi AKS

Powiązane zasoby

• Architektura punktu odniesienia dla usługi AKS w usłudze Azure Local