Ten artykuł jest przeznaczony do uwzględnienia jako rozszerzenia architektury punktu odniesienia usługi AKS, który zawiera szczegółowy przegląd zalecanych konfiguracji w celu wdrożenia klastra usługi AKS w środowisku produkcyjnym. Ten artykuł koncentruje się na dostarczaniu wskazówek dotyczących wdrażania kontenerów systemu Windows w usłudze AKS. W związku z tym ten artykuł koncentruje się na tych konfiguracjach specyficznych dla wdrażania systemu Windows w usłudze AKS i należy wrócić do dokumentacji punktu odniesienia usługi AKS pod kątem konfiguracji, które zostały już tam opisane.
Zapoznaj się z projektem GitHub punktu odniesienia systemu Windows usługi AKS, aby przejrzeć implementację referencyjną skojarzoną z tą architekturą referencyjną, w tym przykładowy kod wdrożenia.
Projekt sieci
Projekt sieci używany w tej architekturze jest oparty na projekcie używanym w architekturze punktu odniesienia usługi AKS i dlatego udostępnia wszystkie podstawowe składniki tego projektu z wyjątkiem następujących zmian.
- Kontrolery domeny usługi Active Directory zostały dodane do obsługi obciążeń opartych na systemie Windows.
- Rozwiązanie ruchu przychodzącego w tej architekturze korzysta z usługi Azure Front Door (AFD) i serwera proxy aplikacji entra firmy Microsoft (AAP), a nie bramy aplikacja systemu Azure, która jest używana w architekturze punktu odniesienia usługi AKS.
Uwaga
Migrowanie obciążeń systemu Windows do usługi AKS zwykle nie obejmuje poważnych działań refaktoryzacji, a w związku z tym obciążenia mogą używać funkcji, które były stosunkowo łatwe do wdrożenia w środowisku lokalnym, ale stanowią wyzwanie na platformie Azure. Przykładem może być aplikacja korzystająca z uwierzytelniania gMSA i Kerberos. Jest to typowy przypadek użycia, a w związku z tym ta architektura prowadzi do składników, które zaspokajają potrzeby tych obciążeń. W szczególności używanie protokołu AAP fronted przez usługę AFD w ramach ścieżki ruchu przychodzącego. Jeśli obciążenie nie wymaga tej obsługi, możesz postępować zgodnie z tymi samymi wskazówkami co w punkcie odniesienia usługi AKS dla ruchu przychodzącego.
Projekt ruchu przychodzącego
Składniki:
- Usługa Azure Front Door z zaporą aplikacji internetowej: AFD to publiczny punkt ruchu przychodzącego dla aplikacji hostowanych w klastrze usługi AKS. Usługa AFD Premium jest używana w tym projekcie, ponieważ umożliwia korzystanie z usługi Private Link, która blokuje ruch aplikacji wewnętrznych do sieci prywatnej, zapewniając najwyższy poziom zabezpieczeń. Zapora aplikacji internetowej chroni przed typowymi lukami w zabezpieczeniach i lukami w zabezpieczeniach aplikacji internetowych.
- Serwer proxy aplikacji Firmy Microsoft Entra: ten składnik służy jako drugi punkt ruchu przychodzącego przed wewnętrznym modułem równoważenia obciążenia zarządzanym przez usługę AKS. Ma on włączony identyfikator Entra firmy Microsoft do wstępnego uwierzytelniania użytkowników i używa zasad dostępu warunkowego, aby zapobiec nieautoryzowanemu zakresom adresów IP (AAP widzi źródłowy adres IP klienta, który porównuje z zasadami dostępu warunkowego) i użytkowników z uzyskiwania dostępu do witryny. Jest to jedyny sposób kierowania żądań uwierzytelniania Kerberos podczas korzystania z usługi platformy Azure obsługującej zaporę aplikacji internetowej. Aby uzyskać szczegółowy opis zapewniania dostępu do logowania jednokrotnego do aplikacji chronionych serwer proxy aplikacji, zobacz Ograniczone delegowanie protokołu Kerberos na potrzeby logowania jednokrotnego (SSO) do aplikacji przy użyciu serwer proxy aplikacji
- Wewnętrzny moduł równoważenia obciążenia: zarządzany przez usługę AKS. Ten moduł równoważenia obciążenia uwidacznia kontroler ruchu przychodzącego za pośrednictwem prywatnego statycznego adresu IP. Służy jako pojedynczy punkt kontaktu, który odbiera przychodzące żądania HTTP.
- W tej architekturze nie są używane żadne kontrolery ruchu przychodzącego (na przykład Nginx).
Aby zaimplementować ten projekt, usługa AFD musi być skonfigurowana tak, aby korzystała z adresu URL serwer proxy aplikacji tworzonego podczas publikowania aplikacji w tej usłudze. Ta konfiguracja kieruje ruch przychodzący do serwera proxy i umożliwia wstępne uwierzytelnianie.
Uwaga
Zachowywanie źródłowego adresu IP klienta nie jest obsługiwane, dlatego architekci aplikacji powinni planować alternatywne środki w celu zewnętrzności tej logiki poza klastrem dla aplikacji, które zależą od źródłowego adresu IP.
Topologia sieci
Na poniższym diagramie przedstawiono projekt sieci piasty i szprych używany w tej architekturze.
Pobierz plik programu Visio z tą architekturą.
Topologia puli węzłów
Ta architektura korzysta z trzech pul węzłów: puli węzłów systemowych z systemem Linux, puli węzłów użytkownika z systemem Linux i puli węzłów użytkownika z systemem Windows. Pule węzłów użytkownika systemu Windows i Linux są używane dla obciążeń, podczas gdy pula węzłów systemowych jest używana dla wszystkich konfiguracji na poziomie systemu, takich jak CoreDNS.
Przepływ ruchu przychodzącego
- Klient wysyła żądanie HTTPS do nazwy domeny: bicycle.contoso.com. Ta nazwa jest skojarzona z rekordem DNS A dla publicznego adresu IP usługi Azure Front Door. Ten ruch jest szyfrowany, aby upewnić się, że nie można sprawdzić ani zmienić ruchu między przeglądarką klienta a bramą.
- Usługa Azure Front Door ma zintegrowaną zaporę aplikacji internetowej (WAF) i negocjuje uzgadnianie protokołu TLS dla bicycle.contoso.com, co umożliwia tylko bezpieczne szyfrowanie. Usługa Azure Front Door Gateway jest punktem zakończenia protokołu TLS, ponieważ jest wymagana do przetwarzania reguł inspekcji zapory aplikacji internetowej i wykonywania reguł routingu przekazujących ruch do skonfigurowanego zaplecza. Certyfikat TLS jest przechowywany w usłudze Azure Key Vault.
- Usługa AFD kieruje żądanie użytkownika do serwera proxy aplikacja systemu Azure. Usługa AFD jest skonfigurowana tak, aby zezwalała tylko na ruch HTTPS. Jeśli włączono wstępne uwierzytelnianie, użytkownik musi uwierzytelnić się przy użyciu identyfikatora Entra firmy Microsoft.
- Serwer proxy aplikacji kieruje użytkownika do kontenera aplikacji zaplecza za pośrednictwem modułu równoważenia obciążenia usługi AKS.
Uwaga
W każdym przeskoku w przepływie można wymusić pełny ruch TLS, ale należy rozważyć pomiar wydajności, opóźnień i wpływu operacyjnego podczas podejmowania decyzji o zabezpieczeniu ruchu zasobnika do zasobnika. W przypadku większości klastrów z jedną dzierżawą, z odpowiednią kontrolą RBAC i dojrzałymi praktykami cyklu życia tworzenia oprogramowania wystarczy wymusić szyfrowanie do kontrolera ruchu przychodzącego i chronić zaplecze za pomocą zapory aplikacji internetowej (WAF). Ta konfiguracja zminimalizuje obciążenie związane z zarządzaniem obciążeniami i wpływa na wydajność sieci. Wymagania dotyczące obciążenia i zgodności będą decydować o tym, gdzie wykonasz zakończenie szyfrowania TLS.
Przepływ ruchu wychodzącego
Wszystkie wskazówki zawarte w artykule Punkt odniesienia usługi AKS mają zastosowanie tutaj z dodatkowym zaleceniem dla obciążeń systemu Windows: Aby korzystać z automatycznych aktualizacji systemu Windows Server, nie można blokować wymaganych nazw FQDN w zestawie reguł usługi Azure Firewall.
Uwaga
Użycie oddzielnych pul węzłów dla obciążeń opartych na systemie Linux i Windows wymaga użycia selektora węzłów, aby upewnić się, że podczas wdrażania danego obciążenia jest wdrażana w odpowiedniej puli węzłów na podstawie typu obciążenia.
Planowanie adresów IP
W przeciwieństwie do klastrów usługi AKS z pulami węzłów systemu Linux klastry usługi AKS z pulami węzłów systemu Windows wymagają usługi Azure CNI. Korzystanie z sieci CNI platformy Azure umożliwia przypisanie zasobnika adresu IP z sieci wirtualnej platformy Azure. Zasobnik może następnie komunikować się za pośrednictwem usługi Azure Virtual Network tak samo jak w przypadku każdego innego urządzenia. Może łączyć się z innymi zasobnikami, sieciami równorzędnymi lub sieciami lokalnymi przy użyciu usługi ExpressRoute lub sieci VPN albo z innymi usługami platformy Azure przy użyciu usługi Private Link.
Wszystkie wskazówki dotyczące planowania adresów IP podanych w artykule Dotyczącym architektury punktu odniesienia usługi AKS dotyczą jednego dodatkowego zalecenia: rozważ aprowizowanie dedykowanej podsieci dla kontrolerów domeny. W odniesieniu do puli węzłów systemu Windows zaleca się oddzielenie ich od innych pul węzłów logicznie za pośrednictwem oddzielnych podsieci.
Uaktualnianie puli węzłów
Proces uaktualniania węzłów systemu Windows nie zmienił się od wskazówek podanych w dokumentacji uaktualniania obrazu węzła usługi Azure Kubernetes Service (AKS), ale należy wziąć pod uwagę następujące różnice w harmonogramie planowania cykli uaktualniania.
Firma Microsoft udostępnia nowe obrazy systemu Windows Server, w tym aktualne poprawki, dla węzłów co miesiąc i nie wykonuje żadnych automatycznych poprawek ani aktualizacji. W związku z tym należy ręcznie lub programowo zaktualizować węzły zgodnie z tym harmonogramem. Użycie funkcji GitHub Actions do utworzenia zadania cron uruchamianego zgodnie z harmonogramem umożliwia programowe planowanie miesięcznych uaktualnień. Wskazówki podane w powyższej dokumentacji odzwierciedlają procesy węzłów systemu Linux, ale możesz zaktualizować plik YAML, aby ustawić harmonogram cron tak, aby był uruchamiany co miesiąc, a nie dwutygodnie. Należy również zmienić parametr "runs-on" w pliku YAML na "windows-latest", aby upewnić się, że uaktualniasz do najnowszego obrazu systemu Windows Server.
Aby uzyskać dodatkowe wskazówki, zobacz przewodnik operatora usługi AKS dotyczący stosowania poprawek i aktualizacji węzła roboczego.
Uwaga
Przed wykonaniem uaktualnień węzłów i puli węzłów należy uaktualnić klastry. Postępuj zgodnie ze wskazówkami dotyczącymi uaktualniania klastra , aby przeprowadzić uaktualnienie.
Zagadnienia dotyczące obliczeń
Większe rozmiary obrazów skojarzone z obrazami opartymi na serwerze systemu Windows wymagają wdrożenia odpowiednio rozmiarów dysków systemu operacyjnego w puli węzłów. Korzystanie z efemerycznych dysków systemu operacyjnego jest nadal zalecane dla wszystkich węzłów, w tym systemu Windows, dlatego upewnij się, że rozumiesz wymagania dotyczące rozmiaru, które należy spełnić podczas planowania wdrożenia.
Zarządzanie tożsamościami
Kontenery systemu Windows nie mogą być przyłączone do domeny, więc jeśli potrzebujesz uwierzytelniania i autoryzacji usługi Active Directory, możesz użyć kont usług zarządzanych przez grupę (gMSA). Aby można było używać konta gMSA, należy włączyć profil gMSA w klastrze usługi AKS z uruchomionymi węzłami systemu Windows. Zapoznaj się z dokumentacją usługi AKS usługi gMSA, aby zapoznać się z pełną recenzją architektury i przewodnikiem dotyczącym włączania profilu.
Skalowanie węzłów i zasobników
Wskazówki dotyczące automatycznego skalowania klastra są niezmienione dla kontenerów systemu Windows. Aby uzyskać wskazówki, zapoznaj się z dokumentacją narzędzia do automatycznego skalowania klastra.
W dokumentacji klastra bazowego opisano metody ręcznego i automatycznego skalowania, które są dostępne na potrzeby skalowania zasobników. Oba podejścia są dostępne dla klastrów z kontenerami systemu Windows i wskazówki podane w tym artykule mają również zastosowanie tutaj.
To, co różni się między kontenerami systemu Linux i Windows w odniesieniu do operacji skalowania zasobników, jest rozmiar obrazu w większości przypadków. Większe rozmiary obrazów kontenerów systemu Windows prawdopodobnie zwiększą ilość czasu na ukończenie operacji skalowania i dlatego należy wziąć pod uwagę pewne zagadnienia dotyczące podejścia do skalowania. Ten scenariusz jest typowy w przypadku starszych aplikacji .NET ze względu na rozmiar środowiska uruchomieniowego platformy .NET. Aby ograniczyć opóźnienia ściągania obrazu w dół w czasie skalowania, można użyć elementu DaemonSet , aby ściągnąć obraz z usługi ACR do pamięci podręcznej na każdym węźle systemu Windows, a tym samym uruchomić zasobniki ze wstępnie załadowanym obrazem. Od tego momentu zasobniki muszą jedynie uruchomić procesy konfiguracji aplikacji zdefiniowane dla obciążenia przed przełączeniem do trybu online.
Ćwiczenia porównawcze należy wykonać, aby zrozumieć wpływ czasu wykonywania operacji skalowania, a te dane powinny być ważone zgodnie z wymaganiami biznesowymi. Jeśli obciążenie musi być skalowane szybciej niż jest to możliwe za pomocą skalowania automatycznego, zaleca się rozważenie następującego alternatywnego rozwiązania "hot spare":
Najpierw należy przeprowadzić testy bazowe, aby określić, ile zasobników trzeba będzie uruchamiać w godzinach szczytowego obciążenia i poza szczytowym czasem ładowania. Po ustanowieniu tego punktu odniesienia można zaplanować liczbę węzłów, aby uwzględnić łączną liczbę węzłów, które będą dostępne w danym momencie. To rozwiązanie obejmuje ręczne skalowanie klastra i ustawienie początkowej liczby węzłów na wymaganą liczbę węzłów poza szczytową liczbą węzłów. W przypadku zbliżania się do okresu szczytowego konieczne będzie wstępne skalowanie do maksymalnej liczby węzłów w czasie szczytowego obciążenia. W miarę upływu czasu należy regularnie ponownie ustanowić punkt odniesienia, aby uwzględnić zmianę użycia aplikacji lub innych wymagań biznesowych.
Monitorowanie
Kontenery z systemem Windows można monitorować za pomocą usług Azure Monitor i Container Szczegółowe informacje, podobnie jak kontenery systemu Linux. W związku z tym wskazówki zawarte w artykule Punkt odniesienia usługi AKS mają zastosowanie również w większości przypadków. Jednak monitorowanie kontenera Szczegółowe informacje dla klastra systemu Windows Server ma następujące ograniczenia:
- System Windows nie ma metryki RSS pamięci. W związku z tym nie jest dostępna dla węzłów i kontenerów systemu Windows. Metryka Zestawu roboczego jest dostępna
- Informacje o pojemności magazynu dysku nie są dostępne dla węzłów systemu Windows.
Możesz również uzupełnić Szczegółowe informacje kontenerów przy użyciu reguł zbierania danych w celu zbierania zdarzeń i liczników wydajności z systemów Windows Server.
Uwaga
Usługa Container Insights dla systemu operacyjnego Windows Server 2022 jest dostępna w publicznej wersji zapoznawczej.
Zarządzanie zasadami
Wszystkie wskazówki dotyczące zasad znalezione w artykule Punkt odniesienia usługi AKS dotyczą obciążeń systemu Windows. Dodatkowe zasady specyficzne dla systemu Windows znajdujące się we wbudowanych definicjach usługi Azure Policy dla usługi Azure Kubernetes Service , które należy wziąć pod uwagę, to:
- Kontenery klastra Kubernetes systemu Windows nie powinny nadmiernie zatwierdzać procesora CPU i pamięci
- Kontenery systemu Windows klastra Kubernetes nie powinny działać jako kontener Administracja istrator
- Kontenery systemu Windows klastra Kubernetes powinny być uruchamiane tylko z zatwierdzoną grupą użytkowników i domeny
Uruchamianie klastra
Podobnie jak w przypadku wskazówek dotyczących uruchamiania klastra podanych w artykule Punkt odniesienia usługi AKS, operatorzy klastrów powinni rozważyć podejście do uruchamiania obciążeń opartych na systemie Windows. Te same wskazówki podane w artykule Punkt odniesienia usługi AKS mają zastosowanie również tutaj.
Zarządzanie kosztami
Wszystkie wskazówki dotyczące optymalizacji kosztów znalezione w artykule Punkt odniesienia usługi AKS dotyczą obciążeń systemu Windows. Inne zagadnienia dotyczące kosztów, które należy uwzględnić, to:
- Koszty licencjonowania systemu Windows Server zwiększają koszt węzłów klastra usługi AKS. Zalecenia dotyczące optymalizacji kosztów dla tego czynnika obejmują rezerwowanie pojemności lub używanie istniejących licencji, jeśli masz je już do innych zastosowań biznesowych.
- Zapoznaj się z dokumentacją Korzyść użycia hybrydowego platformy Azure dla systemu Windows Server (AHUB), aby dowiedzieć się więcej o rabatach dotyczących licencji programu Software Assurance (SA) odpowiednich dla systemu Windows Server.
- Zapoznaj się z często zadawanymi pytaniami dotyczącymi kontenerów systemu Windows Server, aby uzyskać instrukcje dotyczące stosowania korzyści do nowych i istniejących klastrów.
- Rozmiar obrazów kontenerów systemu Windows może wiązać się z dodatkowymi kosztami usługi Azure Container Registry (ACR) ze względu na ilość miejsca wymaganego dla wielu obrazów, liczbę współbieżnych węzłów ściągniętych z wymagań usługi ACR i replikacji geograficznej.
Współautorzy
Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.
Autorzy zabezpieczeń:
- Isabelle Bersano | Architekt rozwiązań w chmurze
- Akshay Nimbalkar | Główny architekt rozwiązań w chmurze
- Clayton Siemens | Główny deweloper zawartości
Aby wyświetlić niepubalne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.
Następne kroki
- Dowiedz się więcej o kontenerach systemu Windows
Powiązane zasoby
- Dowiedz się, jak wdrożyć pule węzłów systemu Windows w klastrze usługi AKS