Edytuj

Udostępnij za pośrednictwem

Niebieskie wdrożenie klastrów usługi AKS

Azure Kubernetes Service (AKS)
Azure Application Gateway
Azure Container Registry
Azure Front Door
Azure DNS

Ten artykuł zawiera wskazówki dotyczące implementowania strategii wdrażania niebieskiego zielonego w celu przetestowania nowej wersji klastra usługi Azure Kubernetes Service (AKS) podczas kontynuowania działania bieżącej wersji. Po zweryfikowaniu nowej wersji zmiana routingu przełącza do niego ruch użytkowników. Wdrażanie w ten sposób zwiększa dostępność podczas wprowadzania zmian, w tym uaktualnień, do klastrów usługi AKS. W tym artykule opisano projekt i implementację niebieskiego zielonego wdrożenia usługi AKS, które korzysta z usług zarządzanych platformy Azure i natywnych funkcji platformy Kubernetes.

Architektura

W tej sekcji opisano architektury dla niebieskiego zielonego wdrożenia klastrów usługi AKS. Są dwa przypadki:

  • Aplikacje i interfejsy API są dostępne publicznie.
  • Aplikacje i interfejsy API są dostępne prywatnie.

Istnieje również przypadek hybrydowy, który nie został omówiony w tym miejscu, w którym w klastrze istnieje połączenie aplikacji i interfejsów API przeznaczonych dla użytkowników publicznych i prywatnych.

Na poniższym diagramie przedstawiono architekturę dla przypadku publicznego:

Diagram architektury publicznej.

Pobierz plik programu Visio z tą architekturą.

Usługi Azure Front Door i Azure DNS zapewniają mechanizm routingu, który przełącza ruch między niebieskimi i zielonymi klastrami. Aby uzyskać więcej informacji, zobacz Blue-green deployment with Azure Front Door (Niebieskie wdrożenie za pomocą usługi Azure Front Door). Za pomocą usługi Azure Front Door można zaimplementować przełącznik pełny lub bardziej kontrolowany przełącznik oparty na wagach. Ta technika jest najbardziej niezawodna i wydajna w środowisku platformy Azure. Jeśli chcesz użyć własnego systemu DNS i modułu równoważenia obciążenia, upewnij się, że zostały skonfigurowane w celu zapewnienia bezpiecznego i niezawodnego przełącznika.

aplikacja systemu Azure Gateway udostępnia frontony przeznaczone dla publicznych punktów końcowych.

Ten diagram dotyczy przypadku prywatnego:

Diagram architektury prywatnej.

Pobierz plik programu Visio z tą architekturą.

W tym przypadku pojedyncze wystąpienie usługi Azure DNS implementuje przełączanie ruchu między niebieskimi i zielonymi klastrami. Odbywa się to przy użyciu rekordów A i .CNAME Aby uzyskać szczegółowe informacje, zobacz sekcję T3: Przełączanie ruchu do zielonego klastra.

Usługa Application Gateway udostępnia frontony przeznaczone dla prywatnych punktów końcowych.

Przepływ pracy

W przypadku wdrożenia niebieskiego zielonego istnieje pięć etapów aktualizowania bieżącej wersji klastra do nowej wersji. W naszym opisie niebieski klaster jest bieżącą wersją, a zielony klaster jest nowym klastrem.

Etapy to:

  1. T0: Niebieski klaster jest włączony.
  2. T1: Wdróż zielony klaster.
  3. T2: Zsynchronizuj stan kubernetes między niebieskimi i zielonymi klastrami.
  4. T3: Przełącz ruch do zielonego klastra.
  5. T4: Zniszcz niebieski klaster.

Gdy nowa wersja będzie aktywna, stanie się ona niebieskim klastrem dla każdej zmiany lub aktualizacji.

Klastry niebieskie i zielone działają w tym samym czasie, ale tylko przez ograniczony czas, co optymalizuje koszty i działania operacyjne.

Wyzwalacze przejścia

Wyzwalacze przejścia z etapu do etapu można zautomatyzować. Dopóki nie zostanie to osiągnięte, niektóre lub wszystkie z nich są ręczne. Wyzwalacze są powiązane z:

  • Określone metryki obciążenia, cele poziomu usług (SLO) i umowy dotyczące poziomu usług (SLA): są one używane głównie na etapie T3 w celu zweryfikowania ogólnego stanu klastra usługi AKS przed przełączeniem ruchu.
  • Metryki platformy Azure: służą one do oceny stanu i kondycji obciążeń oraz klastra usługi AKS. Są one używane we wszystkich przejściach.

Odnajdywanie sieci klastrów

Możliwości odnajdywania sieci dla klastrów można uzyskać w następujący sposób:

  • Mają rekordy DNS wskazujące klastry. Na przykład:

    • aks-blue.contoso.com wskazuje prywatny lub publiczny adres IP niebieskiego klastra.
    • aks-green.contoso.com wskazuje prywatny lub publiczny adres IP klastra zielonego.

    Następnie możesz użyć tych nazw hostów bezpośrednio lub w konfiguracji puli zaplecza bramy aplikacji, która znajduje się przed każdym klastrem.

  • Mają rekordy DNS wskazujące bramy aplikacji. Na przykład:

    • aks-blue.contoso.com wskazuje prywatny lub publiczny adres IP bramy aplikacji, który ma jako pulę zaplecza prywatny lub publiczny adres IP niebieskiego klastra.
    • aks-green.contoso.com wskazuje prywatny lub publiczny adres IP bramy aplikacji, który ma jako pulę zaplecza prywatny lub publiczny adres IP klastra zielonego.

T0: Niebieski klaster jest włączony

Początkowy etap T0 oznacza, że niebieski klaster jest aktywny. Ten etap przygotowuje nową wersję klastra do wdrożenia.

Diagram etapu T0: niebieski klaster jest włączony.

Warunek wyzwalacza dla etapu T1 to wydanie nowej wersji klastra — zielonego klastra.

T1: Wdrażanie zielonego klastra

Ten etap rozpoczyna wdrażanie nowego zielonego klastra. Niebieski klaster pozostaje włączony, a ruch na żywo jest nadal kierowany do niego.

Diagram etapu T1: wdrożenie klastra zielonego.

Wyzwalacz, który ma przejść do etapu T2, to weryfikacja zielonego klastra AKS na poziomie platformy. Walidacja używa metryk usługi Azure Monitor i poleceń interfejsu wiersza polecenia w celu sprawdzenia kondycji wdrożenia. Aby uzyskać więcej informacji, zobacz Monitoring Azure Kubernetes Service (AKS) with Monitor and Monitoring AKS data reference (Monitorowanie i monitorowanie danych usługi AKS).

Monitorowanie usługi AKS można podzielić na różne poziomy, jak pokazano na poniższym diagramie:

Diagram poziomów monitorowania usługi AKS.

Kondycja klastra jest oceniana na poziomie 1 i 2, a na pewnym poziomie 3. W przypadku poziomu 1 można użyć natywnego widoku z wieloma klastrami z monitora, aby zweryfikować kondycję, jak pokazano poniżej:

Zrzut ekranu przedstawiający monitorowanie klastrów monitorowania.

Na poziomie 2 upewnij się, że serwer interfejsu API Kubernetes i rozwiązanie Kubelet działają prawidłowo. Możesz użyć skoroszytu Kubelet w monitorze, w szczególności dwie siatki skoroszytu, które pokazują kluczowe statystyki operacyjne węzłów:

  • Omówienie siatki węzłów podsumowuje łączną operację, łączną liczbę błędów i pomyślne operacje według procentu i trendu dla każdego węzła.
  • Omówienie siatki typu operacji zawiera informacje o poszczególnych typach operacji, liczbie operacji, błędach i pomyślnych operacjach według procentu i trendu.

Poziom 3 jest przeznaczony dla obiektów i aplikacji Kubernetes, które są domyślnie wdrażane w usłudze AKS, takich jak omsagent, kube-proxy itd. Na potrzeby tego sprawdzenia możesz użyć widoku Szczegółowe informacje monitora, aby sprawdzić stan wdrożeń usługi AKS:

Zrzut ekranu przedstawiający widok Monitorowanie szczegółowych informacji.

Alternatywnie możesz użyć dedykowanego skoroszytu udokumentowanego w temacie Wdrażanie i metryki HPA za pomocą szczegółowych informacji o kontenerze. Oto przykład:

Zrzut ekranu przedstawiający dedykowany skoroszyt.

Po pomyślnym zakończeniu walidacji można przejść do etapu T2.

T2: Synchronizowanie stanu platformy Kubernetes między niebieskimi i zielonymi klastrami

Na tym etapie aplikacje, operatory i zasoby kubernetes nie są jeszcze wdrażane w zielonym klastrze lub przynajmniej nie wszystkie z nich mają zastosowanie i są wdrażane podczas aprowizowania klastra usługi AKS. Ostatecznym celem tego etapu jest to, że na końcu synchronizacji zielony klaster jest zgodny z niebieskim. Jeśli tak, można zweryfikować stan nowego klastra przed przełączeniem ruchu do zielonego klastra.

Istnieją różne sposoby synchronizowania stanu platformy Kubernetes między klastrami:

  • Ponowne wdrażanie za pośrednictwem ciągłej integracji i ciągłego dostarczania (CI/CD). Zazwyczaj wystarczy użyć tych samych potoków ciągłej integracji/ciągłego wdrażania, które są używane do normalnego wdrażania aplikacji. Typowe narzędzia do wykonywania tych czynności to: GitHub Actions, Azure DevOps i Jenkins.
  • GitOps z rozwiązaniami promowanymi w witrynie internetowej Cloud Native Computing Foundation (CNCF), takimi jak Flux i ArgoCD.
  • Dostosowane rozwiązanie, które przechowuje konfiguracje i zasoby platformy Kubernetes w magazynie danych. Zazwyczaj te rozwiązania są oparte na generatorach manifestów Kubernetes, które zaczynają się od definicji metadanych, a następnie przechowują wygenerowane manifesty Kubernetes w magazynie danych, takim jak Azure Cosmos DB. Są to zazwyczaj rozwiązania niestandardowe oparte na używanej strukturze opisu aplikacji.

Na poniższym diagramie przedstawiono proces synchronizacji stanu platformy Kubernetes:

Diagram etapu T2: zsynchronizuj stan kubernetes między niebieskimi i zielonymi klastrami.

Zazwyczaj podczas synchronizacji wdrażanie nowych wersji aplikacji nie jest dozwolone w klastrze na żywo. Ten okres rozpoczyna się od synchronizacji i kończy się po zakończeniu przełączania do zielonego klastra. Sposób wyłączenia wdrożeń na platformie Kubernetes może się różnić. Istnieją dwa możliwe rozwiązania:

  • Wyłącz potoki wdrażania.

  • Wyłącz konto usługi Kubernetes, które wykonuje wdrożenia.

    Można zautomatyzować wyłączenie konta usługi przy użyciu agenta open policy (OPA). Nie można jeszcze używać funkcji natywnych usługi AKS, ponieważ są one nadal dostępne w wersji zapoznawczej.

Okres synchronizacji można uniknąć przy użyciu zaawansowanych mechanizmów, które zarządzają stanem kubernetes w wielu klastrach.

Po zakończeniu synchronizacji wymagana jest weryfikacja klastra i aplikacji. Obejmuje to:

  • Sprawdzanie platform monitorowania i rejestrowania w celu zweryfikowania kondycji klastra. Możesz rozważyć wykonanie czynności w etapie T1: Wdrażanie zielonego klastra .
  • Testowanie funkcjonalne aplikacji na podstawie aktualnie używanego łańcucha narzędzi.

Zalecamy również wykonanie sesji testu obciążeniowego w celu porównania wydajności aplikacji klastra zielonego z punktem odniesienia wydajności. Możesz użyć preferowanego narzędzia lub testowania obciążenia platformy Azure.

Zazwyczaj zielony klaster jest uwidoczniony w bramie aplikacji lub zewnętrznym module równoważenia obciążenia z wewnętrznym adresem URL, który nie jest widoczny dla użytkowników zewnętrznych.

Po zweryfikowaniu nowego klastra możesz przejść do następnego etapu, aby przełączyć ruch do nowego klastra.

T3: Przełącz ruch do zielonego klastra

Po zakończeniu synchronizacji, a zielony klaster jest weryfikowany na poziomie platformy i aplikacji, jest gotowy do podwyższenia poziomu do klastra podstawowego i rozpoczęcia odbierania ruchu na żywo. Przełącznik jest wykonywany na poziomie sieci. Często obciążenia są bezstanowe. Jeśli jednak obciążenia są stanowe, należy zaimplementować dodatkowe rozwiązanie w celu zachowania stanu i buforowania podczas przełączania.

Oto diagram przedstawiający stan docelowy po zastosowaniu przełącznika:

Diagram etapu T3: zielony przełącznik ruchu klastra.

Techniki opisane w tym artykule implementują pełne przełączniki: 100% ruchu jest kierowane do nowego klastra. Jest to spowodowane tym, że routing jest stosowany na poziomie DNS przy użyciu A przypisania rekordu lub CNAME zaktualizowanego w celu wskazania zielonego klastra i istnieje brama aplikacji dla każdego klastra.

Oto przykład konfiguracji przełączania prywatnych punktów końcowych. Proponowane rozwiązanie używa A rekordów do przełączenia. Z perspektywy mapowania dns i adresu IP sytuacja jest następująca przed przełącznikiem:

  • A rekord aks.priv.contoso.com wskazuje prywatny adres IP niebieskiej bramy aplikacji.
  • A rekord aks-blue.priv.contoso.com wskazuje prywatny adres IP niebieskiej bramy aplikacji.
  • A rekord aks-green.priv.contoso.com wskazuje prywatny adres IP zielonej bramy aplikacji.

Przełącznik zmienia konfigurację na następujące elementy:

  • A rekord aks.priv.contoso.com wskazuje prywatny adres IP zielonej bramy aplikacji.
  • A rekord aks-blue.priv.contoso.com wskazuje prywatny adres IP niebieskiej bramy aplikacji.
  • A rekord aks-green.priv.contoso.com wskazuje prywatny adres IP zielonej bramy aplikacji.

Użytkownicy klastrów zobaczą przełącznik po czasie wygaśnięcia (TTL) i propagację DNS rekordów.

W przypadku publicznych punktów końcowych zalecane podejście korzysta z usług Azure Front Door i Azure DNS. Poniżej przedstawiono konfigurację przed przełącznikiem:

Przełącznik zmienia konfigurację na następujące elementy:

  • CNAME rekord official-aks.contoso.com wskazuje rekord automatycznie wygenerowanej domeny usługi Azure Front Door.
  • A rekord aks.contoso.com wskazuje publiczny adres IP zielonej bramy aplikacji.
  • Konfiguracja źródła usługi Azure Front Door wskazuje aks.contoso.com nazwę hosta.
    • A rekord aks-blue.contoso.com wskazuje publiczny adres IP niebieskiej bramy aplikacji.
    • A rekord aks-green.contoso.com wskazuje publiczny adres IP zielonej bramy aplikacji.

Alternatywne techniki przełączania, takie jak przełączniki częściowe dla wydań kanarowych, są możliwe w przypadku dodatkowych usług platformy Azure, takich jak Azure Front Door lub Traffic Manager. Aby uzyskać informacje na temat implementacji przełącznika ruchu niebieskiego na poziomie usługi Azure Front Door, zobacz Blue-green deployment with Azure Front Door (Wdrażanie niebieski-zielony za pomocą usługi Azure Front Door).

Jak opisano w przykładzie, z perspektywy sieci ta technika jest oparta na definicji czterech nazw hostów:

  • Oficjalna publiczna nazwa hosta: oficjalna publiczna nazwa hosta używana przez użytkowników końcowych i użytkowników końcowych.
  • Nazwa hosta klastra: oficjalna nazwa hosta używana przez użytkowników obciążeń hostowanych w klastrach.
  • Nazwa hosta klastra niebieskiego: dedykowana nazwa hosta dla niebieskiego klastra.
  • Nazwa hosta klastra zielonego: dedykowana nazwa hosta dla zielonego klastra.

Nazwa hosta klastra to nazwa skonfigurowana na poziomie bramy aplikacji do zarządzania ruchem przychodzącym. Nazwa hosta jest również częścią konfiguracji ruchu przychodzącego usługi AKS w celu prawidłowego zarządzania protokołem Transport Layer Security (TLS). Ten host jest używany tylko w przypadku transakcji i żądań na żywo.

Jeśli usługa Azure Front Door jest również częścią wdrożenia, nie ma to wpływu na przełącznik, ponieważ zarządza tylko oficjalną nazwą hosta klastra. Zapewnia ona właściwą abstrakcję dla użytkowników aplikacji. Nie mają one wpływu na przełącznik, ponieważ rekord DNS CNAME zawsze wskazuje usługę Azure Front Door.

Nazwy hostów niebieskiego i zielonego klastra są używane głównie do testowania i weryfikowania klastrów. W tych celach nazwy hostów są widoczne na poziomie bramy aplikacji z dedykowanymi punktami końcowymi, a także na poziomie kontrolera ruchu przychodzącego usługi AKS w celu prawidłowego zarządzania protokołem TLS.

Na tym etapie weryfikacja jest oparta na metrykach monitorowania infrastruktury i aplikacji oraz na oficjalnym poziomie slo i umowie SLA, jeśli jest dostępna. Jeśli walidacja zakończy się pomyślnie, przejdź do ostatniego etapu, aby zniszczyć niebieski klaster.

T4: Niszczenie niebieskiego klastra

Pomyślne przełączenie ruchu powoduje przejście do ostatniego etapu, w którym nadal występuje walidacja i monitorowanie w celu zapewnienia, że zielony klaster działa zgodnie z oczekiwaniami w przypadku ruchu na żywo. Walidacja i monitorowanie obejmują zarówno platformę, jak i poziom aplikacji.

Po zakończeniu weryfikacji można zniszczyć niebieski klaster. Zniszczenie to krok, który jest zdecydowanie zalecany w celu zmniejszenia kosztów i odpowiedniego wykorzystania elastyczności zapewnianej przez platformę Azure, szczególnie usługi AKS.

Oto sytuacja po zniszczeniu niebieskiego klastra:

Diagram etapu T4: niebieski klaster jest niszczony.

Składniki

  • Usługa Application Gateway to moduł równoważenia obciążenia ruchu internetowego (WARSTWA 7) OSI, który umożliwia zarządzanie ruchem do aplikacji internetowych. W tym rozwiązaniu jest używana jako brama dla ruchu HTTP w celu uzyskania dostępu do klastrów usługi AKS.
  • Azure Kubernetes Service (AKS) to zarządzana usługa Kubernetes, której można użyć do wdrażania konteneryzowanych aplikacji i zarządzania nimi. Ta platforma aplikacji jest głównym składnikiem tego wzorca.
  • Azure Container Registry to zarządzana usługa służąca do przechowywania obrazów kontenerów i powiązanych artefaktów oraz zarządzania nimi. W tym rozwiązaniu można przechowywać i rozpowszechniać obrazy kontenerów oraz artefakty, takie jak wykresy Helm, w klastrach usługi AKS.
  • Usługa Azure Monitor to rozwiązanie do monitorowania służące do zbierania, analizowania i reagowania na dane monitorowania ze środowisk w chmurze i środowiskach lokalnych. Udostępnia podstawowe funkcje monitorowania wymagane do wykonania niebieskiego zielonego wdrożenia. Jest on używany w tej architekturze ze względu na integrację z usługą AKS i możliwość zapewniania możliwości rejestrowania, monitorowania i alertów, które mogą służyć do zarządzania przejściami etapu.
  • Usługa Azure Key Vault pomaga rozwiązać następujące problemy: Zarządzanie wpisami tajnymi, zarządzanie kluczami i zarządzanie certyfikatami; służy do przechowywania wpisów tajnych i certyfikatów wymaganych na poziomie platfomr i aplikacji dla tego rozwiązania oraz zarządzania nimi.
  • Usługa Azure Front Door to globalny moduł równoważenia obciążenia i system zarządzania punktami końcowymi aplikacji. Jest on używany w tym rozwiązaniu jako publiczny punkt końcowy dla aplikacji HTTP hostowanych w usłudze AKS. W tym rozwiązaniu ma krytyczne znaczenie dla zarządzania przełączaniem ruchu między niebieskimi i zielonymi bramami aplikacji.
  • Azure DNS to usługa hostingu dla domen DNS, która zapewnia rozpoznawanie nazw przy użyciu infrastruktury platformy Microsoft Azure. Zarządza ona nazwami hostów, które są używane w rozwiązaniu dla niebieskich i zielonych klastrów, i odgrywa ważną rolę w przełącznikach ruchu, szczególnie w przypadku prywatnych punktów końcowych.

Alternatywy

  • Istnieją alternatywne techniki implementowania przełączników ruchu, które mogą zapewnić większą kontrolę. Na przykład można wykonać przełącznik częściowy przy użyciu reguł ruchu opartych na co najmniej jednej z następujących czynności:
    • Procent ruchu przychodzącego
    • Nagłówki HTTP
    • Pliki cookie
  • Inną alternatywą, która zapewnia większą ochronę przed problemami spowodowanymi zmianami, jest wdrożenie oparte na pierścieniu. Zamiast tylko niebieskich i zielonych klastrów, można mieć więcej klastrów nazywanych pierścieniami. Każdy pierścień jest wystarczająco duży dla liczby użytkowników, którzy mają dostęp do nowej wersji usługi AKS. Jeśli chodzi o wdrożenie niebiesko-zielone opisane w tym miejscu, pierścienie można usunąć, aby mieć odpowiednią optymalizację kosztów i kontrolę.
  • Możliwe alternatywy dla usługi Application Gateway to NGINX i HAProxy.
  • Możliwą alternatywą dla usługi Container Registry jest Port.
  • W niektórych okolicznościach można użyć różnych usług równoważenia obciążenia i usług DNS do wykonywania przełączników ruchu, a nie usług Azure Front Door i Azure DNS.
  • To rozwiązanie jest oparte na standardowych interfejsach API kontrolera ruchu przychodzącego Kubernetes. Jeśli rozwiązanie skorzystałoby zamiast tego z interfejsu API bramy, użyj usługi Application Gateway dla kontenerów. Może pomóc w zarządzaniu równoważeniem obciążenia i obsługą zarządzania ruchem przychodzącym między usługą Application Gateway i zasobnikami. Usługa Application Gateway for Containers kontroluje ustawienia bram aplikacji.

Szczegóły scenariusza

Główne zalety rozwiązania to:

  • Zminimalizowany przestój podczas wdrażania.
  • Strategia planowanego wycofywania.
  • Ulepszona kontrola i operacje podczas wydawania i wdrażania zmian i uaktualnień usługi AKS.
  • Testowanie potrzeby wykonywania procedur odzyskiwania po awarii (DR).

Kluczowe zasady i podstawowe aspekty wdrażania niebieski-zielony zostały omówione w następujących artykułach:

Z perspektywy automatyzacji i ciągłej integracji/ciągłego wdrażania rozwiązanie można zaimplementować na wiele sposobów. Sugerujemy:

Potencjalne przypadki użycia

Wdrożenie niebiesko-zielone umożliwia wprowadzanie zmian w klastrach bez wpływu na uruchomione aplikacje i obciążenia. Przykłady zmian to:

  • Zmiany operacyjne
  • Aktywowanie nowych funkcji usługi AKS
  • Zmiany w zasobach udostępnionych w klastrach
  • Aktualizowanie wersji rozwiązania Kubernetes
  • Modyfikowanie zasobów i obiektów platformy Kubernetes, takich jak brama ruchu przychodzącego, siatka usługi, operatory, zasady sieciowe itd.
  • Powrót do poprzedniej wersji klastra usługi AKS, który jest nadal wdrożony, bez wpływu na obciążenia uruchomione w klastrze

Kwestie wymagające rozważenia

Te zagadnienia implementują filary struktury Azure Well-Architected Framework, która jest zestawem wytycznych, które mogą służyć do poprawy jakości obciążenia. Aby uzyskać więcej informacji, zobacz Microsoft Azure Well-Architected Framework.

  • Wdrożenie niebiesko-zielone może być w pełni zautomatyzowane, takie jak wdrożenie bezobsługowe. Zazwyczaj początkowa implementacja ma wyzwalacze ręczne, aby aktywować etapy. Po drodze i z odpowiednimi funkcjami dojrzałości i monitorowania można zautomatyzować wyzwalacze. Oznacza to, że istnieje zautomatyzowane testowanie i określone metryki, umowa SLA i slo w celu zautomatyzowania wyzwalaczy.
  • Ważne jest, aby mieć dedykowane nazwy hostów dla niebieskich i zielonych klastrów, a także mieć dedykowane konfiguracje punktów końcowych w bramach i modułach równoważenia obciążenia, które znajdują się przed klastrami. Ma to kluczowe znaczenie dla poprawy niezawodności i poprawności wdrożenia nowego klastra. W ten sposób weryfikacja wdrożenia odbywa się przy użyciu tej samej architektury i konfiguracji standardowego klastra produkcyjnego.
  • Rozważ sytuację, w której klastry usługi AKS są zasobami udostępnionymi dla wielu aplikacji zarządzanych przez różne jednostki biznesowe. W takich przypadkach często platforma AKS jest zarządzana przez dedykowany zespół odpowiedzialny za ogólną operację i cykl życia klastrów oraz że istnieją punkty końcowe w klastrach na potrzeby administratora i operacji. Sugerujemy, że te punkty końcowe mają dedykowany kontroler ruchu przychodzącego w klastrach usługi AKS w celu zapewnienia prawidłowego rozdzielenia problemów i niezawodności.
  • Wdrożenie niebiesko-zielone jest przydatne do implementowania i testowania rozwiązań dotyczących ciągłości działania i odzyskiwania po awarii (BC/DR) dla usługi AKS i powiązanych obciążeń. W szczególności zapewnia podstawowe struktury zarządzania wieloma klastrami, w tym przypadki, w których klastry są rozłożone między wiele regionów.
  • Sukces z niebieskim zielonym wdrożeniem polega na zastosowaniu wszystkich aspektów implementacji, takich jak automatyzacja, monitorowanie i walidacja, nie tylko na platformie AKS, ale także na obciążeniach i aplikacjach wdrożonych na platformie. Dzięki temu można uzyskać maksymalną korzyść z wdrożenia niebieskiego zielonego.
  • W proponowanym rozwiązaniu istnieją dwie bramy aplikacji na każdy scenariusz publiczny i prywatny, więc łącznie cztery. Ta decyzja polega na zastosowaniu niebieskiego zielonego wdrożenia na poziomie bramy aplikacja systemu Azure, aby uniknąć przestojów spowodowanych błędną konfiguracją bram. Główną wadą tej decyzji jest koszt, ponieważ istnieją cztery wystąpienia usługi Application Gateway. Są one uruchamiane równolegle tylko w okresie, w którym istnieją istotne zmiany konfiguracji usługi Application Gateway, takie jak zasady zapory aplikacji internetowej lub konfiguracja skalowania. W celu dalszej optymalizacji kosztów można wybrać pojedynczą usługę Application Gateway dla każdego scenariusza, oznacza to, że w sumie dwie usługi Application Gateway. Będzie to wymagało przeniesienia logiki niebieskiej/zielonej do bramy aplikacji zamiast usługi Azure Front Door. Dlatego zamiast kontrolować usługę Azure Front Door, usługa Application Gateway jest niezbędna.

Niezawodność

Niezawodność gwarantuje, że aplikacja może spełnić zobowiązania wobec klientów. Aby uzyskać więcej informacji, zobacz Omówienie filaru niezawodności.

  • Wdrożenie niebiesko-zielone ma bezpośredni i pozytywny wpływ na dostępność platformy i obciążeń usługi AKS. W szczególności zwiększa dostępność podczas wdrażania zmian platformy AKS. Brak przestoju, jeśli sesje użytkowników są zarządzane prawidłowo.
  • Wdrożenie niebiesko-zielone zapewnia pokrycie niezawodności podczas wdrażania, ponieważ domyślnie istnieje możliwość wycofania się z poprzedniej wersji klastra usługi AKS, jeśli coś pójdzie nie tak w nowej wersji klastra.

Optymalizacja kosztów

Optymalizacja kosztów dotyczy sposobów zmniejszenia niepotrzebnych wydatków i poprawy wydajności operacyjnej. Aby uzyskać więcej informacji, zobacz Omówienie filaru optymalizacji kosztów.

  • Wdrożenie niebiesko-zielone jest powszechnie stosowane na platformie Azure ze względu na natywną elastyczność zapewnianą przez chmurę. Dzięki temu można optymalizować koszty w zakresie operacji i zużycia zasobów. Większość oszczędności wynika z usunięcia klastra, który nie jest już potrzebny po pomyślnym wdrożeniu nowej wersji klastra.
  • Po wdrożeniu nowej wersji typowe jest hostowanie zarówno niebieskich, jak i zielonych klastrów w tej samej podsieci, aby nadal mieć ten sam koszt bazowy. Wszystkie połączenia sieciowe i dostęp do zasobów i usług są takie same dla dwóch klastrów, a wszystkie usługi i zasoby platformy Azure pozostają takie same.

Doskonałość operacyjna

Doskonałość operacyjna obejmuje procesy operacyjne, które wdrażają aplikację i działają w środowisku produkcyjnym. Aby uzyskać więcej informacji, zobacz Omówienie filaru doskonałości operacyjnej.

  • Wdrożenie niebiesko-zielone, właściwie zaimplementowane, zapewnia automatyzację, ciągłe dostarczanie i odporne wdrażanie.
  • Jednym z kluczowych aspektów ciągłego dostarczania jest iteracyjne dostarczanie przyrostów zmian platformy i obciążeń. Dzięki niebieskiemu zielonemu wdrożeniu usługi AKS można osiągnąć ciągłe dostarczanie na poziomie platformy w kontrolowany i bezpieczny sposób.
  • Odporność ma podstawowe znaczenie dla wdrożenia niebieskiego zielonego, ponieważ obejmuje opcję wycofania się z poprzedniego klastra.
  • Wdrożenie niebiesko-zielone zapewnia odpowiedni poziom automatyzacji, aby zmniejszyć nakład pracy związany ze strategią ciągłości działania.
  • Monitorowanie platformy i aplikacji ma kluczowe znaczenie dla pomyślnej implementacji. W przypadku platformy można używać natywnych funkcji monitorowania platformy Azure. W przypadku aplikacji monitorowanie musi być zaprojektowane i zaimplementowane.

Wdrażanie tego scenariusza

Aby zapoznać się z zaimplementowanym przykładem wdrożenia niebieskiego zielonego opisanego w tym przewodniku, zobacz AKS Landing Zone Accelerator (Akcelerator strefy docelowej usługi AKS).

Ta implementacja referencyjna jest oparta na usłudze Application Gateway i kontrolerze ruchu przychodzącego usługi Application Gateway (AGIC). Każdy klaster ma własną bramę aplikacji, a przełącznik ruchu odbywa się za pośrednictwem systemu DNS, w szczególności za pośrednictwem CNAME konfiguracji.

Ważne

W przypadku obciążeń o znaczeniu krytycznym ważne jest połączenie wdrożeń niebieskich/zielonych zgodnie z opisem w tym przewodniku z automatyzacją wdrażania i ciągłą walidacją w celu osiągnięcia wdrożeń bez przestojów. Więcej informacji i wskazówek można znaleźć w metodologii projektowania o znaczeniu krytycznym.

Zagadnienia dotyczące regionów

Możesz wdrożyć niebieskie i zielone klastry w oddzielnych regionach lub w tym samym regionie. Te zasady projektowania i działania nie mają wpływu na ten wybór. Można jednak mieć wpływ na niektóre typy dodatkowych konfiguracji sieci, takich jak:

  • Dedykowana sieć wirtualna i podsieć dla usługi AKS i bramy aplikacji.
  • Połączenie z usługami zapasowymi, takimi jak Monitor, Container Registry i Key Vault.
  • Widoczność bramy aplikacji w usłudze Azure Front Door.

Istnieją wymagania wstępne dotyczące wdrażania w tym samym regionie:

  • Sieci wirtualne i podsieci muszą mieć rozmiar, aby hostować dwa klastry.
  • Subskrypcja platformy Azure musi zapewnić wystarczającą pojemność dla dwóch klastrów.

Wdrażanie kontrolera ruchu przychodzącego i zewnętrznych modułów równoważenia obciążenia

Istnieją różne podejścia do wdrażania kontrolera ruchu przychodzącego i zewnętrznych modułów równoważenia obciążenia:

  • Możesz mieć jeden kontroler ruchu przychodzącego z dedykowanym zewnętrznym modułem równoważenia obciążenia, takim jak implementacja referencyjna architektury opisanej w tym przewodniku. AGIC to aplikacja Kubernetes, która umożliwia korzystanie z modułu równoważenia obciążenia usługi Application Gateway L7 w celu uwidaczniania oprogramowania w chmurze do Internetu. W niektórych scenariuszach oprócz punktów końcowych aplikacji istnieją punkty końcowe administratora w klastrach usługi AKS. Punkty końcowe administratora służą do wykonywania zadań operacyjnych w aplikacjach lub zadań konfiguracyjnych, takich jak aktualizowanie map konfiguracji, wpisów tajnych, zasad sieciowych i manifestów.
  • Można mieć jeden zewnętrzny moduł równoważenia obciążenia, który obsługuje wiele kontrolerów ruchu przychodzącego wdrożonych w tym samym klastrze lub w wielu klastrach. Takie podejście nie jest omówione w implementacji referencyjnej. W tym scenariuszu zalecamy posiadanie oddzielnych bram aplikacji dla publicznych punktów końcowych i prywatnych.
  • Wynikowa architektura, która jest proponowana i przedstawiona w tym przewodniku, jest oparta na standardowym kontrolerze ruchu przychodzącego wdrożonym w ramach klastra usługi AKS, takim jak NGINX i Envoy . W implementacji referencyjnej używamy programu AGIC, co oznacza, że istnieje bezpośrednie połączenie między bramą aplikacji a zasobnikami usługi AKS, ale nie ma to wpływu na ogólną architekturę niebiesko-zieloną.

Współautorzy

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

Autorzy zabezpieczeń:

Inni współautorzy:

Aby wyświetlić niepubalne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Następne kroki