Wysoka dostępność dla wielowarstwowych aplikacji usługi AKS

Azure Cosmos DB

Azure Disk Storage

Azure Files

Azure Kubernetes Service (AKS)

Azure Load Balancer

W tym przewodniku omówiono wysoką dostępność dla wielowarstwowego wdrażania aplikacji w klastrach usługi Azure Kubernetes Service (AKS). W tym artykule opisano mechanizmy i konstrukcje platformy Kubernetes HA oraz podano listę kontrolną i wytyczne umożliwiające identyfikowanie i eliminowanie pojedynczych punktów awarii wysokiej dostępności.

Istnieją dwa podstawowe zadania implementowania wysokiej dostępności dla aplikacji usługi AKS.

• Zidentyfikuj wszystkie pojedyncze punkty awarii w aplikacji.
• Eliminowanie pojedynczych punktów awarii.

Wyeliminowanie pojedynczych punktów awarii wymaga rozwiązania wysokiej dostępności.

Cztery filary wysokiej dostępności

Cztery filary wysokiej dostępności pojawiają się w każdym systemie o wysokiej dostępności:

• Nadmiarowość
• Monitorowanie
• Odzyskiwania
• Punktowanie kontrolne

Rozważ wielowarstwową aplikację usługi AKS, w której ruch dociera do warstwy logiki biznesowej, warstwa danych zachowuje stan, a aplikacja zwraca odpowiedzi użytkownikom.

Identyfikowanie pojedynczych punktów awarii

Aby zidentyfikować pojedyncze punkty awarii, zacznij od określenia ścieżki krytycznej między żądaniami klienta a składnikami obsługującymi te żądania. Każdy składnik na tej ścieżce, który nie jest zarządzany zgodnie z czterema filarami wysokiej dostępności, lub trzema filarami, jeśli jest to składnik bezstanowy bez tworzenia punktów kontrolnych, jest pojedynczym punktem awarii. Nawet zreplikowany składnik jest uważany za pojedynczy punkt awarii, jeśli nie jest monitorowany, ponieważ jego awaria jest dyskretnie niezakryta.

Eliminowanie pojedynczych punktów awarii

Aby wyeliminować pojedyncze punkty awarii, wdróż aplikację w celu replikacji składników ścieżki krytycznej i zastosuj mechanizmy równoważenia obciążenia, monitorowania i odzyskiwania. Platforma Kubernetes może obsługiwać wszystkie te działania.

Pobierz plik programu Visio z tego diagramu.

W replikowanej aplikacji:

• Składniki warstwy biznesowej są replikowane z różnymi liczbami replik na składnik w zależności od ich wydajności i obciążenia.
• Można również replikować warstwę danych za modułem równoważenia obciążenia.

Platforma Kubernetes oferuje kilka konstrukcji i mechanizmów, takich jak równoważenie obciążenia i sondy utrzymania, które pomagają zaimplementować filary wysokiej dostępności. Poniższa lista kontrolna i dyskusja dzielą te konstrukcje i mechanizmy na kategorie, które są mapujące na cztery filary wysokiej dostępności.

Lista kontrolna platformy Kubernetes HA

Poza zarządzaniem stanem platforma Kubernetes wykonuje wyjątkowe zadanie utrzymania wysokiej dostępności aplikacji. Lista kontrolna wysokiej dostępności zawiera listę typowych konfiguracji, których można użyć do optymalizacji zarządzania wysoką dostępnością platformy Kubernetes. Aby użyć listy kontrolnej, oceń wdrożenie platformy Kubernetes pod kątem następujących mechanizmów i konstrukcji oraz zaimplementuj brakujące elementy.

Filar wysokiej dostępności	Rozwiązanie
Nadmiarowość	☐ Typ kontrolera Kubernetes ☐ Liczba replik ☐ Planowanie koligacji anty-koligacji
Monitorowanie	☐ Sondy liveness ☐ Sondy gotowości ☐ Sondy uruchamiania
Odzyskiwanie	☐ Typ usługi ☐ Wybory lidera ☐ Zasady ponownego uruchamiania ☐ Zaczepy przed zatrzymaniem
Tworzenie punktów kontrolnych	☐ Oświadczenia trwałego woluminu ☐ Woluminy trwałe

Nadmiarowość

Nadmiarowość ogranicza liczbę pojedynczych punktów awarii. Potrzebna jest nadmiarowość we wszystkich warstwach aplikacji. Aby uzyskać nadmiarowość, replikujesz składnik danej warstwy z co najmniej jedną identyczną repliką.

• Typ kontrolera, konfiguracja kind: Deployment. Platforma Kubernetes oferuje kilka kontrolerów, które mogą zarządzać cyklem życia zasobnika aplikacji. Najpopularniejszym kontrolerem Deploymentjest . Inne kontrolery obejmują Statefulsetelement , który przydaje się, gdy ważne jest zachowanie tożsamości zasobnika po odzyskiwaniu. Inne kontrolery, takie jak Replicasets nie oferują tych samych przydatnych funkcji, takich jak wycofywanie, które oferuje wdrożenie.

• Liczba replik, konfiguracja spec.replicas. Ustawienie liczby replik na tylko jedną jest celową decyzją o użyciu modelu rezerwy zimnej. Rezerwa zimna oznacza, że gdy wystąpi awaria, nowe wystąpienie zaczyna się od podstaw, co wpływa na dostępność. Ten model może działać w przypadku składników z obciążeniami o małym woluminie, ale należy rozważyć replikowanie składników bezstanowych i dużych woluminów.

  Określając limity żądań zasobów, spec.containers[].resourcesmożna dodać skalowanie automatyczne zasobnika poziomego (HPA), co powoduje automatyczne skalowanie platformy Kubernetes w górę lub w dół liczby replik na podstawie zdefiniowanych progów wykorzystania zasobów. HpA pomaga uniknąć przypadków, w których wzrost obciążenia uniemożliwia aplikacji obsługę żądań z powodu przeciążenia.

• Planowanie koligacji, konfiguracji spec.affinity.podAntiAffinity. Typowy klaster Kubernetes na poziomie produkcyjnym ma węzły rozmieszczone w wielu strefach dostępności wyrażonych przy użyciu klasy topologyKey. Zasobniki tego samego wdrożenia powinny mieć preferowaną lub miękką anty-koligację ze sobą. Ta konfiguracja gwarantuje, że zasobniki są zaplanowane na węzłach w różnych strefach dostępności.

  Klaster usługi AKS może mieć wiele pul węzłów, z których każdy ma różne rozmiary i specyfikacje zestawu skalowania maszyn wirtualnych. Można na przykład hostować zasobniki bazy danych na węzłach z szybkimi dyskami półprzewodnikowymi (SSD) i hostować zasobniki uczenia maszynowego na węzłach za pomocą procesorów graficznych (GPU).

Monitorowanie

Bez monitorowania nadmiarowość może stać się nieskuteczna. Potrzebujesz stałego mechanizmu monitorowania, aby upewnić się, że obciążenie osiąga replikę w dobrej kondycji.

• Sondy aktualności, konfiguracja spec.containers.livenessProbe, monitoruj kondycję zasobników. Jeśli kontener ulegnie awarii lub zakończy działanie, platforma Kubernetes może go wykryć. Gdy działanie zakończy się niepowodzeniem, platforma Kubernetes ponownie uruchomi kontener.

• Sondy gotowości, konfiguracja spec.containers.readinessProbe, określają, czy ruch ma być wysyłany do zasobnika. Jeśli jakiekolwiek zasobniki wdrożenia nie są gotowe, nie będą one częścią punktów końcowych usługi Kubernetes abstrakcji wdrożenia i dlatego nie będą przydatne. Ważne jest, aby dokładnie ustawić sondy gotowości, ponieważ nie wyzwalają ponownego uruchomienia, ale są używane do odizolowania zasobników od odbierania ruchu, dopóki nie będą gotowe.

• Sondy uruchamiania, konfiguracja spec.containers.startupProbe, głównie zapobiegają fałszywie dodatnim gotowości i żywotności w aplikacjach wolno uruchamianych. Gdy sonda startowa zakończyła się pomyślnie, sonda liveness się rozpocznie.

Platforma Azure oferuje bardziej szczegółowe informacje , które umożliwiają ustawianie alertów na podstawie kondycji klastra.

Odzyskiwanie

Głównym celem monitorowania jest wyzwolenie odzyskiwania po wykryciu awarii. Proces odzyskiwania obejmuje trzy fazy:

1. Izoluj i przekieruj: upewnij się, że wadliwa replika nie odbiera ruchu i kieruje obciążenie do replik w dobrej kondycji.
2. Naprawa: Uruchom ponownie wadliwą replikę, która może naprawiać błędy przejściowe.
3. Ponownie dołącz: po naprawie, jeśli monitorowanie uzna replikę za w dobrej kondycji, ponownie dołącz replikę do innych replik w obsłudze obciążenia.

• Typ usługi, konfiguracja spec.type. Uwidacznianie zasobników za pośrednictwem usługi może być klasyfikowane w ramach nadmiarowości, a także odzyskiwania. Jednak w niektórych przypadkach może istnieć wdrożenie z jedną repliką. Nadal istnieją korzyści wynikające z uwidaczniania zasobników za pośrednictwem usługi, mimo że nie ma równoważenia obciążenia.

  Główną zaletą usługi jest to, że wpisy usługi nazw domen (DNS) są automatycznie aktualizowane przy użyciu punktów końcowych usługi Kubernetes. Zasobnik z kontenerami z sondami gotowości z niepowodzeniem nie będzie odbierać ruchu za pośrednictwem usługi AKS. Mimo że możliwość równoważenia obciążenia usług IP klastra Kubernetes jest podstawowa, można połączyć bezgłówną usługę z przychodzącymi lub innymi rozwiązaniami siatki usług, aby lepiej zrównoważyć rozkład obciążenia.

  Jak ruch zewnętrzny dociera do klastra usługi AKS, znajduje się poza zakresem rozwiązania Kubernetes. Ruch zewnętrzny można obsługiwać za pomocą usług, takich jak aplikacja systemu Azure Gateway.

• Wybory lidera. Niektóre składniki są najlepiej wdrażane jako pojedynczetony. Harmonogram jest takim składnikiem, ponieważ dwa aktywne harmonogramy mogą powodować konflikt. Posiadanie pojedynczego elementu uwidacznia aplikację w przypadku problemów z zimnym wstrzymaniem. Aby włączyć ciepłe wstrzymanie zasobnika, możesz użyć wyborów lidera, gdzie tylko jeden zasobnik, lider, obsługuje żądania.

• Uruchom ponownie zasady, konfigurację spec.restartPolicy. Zasady ponownego uruchamiania dotyczą wszystkich kontenerów w zasobniku. Powinno istnieć prawidłowe uzasadnienie ustawienia tego atrybutu na Never. Niektóre kontenery kontaktują się z serwerem licencji za każdym razem, gdy się uruchamiają, i możesz uniknąć dodanych kosztów nadmiernego ponownego uruchamiania.

• Wstępne zatrzymywanie punktów zaczepienia, konfiguracja spec.containers.lifecycle.preStop. Przed uruchomieniem punktów zaczepienia przed wysłaniem SIGTERM sygnału do kontenera. Skrypt przed zatrzymaniem może być tak prosty, jak 30-sekundowe polecenie uśpienia.

  Na przykład gdy aplikacja zarządzana przez aplikację HPA jest skalowana w dół, żądania w toku mogą zostać nagle zakończone, chyba że aplikacja ma SIGTERM program obsługi, który kończy obsługę przed zakończeniem wykonywania żądań. Punkt końcowy zasobnika przed zatrzymaniem usuwa punkt końcowy zasobnika, a w związku z tym wpis DNS z punktu końcowego usługi. Gdy punkt zaczepienia przed zatrzymaniem jest uruchomiony, do zasobnika nie można wysyłać żadnych nowych żądań. Punkt zaczepienia przed zatrzymaniem umożliwia zasobnikowi zakończenie przetwarzania żądań w toku bez odbierania nowych. Wstępnie zatrzymane haki to prosty sposób zminimalizowania porzuconych żądań bez modyfikowania kodu aplikacji.

Tworzenie punktów kontrolnych

Nowoczesne aplikacje mają wiele składników bezstanowych, ale całkowicie bezstanowe aplikacje są nadal rzadkie. Większość aplikacji sprawdza ich stan w warstwie danych. Platforma Kubernetes celowo nie udostępnia żadnego mechanizmu do obsługi stanu aplikacji. Zarządzanie stanem to złożone zadanie, które nie jest częścią zarządzania kontenerami.

Stan aplikacji można utrwalać na trzech poziomach:

• Poziom rekordów danych przechowuje dane w bazie danych. Każdy rekord bazy danych może być replikowany w wielu wystąpieniach bazy danych. Rekordy bazy danych są dominującą formą trwałości stanu, szczególnie w zarządzanych bazach danych w chmurze, takich jak Azure Cosmos DB.

• Poziom systemu plików zwykle replikuje pliki danych, takie jak pliki rejestrowania z wyprzedzeniem (WAL, write-ahead logging). Większość dostawców usług w chmurze oferuje wtyczki dla swoich rozwiązań, takich jak Azure Files.

• Poziom dysku utrzymuje dane na poziomie bloku, co zapewnia elastyczność definiowania systemu plików do użycia, jak w usłudze Azure Disk Storage.

Woluminy Kubernetes , woluminy trwałe i trwałe oświadczenia woluminów mogą utrwalać stan aplikacji na poziomie systemu plików lub dysku. Najczęstszym wzorcem przechowywania stanu jest nadal poziom rekordów danych.

Wysoka dostępność i odzyskiwanie po awarii

Zarówno w przypadku wysokiej dostępności, jak i odzyskiwania po awarii (DR) wybór rozwiązań topologii sieci i równoważenia obciążenia jest ważny.

Jednak odzyskiwanie po awarii wymaga wdrożenia usługi w wielu regionach na całym poziomie usługi z rozwiązaniami równoważenia obciążenia między regionami platformy Azure. Aplikacja jest rozłożona na wiele regionów lub całe wystąpienie aplikacji jest wdrażane w każdym regionie. Wybór zależy od typu aplikacji, architektury aplikacji i tolerancji opóźnień między składnikami.

Zamiast korzystać z wielu regionów, wysoka dostępność korzysta z wdrożeń wielostrefowych w regionach świadczenia usługi Azure. Na poniższym diagramie przedstawiono różnicę między strefami dostępności i regionami wysokiej dostępności i odzyskiwania po awarii.

Pobierz plik programu Visio z tą architekturą.

Ten przewodnik koncentruje się na wysokiej dostępności na poziomie aplikacji w ramach jednego klastra usługi AKS. Aby uzyskać więcej informacji na temat odzyskiwania po awarii w wdrożeniach wieloklastrowych usługi AKS, zobacz Punkt odniesienia usługi AKS dla klastrów wieloregionowych.

Inne uwagi

• Aby zachować wysoką dostępność aplikacji, upewnij się, że płaszczyzna sterowania platformy Kubernetes, w tym serwer interfejsu API i menedżer kontrolera, jest wysoce dostępna. Rozważ użycie umowy SLA czasu pracy usługi AKS, aby zapewnić wysoką dostępność.

• Strategia konsolidacji zasobów bezpośrednio narusza filar nadmiarowości wysokiej dostępności. W związku z tym należy dokładnie przeanalizować koszt nadmiarowości. Kalkulator cen platformy Azure może pomóc.

Współautorzy

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

Główny autor:

• Ali Kanso | Główny inżynier oprogramowania

Inni współautorzy:

• Karthik Sankara Subramanian | Inżynier oprogramowania II
• Kinshuman Patra | Menedżer inżynierów grup partnerskich
• Ayobami Ayodeji | Starszy menedżer programu
• Oscar L Pla Alvarez | Architekt rozwiązań domeny

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

Następne kroki

• Wzorzec klastra Kubernetes o wysokiej dostępności
• Regiony i strefy dostępności
• Limity przydziału, ograniczenia rozmiaru maszyny wirtualnej i dostępność regionów w usłudze Azure Kubernetes Service (AKS)
• Organizowanie aplikacji mikrousług i aplikacji z wieloma kontenerami w celu zapewnienia wysokiej skalowalności i dostępności
• Architektura i operacje klastra usługi Azure Kubernetes Service (AKS)

Powiązane zasoby

• Punkt odniesienia usługi AKS dla klastrów wieloregionowych
• Architektura mikrousług w usłudze Azure Kubernetes Service
• Przegląd platformy Azure Well-Architected Framework — Azure Kubernetes Service (AKS)

W tym przewodniku omówiono wysoką dostępność dla wielowarstwowego wdrażania aplikacji w klastrach usługi Azure Kubernetes Service (AKS). W tym artykule opisano mechanizmy i konstrukcje platformy Kubernetes HA oraz podano listę kontrolną i wytyczne umożliwiające identyfikowanie i eliminowanie pojedynczych punktów awarii wysokiej dostępności.

Istnieją dwa podstawowe zadania implementowania wysokiej dostępności dla aplikacji usługi AKS.

• Zidentyfikuj wszystkie pojedyncze punkty awarii w aplikacji.
• Eliminowanie pojedynczych punktów awarii.

Wyeliminowanie pojedynczych punktów awarii wymaga rozwiązania wysokiej dostępności.

Cztery filary wysokiej dostępności

Cztery filary wysokiej dostępności pojawiają się w każdym systemie o wysokiej dostępności:

• Nadmiarowość
• Monitorowanie
• Odzyskiwania
• Punktowanie kontrolne

Rozważ wielowarstwową aplikację usługi AKS, w której ruch dociera do warstwy logiki biznesowej, warstwa danych zachowuje stan, a aplikacja zwraca odpowiedzi użytkownikom.

Identyfikowanie pojedynczych punktów awarii

Aby zidentyfikować pojedyncze punkty awarii, zacznij od określenia ścieżki krytycznej między żądaniami klienta a składnikami obsługującymi te żądania. Każdy składnik na tej ścieżce, który nie jest zarządzany zgodnie z czterema filarami wysokiej dostępności, lub trzema filarami, jeśli jest to składnik bezstanowy bez tworzenia punktów kontrolnych, jest pojedynczym punktem awarii. Nawet zreplikowany składnik jest uważany za pojedynczy punkt awarii, jeśli nie jest monitorowany, ponieważ jego awaria jest dyskretnie niezakryta.

Eliminowanie pojedynczych punktów awarii

Aby wyeliminować pojedyncze punkty awarii, wdróż aplikację w celu replikacji składników ścieżki krytycznej i zastosuj mechanizmy równoważenia obciążenia, monitorowania i odzyskiwania. Platforma Kubernetes może obsługiwać wszystkie te działania.

Pobierz plik programu Visio z tego diagramu.

W replikowanej aplikacji:

• Składniki warstwy biznesowej są replikowane z różnymi liczbami replik na składnik w zależności od ich wydajności i obciążenia.
• Można również replikować warstwę danych za modułem równoważenia obciążenia.

Platforma Kubernetes oferuje kilka konstrukcji i mechanizmów, takich jak równoważenie obciążenia i sondy utrzymania, które pomagają zaimplementować filary wysokiej dostępności. Poniższa lista kontrolna i dyskusja dzielą te konstrukcje i mechanizmy na kategorie, które są mapujące na cztery filary wysokiej dostępności.

Lista kontrolna platformy Kubernetes HA

Poza zarządzaniem stanem platforma Kubernetes wykonuje wyjątkowe zadanie utrzymania wysokiej dostępności aplikacji. Lista kontrolna wysokiej dostępności zawiera listę typowych konfiguracji, których można użyć do optymalizacji zarządzania wysoką dostępnością platformy Kubernetes. Aby użyć listy kontrolnej, oceń wdrożenie platformy Kubernetes pod kątem następujących mechanizmów i konstrukcji oraz zaimplementuj brakujące elementy.

Filar wysokiej dostępności	Rozwiązanie
Nadmiarowość	☐ Typ kontrolera Kubernetes ☐ Liczba replik ☐ Planowanie koligacji anty-koligacji
Monitorowanie	☐ Sondy liveness ☐ Sondy gotowości ☐ Sondy uruchamiania
Odzyskiwanie	☐ Typ usługi ☐ Wybory lidera ☐ Zasady ponownego uruchamiania ☐ Zaczepy przed zatrzymaniem
Tworzenie punktów kontrolnych	☐ Oświadczenia trwałego woluminu ☐ Woluminy trwałe

Nadmiarowość

Nadmiarowość ogranicza liczbę pojedynczych punktów awarii. Potrzebna jest nadmiarowość we wszystkich warstwach aplikacji. Aby uzyskać nadmiarowość, replikujesz składnik danej warstwy z co najmniej jedną identyczną repliką.

• Typ kontrolera, konfiguracja kind: Deployment. Platforma Kubernetes oferuje kilka kontrolerów, które mogą zarządzać cyklem życia zasobnika aplikacji. Najpopularniejszym kontrolerem Deploymentjest . Inne kontrolery obejmują Statefulsetelement , który przydaje się, gdy ważne jest zachowanie tożsamości zasobnika po odzyskiwaniu. Inne kontrolery, takie jak Replicasets nie oferują tych samych przydatnych funkcji, takich jak wycofywanie, które oferuje wdrożenie.

• Liczba replik, konfiguracja spec.replicas. Ustawienie liczby replik na tylko jedną jest celową decyzją o użyciu modelu rezerwy zimnej. Rezerwa zimna oznacza, że gdy wystąpi awaria, nowe wystąpienie zaczyna się od podstaw, co wpływa na dostępność. Ten model może działać w przypadku składników z obciążeniami o małym woluminie, ale należy rozważyć replikowanie składników bezstanowych i dużych woluminów.

  Określając limity żądań zasobów, spec.containers[].resourcesmożna dodać skalowanie automatyczne zasobnika poziomego (HPA), co powoduje automatyczne skalowanie platformy Kubernetes w górę lub w dół liczby replik na podstawie zdefiniowanych progów wykorzystania zasobów. HpA pomaga uniknąć przypadków, w których wzrost obciążenia uniemożliwia aplikacji obsługę żądań z powodu przeciążenia.

• Planowanie koligacji, konfiguracji spec.affinity.podAntiAffinity. Typowy klaster Kubernetes na poziomie produkcyjnym ma węzły rozmieszczone w wielu strefach dostępności wyrażonych przy użyciu klasy topologyKey. Zasobniki tego samego wdrożenia powinny mieć preferowaną lub miękką anty-koligację ze sobą. Ta konfiguracja gwarantuje, że zasobniki są zaplanowane na węzłach w różnych strefach dostępności.

  Klaster usługi AKS może mieć wiele pul węzłów, z których każdy ma różne rozmiary i specyfikacje zestawu skalowania maszyn wirtualnych. Można na przykład hostować zasobniki bazy danych na węzłach z szybkimi dyskami półprzewodnikowymi (SSD) i hostować zasobniki uczenia maszynowego na węzłach za pomocą procesorów graficznych (GPU).

Monitorowanie

Bez monitorowania nadmiarowość może stać się nieskuteczna. Potrzebujesz stałego mechanizmu monitorowania, aby upewnić się, że obciążenie osiąga replikę w dobrej kondycji.

• Sondy aktualności, konfiguracja spec.containers.livenessProbe, monitoruj kondycję zasobników. Jeśli kontener ulegnie awarii lub zakończy działanie, platforma Kubernetes może go wykryć. Gdy działanie zakończy się niepowodzeniem, platforma Kubernetes ponownie uruchomi kontener.

• Sondy gotowości, konfiguracja spec.containers.readinessProbe, określają, czy ruch ma być wysyłany do zasobnika. Jeśli jakiekolwiek zasobniki wdrożenia nie są gotowe, nie będą one częścią punktów końcowych usługi Kubernetes abstrakcji wdrożenia i dlatego nie będą przydatne. Ważne jest, aby dokładnie ustawić sondy gotowości, ponieważ nie wyzwalają ponownego uruchomienia, ale są używane do odizolowania zasobników od odbierania ruchu, dopóki nie będą gotowe.

• Sondy uruchamiania, konfiguracja spec.containers.startupProbe, głównie zapobiegają fałszywie dodatnim gotowości i żywotności w aplikacjach wolno uruchamianych. Gdy sonda startowa zakończyła się pomyślnie, sonda liveness się rozpocznie.

Platforma Azure oferuje bardziej szczegółowe informacje , które umożliwiają ustawianie alertów na podstawie kondycji klastra.

Odzyskiwanie

Głównym celem monitorowania jest wyzwolenie odzyskiwania po wykryciu awarii. Proces odzyskiwania obejmuje trzy fazy:

1. Izoluj i przekieruj: upewnij się, że wadliwa replika nie odbiera ruchu i kieruje obciążenie do replik w dobrej kondycji.
2. Naprawa: Uruchom ponownie wadliwą replikę, która może naprawiać błędy przejściowe.
3. Ponownie dołącz: po naprawie, jeśli monitorowanie uzna replikę za w dobrej kondycji, ponownie dołącz replikę do innych replik w obsłudze obciążenia.

• Typ usługi, konfiguracja spec.type. Uwidacznianie zasobników za pośrednictwem usługi może być klasyfikowane w ramach nadmiarowości, a także odzyskiwania. Jednak w niektórych przypadkach może istnieć wdrożenie z jedną repliką. Nadal istnieją korzyści wynikające z uwidaczniania zasobników za pośrednictwem usługi, mimo że nie ma równoważenia obciążenia.

  Główną zaletą usługi jest to, że wpisy usługi nazw domen (DNS) są automatycznie aktualizowane przy użyciu punktów końcowych usługi Kubernetes. Zasobnik z kontenerami z sondami gotowości z niepowodzeniem nie będzie odbierać ruchu za pośrednictwem usługi AKS. Mimo że możliwość równoważenia obciążenia usług IP klastra Kubernetes jest podstawowa, można połączyć bezgłówną usługę z przychodzącymi lub innymi rozwiązaniami siatki usług, aby lepiej zrównoważyć rozkład obciążenia.

  Jak ruch zewnętrzny dociera do klastra usługi AKS, znajduje się poza zakresem rozwiązania Kubernetes. Ruch zewnętrzny można obsługiwać za pomocą usług, takich jak aplikacja systemu Azure Gateway.

• Wybory lidera. Niektóre składniki są najlepiej wdrażane jako pojedynczetony. Harmonogram jest takim składnikiem, ponieważ dwa aktywne harmonogramy mogą powodować konflikt. Posiadanie pojedynczego elementu uwidacznia aplikację w przypadku problemów z zimnym wstrzymaniem. Aby włączyć ciepłe wstrzymanie zasobnika, możesz użyć wyborów lidera, gdzie tylko jeden zasobnik, lider, obsługuje żądania.

• Uruchom ponownie zasady, konfigurację spec.restartPolicy. Zasady ponownego uruchamiania dotyczą wszystkich kontenerów w zasobniku. Powinno istnieć prawidłowe uzasadnienie ustawienia tego atrybutu na Never. Niektóre kontenery kontaktują się z serwerem licencji za każdym razem, gdy się uruchamiają, i możesz uniknąć dodanych kosztów nadmiernego ponownego uruchamiania.

• Wstępne zatrzymywanie punktów zaczepienia, konfiguracja spec.containers.lifecycle.preStop. Przed uruchomieniem punktów zaczepienia przed wysłaniem SIGTERM sygnału do kontenera. Skrypt przed zatrzymaniem może być tak prosty, jak 30-sekundowe polecenie uśpienia.

  Na przykład gdy aplikacja zarządzana przez aplikację HPA jest skalowana w dół, żądania w toku mogą zostać nagle zakończone, chyba że aplikacja ma SIGTERM program obsługi, który kończy obsługę przed zakończeniem wykonywania żądań. Punkt końcowy zasobnika przed zatrzymaniem usuwa punkt końcowy zasobnika, a w związku z tym wpis DNS z punktu końcowego usługi. Gdy punkt zaczepienia przed zatrzymaniem jest uruchomiony, do zasobnika nie można wysyłać żadnych nowych żądań. Punkt zaczepienia przed zatrzymaniem umożliwia zasobnikowi zakończenie przetwarzania żądań w toku bez odbierania nowych. Wstępnie zatrzymane haki to prosty sposób zminimalizowania porzuconych żądań bez modyfikowania kodu aplikacji.

Tworzenie punktów kontrolnych

Nowoczesne aplikacje mają wiele składników bezstanowych, ale całkowicie bezstanowe aplikacje są nadal rzadkie. Większość aplikacji sprawdza ich stan w warstwie danych. Platforma Kubernetes celowo nie udostępnia żadnego mechanizmu do obsługi stanu aplikacji. Zarządzanie stanem to złożone zadanie, które nie jest częścią zarządzania kontenerami.

Stan aplikacji można utrwalać na trzech poziomach:

• Poziom rekordów danych przechowuje dane w bazie danych. Każdy rekord bazy danych może być replikowany w wielu wystąpieniach bazy danych. Rekordy bazy danych są dominującą formą trwałości stanu, szczególnie w zarządzanych bazach danych w chmurze, takich jak Azure Cosmos DB.

• Poziom systemu plików zwykle replikuje pliki danych, takie jak pliki rejestrowania z wyprzedzeniem (WAL, write-ahead logging). Większość dostawców usług w chmurze oferuje wtyczki dla swoich rozwiązań, takich jak Azure Files.

• Poziom dysku utrzymuje dane na poziomie bloku, co zapewnia elastyczność definiowania systemu plików do użycia, jak w usłudze Azure Disk Storage.

Woluminy Kubernetes , woluminy trwałe i trwałe oświadczenia woluminów mogą utrwalać stan aplikacji na poziomie systemu plików lub dysku. Najczęstszym wzorcem przechowywania stanu jest nadal poziom rekordów danych.

Wysoka dostępność i odzyskiwanie po awarii

Zarówno w przypadku wysokiej dostępności, jak i odzyskiwania po awarii (DR) wybór rozwiązań topologii sieci i równoważenia obciążenia jest ważny.

Jednak odzyskiwanie po awarii wymaga wdrożenia usługi w wielu regionach na całym poziomie usługi z rozwiązaniami równoważenia obciążenia między regionami platformy Azure. Aplikacja jest rozłożona na wiele regionów lub całe wystąpienie aplikacji jest wdrażane w każdym regionie. Wybór zależy od typu aplikacji, architektury aplikacji i tolerancji opóźnień między składnikami.

Zamiast korzystać z wielu regionów, wysoka dostępność korzysta z wdrożeń wielostrefowych w regionach świadczenia usługi Azure. Na poniższym diagramie przedstawiono różnicę między strefami dostępności i regionami wysokiej dostępności i odzyskiwania po awarii.

Pobierz plik programu Visio z tą architekturą.

Ten przewodnik koncentruje się na wysokiej dostępności na poziomie aplikacji w ramach jednego klastra usługi AKS. Aby uzyskać więcej informacji na temat odzyskiwania po awarii w wdrożeniach wieloklastrowych usługi AKS, zobacz Punkt odniesienia usługi AKS dla klastrów wieloregionowych.

Inne uwagi

• Aby zachować wysoką dostępność aplikacji, upewnij się, że płaszczyzna sterowania platformy Kubernetes, w tym serwer interfejsu API i menedżer kontrolera, jest wysoce dostępna. Rozważ użycie umowy SLA czasu pracy usługi AKS, aby zapewnić wysoką dostępność.

• Strategia konsolidacji zasobów bezpośrednio narusza filar nadmiarowości wysokiej dostępności. W związku z tym należy dokładnie przeanalizować koszt nadmiarowości. Kalkulator cen platformy Azure może pomóc.

Współautorzy

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

Główny autor:

• Ali Kanso | Główny inżynier oprogramowania

Inni współautorzy:

• Karthik Sankara Subramanian | Inżynier oprogramowania II
• Kinshuman Patra | Menedżer inżynierów grup partnerskich
• Ayobami Ayodeji | Starszy menedżer programu
• Oscar L Pla Alvarez | Architekt rozwiązań domeny

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

Następne kroki

• Wzorzec klastra Kubernetes o wysokiej dostępności
• Regiony i strefy dostępności
• Limity przydziału, ograniczenia rozmiaru maszyny wirtualnej i dostępność regionów w usłudze Azure Kubernetes Service (AKS)
• Organizowanie aplikacji mikrousług i aplikacji z wieloma kontenerami w celu zapewnienia wysokiej skalowalności i dostępności
• Architektura i operacje klastra usługi Azure Kubernetes Service (AKS)

Powiązane zasoby

• Punkt odniesienia usługi AKS dla klastrów wieloregionowych
• Architektura mikrousług w usłudze Azure Kubernetes Service
• Przegląd platformy Azure Well-Architected Framework — Azure Kubernetes Service (AKS)