Niezawodność w Azure Application Gateway dla kontenerów

Azure Application Gateway for Containers to zarządzana usługa równoważenia obciążenia i dynamicznego zarządzania ruchem w warstwie aplikacji (warstwa 7) dla obciążeń uruchomionych na platformie Kubernetes. Kieruje przychodzące żądania do celów backendu w klastrze.

W przypadku korzystania z platformy Azure niezawodność jest wspólną odpowiedzialnością. Microsoft oferuje szereg funkcjonalności wspierających odporność i odzyskiwanie. Odpowiadasz za zrozumienie, jak te możliwości działają w ramach wszystkich używanych usług oraz za wybór tych, które są potrzebne do osiągnięcia Twoich celów biznesowych i celów dotyczących niezawodności.

W tym artykule opisano, jak Azure Application Gateway for Containers obsługuje błędy przejściowe, błędy strefy dostępności, awarie całego regionu i konserwację usługi. W tym artykule opisano również opcje tworzenia i przywracania kopii zapasowych oraz kluczowe informacje o umowie dotyczącej poziomu usług (SLA).

Zalecenia dotyczące wdrażania produkcyjnego pod kątem niezawodności

Usługa Application Gateway dla kontenerów jest domyślnie wysoce dostępna. W przypadku obciążeń produkcyjnych:

Aby zapoznać się z przykładową architekturą i wskazówkami dotyczącymi topologii, przepływu ruchu, niezawodności, zabezpieczeń i operacji, zobacz Deploy Application Gateway for Containers on Azure Kubernetes Service.

Omówienie architektury niezawodności

W tej sekcji opisano niektóre ważne aspekty działania usługi, które są najbardziej istotne z perspektywy niezawodności. W sekcji przedstawiono architekturę logiczną, która zawiera niektóre z zasobów i funkcji wdrażanych i używanych. Omówiono również architekturę fizyczną, która zawiera szczegółowe informacje na temat działania usługi za kulisami.

Architektura logiczna

Wdrożenie usługi Application Gateway for Containers obejmuje zasoby w Azure i w klastrze Kubernetes.

  • Zasoby platformy Azure:płaszczyzna sterowania organizuje konfigurację serwera proxy bramy na podstawie konfiguracji. Płaszczyzna danych zarządzana Azure działa poza klastrem i przetwarza ruch aplikacji.
  • Zasoby platformy Kubernetes: Routing i inne konfiguracje definiuje się przy użyciu zasobów platformy Kubernetes. Kontroler usługi ALB działa w klastrze, obserwuje te zasoby i propaguje konfigurację do usługi Application Gateway for Containers w Azure.

Można wybrać między dwiema strategiami wdrażania. Dzięki strategii bring your own (BYO) można zarządzać cyklem życia usługi Application Gateway for Containers, skojarzenia i zasobów frontonu za pomocą narzędzi Azure. Dzięki strategii zarządzanej przez kontroler ALB kontroler usługi ALB zarządza cyklem życia tych zasobów Azure na podstawie zdefiniowanych zasobów Kubernetes.

Pełny opis składników można znaleźć w temacie Application Gateway for Containers components.

Po wdrożeniu i skonfigurowaniu usługa Application Gateway dla kontenerów kieruje przychodzące żądania do elementów docelowych zaplecza, które reprezentują aplikację działającą w ramach platformy Kubernetes.

Jeśli kontroler usługi ALB lub płaszczyzna sterowania jest niedostępna, płaszczyzna danych nadal przetwarza ruch przy użyciu ostatniej pomyślnie zastosowanej konfiguracji. Podczas awarii aktualizacje konfiguracji nie są propagowane, a usługa nie może zastosować konfiguracji wymaganej do zdarzeń skalowania w poziomie.

Architektura fizyczna

Azure zarządza infrastrukturą płaszczyzny danych i automatycznie skaluje infrastrukturę na podstawie ruchu aplikacji. Usługa Application Gateway dla kontenerów jest zawsze wdrażana w konfiguracji o wysokiej dostępności: w regionach obsługujących strefy dostępności bramy są strefowo nadmiarowe; w regionach, które nie obsługują stref dostępności, Azure używa zestawów dostępności.

Odporność na błędy przejściowe

Błędy przejściowe to krótkotrwałe, sporadyczne awarie w komponentach. Występują one często w środowisku rozproszonym, takich jak chmura, i są one normalną częścią operacji. Błędy przejściowe naprawiają się po krótkim czasie. Ważne jest, aby aplikacje mogły obsługiwać błędy przejściowe, zwykle ponawiając próby żądań, których dotyczy problem.

Wszystkie aplikacje hostowane w chmurze powinny postępować zgodnie ze wskazówkami dotyczącymi obsługi błędów przejściowych platformy Azure podczas komunikowania się z dowolnymi interfejsami API hostowanymi w chmurze, bazami danych i innymi składnikami. Aby uzyskać więcej informacji, zobacz Zalecenia dotyczące obsługi błędów przejściowych.

W przypadku korzystania z usługi Application Gateway dla kontenerów należy wziąć pod uwagę następujące najlepsze rozwiązania:

  • Zaimplementuj logikę ponawiania prób. Skonfiguruj klientów, aby ponawiać żądania po przejściowych błędach połączenia.

  • Skonfiguruj sondy zdrowotne z tolerancją. Jeśli skonfigurujesz niestandardowe sondy kondycji, ustaw próg stanu niezdrowego, aby tolerować błędy przejściowe. Próg niezdrowego stanu określa liczbę kolejnych nieudanych sond, które powodują oznaczenie celu zaplecza jako będącego w niezdrowym stanie. Domyślna sonda kondycji używa progu niezdrowia wynoszącego trzy sondy, co pomaga zapobiec oznaczeniu backendu jako niezdrowego z powodu pojedynczego przejściowego niepowodzenia sondy.

Odporność na błędy strefy dostępności

Strefy dostępności są fizycznie oddzielnymi grupami centrów danych w regionie świadczenia usługi Azure. Gdy jedna strefa ulegnie awarii, usługi mogą przejść w tryb failover do jednej z pozostałych stref.

Podczas wdrażania usługi Application Gateway for Containers w regionie Azure obsługującym strefy dostępności Microsoft automatycznie konfiguruje płaszczyznę sterowania i płaszczyznę danych jako strefowo nadmiarową w wielu strefach. Nie wybierasz stref używanych przez usługę.

Important

Microsoft zarządza nadmiarowością strefową dla płaszczyzny sterowania i płaszczyzny danych usługi Application Gateway for Containers. Aby uzyskać kompleksową odporność między strefami, skonfiguruj klaster Kubernetes, zasoby Kubernetes i obciążenia zaplecza, aby zapewnić sprawne zasoby docelowe we wszystkich strefach.

Requirements

Obsługa regionów: Aby użyć nadmiarowości strefy, wybierz region obsługujący zarówno usługę Application Gateway for Containers, jak i strefy dostępności. Sprawdź dostępność regionów usługi Application Gateway dla kontenerów i porównaj ją z listą regionów obsługujących strefy dostępności.

Considerations

Wspólna odpowiedzialność za platformę Kubernetes: Microsoft zarządza przekierowywaniem ruchu dla usługi Application Gateway for Containers podczas awarii strefy. W przypadku Azure Kubernetes Service (AKS) Microsoft zarządza płaszczyzną sterowania Platformy Kubernetes. Odpowiadasz za konfigurowanie odporności na awarie stref dla pul węzłów klastra i innych zasobów, którymi zarządzasz, oraz za zachowanie aplikacji podczas awarii strefy.

  • Klaster: Skonfiguruj pule węzłów usługi AKS i inne zasoby klastra powiązane ze strefami, którymi zarządzasz, tak aby obejmowały strefy dostępności. Usługa AKS zarządza płaszczyzną sterowania; Zobacz Konfigurowanie stref dostępności dla pul węzłów usługi AKS.

  • Obciążenia robocze: Odpowiadasz za wdrażanie wielu replik zasobników, rozłożenie ich między strefy i zapewnienie, że obciążenia zaplecza w dobrej kondycji są dostępne do obsługi ruchu podczas awarii strefy. Można użyć pul węzłów obejmujących strefy dostępności, ograniczeń rozkładu topologicznego i antyafinity podów.

  • Obiekty konfiguracji platformy Kubernetes: Usługa Application Gateway for Containers używa obiektów konfiguracji platformy Kubernetes przechowywanych przez interfejs API klastra. Ich dostępność zależy od płaszczyzny kontrolnej Kubernetes i konfiguracji, którą zarządzasz w swoim klastrze.

  • Kontroler usługi ALB: Aby uzgodnić konfigurację, należy wdrożyć kontroler usługi ALB w klastrze Kubernetes. Nie jest częścią ścieżki danych usługi Application Gateway for Containers.

    Kontroler usługi ALB uruchamia dwie repliki, z których jedna działa jako lider, a druga jako pomocnicza. Jeśli lider stanie się niedostępny, węzeł pomocniczy może stać się liderem i kontynuować propagację konfiguracji. Obie repliki mogą działać w tej samej strefie dostępności, w zależności od tego, jak klaster je rozmieszcza. Odpowiadasz za konfigurowanie zasobników klastra i zasobników kontrolera pod kątem odporności na awarie stref. Użyj ograniczeń rozprzestrzeniania topologii poda lub antyafinity poda, aby dystrybuować repliki między strefami. Aby uzyskać więcej informacji, zobacz Konfigurowanie stref dostępności dla pul węzłów usługi AKS.

Cost

Obsługa strefy dostępności dla usługi Application Gateway dla kontenerów nie powoduje naliczania dodatkowych opłat poza standardowymi cenami usług. Aby uzyskać szczegółowe informacje o cenach, zobacz Azure Application Gateway cennik.

Konfiguruj obsługę stref dostępności

Podczas wdrażania nowej bramy w obsługiwanym regionie jest ona domyślnie strefowo nadmiarowa. Nie trzeba włączać nadmiarowości strefowej w zasobach Azure.

Odpowiadasz za konfigurowanie klastra Kubernetes, kontrolera usługi ALB i obciążeń zaplecza pod kątem odporności na awarie stref.

Zachowanie, gdy wszystkie strefy są w dobrej kondycji

W tej sekcji opisano, czego można oczekiwać podczas wdrażania usługi Application Gateway for Containers w regionie obsługującym strefy dostępności oraz gdy wszystkie strefy używane przez usługę są sprawne.

  • Działanie między strefami: Płaszczyzna danych usługi Application Gateway for Containers zarządzana przez platformę Azure dystrybuuje żądania przychodzące w infrastrukturze w wielu strefach.

    Odpowiadasz za skonfigurowanie obciążeń zaplecza do uruchamiania w różnych strefach i zapewnienie sprawnych celów do odbierania tego ruchu.

  • Replikacja danych między strefami: Usługa Application Gateway for Containers nie przechowuje danych aplikacji. Platforma zarządza stanem konfiguracji za pośrednictwem strefowo nadmiarowej płaszczyzny sterowania w celu zapewnienia trwałości i odporności.

Zachowanie podczas awarii strefy

W tej sekcji opisano, czego można oczekiwać podczas wdrażania usługi Application Gateway for Containers w regionie obsługującym strefy dostępności, gdy jedna ze stref używanych przez usługę ulegnie awarii.

  • Wykrywanie i reagowanie: Usługa Application Gateway dla kontenerów przekierowuje ruch do infrastruktury w pozostałych strefach w dobrej kondycji podczas awarii strefy. Nie musisz podejmować działań w związku z ponowną dystrybucją ruchu bramy.

    Jednak odpowiadasz za wpływ awarii na klaster Kubernetes i aplikacje zaplecza.

  • Powiadomienie: Firma Microsoft nie powiadamia cię automatycznie, gdy strefa nie działa. Można jednak użyć Azure Service Health aby zrozumieć ogólną kondycję usługi, w tym wszelkie błędy strefy, i skonfigurować alerty Service Health w celu powiadamiania o problemach.

  • Aktywne żądania: Istniejące połączenia ze strefą, która uległa awarii, są porzucane. Klienci powinni ponowić żądania, postępując zgodnie ze wskazówkami w temacie Odporność na błędy przejściowe. Nowe połączenia są ustanawiane z infrastrukturą w pozostałych sprawnych strefach.

  • Oczekiwana utrata danych: Usługa Application Gateway for Containers nie przechowuje danych aplikacji. Platforma zarządza stanem konfiguracji za pośrednictwem strefowo nadmiarowej płaszczyzny sterowania w celu zapewnienia trwałości i odporności.

  • Oczekiwany przestój: Klienci mogą napotkać krótką przerwę w działaniu, gdy połączenia ze strefą, która uległa awarii, zostaną zerwane. Klienci powinni ponowić żądania w celu ustanowienia nowych połączeń z infrastrukturą w pozostałych sprawnych strefach.

    Warstwa sterowania zarządzana przez Azure pozostaje dostępna podczas awarii jednej strefy. Jednak możliwość stosowania aktualizacji konfiguracji zależy również od dostępności płaszczyzny sterowania Kubernetes i kontrolera ALB.

  • Redystrybucja: Usługa Application Gateway dla kontenerów przekierowuje ruch do infrastruktury w pozostałych zdrowych strefach.

Odzyskiwanie strefy

Usługa Application Gateway dla kontenerów samoczynnie odzyskuje sprawność po problemach leżących u podstaw. Azure zarządza przywracaniem infrastruktury bramy.

Testowanie pod kątem niepowodzeń strefy

Platforma Application Gateway for Containers zarządza routingiem ruchu i obsługą awarii stref dla samej bramy. Nie musisz inicjować odpowiedzi bramy ani zarządzać nią. Jeśli masz klaster Kubernetes, którym zarządzasz, możesz użyć Azure Chaos Studio do przetestowania odpowiedzi klastra na awarie stref. Aby uzyskać więcej informacji, zobacz Testowanie odporności strefy dostępności.

Odporność na awarie całego regionu

Usługa Application Gateway for Containers to usługa jednoregionowa. Jeśli region Azure, w którym wdrożono bramę, stanie się niedostępny, ta brama będzie niedostępna.

Niestandardowe rozwiązania wieloregionowe zapewniające odporność

Usługa Application Gateway dla kontenerów nie zapewnia wbudowanego wdrożenia w wielu regionach ani rozwiązania trybu failover. Aby przygotować system na awarię regionu, wdróż i skonfiguruj oddzielną bramę i klaster Kubernetes w każdym regionie. Odpowiadasz za kierowanie ruchem między bramami regionalnymi i konfigurowanie trybu failover.

  • Skonfiguruj usługę Application Gateway dla kontenerów spójnie w różnych regionach. Aby uprościć wdrożenia i zachować dopasowanie konfiguracji, zdefiniuj infrastrukturę jako kod (IaC) przy użyciu narzędzi, takich jak Bicep lub Terraform.

  • Wybierz i skonfiguruj globalną usługę zarządzania ruchem, taką jak Azure Front Door lub Azure Traffic Manager, aby skierować klientów do bram regionalnych. Te usługi korzystają z różnych modeli routingu i konfiguracji sond monitorowania kondycji. Skonfiguruj wybraną usługę tak, aby kierowała ruch z dala od niedostępnej bramy, i przejrzyj jej dokumentację, aby zrozumieć zachowanie routingu i zagadnienia dotyczące trybu failover. Azure Front Door oferuje również funkcje, takie jak rozproszona ochrona przed atakami typu „odmowa usługi” (DDoS), możliwości zapory aplikacji internetowej (WAF) i trasowanie oparte na regułach.

  • Wdróż aplikacje zaplecza w każdym regionie i skonfiguruj je w celu zapewnienia prawidłowego działania obciążeń podczas awarii. Jeśli Twoje aplikacje zależą od danych lub innych usług Azure, zaprojektuj i skonfiguruj te usługi pod kątem dostępności w wielu regionach. Zapoznaj się ze wskazówkami dotyczącymi niezawodności każdej usługi, aby poznać jej opcje wieloregionalne i ograniczenia.

Tworzenie kopii zapasowej i przywracanie

Usługa Application Gateway for Containers nie przechowuje danych aplikacji. Azure Resource Manager przechowuje konfigurację zasobów Azure bramy. Możesz ponownie utworzyć te zasoby, ponownie wdrażając ich konfigurację.

Odpowiadasz za utrzymanie konfiguracji i zasobów platformy Kubernetes definiujących sposób wdrażania bramy i kierowania ruchem:

  • Zdefiniuj zasoby Azure i ich ustawienia w infrastrukturze jako kod (IaC), takie jak Bicep lub Terraform, i zachowaj definicje w kontroli wersji. Można ich użyć do ponownego wdrożenia zasobów bramy.

  • Wykonaj kopię zapasową zasobów platformy Kubernetes, które konfigurują bramę, takich jak zasoby ApplicationLoadBalancer, Gateway i HTTPRoute. Przywróć je do klastra, gdy musisz ponownie utworzyć konfigurację routingu.

  • Zachowaj powiązaną konfigurację, w tym reguły niestandardowe i zasady zapory aplikacji internetowej, w kontroli wersji lub za pośrednictwem standardowego procesu tworzenia kopii zapasowej konfiguracji. Potoki wdrażania umożliwiają spójne odtwarzanie zasobów Azure i Kubernetes.

Odporność usługi na prace konserwacyjne

Microsoft zarządza konserwacją usługi Application Gateway dla kontenerów przy zachowaniu wysokiej dostępności usługi.

Wymagany minimalny rozmiar podsieci /24 dla każdego skojarzenia uwzględnia okna konserwacyjne, więc nie trzeba przydzielać dodatkowej przestrzeni adresów IP podsieci na potrzeby konserwacji.

Aby uzyskać więcej informacji, zobacz Skalowanie i dostępność dla usługi Application Gateway dla kontenerów.

Umowa dotycząca poziomu usług

Umowa dotycząca poziomu usług (SLA) dla usług platformy Azure opisuje oczekiwaną dostępność każdej usługi oraz warunki, które rozwiązanie musi spełnić, aby osiągnąć te oczekiwania dotyczące dostępności. Aby uzyskać więcej informacji, zobacz Umowy SLA dotyczące usług online.

W umowie SLA usługi Application Gateway for Containers oddzielnie ocenia się płaszczyznę sterowania i płaszczyznę danych. Oba poziomy są uwzględniane w ogólnym obliczaniu wskaźnika SLA.

Treści powiązane

  • Ostatnia aktualizacja o