Udostępnij przez


Niezawodność w usłudze Azure Container Apps

Azure Container Apps to w pełni zarządzana bezserwerowa usługa hostingu kontenerów do wdrażania mikrousług i konteneryzowanych aplikacji.

W przypadku korzystania z platformy Azure niezawodność jest wspólną odpowiedzialnością. Firma Microsoft oferuje szereg możliwości wspierania odporności systemów i odzyskiwania. Odpowiadasz za zrozumienie sposobu działania tych możliwości we wszystkich używanych usługach oraz wybór możliwości potrzebnych do osiągnięcia twoich celów biznesowych i celów dostępności.

W tym artykule opisano, jak zapewnić odporność usługi Container Apps na różne potencjalne awarie i problemy, w tym przejściowe błędy, awarie strefy dostępności, awarie regionów i konserwację usługi. Opisano również, jak używać kopii zapasowych do odzyskiwania po innych typach problemów i wyróżnia kluczowe informacje o umowie dotyczącej poziomu usług (SLA) usługi Container Apps.

Zalecenia dotyczące wdrażania produkcyjnego

Aby dowiedzieć się, jak wdrożyć usługę Container Apps, aby obsługiwać wymagania dotyczące niezawodności rozwiązania i jak niezawodność wpływa na inne aspekty architektury, zobacz Artykuł Architecture best practices for Container Apps in the Azure Well-Architected Framework (Najlepsze rozwiązania dotyczące architektury dla usługi Container Apps w strukturze Azure Well-Architected Framework).

Omówienie architektury niezawodności

W przypadku korzystania z usługi Container Apps wdrażasz środowisko , które służy jako podstawowa jednostka wdrażania i definiuje bezpieczną granicę wokół grupy aplikacji kontenera. W środowisku można skonfigurować podstawowe ustawienia, w tym obsługę strefy dostępności i konfigurację sieci. Dwa typy środowisk to środowiska profilów obciążeń roboczych i środowiska wyłącznie konsumpcyjne. Aby uzyskać więcej informacji, zobacz Obliczenia i struktury rozliczeń w usłudze Container Apps.

W jednym środowisku można wdrożyć wiele aplikacji . Każda aplikacja uruchamia co najmniej jeden kontener. Środowisko może również uruchamiać co najmniej jedno zadanie, które reprezentuje zadania nieinteraktywne. Aby uzyskać więcej informacji, zobacz Kontenery w usłudze Container Apps i Zadania w usłudze Container Apps.

Każda aplikacja ma co najmniej jedną replikę reprezentującą uruchomione wystąpienia aplikacji. Możesz kontrolować sposób skalowania aplikacji, w tym minimalną i maksymalną liczbę replik oraz sposób dynamicznego dodawania i usuwania replik przez aplikację. Harmonogram platformy zapewnia optymalną dystrybucję na hostach fizycznych przy jednoczesnym spełnieniu minimalnych wymagań dotyczących liczby replik. Aby uzyskać więcej informacji, zobacz Ustawianie reguł skalowania w usłudze Container Apps.

Diagram przedstawiający środowisko usługi Container Apps, które uruchamia aplikację z trzema replikami.

Usługa Container Apps obsługuje niezawodność aplikacji przy użyciu różnych możliwości:

  • Automatyczne monitorowanie kondycji: Wbudowany kontroler ruchu przychodzącego automatycznie równoważy obciążenie ruchu między replikami w dobrej kondycji. Jeśli replika nie przejdzie sprawdzania kondycji lub jej podstawowa infrastruktura stanie się niedostępna przez dłuższy czas, usługa automatycznie ponownie uruchomi kontenery, które zawiodły, lub utworzy repliki zastępcze. Ponadto ponownie dystrybuuje ruch od niezdrowych replik i zarządza próbami ponownego nawiązania połączeń sieciowych w klastrze. Ten proces automatycznego odzyskiwania nie wymaga interwencji klienta i utrzymuje określoną liczbę replik. Aby uzyskać więcej informacji, zobacz Sondy kondycji.

  • Odporność aplikacji za pośrednictwem języka Dapr: Usługa Container Apps zapewnia ścisłą integrację z platformą Dapr, która obsługuje mikrousługi klasy produkcyjnej i konteneryzowane aplikacje. Dapr zawiera funkcje, które pomagają zwiększyć odporność, w tym obsługę błędów w innych usługach. Aby uzyskać więcej informacji, zobacz Mikrousługi z usługą Container Apps.

  • Odporność infrastruktury dla składników systemowych: Ta odporność obejmuje płaszczyznę sterowania, kontrolery ruchu przychodzącego i środowisko uruchomieniowe kontenera. W regionach, które mają strefy dostępności, usługa Container Apps zapewnia nadmiarowość stref. Aby uzyskać więcej informacji, zobacz Odporność na błędy strefy 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.

Usługa Container Apps automatycznie obsługuje wiele błędów przejściowych za pośrednictwem mechanizmów ponawiania na poziomie platformy i monitorowania stanu zdrowia. Aby upewnić się, że aplikacje są odporne na błędy przejściowe, wykonaj następujące czynności:

  • Skonfiguruj sondy kondycji , które umożliwiają platformie wykrywanie i reagowanie na warunki awarii specyficzne dla aplikacji. Ustaw odpowiednie progi błędów i wartości limitu czasu na podstawie właściwości uruchamiania aplikacji. Aby na przykład uniknąć przedwczesnego ponownego uruchamiania kontenera podczas tymczasowych problemów, należy użyć progu niepowodzenia wynoszącego 3 z okresem 10 sekund dla sond aktywności. Aby uzyskać więcej informacji, zobacz Sondy kondycji.

  • Zasady odporności w odnajdywaniu usług (wersja zapoznawcza) umożliwiają proaktywne zapobieganie awariom żądań usług, ich wykrywanie i odzyskiwanie. Na przykład w przypadku korzystania z zasad odporności każde przychodzące żądanie do aplikacji może zostać automatycznie ponowione, jeśli wystąpi błąd przejściowy, który uniemożliwia aplikacji odpowiadanie. Aby uzyskać więcej informacji, zobacz Odporność odnajdywania usług (wersja zapoznawcza).

  • Zaimplementuj logikę ponawiania prób w aplikacjach na potrzeby wywołań usług zewnętrznych, połączeń bazy danych i żądań interfejsu API.

    Jeśli Twoja aplikacja używa Dapr do integracji z usługami w chmurze, użyj odporności komponentów Dapr (wersja zapoznawcza), aby skonfigurować ponawianie prób, limity czasu i wyłączniki obwodów.

    W przypadku innych zależności aplikacja musi obsługiwać błędy przejściowe. Użyj strategii wycofywania wykładniczego i wzorców wyłącznika podczas wywoływania usług zewnętrznych, aby zapobiec awariom kaskadowym podczas zakłóceń usług podrzędnych. Wbudowane funkcje odnajdywania i równoważenia obciążenia usługi Container Apps automatycznie kierują ruch od wystąpień, które uległy awarii, ale zasady ponawiania na poziomie aplikacji zapewniają bezproblemową obsługę przejściowych problemów przed tym, nim kontrola kondycji na poziomie platformy spowoduje ponowne uruchomienie kontenera.

  • Zadania projektowe mają być odporne na błędy przejściowe, w tym błędy podczas wykonywania zadania lub w ich zależnościach. Zaprojektuj zadania, aby wznowiły pracę, jeśli zostaną ponownie uruchomione, lub zaprojektuj tak, aby były idempotentne, co pozwoli na ich bezpieczne ponowne uruchamianie.

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 tworzenia środowiska Container Apps możesz włączyć nadmiarowość strefową, aby rozdzielić podstawową infrastrukturę między kilka stref dostępności w wybranym regionie Azure. Usługa Container Apps automatycznie planuje repliki aplikacji w różnych strefach. Ta dystrybucja odbywa się w sposób niewidoczny, co oznacza, że nie trzeba określać położenia strefy dla poszczególnych replik.

Redundancja strefowa zwiększa odporność aplikacji na awarie na poziomie strefy, zapewniając, że repliki aplikacji kontenerowej są rozproszone po wielu strefach.

Na poniższym diagramie przedstawiono strefowo-redundantną aplikację kontenerową z trzema replikami. Każda replika działa w oddzielnej strefie dostępności.

Diagram przedstawiający aplikację kontenerową z wykorzystaniem nadmiarowości strefowej z trzema replikami. Każda replika działa w oddzielnej strefie dostępności.

Requirements

  • Sprawdź obsługę regionów. Redundancja strefowa jest dostępna we wszystkich regionach, które obsługują aplikacje kontenerowe i strefy dostępności.

    Aby zobaczyć, które regiony obsługują strefy dostępności, zobacz Regiony świadczenia usługi Azure z obsługą stref dostępności.

    Aby zobaczyć, które regiony obsługują usługę Container Apps, zobacz Dostępność produktu według regionów.

  • Użyj profilów obciążeń. Redundancja strefowa jest dostępna dla wszystkich planów usługi Container Apps, w tym profili zużycia i dedykowanych.

  • Włącz redundancję strefy podczas tworzenia środowiska. Tego ustawienia nie można zmienić po utworzeniu środowiska.

  • Wdrażanie środowiska usługi Container Apps w sieci wirtualnej. Sieć wirtualna musi znajdować się w regionie obsługującym strefy dostępności. Upewnij się, że sieć wirtualna ma podsieć o odpowiednim rozmiarze. Środowiska tylko do użycia wymagają podsieci z zakresem /23 CIDR (Classless Inter-Domain Routing) lub większym, podczas gdy środowiska profilów obciążeń wymagają zakresu CIDR lub większego /27 .

  • Ustaw minimalną liczbę replik na co najmniej dwie, aby zapewnić dystrybucję w wielu strefach dostępności. Rozważ ustawienie wyższej minimalnej liczby replik, jeśli ma zastosowanie którykolwiek z następujących warunków:

    • Oczekiwane obciążenie szczytowe wymaga więcej niż dwóch replik.

    • Musisz być odporny na wiele równoczesnych awarii w strefach.

    • Podczas awarii strefy chcesz zminimalizować czas oczekiwania na utworzenie nowych replik w innych strefach.

Koszt

W przypadku włączenia redundancji strefowej nie są naliczane dodatkowe opłaty wykraczające poza standardowe opłaty za Container Apps. Płacisz te same stawki za zasoby obliczeniowe, żądania i sekundy vCore, niezależnie od włączenia zapasowości strefowej. Aby uzyskać więcej informacji, zobacz Cennik usługi Container Apps i Rozliczenia usługi Container Apps.

Konfiguruj obsługę stref dostępności

  • Utwórz środowisko Container Apps o strefowej nadmiarowości. Aby uzyskać instrukcje wdrażania dotyczące portalu Azure, Azure CLI i Azure PowerShell, zobacz Tworzenie strefowo nadmiarowej aplikacji kontenera.

  • Przejdź do strefowo-zredundantnego wdrożenia. Nie można włączyć nadmiarowości strefy w istniejącym środowisku usługi Container Apps. Aby uaktualnić istniejące środowiska, które nie mają nadmiarowości strefowej, utwórz nowe środowisko z nadmiarowością strefową włączoną w obsługiwanym regionie. Następnie ponownie wdróż aplikacje kontenera.

  • Wyłącz strefową nadmiarowość. Redundancja strefowa nie może być wyłączona po jej włączeniu podczas tworzenia środowiska. Jeśli potrzebujesz wdrożenia bez nadmiarowości strefowej, musisz utworzyć nowe środowisko bez włączania opcji nadmiarowości strefowej lub wdrożyć w regionie, który nie obsługuje strefy dostępności.

  • Sprawdź redundancję strefy. Aby sprawdzić stan nadmiarowości strefy środowiska, możesz użyć witryny Azure Portal, interfejsu wiersza polecenia platformy Azure i programu Azure PowerShell.

Planowanie pojemności i zarządzanie nimi

Jeśli strefa dostępności stanie się niedostępna, platforma Container Apps używa reguł skalowania, aby zdecydować, kiedy zastąpić wszelkie utracone repliki w tej strefie. Ważne jest, aby prawidłowo skonfigurować reguły skalowania, aby harmonogram mógł podejmować odpowiednie decyzje dotyczące planowania.

Aby prawidłowo skonfigurować reguły skalowania, postępuj zgodnie z następującymi zasadami:

  • Ustaw minimalną liczbę replik , które aplikacja może tolerować. Zastąpienie utraconych replik może zająć krótki czas, ponieważ platforma musi wykryć, że stare repliki znikną. Następnie nowe repliki muszą uruchomić się i zwrócić pozytywny status sondy gotowości, zanim będą mogły odbierać przychodzące żądania. Jeśli nie możesz tolerować żadnego okresu z mniejszą niż minimalną liczbą określonych replik, rozważ nadmiarową alokację , aby utrzymać wydajność aplikacji, nawet jeśli strefa stanie się niedostępna.

  • Ustaw żądania zasobów i limity , aby ułatwić harmonogramowi usługi Container Apps podejmowanie optymalnych decyzji dotyczących umieszczania w różnych strefach. Niedoprecyzowane wymagania dotyczące zasobów mogą prowadzić do nierównego rozkładu lub problemów z rozmieszczeniem przy wysokim obciążeniu.

Aby uzyskać więcej informacji na temat opcji konfiguracji, zobacz Ustawianie reguł skalowania.

Zachowanie, gdy wszystkie strefy są w dobrej kondycji

W tej sekcji opisano, czego można się spodziewać, kiedy zasoby usługi Container Apps są skonfigurowane pod kątem nadmiarowości strefowej i wszystkie strefy dostępności są operacyjne.

  • Routing ruchu między strefami: W przypadku strefowo nadmiarowych aplikacji kontenerów platforma działa w modelu aktywny-aktywny, w którym wiele replik jednocześnie obsługuje ruch. Kontroler ingress rozpowszechnia żądania przychodzące na wszystkie repliki w dobrej kondycji, niezależnie od ich strefy, i domyślnie używa round-robin do równoważenia obciążenia. Każda strefa przetwarza żądania niezależnie, a platforma nie określa priorytetu żadnej określonej strefy dla dystrybucji ruchu. Ze wszystkich stref pochodzą sondy zdrowotne, aby zapewnić dokładną ocenę zdrowia wszystkich replik z wielu perspektyw.

  • Replikacja danych między strefami: Usługa Container Apps nie replikuje danych aplikacji między strefami, ponieważ jest przeznaczona dla obciążeń bezstanowych. Wszystkie dane przechowywane w magazynie efemerycznym, w tym w magazynie o zakresie kontenera i magazynie o zakresie replik, są usuwane po zamknięciu kontenera lub repliki.

    W przypadku wymagań dotyczących danych stanowych montuj udział plików usługi Azure Files skonfigurowany dla magazynu strefowo nadmiarowego lub użyj innych usług platformy Azure, takich jak Azure Cosmos DB lub Azure SQL Database, które zapewniają własne możliwości replikacji między strefami.

    Platforma replikuje tylko metadane warstwy kontrolnej, w tym konfiguracje aplikacji, reguły skalowania i tajemnice w różnych strefach, aby zapewnić wysoką dostępność. Obrazy kontenerów są pobierane z rejestru kontenerów do każdej strefy, gdy jest to konieczne przy tworzeniu replik.

Zachowanie podczas awarii strefy

W tej sekcji opisano, czego można oczekiwać, gdy zasoby usługi Container Apps są skonfigurowane pod kątem nadmiarowości strefowej i nastąpi awaria strefy dostępności.

  • Wykrywanie i reagowanie: Platforma Azure automatycznie wykrywa błędy strefy. Usługa Container Apps natychmiast zatrzymuje planowanie nowych replik do strefy, która zakończyła się niepowodzeniem i rozpoczyna ponowne dystrybuowanie ruchu do replik w dobrej kondycji w pozostałych strefach. Platforma automatycznie obsługuje wszystkie operacje trybu failover bez konieczności interwencji użytkownika.

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

    Kondycję aplikacji można również monitorować za pomocą metryk usługi Container Apps w usłudze Azure Monitor. Skonfiguruj alerty dotyczące spadków liczby replik i współczynników niepowodzeń żądań, aby otrzymywać natychmiastowe powiadomienia, gdy wystąpią problemy związane z strefą.

  • Aktywne żądania: Żądania w locie do replik w strefie, która zakończyła się niepowodzeniem, mogą zostać porzucone lub napotkać przekroczenia limitu czasu lub błędy połączenia. Wszystkie wykonania zadań w strefie, której dotyczy problem, są przerywane i oznaczane jako nieudane.

  • Oczekiwana utrata danych: Na poziomie platformy Container Apps nie występuje żadna utrata danych, ponieważ usługa jest przeznaczona dla obciążeń bezstanowych. Wszelkie dane przechowywane w magazynie efemerycznym w strefie dostępności zostaną utracone po zakończeniu działania repliki, a efemeryczny magazyn powinien być używany tylko dla danych tymczasowych.

  • Oczekiwany przestój: Aplikacje doświadczają minimalnych przestojów lub ich braku podczas awarii strefy. Rzeczywisty wpływ zależy od ustawień sondy kondycji aplikacji i liczby replik w strefach w dobrej kondycji. Upewnij się, że klienci postępują zgodnie ze wskazówkami dotyczącymi obsługi błędów przejściowych , aby zminimalizować wszelkie efekty.

    Wszystkie zadania uruchamiane w strefie, której dotyczy problem, zostaną przerwane i oznaczone jako nieudane. Jeśli potrzebujesz zadania odpornego na awarię strefy, skonfiguruj ponawianie prób lub skonfiguruj równoległość tak, aby zadanie uruchamiało wiele kopii tego samego wykonania. Aby uzyskać więcej informacji, zobacz Konfiguracja zadania zaawansowanego.

  • Przekierowywanie ruchu: Sondy kondycji kontrolera wejściowego szybko wykrywają niedostępne repliki i usuwają je z puli równoważenia obciążenia. W zależności od konfiguracji sondy kontrolnej aplikacji, proces przełączania awaryjnego trwa około 30 sekund. Następny ruch przychodzący jest dystrybuowany pomiędzy pozostałe zdrowe repliki. To przekierowywanie ruchu odbywa się w sposób niewidoczny dla klientów, którzy nadal używają tego samego adresu URL aplikacji.

    Jeśli koligacja sesji jest włączona, a strefa ulegnie awarii, klienci, którzy wcześniej zostali przekierowani do replik w tej strefie, są kierowani do nowych replik, ponieważ poprzednie repliki nie są już dostępne. Wszystkie stany skojarzone z poprzednimi replikami zostaną utracone.

    Żadne nowe wystąpienia zadań nie zostaną uruchomione w uszkodzonej strefie.

  • Zarządzanie wystąpieniami: Nowe wystąpienia repliki mogą być tworzone w zdrowych strefach, jeśli reguły automatycznego skalowania są wyzwalane na podstawie zwiększonego obciążenia.

Odzyskiwanie strefy

Gdy strefa dostępności zostanie odzyskana po awarii, usługa Container Apps automatycznie ponownie połączy strefę z aktywną usługą bez konieczności interwencji. Sondy kondycji platformy wykrywają, kiedy infrastruktura w odzyskanej strefie stanie się dostępna, a usługa Container Apps rozpoczyna planowanie nowych replik do tej strefy na podstawie konfiguracji skalowania. Istniejące repliki w strefach w dobrej kondycji nadal obsługują ruch podczas procesu ponownej integracji, co pomaga zapobiegać przerwom w działaniu usługi.

Usługa Container Apps stopniowo ponownie równoważy dystrybucję replik we wszystkich dostępnych strefach w ramach normalnych operacji skalowania. To automatyczne ponowne równoważenie występuje, gdy repliki są tworzone ze względu na zdarzenia skalowania lub gdy repliki w złej kondycji są zastępowane. Platforma nie wymusza natychmiastowej redystrybucji istniejących replik w dobrej kondycji, co zapobiega niepotrzebnym ponownym uruchomieniom kontenera i utrzymuje stabilność aplikacji podczas odzyskiwania.

Testowanie pod kątem niepowodzeń strefy

Platforma Container Apps zarządza routingiem ruchu, obsługą awarii (failover) oraz odzyskiwaniem (failback) dla strefowo redundantnych aplikacji kontenerowych. Ta funkcja jest w pełni zarządzana, więc nie trzeba inicjować ani weryfikować procesów awarii strefy dostępności.

Aby zweryfikować odporność aplikacji na awarie strefy, symuluj zakłócenia na poziomie strefy w warstwie aplikacji przy użyciu kontrolowanych metod testowania. Zatrzymaj lub usuń repliki z określonych stref, zmniejszając skalę aplikacji i obserwuj, jak pozostałe repliki radzą sobie ze zwiększonym obciążeniem. Monitoruj kluczowe metryki podczas testowania odporności, w tym liczbę replik, współczynniki powodzenia żądań, czasy odpowiedzi i zachowanie skalowania automatycznego. Upewnij się, że minimalna liczba replik utrzymuje dostępność usługi po usunięciu replik i sprawdź, czy reguły skalowania mogą obsłużyć zwiększone obciążenie pozostałych replik. Przetestuj konfiguracje sondy kondycji, celowo przeciążając punkty końcowe sprawdzania kondycji, aby potwierdzić, że platforma usuwa niesprawne wystąpienia z rotacji w oczekiwanych przedziałach czasowych.

Odporność na awarie całego regionu

Usługa Container Apps jest dostępna w jednym regionie. Jeśli region stanie się niedostępny, środowisko i aplikacje są również niedostępne.

Niestandardowe rozwiązania obejmujące wiele regionów w celu zapewnienia odporności

Aby zmniejszyć ryzyko awarii w jednym regionie, która wpływa na aplikację, można wdrożyć środowiska w wielu regionach. Poniższe kroki pomagają zwiększyć odporność:

  • Wdróż aplikacje w środowiskach w każdym regionie. Każde środowisko wymaga własnej konfiguracji sieci wirtualnej, a wymagania dotyczące podsieci mają zastosowanie niezależnie do każdego wdrożenia regionalnego. Obrazy kontenerów muszą być dostępne we wszystkich regionach, które można osiągnąć za pomocą usługi Azure Container Registry z włączoną replikacją geograficzną.

  • Konfigurowanie zasad równoważenia obciążenia i trybu failover przy użyciu usługi, takiej jak Azure Front Door lub Azure Traffic Manager.

  • Replikuj dane między regionami, aby można było odzyskać ostatni stan aplikacji.

Tworzenie kopii zapasowej i przywracanie

Usługa Container Apps nie zapewnia wbudowanych funkcji tworzenia kopii zapasowych dla aplikacji lub danych. Jako bezstanowa platforma hostingu kontenerów usługa Container Apps oczekuje, że aplikacje będą zarządzać własnymi strategiami trwałości i odzyskiwania danych za pośrednictwem usług zewnętrznych. Kontenery aplikacji i ich lokalne systemy plików są efemeryczne, a wszystkie przechowywane lokalnie dane zostaną utracone po ponownym uruchomieniu lub przeniesieniu replik.

Odporność podczas aktualizacji aplikacji

Zarządzanie poprawkami umożliwia wdrażanie aktualizacji w aplikacji bez przestojów. Możesz tworzyć nowe poprawki ze zaktualizowanymi obrazami kontenerów i przeprowadzać migrację przy użyciu strategii wdrażania niebieski-zielony lub stopniowo przekierowywać ruch przy użyciu reguł podziału ruchu. Podczas aktualizacji aplikacji platforma utrzymuje minimalną liczbę replik, tworząc nowe kontenery przed zlikwidowaniem starych, co pomaga zapobiegać przerwom w działaniu usługi.

Aby uzyskać więcej informacji, zobacz Aktualizowanie i wdrażanie zmian w usłudze Container Apps.

Odporność usługi na prace konserwacyjne

Usługa Container Apps wykonuje automatyczną konserwację platformy w celu stosowania aktualizacji zabezpieczeń, wdrażania nowych funkcji i zwiększania niezawodności usługi. Platforma używa aktualizacji ciągłych w różnych domenach błędów i strefach dostępności, aby zminimalizować zakłócenia w działaniu aplikacji. Podczas okien konserwacji, kontenery nadal działają bez przerw, ponieważ aktualizacje są stosowane do podstawowej infrastruktury etapowo.

Możesz określić własne okna obsługi, które są okresami, w których chcesz przeprowadzić konserwację w aplikacjach. Należy pamiętać, że aktualizacje krytyczne mogą występować poza oknami obsługi. Aby uzyskać więcej informacji, zobacz Planowana konserwacja usługi Container Apps.

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.

Umowa SLA dotycząca dostępności dla usługi Container Apps jest oparta na regułach skalowania ustawionych w aplikacjach.