Udostępnij za pośrednictwem

Ogólne zagadnienia dotyczące architektury dotyczące wybierania usługi kontenera platformy Azure

  • Artykuł

Ten artykuł przeprowadzi Cię przez proces wybierania usługi kontenera platformy Azure. Zawiera omówienie zagadnień dotyczących poziomu funkcji, które są typowe i krytyczne dla niektórych obciążeń. Może to pomóc w podejmowaniu decyzji w celu zapewnienia, że obciążenie spełnia wymagania dotyczące niezawodności, bezpieczeństwa, optymalizacji kosztów, doskonałości operacyjnej i wydajności.

Uwaga

Ten artykuł jest drugą częścią serii, która rozpoczyna się od pozycji Wybierz usługę kontenera platformy Azure. Zdecydowanie zalecamy przeczytanie tego artykułu z omówieniem, aby uzyskać kontekst dla tych zagadnień dotyczących architektury.

Omówienie

Zagadnienia opisane w tym artykule są podzielone na cztery kategorie:

Zagadnienia dotyczące architektury i sieci

  • Obsługa systemów operacyjnych
  • Przestrzenie adresowe sieci
  • Informacje o przepływie ruchu
  • Planowanie podsieci
  • Liczba dostępnych adresów IP ruchu przychodzącego
  • Obsługa tras zdefiniowanych przez użytkownika i bramy translatora adresów sieciowych
  • Integracja sieci prywatnej
  • Pokrycie protokołów
  • Równoważenie obciążenia
  • Odnajdywanie usług
  • Domeny niestandardowe i zarządzany protokół TLS
  • Wzajemne protokoły TLS
  • Pojęcia dotyczące sieci dla określonych usług platformy Azure

Zagadnienia związane z zabezpieczeniami

  • Zapewnianie zabezpieczeń ruchu wewnątrz klastra przy użyciu zasad sieciowych
  • Sieciowe grupy zabezpieczeń
  • Integracja magazynu kluczy Azure
  • Obsługa tożsamości zarządzanej
  • Oceny zagrożeń i luk w zabezpieczeniach za pomocą usługi Defender for Containers
  • Punkty odniesienia zabezpieczeń
  • Azure Well-Architected Framework for Security

Zagadnienia operacyjne

  • Aktualizacje i poprawki
  • Aktualizacje obrazu kontenera
  • Skalowalność infrastruktury pionowej
  • Skalowalność infrastruktury poziomej
  • Skalowalność aplikacji
  • Wgląd w informacje
  • Dobrze zaprojektowana struktura doskonałości operacyjnej

Zagadnienia dotyczące niezawodności

  • Umowy dotyczące poziomu usług
  • Nadmiarowość za pośrednictwem stref dostępności
  • Kontrole kondycji i samonaprawiania
  • Wdrożenia aplikacji bez przestojów
  • Limity zasobów
  • Dobrze zaprojektowana struktura pod kątem niezawodności

Należy pamiętać, że ten artykuł koncentruje się na podzestawie usług kontenerów platformy Azure, które oferują dojrzały zestaw funkcji dla aplikacji internetowych i interfejsów API, sieci, możliwości obserwowania, narzędzi deweloperskich i operacji: Azure Kubernetes Service (AKS), Azure Container Apps i Web App for Containers. Aby uzyskać pełną listę wszystkich usług kontenerów platformy Azure, zobacz stronę kategorii produktów usług kontenerów.

Uwaga

W tym przewodniku termin obciążenie odnosi się do kolekcji zasobów aplikacji, które obsługują cel biznesowy lub wykonywanie procesu biznesowego. Obciążenie korzysta z wielu składników, takich jak interfejsy API i magazyny danych, które współpracują ze sobą w celu zapewnienia konkretnej kompleksowej funkcjonalności.

Zagadnienia dotyczące architektury

W tej sekcji opisano decyzje dotyczące architektury, które są trudne do odwrócenia lub naprawienia bez konieczności znaczącego przestoju lub ponownego wdrażania. Szczególnie ważne jest, aby wziąć pod uwagę podstawowe składniki, takie jak sieć i zabezpieczenia.

Te zagadnienia nie są specyficzne dla filarów dobrze zaprojektowanej struktury. Jednak zasługują na dodatkową kontrolę i ocenę wymagań firm podczas wybierania usługi kontenera platformy Azure.

Obsługa systemów operacyjnych

Większość konteneryzowanych aplikacji działa w kontenerach systemu Linux, które są obsługiwane przez wszystkie usługi kontenerów platformy Azure. Opcje są bardziej ograniczone w przypadku składników obciążenia, które wymagają kontenerów systemu Windows.

Aplikacje kontenera AKS Web App for Containers
Obsługa systemu Linux ✅ ✅ ✅
Obsługa systemu Windows ❌ ✅ ✅
Obsługa mieszanego systemu operacyjnego ❌ ✅ ❌*

*Obsługa mieszanego systemu operacyjnego dla usługi Web App for Containers wymaga oddzielnych planów usługi aplikacja systemu Azure dla systemów Windows i Linux.

Zagadnienia dotyczące pracy w sieci

Ważne jest, aby zrozumieć projekt sieci na wczesnym etapie procesów planowania ze względu na ograniczenia zabezpieczeń i zgodności oraz nałożone wytyczne. Ogólnie rzecz biorąc, główne różnice między usługami platformy Azure omówione w tym przewodniku zależą od preferencji:

  • Container Apps to oferta PaaS, która udostępnia wiele funkcji sieci zarządzanych przez platformę Azure, takich jak odnajdywanie usług i wewnętrzne domeny zarządzane. Zespoły ds. obciążeń, które wymagają nieco większej możliwości konfigurowania, mogą korzystać z profilów obciążeń/dedykowanych przed rozważeniem alternatyw w celu zmaksymalizowania opcji sieci.
  • Usługa AKS jest najbardziej konfigurowalna z trzech usług i zapewnia największą kontrolę nad przepływem sieci. Na przykład zapewnia niestandardowe kontrolery ruchu przychodzącego i kontrolę ruchu wewnątrz klastra za pośrednictwem zasad sieciowych platformy Kubernetes. Zespoły ds. obciążeń mogą korzystać z różnych dodatków sieci zarządzanych przez platformę Azure, a także instalować i obsługiwać wszelkie dodatki z szerszego ekosystemu Kubernetes.
  • Funkcja Web App for Containers jest funkcją usługi App Service. W związku z tym koncepcje dotyczące sieci, zwłaszcza integracji sieci prywatnych, są bardzo specyficzne dla usługi App Service. Ta usługa będzie znana zespołom ds. obciążeń, które już korzystają z usługi App Service. Zespoły, które nie mają doświadczenia z usługą App Service i chcą bardziej znanej integracji z siecią wirtualną platformy Azure, są zachęcane do rozważenia usługi Container Apps.

Należy pamiętać, że sieć jest podstawową warstwą infrastruktury. Często trudno jest wprowadzać zmiany w projekcie bez ponownego wdrażania obciążenia, co może prowadzić do przestojów. W związku z tym, jeśli obciążenie ma określone wymagania dotyczące sieci, dokładnie zapoznaj się z tą sekcją przed zawężeniem wyboru usługi kontenera platformy Azure.

Przestrzenie adresowe sieci

Po zintegrowaniu aplikacji z sieciami wirtualnymi należy zaplanować kilka adresów IP, aby upewnić się, że dla wystąpień kontenerów są dostępne wystarczające adresy IP. Podczas tego procesu zaplanuj dodatkowe adresy aktualizacji, wdrożeń niebieski/zielony i podobne sytuacje, w których są wdrażane dodatkowe wystąpienia, co zużywa dodatkowe adresy IP.

Aplikacje kontenera AKS Web App for Containers
Dedykowane podsieci Plan zużycia: opcjonalnie
Dedykowany plan: wymagany		 Wymagania Opcjonalnie
Wymagania dotyczące adresów IP Plan zużycia: zobacz Środowisko tylko do użycia.
Plan dedykowany: zobacz Środowisko profilów obciążeń.		 Zobacz Sieci wirtualne platformy Azure dla usługi AKS. Zobacz Wymagania dotyczące podsieci usługi App Service.

Należy pamiętać, że wymagania usługi AKS zależą od wybranej wtyczki sieciowej. Niektóre wtyczki sieciowe dla usługi AKS wymagają szerszych rezerwacji adresów IP. Szczegóły wykraczają poza zakres tego artykułu. Aby uzyskać więcej informacji, zobacz Pojęcia dotyczące sieci dla usługi AKS.

Informacje o przepływie ruchu

Typy przepływu ruchu wymaganego dla rozwiązania mogą mieć wpływ na projekt sieci.

Poniższe sekcje zawierają informacje o różnych ograniczeniach sieci. Te ograniczenia wpływają na potrzebę wdrożenia dodatkowych podsieci w zależności od tego, czy są wymagane:

  • Wiele obciążeń kolokowanych.
  • Prywatny i/lub publiczny ruch przychodzący.
  • Kontrolowany dostęp przepływ ruchu wschodnio-zachodniego w klastrze (dla usługi Container Apps i AKS) lub w sieci wirtualnej (dla wszystkich usług kontenerów platformy Azure).

Planowanie podsieci

Upewnienie się, że masz podsieć, która jest wystarczająco duża, aby uwzględnić wystąpienia aplikacji dla obciążenia, nie jest jedynym czynnikiem, który określa ślad sieciowy, w którym te aplikacje są wdrażane.

Aplikacje kontenera AKS Web App for Containers
Obsługa obciążeń kolokowanych w podsieci* ❌* ✅ Nie dotyczy*

*Opisuje to najlepsze rozwiązanie, a nie ograniczenie techniczne.

W przypadku usługi Container Apps integracja podsieci dotyczy tylko jednego środowiska usługi Container Apps. Każde środowisko usługi Container Apps jest ograniczone do pojedynczego adresu IP ruchu przychodzącego, publicznego lub prywatnego.

Każde środowisko usługi Container Apps jest przeznaczone tylko dla pojedynczego obciążenia, w którym są współlokowane aplikacje zależne. W związku z tym należy wprowadzić dodatkowe urządzenia sieciowe platformy Azure na potrzeby równoważenia obciążenia przychodzącego, jeśli potrzebujesz zarówno ruchu przychodzącego, jak i publicznego. Przykłady obejmują aplikacja systemu Azure Gateway i Azure Front Door. Ponadto jeśli masz wiele obciążeń, które muszą być segregowane, wymagane są dodatkowe środowiska usługi Container Apps, więc dodatkowa podsieć musi zostać przydzielona dla każdego środowiska.

Usługa AKS zapewnia szczegółową kontrolę przepływu sieci wschód-zachód w klastrze w postaci zasad sieci platformy Kubernetes. Ta kontrola przepływu umożliwia segmentowanie wielu obciążeń z różnymi granicami zabezpieczeń sieci w tym samym klastrze.

W przypadku usługi Web App for Containers nie ma ograniczeń dotyczących liczby aplikacji, które można zintegrować z jedną podsiecią, o ile podsieć jest wystarczająco duża. Nie ma najlepszych rozwiązań dotyczących kontroli dostępu między aplikacjami internetowymi w tej samej sieci wirtualnej. Każda aplikacja internetowa niezależnie zarządza kontrolą dostępu dla ruchu east-west lub north-south z sieci wirtualnej lub Internetu, odpowiednio.

Uwaga

Nie można zmienić rozmiaru podsieci, które mają wdrożone zasoby. Podczas planowania sieci należy zachować szczególną ostrożność, aby uniknąć konieczności ponownego wdrażania całych składników obciążenia, co może prowadzić do przestojów.

Liczba dostępnych adresów IP ruchu przychodzącego

W poniższej tabeli przedstawiono poprzednią sekcję planowania podsieci w celu zdefiniowania liczby adresów IP, które mogą być uwidocznione dla dowolnej liczby aplikacji hostowanych w jednym wdrożeniu usługi kontenera platformy Azure.

Aplikacje kontenera AKS Web App for Containers
Liczba adresów IP ruchu przychodzącego Jeden Dużo App Service Environment: jeden
Brak środowiska usługi App Service: wiele

Usługa Container Apps umożliwia korzystanie z jednego adresu IP na środowisko, publiczne lub prywatne. Usługa AKS zezwala na dowolną liczbę adresów IP, publicznych lub prywatnych. Usługa Web App for Containers, poza środowiskiem App Service Environment, umożliwia korzystanie z jednego publicznego adresu IP dla wszystkich aplikacji w ramach planu usługi App Service i wielu prywatnych adresów IP korzystających z prywatnych punktów końcowych platformy Azure.

Należy pamiętać, że aplikacje internetowe zintegrowane ze środowiskiem App Service Environment odbierają ruch tylko za pośrednictwem pojedynczego adresu IP ruchu przychodzącego skojarzonego ze środowiskiem App Service Environment, niezależnie od tego, czy jest to publiczny, czy prywatny.

Obsługa tras zdefiniowanych przez użytkownika i bramy translatora adresów sieciowych

Jeśli obciążenie wymaga tras zdefiniowanych przez użytkownika i funkcji bramy translatora adresów sieciowych na potrzeby szczegółowej kontroli sieci, usługa Container Apps wymaga użycia profilów obciążeń. Zgodność trasy zdefiniowanej przez użytkownika i bramy translatora adresów sieciowych nie jest dostępna w planie tylko do użycia dla usługi ACA.

Usługi AKS i Web App for Containers implementują te dwie funkcje sieciowe za pomocą standardowych funkcji sieci wirtualnej lub integracji sieci wirtualnej. W celu opracowania pul węzłów usługi AKS i funkcji Web App for Containers w środowisku App Service Environment są już bezpośrednio zasobami sieci wirtualnej. Usługa Web App for Containers, która nie znajduje się w środowisku App Service Environment, obsługuje trasy zdefiniowane przez użytkownika i bramę translatora adresów sieciowych za pośrednictwem integracji z siecią wirtualną. W przypadku integracji z siecią wirtualną zasób technicznie nie znajduje się bezpośrednio w sieci wirtualnej, ale wszystkie przepływy dostępu wychodzącego przez sieć wirtualną, a skojarzone reguły sieci wpływają na ruch zgodnie z oczekiwaniami.

Aplikacje kontenera AKS Web App for Containers
Obsługa trasy zdefiniowanej przez użytkownika Plan tylko do użycia: ❌
Plan profilu obciążenia: ✅		 ✅ ✅
Obsługa bramy translatora adresów sieciowych Plan tylko do użycia: ❌
Plan profilu obciążenia: ✅		 ✅ ✅

Integracja sieci prywatnej

W przypadku obciążeń wymagających ścisłej sieci prywatnej warstwy 4 zarówno dla ruchu przychodzącego, jak i wychodzącego należy rozważyć użycie usługi Container Apps, AKS i jednostki SKU środowiska App Service Environment z jedną dzierżawą, w której obciążenia są wdrażane w sieci wirtualnej zarządzanej samodzielnie, zapewniając niestandardowe szczegółowe mechanizmy kontroli sieci prywatnej.

Aplikacje kontenera AKS Web App for Containers
Prywatny ruch przychodzący do sieci wirtualnej ✅ ✅ Za pośrednictwem prywatnego punktu końcowego
Prywatny ruch wychodzący z sieci wirtualnej ✅ ✅ Za pośrednictwem integracji z siecią wirtualną
W pełni pominięty publiczny punkt końcowy ✅ ✅ Tylko środowisko App Service Environment
Sieć prywatna z usługą Web App for Containers

Usługa Web App for Containers udostępnia dodatkowe funkcje sieciowe, które nie są udostępniane w ten sam sposób przez inne usługi platformy Azure opisane w tym artykule. Aby zaimplementować ścisłe wymagania dotyczące sieci prywatnej, zespoły ds. obciążeń muszą zapoznać się z tymi pojęciami dotyczącymi sieci. Dokładnie przejrzyj następujące funkcje sieciowe:

Jeśli potrzebujesz rozwiązania PaaS i preferujesz pojęcia dotyczące sieci, które są współużytkowane w wielu rozwiązaniach platformy Azure, rozważ użycie usługi Container Apps.

Pokrycie protokołów

Ważną kwestią dla platformy hostingu są protokoły sieciowe obsługiwane dla przychodzących żądań aplikacji (przychodzących). Usługa Web App for Containers jest najbardziej rygorystyczną opcją, która obsługuje tylko protokół HTTP i HTTPS. Usługa Container Apps dodatkowo zezwala na przychodzące połączenia TCP. Usługa AKS jest najbardziej elastyczna, obsługując nieograniczone użycie protokołów TCP i UDP na wybranych samodzielnie portach.

Aplikacje kontenera AKS Web App for Containers
Obsługa protokołów i portów HTTP (port 80)*
HTTPS (port 443)*
TCP (porty 1–65535, z wyjątkiem 80 i 443)		 TCP (dowolny port)
UDP (dowolny port)		 HTTP (port 80)
HTTPS (port 443)
Obsługa protokołu WebSocket ✅ ✅ ✅
Obsługa protokołu HTTP/2 ✅ ✅ ✅

*W środowisku usługi Container Apps protokół HTTP/S można uwidocznić na dowolnym porcie na potrzeby komunikacji wewnątrz klastra. W tym scenariuszu wbudowane funkcje HTTP usługi Container Apps, takie jak CORS i koligacja sesji, nie mają zastosowania.

Zarówno aplikacje kontenera, jak i usługa Web App for Containers obsługują protokół TLS 1.2 dla wbudowanego ruchu przychodzącego HTTPS.

Równoważenie obciążenia

Dzięki usłudze Container Apps i Web App for Containers platforma Azure w pełni wyodrębnia moduły równoważenia obciążenia warstwy 4 i warstwy 7.

W przeciwieństwie do usługi AKS jest używany model wspólnej odpowiedzialności, w którym platforma Azure zarządza podstawową infrastrukturą platformy Azure, którą zespół obciążeń konfiguruje, łącząc się z interfejsem API Kubernetes. W przypadku równoważenia obciążenia warstwy 7 w usłudze AKS można wybrać opcje zarządzane przez platformę Azure, na przykład dodatek routingu aplikacji zarządzanych przez usługę AKS lub usługę Application Gateway for Containers albo wdrożyć wybrany kontroler ruchu przychodzącego i samodzielnie nim zarządzać.

Aplikacje kontenera AKS Web App for Containers
Moduł równoważenia obciążenia warstwy 4 Zarządzane przez platformę Azure Wspólna odpowiedzialność Zarządzane przez platformę Azure
Moduł równoważenia obciążenia warstwy 7 Zarządzane przez platformę Azure Współużytkowany lub samodzielny Zarządzane przez platformę Azure

Odnajdywanie usług

W architekturach chmury środowiska uruchomieniowe można usuwać i ponownie tworzyć w dowolnym momencie w celu ponownego równoważenia zasobów, więc adresy IP wystąpień regularnie zmieniają się. Te architektury używają w pełni kwalifikowanych nazw domen (FQDN) do niezawodnej i spójnej komunikacji.

Aplikacje kontenera AKS Web App for Containers
Odnajdywanie usług Nazwa FQDN zarządzana przez platformę Azure Konfigurowalne rozwiązanie Kubernetes Nazwa FQDN zarządzana przez platformę Azure

Usługa Web Apps for Containers udostępnia publiczne numery FQDN ruchu przychodzącego (komunikacja północno-południowa). Nie jest wymagana żadna dodatkowa konfiguracja DNS. Nie ma jednak wbudowanego mechanizmu ułatwiania lub ograniczania ruchu między innymi aplikacjami (komunikacja wschodnio-zachodnia).

Usługa Container Apps udostępnia również publiczne nazwy FQDN ruchu przychodzącego. Jednak usługa Container Apps umożliwia uwidocznienie nazwy FQDN aplikacji i ograniczenie ruchu tylko w środowisku. Ta funkcja ułatwia zarządzanie komunikacją wschodnio-zachodnią i włączanie składników, takich jak Dapr.

Wdrożenia platformy Kubernetes nie są początkowo wykrywalne w ramach klastra lub spoza niego. Należy utworzyć usługi Kubernetes zdefiniowane przez interfejs API Kubernetes, który następnie uwidacznia aplikacje w sieci w sposób adresowalny.

Ważne

Tylko usługi Container Apps i AKS zapewniają odnajdywanie usług za pośrednictwem wewnętrznych schematów DNS w odpowiednich środowiskach. Ta funkcja może uprościć konfiguracje DNS w środowiskach deweloperskich/testowych i produkcyjnych. Można na przykład utworzyć te środowiska z dowolnymi nazwami usług, które muszą być unikatowe tylko w środowisku lub klastrze, dzięki czemu mogą być takie same w środowisku deweloperskim/testowym i produkcyjnym. W przypadku usługi Web App for Containers nazwy usług muszą być unikatowe w różnych środowiskach, aby uniknąć konfliktów z usługą Azure DNS.

Domeny niestandardowe i zarządzany protokół TLS

Zarówno usługa Container Apps, jak i usługa Web App for Containers udostępniają gotowe rozwiązania do zarządzania domenami niestandardowymi i certyfikatami.

Aplikacje kontenera AKS Web App for Containers
Konfigurowanie domen niestandardowych Poza pudełkiem BYO Poza pudełkiem
Zarządzany protokół TLS dla nazw FQDN platformy Azure Poza pudełkiem Nie dotyczy Poza pudełkiem
Zarządzany protokół TLS dla domen niestandardowych W wersji zapoznawczej BYO Gotowe do użycia lub BYO

Użytkownicy usługi AKS są odpowiedzialni za zarządzanie systemami DNS, konfiguracjami klastra i certyfikatami TLS dla swoich domen niestandardowych. Mimo że usługa AKS nie oferuje zarządzanego protokołu TLS, klienci mogą korzystać z oprogramowania z ekosystemu Kubernetes, na przykład popularnego menedżera certyfikatów do zarządzania certyfikatami TLS.

Wzajemne protokoły TLS

Inną alternatywą dla ograniczania ruchu przychodzącego jest wzajemne protokoły TLS (mTLS). Protokół TLS jest protokołem zabezpieczeń, który gwarantuje, że zarówno klient, jak i serwer w komunikacji są uwierzytelniane. Aby przeprowadzić uwierzytelnianie, obie strony wymieniają i weryfikują certyfikaty przed przesłaniem jakichkolwiek danych.

Usługa Web App for Containers ma wbudowaną obsługę mTLS dla przychodzących połączeń klienckich. Jednak aplikacja musi zweryfikować certyfikat, korzystając z nagłówka HTTP przekazywanego X-ARR-ClientCert przez platformę App Service.

Usługa Container Apps ma również wbudowaną obsługę biblioteki mTLS. Przekazuje certyfikat klienta do aplikacji w nagłówku HTTP X-Forwarded-Client-Cert. Można również łatwo włączyć automatyczne mTLS na potrzeby komunikacji wewnętrznej między aplikacjami w jednym środowisku.

Wzajemne protokoły TLS w usłudze AKS można zaimplementować za pośrednictwem siatki usług opartej na systemie Istio jako zarządzanego dodatku, który obejmuje funkcje mTLS dla przychodzących połączeń klienckich i komunikacji wewnątrz klastra między usługami. Zespoły ds. obciążeń mogą również zdecydować się na zainstalowanie innej oferty siatki usług i zarządzanie nią z ekosystemu Kubernetes. Te opcje sprawiają, że implementacja mTLS na platformie Kubernetes jest najbardziej elastyczna.

Pojęcia dotyczące sieci specyficzne dla usługi

W poprzednich sekcjach opisano niektóre z najczęstszych zagadnień, które należy wziąć pod uwagę. Aby uzyskać więcej informacji i dowiedzieć się więcej na temat funkcji sieciowych specyficznych dla poszczególnych usług kontenerów platformy Azure, zobacz następujące artykuły:

Powyższe sekcje koncentrują się na projektowaniu sieci. Przejdź do następnej sekcji, aby dowiedzieć się więcej na temat zabezpieczeń sieci i zabezpieczania ruchu sieciowego.

Zagadnienia dotyczące zabezpieczeń

Niepowodzenie rozwiązywania problemów z zagrożeniami bezpieczeństwa może prowadzić do nieautoryzowanego dostępu, naruszeń danych lub wycieków poufnych informacji. Kontenery oferują hermetyzowane środowisko dla aplikacji. Systemy hostingu i bazowe nakładki sieciowe wymagają jednak dodatkowych barier zabezpieczających. Wybór usługi kontenera platformy Azure musi obsługiwać określone wymagania dotyczące zabezpieczania poszczególnych aplikacji indywidualnie i zapewnić odpowiednie środki bezpieczeństwa, aby zapobiec nieautoryzowanemu dostępowi i ograniczyć ryzyko ataków.

Omówienie porównania zabezpieczeń

Większość usług platformy Azure, w tym usługi Container Apps, AKS i Web App for Containers, integruje się z ofertami zabezpieczeń kluczy, w tym z usługą Key Vault i tożsamościami zarządzanymi.

W przypadku usług w tym przewodniku usługa AKS oferuje najbardziej konfigurowalność i rozszerzalność po części przez uwidacznianie podstawowych składników, które często można zabezpieczyć za pośrednictwem opcji konfiguracji. Na przykład klienci mogą wyłączyć konta lokalne na serwerze interfejsu API Kubernetes lub włączyć automatyczne aktualizacje węzłów bazowych za pomocą opcji konfiguracji.

Aby zapoznać się ze szczegółowym porównaniem, dokładnie zapoznaj się z poniższymi zagadnieniami, aby upewnić się, że można spełnić wymagania dotyczące zabezpieczeń obciążenia.

Zabezpieczenia płaszczyzny sterowania kubernetes

Usługa AKS oferuje największą elastyczność trzech opcji rozważanych w tym artykule, zapewniając pełny dostęp do interfejsu API Kubernetes, dzięki czemu można dostosować aranżację kontenerów. Ten dostęp do interfejsu API Kubernetes stanowi jednak również znaczną powierzchnię ataków i musisz go zabezpieczyć.

Ważne

Należy pamiętać, że ta sekcja nie jest odpowiednia dla usługi Web App for Containers, która używa interfejsu API usługi Azure Resource Manager jako płaszczyzny sterowania.

Zabezpieczenia oparte na tożsamościach

Klienci są odpowiedzialni za zabezpieczanie dostępu opartego na tożsamościach do interfejsu API. Platforma Kubernetes oferuje własny system zarządzania uwierzytelnianiem i autoryzacją, który również musi być zabezpieczony za pomocą kontroli dostępu.

Aby skorzystać z jednej płaszczyzny szkła do zarządzania tożsamościami i dostępem na platformie Azure, najlepszym rozwiązaniem jest wyłączenie kont lokalnych specyficznych dla platformy Kubernetes i zaimplementowanie integracji usługi Microsoft Entra zarządzanej przez usługę AKS wraz z kontrolą dostępu opartą na rolach platformy Azure dla platformy Kubernetes. Jeśli zaimplementujesz to najlepsze rozwiązanie, administratorzy nie muszą wykonywać zarządzania tożsamościami i dostępem na wielu platformach.

Aplikacje kontenera AKS
Mechanizmy kontroli dostępu interfejsu API platformy Kubernetes Brak dostępu Pełny dostęp

Klienci korzystający z usługi Container Apps nie mają dostępu do interfejsu API platformy Kubernetes. Firma Microsoft zapewnia zabezpieczenia dla tego interfejsu API.

Zabezpieczenia oparte na sieci

Jeśli chcesz ograniczyć dostęp sieciowy do płaszczyzny sterowania platformy Kubernetes, musisz użyć usługi AKS, która udostępnia dwie opcje. Pierwszą opcją jest użycie prywatnych klastrów usługi AKS, które używają usługi Azure Private Link między siecią prywatną serwera interfejsu API a siecią prywatną klastra AKS. Drugą opcją jest integracja z siecią wirtualną serwera API (wersja zapoznawcza), w której serwer interfejsu API jest zintegrowany z podsiecią delegowaną. Zapoznaj się z dokumentacją, aby dowiedzieć się więcej.

Istnieją konsekwencje implementacji dostępu z ograniczeniami sieci do interfejsu API platformy Kubernetes. W szczególności zarządzanie można wykonywać tylko z poziomu sieci prywatnej. Zazwyczaj oznacza to, że musisz wdrożyć własnych agentów dla usługi Azure DevOps lub GitHub Actions. Aby dowiedzieć się więcej o innych ograniczeniach, zobacz dokumentację specyficzną dla produktu.

Aplikacje kontenera AKS
Zabezpieczenia sieciowe interfejsu API platformy Kubernetes Nie można skonfigurować w usłudze PaaS Możliwe do skonfigurowania: publiczny adres IP lub prywatny adres IP

Te zagadnienia nie mają zastosowania do usługi Container Apps. Ponieważ jest to rozwiązanie PaaS, firma Microsoft abstrahuje od podstawowej infrastruktury.

Zabezpieczenia sieci płaszczyzny danych

Poniższe funkcje sieciowe mogą służyć do kontrolowania dostępu do i z poziomu obciążenia.

Korzystanie z zasad sieciowych w celu zapewnienia zabezpieczeń ruchu wewnątrz klastra

Niektóre stany zabezpieczeń wymagają segregacji ruchu sieciowego w środowisku, na przykład w przypadku korzystania ze środowisk wielodostępnych do hostowania wielu lub wielowarstwowych aplikacji. W tych scenariuszach należy wybrać usługę AKS i wdrożyć zasady sieciowe— technologię natywną dla chmury, która umożliwia szczegółową konfigurację sieci warstwy 4 w klastrach Kubernetes.

Aplikacje kontenera AKS Web App for Containers
Zasady sieciowe Plan zużycia: ❌
Dedykowany plan: ❌		 ✅ ❌

Spośród trzech usług platformy Azure opisanych w tym artykule usługa AKS jest jedyną usługą, która obsługuje dalszą izolację obciążeń w klastrze. Zasady sieciowe nie są obsługiwane w usłudze Container Apps ani Web App for Containers.

Sieciowe grupy zabezpieczeń

We wszystkich scenariuszach można regulować komunikację sieciową w szerszej sieci wirtualnej przy użyciu sieciowych grup zabezpieczeń, co umożliwia korzystanie z reguł ruchu warstwy 4, które regulują ruch przychodzący i wychodzący na poziomie sieci wirtualnej.

Aplikacje kontenera AKS Web App for Containers
Sieciowe grupy zabezpieczeń Plan zużycia: ✅
Dedykowany plan: ✅		 ✅ ✅ Aplikacje zintegrowane z siecią wirtualną: tylko ruch wychodzący

Ograniczenia adresów IP dla ruchu przychodzącego

Zazwyczaj ograniczenia ruchu sieciowego są stosowane za pośrednictwem reguł warstwy 4 opisanych powyżej. Jednak w scenariuszach PaaS aplikacji bez integracji z siecią wirtualną może być przydatne ograniczenie ruchu w warstwie aplikacji.

Kontener Apps i Web App for Containers zapewniają wbudowane ograniczenia źródłowego adresu IP dla ruchu przychodzącego w poszczególnych aplikacjach.

Aplikacje kontenera AKS Web App for Containers
Ograniczenia adresów IP ruchu przychodzącego w warstwie aplikacji Poza pudełkiem Samodzielne zarządzanie lub za pomocą zarządzanego dodatku Poza pudełkiem
Użycie zasobów - Zużywa zasoby klastra -

W przypadku obciążeń usługi AKS implementacja zależy od wybranego kontrolera ruchu przychodzącego. Zarówno samodzielne zarządzanie, jak i dodatek do routingu aplikacji zarządzanych platformy Azure zużywa zasoby klastra.

Zabezpieczenia na poziomie aplikacji

Należy zabezpieczyć obciążenia nie tylko na poziomie sieci i infrastruktury, ale także na poziomie obciążenia i aplikacji. Rozwiązania kontenerów platformy Azure integrują się z ofertami zabezpieczeń platformy Azure, aby ułatwić standaryzację implementacji zabezpieczeń i mechanizmów kontroli aplikacji.

Integracja z usługą Key Vault

Najlepszym rozwiązaniem jest przechowywanie wpisów tajnych, kluczy i certyfikatów oraz zarządzanie nimi w rozwiązaniu do zarządzania kluczami, takimi jak Key Vault, które zapewnia zwiększone bezpieczeństwo tych składników. Zamiast przechowywać i konfigurować wpisy tajne w kodzie lub w usłudze obliczeniowej platformy Azure, wszystkie aplikacje powinny być zintegrowane z usługą Key Vault.

Integracja z usługą Key Vault umożliwia deweloperom aplikacji skoncentrowanie się na kodzie aplikacji. Wszystkie trzy usługi kontenerów platformy Azure opisane w tym artykule mogą automatycznie synchronizować wpisy tajne z usługi Key Vault i udostępniać je aplikacji, zazwyczaj jako zmienne środowiskowe lub zainstalowane pliki.

Aplikacje kontenera AKS Web App for Containers
Integracja z usługą Key Vault ✅ ✅ ✅

Aby uzyskać więcej informacji, zobacz:

Obsługa tożsamości zarządzanej

Aplikacje z przypisanymi tożsamościami zarządzanymi mogą uzyskiwać dostęp do zasobów platformy Azure bez haseł. Wszystkie usługi kontenerów wymienione w tym przewodniku obsługują tożsamości zarządzane.

Aplikacje kontenera AKS Web App for Containers
Obsługa tożsamości zarządzanej ✅ ✅ ✅

Aby uzyskać więcej informacji, zobacz:

Oceny zagrożeń i luk w zabezpieczeniach za pomocą usługi Defender for Containers

Ochrona przed zagrożeniami przed lukami w zabezpieczeniach jest również ważna. Najlepszym rozwiązaniem jest użycie usługi Defender for Containers. Oceny luk w zabezpieczeniach są obsługiwane w rejestrach kontenerów platformy Azure, dzięki czemu mogą być używane przez dowolną usługę kontenera platformy Azure, a nie tylko te opisane w tym artykule. Ochrona środowiska uruchomieniowego usługi Defender for Containers jest jednak dostępna tylko dla usługi AKS.

Ponieważ usługa AKS uwidacznia natywny interfejs API kubernetes, zabezpieczenia klastra można również ocenić za pomocą narzędzi zabezpieczeń specyficznych dla platformy Kubernetes z ekosystemu Kubernetes.

Aplikacje kontenera AKS Web App for Containers
Ochrona przed zagrożeniami w czasie wykonywania ❌ ✅ ❌

Aby uzyskać więcej informacji, zobacz Macierz obsługi kontenerów w Defender dla Chmury.

Należy pamiętać, że oceny luk w zabezpieczeniach obrazów kontenera nie są skanowaniem w czasie rzeczywistym. Rejestr kontenerów platformy Azure jest skanowany w regularnych odstępach czasu.

Punkty odniesienia zabezpieczeń

Ogólnie rzecz biorąc, większość usług kontenerów platformy Azure integruje oferty zabezpieczeń platformy Azure. Ogólnie rzecz biorąc, należy pamiętać, że zestaw funkcji zabezpieczeń jest tylko niewielką częścią implementowania zabezpieczeń w chmurze. Aby uzyskać więcej informacji na temat implementowania zabezpieczeń dla usług kontenerów, zobacz następujące punkty odniesienia zabezpieczeń specyficzne dla usługi:

Punkty odniesienia zabezpieczeń obejmują inne integracje platformy Azure, w tym szyfrowanie sprzętowe i rejestrowanie, które są poza zakresem tego artykułu.

Dobrze zaprojektowana struktura pod kątem zabezpieczeń

Ten artykuł koncentruje się na głównych różnicach między funkcjami usług kontenerów opisanymi tutaj.

Aby uzyskać więcej szczegółowych wskazówek dotyczących zabezpieczeń dotyczących usługi AKS, zobacz Artykuł Well-Architected Framework review — AKS (Dobrze zaprojektowana struktura — AKS).

Zagadnienia operacyjne

Aby pomyślnie uruchomić obciążenie w środowisku produkcyjnym, zespoły muszą wdrożyć praktyki doskonałości operacyjnej, w tym scentralizowane rejestrowanie, monitorowanie, skalowalność, regularne aktualizacje i stosowanie poprawek oraz zarządzanie obrazami.

Aktualizacje i poprawki

Ważne jest, aby podstawowy system operacyjny aplikacji był aktualizowany i regularnie poprawiany. Należy jednak pamiętać, że w przypadku każdej aktualizacji istnieje ryzyko awarii. W tej sekcji i w następnej opisano główne zagadnienia dotyczące trzech usług kontenerów w odniesieniu do wspólnej odpowiedzialności między klientem a platformą.

Jako zarządzana usługa Kubernetes usługa AKS udostępnia zaktualizowane obrazy dla składników systemu operacyjnego węzła i płaszczyzny sterowania. Zespoły obciążeń są jednak odpowiedzialne za stosowanie aktualizacji do swoich klastrów. Aktualizacje można wyzwalać ręcznie lub korzystać z funkcji kanałów automatycznego uaktualniania klastra, aby upewnić się, że klastry są aktualne. Zapoznaj się z przewodnikiem obsługi usługi AKS day-2, aby dowiedzieć się więcej na temat stosowania poprawek i uaktualniania klastrów usługi AKS.

Kontener Apps i Web App for Containers to rozwiązania PaaS. Platforma Azure jest odpowiedzialna za zarządzanie aktualizacjami i poprawkami, dzięki czemu klienci mogą uniknąć złożoności zarządzania uaktualnieniami usługi AKS.

Aplikacje kontenera AKS Web App for Containers
Aktualizacje płaszczyzny sterowania Platforma Klient Platforma
Aktualizacje i poprawki hosta Platforma Klient Platforma
Aktualizacje i poprawki obrazu kontenera Klient Klient Klient

Aktualizacje obrazu kontenera

Niezależnie od rozwiązania kontenera platformy Azure klienci są zawsze odpowiedzialni za własne obrazy kontenerów. Jeśli istnieją poprawki zabezpieczeń dla obrazów bazowych kontenerów, twoim zadaniem jest ponowne kompilowanie obrazów. Aby uzyskać alerty dotyczące tych luk w zabezpieczeniach, użyj usługi Defender for Containers dla kontenerów hostowanych w usłudze Container Registry.

Skalowalność

Skalowanie służy do dostosowywania pojemności zasobów w celu spełnienia wymagań, dodając większą pojemność w celu zapewnienia wydajności i usuwania nieużywanej pojemności w celu zaoszczędzenia pieniędzy. Po wybraniu rozwiązania kontenera należy wziąć pod uwagę ograniczenia infrastruktury i strategie skalowania.

Skalowalność infrastruktury pionowej

Skalowanie w pionie odnosi się do możliwości zwiększenia lub zmniejszenia istniejącej infrastruktury, czyli procesora obliczeniowego i pamięci. Różne obciążenia wymagają różnych ilości zasobów obliczeniowych. Po wybraniu rozwiązania kontenera platformy Azure należy pamiętać o ofertach jednostki SKU sprzętu, które są dostępne dla określonej usługi platformy Azure. Różnią się one i mogą nakładać dodatkowe ograniczenia.

W przypadku usługi AKS przejrzyj rozmiary maszyn wirtualnych w dokumentacji platformy Azure i ograniczenia usługi AKS dla poszczególnych regionów.

Te artykuły zawierają szczegółowe informacje o ofertach jednostek SKU dla pozostałych dwóch usług:

Skalowalność infrastruktury poziomej

Skalowanie w poziomie odnosi się do możliwości zwiększenia lub zmniejszenia pojemności za pośrednictwem nowej infrastruktury, takiej jak węzły maszyn wirtualnych. Podczas skalowania zwiększa lub zmniejsza się warstwa zużycie usługi Container Apps abstrakcji podstawowych maszyn wirtualnych. W przypadku pozostałych usług kontenerów platformy Azure można zarządzać strategią skalowania w poziomie przy użyciu standardowego interfejsu API usługi Azure Resource Manager.

Należy pamiętać, że skalowanie w górę i w programie obejmuje ponowne równoważenie wystąpień, więc powoduje również ryzyko przestoju. Ryzyko jest mniejsze niż odpowiednie ryzyko ze skalowaniem w pionie. Niemniej jednak zespoły obciążeń są zawsze odpowiedzialne za zapewnienie, że ich aplikacje mogą obsługiwać awarie i implementować bezproblemowe uruchamianie i zamykanie aplikacji, aby uniknąć przestojów.

Aplikacje kontenera AKS Web App for Containers
Skalowanie infrastruktury w poziomie i w poziomie Plan zużycia: Nie dotyczy
Dedykowany plan: konfigurowalny		 Konfigurowalny Konfigurowalny
Elastyczna aprowizacja sprzętu Plan zużycia: Nie dotyczy
Plan dedykowany: abstrakcja z profilami obciążeń		 Dowolna jednostka SKU maszyny wirtualnej Abstracted. Zobacz Plan usługi App Service.

Ważne

Opcje aprowizacji sprzętu dostępne za pośrednictwem dedykowanych planów usługi Container Apps (profilów obciążeń) i usługi Web App for Containers (plany usługi App Service) nie są tak elastyczne, jak usługa AKS. Musisz zapoznać się z jednostkami SKU dostępnymi w każdej usłudze, aby upewnić się, że twoje potrzeby są spełnione.

Skalowalność aplikacji

Typową miarą wyzwalającą skalowanie infrastruktury i aplikacji jest użycie zasobów: procesor i pamięć. Niektóre rozwiązania kontenerów mogą skalować liczbę wystąpień kontenera na metryki z kontekstem specyficznym dla aplikacji, na przykład żądania HTTP. Na przykład usługi AKS i Container Apps mogą skalować wystąpienia kontenerów na podstawie kolejek komunikatów za pośrednictwem usługi KEDA i wielu innych metryk za pośrednictwem jego modułów skalowania. Te możliwości zapewniają elastyczność podczas wybierania strategii skalowalności aplikacji. Usługa Web App for Containers korzysta z opcji skalowalności udostępnianych przez platformę Azure. (Zobacz poniższą tabelę). Usługa Web App for Containers nie obsługuje niestandardowych konfiguracji skalowania, takich jak KEDA.

Aplikacje kontenera AKS Web App for Containers
Skalowanie kontenera w poziomie Protokół HTTP, TCP lub metryki (procesor CPU, pamięć, sterowane zdarzeniami). Oparte na metrykach (procesor CPU, pamięć lub niestandardowy). Ręczne, oparte na metrykach lub automatyczne (wersja zapoznawcza).
Skalowalność sterowana zdarzeniami Tak. Natywny dla chmury. Tak. Natywny dla chmury. Wymagana jest dodatkowa konfiguracja. Tak. Specyficzne dla zasobów platformy Azure.

Wgląd w informacje

Instrumentacja obciążenia

Zbieranie metryk dla złożonych lub wielowarstwowych aplikacji może być trudne. Aby uzyskać metryki, możesz zintegrować konteneryzowane obciążenia z usługą Azure Monitor na dwa sposoby:

  • Instrumentacja automatyczna. Nie są wymagane żadne zmiany kodu.
  • Instrumentacja ręczna. Minimalne zmiany kodu wymagane do zintegrowania i skonfigurowania zestawu SDK i/lub klienta.
Aplikacje kontenera AKS Web App for Containers
Automatyczna instrumentacja za pośrednictwem platformy ❌ ❌ Częściowa obsługa*
Automatyczna instrumentacja za pośrednictwem agenta ❌ Częściowa obsługa* Nie dotyczy
Instrumentacja ręczna Za pomocą zestawu SDK lub interfejsu OpenTelemetry Za pomocą zestawu SDK lub interfejsu OpenTelemetry Za pomocą zestawu SDK lub interfejsu OpenTelemetry

*Usługi AKS i Web App for Containers obsługują automatyczną instrumentację niektórych konfiguracji obciążeń systemów Linux i Windows w zależności od języka aplikacji. Więcej informacji można znaleźć w tych artykułach:

Instrumentacja w kodzie aplikacji jest obowiązkiem deweloperów aplikacji, dlatego jest niezależna od dowolnego rozwiązania kontenera platformy Azure. Twoje obciążenie może używać rozwiązań, takich jak:

Dzienniki

Wszystkie usługi kontenerów platformy Azure zapewniają funkcje dziennika aplikacji i platformy. Dzienniki aplikacji to dzienniki konsoli generowane przez obciążenie. Dzienniki platformy przechwytują zdarzenia występujące na poziomie platformy poza zakresem aplikacji, takie jak skalowanie i wdrożenia.

Główne różnice między funkcjami rejestrowania dla usług kontenerów odnoszą się do rejestrowania platformy: co jest rejestrowane i jak dzienniki są zorganizowane wewnętrznie. Azure Monitor to główna usługa rejestrowania na platformie Azure, która integruje się z tymi usługami. Monitor używa dzienników zasobów do oddzielania dzienników pochodzących z różnych źródeł do kategorii. Jednym ze sposobów określenia, które dzienniki są dostępne w każdej usłudze platformy Azure, jest przyjrzenie się kategoriom dzienników zasobów, które są dostępne dla każdej z usług.

Aplikacje kontenera AKS Web App for Containers
Obsługa przesyłania strumieniowego dzienników (przesyłanie strumieniowe w czasie rzeczywistym) ✅ ✅ ✅
Obsługa usługi Azure Monitor ✅ ✅ ✅
Dzienniki zasobów usługi Azure Monitor Konsola i system Serwer interfejsu API Kubernetes, inspekcja, harmonogram, narzędzie do automatycznego skalowania klastra i inne ConsoleLogs, HTTPLogs, EnvironmentPlatformLogs i inne

Aby uzyskać szczegółowy opis poszczególnych dzienników zasobów w tabeli, wybierz linki w tabeli.

Poniżej przedstawiono krótkie podsumowanie możliwości rejestrowania usług kontenerów:

  • Usługa Container Apps abstrakuje wszystkie wewnętrzne dzienniki kubernetes w dwóch kategoriach. Jeden, nazywany dziennikami konsoli , zawiera dzienniki kontenera obciążenia. Druga kategoria System zawiera wszystkie dzienniki związane z platformą.
  • Usługa AKS zapewnia wszystkie dzienniki związane z platformą Kubernetes i szczegółową kontrolę nad tym, co można zarejestrować. Zachowuje również pełną zgodność z narzędziami klienckimi platformy Kubernetes na potrzeby przesyłania strumieniowego dzienników, na przykład kubectl.
  • Usługa Web App for Containers udostępnia wiele kategorii dzienników zasobów, ponieważ jej platforma (App Service) nie jest wyłącznie dla obciążeń kontenerów. W przypadku operacji specyficznych dla kontenera, które zarządzają wewnętrzną platformą Docker, udostępnia kategorię dziennika AppServicePlatformLogs. Inną ważną kategorią jest AppServiceEnvironmentPlatformLogs, która rejestruje zdarzenia, takie jak skalowanie i zmiany konfiguracji.

Dobrze zaprojektowana struktura doskonałości operacyjnej

Ten artykuł koncentruje się na głównych różnicach między funkcjami usług kontenerów opisanymi tutaj. Zapoznaj się z tymi artykułami, aby zapoznać się z pełnymi wskazówkami dotyczącymi doskonałości operacyjnej dla następujących usług:

Niezawodność

Niezawodność odnosi się do zdolności systemu do reagowania na awarie i pozostania w pełni funkcjonalne. Na poziomie oprogramowania aplikacji obciążenia powinny implementować najlepsze rozwiązania, takie jak buforowanie, ponawianie prób, wzorce wyłącznika i kontrole kondycji. Na poziomie infrastruktury platforma Azure jest odpowiedzialna za obsługę awarii fizycznych, takich jak awarie sprzętowe i awarie zasilania, w centrach danych. Nadal mogą wystąpić błędy. Zespoły obciążeń powinny wybrać odpowiednią warstwę usługi platformy Azure i zastosować niezbędne konfiguracje minimalnego wystąpienia w celu zaimplementowania automatycznych przełączeń w tryb failover między strefami dostępności.

Aby wybrać odpowiednią warstwę usług, musisz zrozumieć, jak działają umowy dotyczące poziomu usług (SLA) i strefy dostępności.

Umowy dotyczące poziomu usług

Niezawodność jest często mierzona przez metryki oparte na firmie, takie jak umowy SLA lub metryki odzyskiwania, takie jak cele czasu odzyskiwania (RTO).

Platforma Azure ma wiele umów SLA dla określonych usług. Nie ma czegoś takiego jak 100% poziomu usług, ponieważ awarie mogą zawsze występować w oprogramowaniu i sprzęcie, a w naturze, na przykład burze i trzęsienia ziemi. Umowa SLA nie jest gwarancją, ale raczej finansowo wspieraną umową dotyczącą dostępności usług.

Aby uzyskać najnowsze umowy SLA i szczegółowe informacje, pobierz najnowszy dokument SLA dla usług Online Services firmy Microsoft z witryny internetowej licencjonowania firmy Microsoft.

Warstwy bezpłatne a płatne

Ogólnie rzecz biorąc, warstwy bezpłatne usług platformy Azure nie oferują umowy SLA, co sprawia, że są one opłacalne dla środowisk nieprodukcyjnych. Jednak w przypadku środowisk produkcyjnych najlepszym rozwiązaniem jest wybranie warstwy płatnej, która ma umowę SLA.

Dodatkowe czynniki dla usługi AKS

Usługa AKS ma różne umowy SLA dla różnych składników i konfiguracji:

  • Płaszczyzna sterowania. Serwer interfejsu API Kubernetes ma oddzielną umowę SLA.
  • Płaszczyzna danych. Pule węzłów używają bazowych umów SLA jednostek SKU maszyn wirtualnych.
  • Strefy dostępności. Istnieją różne umowy SLA dla obu płaszczyzn, w zależności od tego, czy klaster usługi AKS ma włączone strefy dostępności i uruchamia wiele wystąpień w różnych strefach dostępności.

Należy pamiętać, że w przypadku korzystania z wielu usług platformy Azure złożone cele SLA mogą się różnić od umów SLA poszczególnych usług i być niższe.

Nadmiarowość ze strefami dostępności

Strefy dostępności to odrębne centra danych, które mają niezależne zasilanie elektryczne, chłodzenie itd. w jednym regionie. Wynikowa nadmiarowość zwiększa tolerancję awarii bez konieczności implementowania architektur obejmujących wiele regionów.

Platforma Azure ma strefy dostępności w każdym kraju/regionie, w którym platforma Azure obsługuje region centrum danych. Aby zezwolić wielu wystąpień kontenerów na wiele stref dostępności, należy wybrać jednostki SKU, warstwy usług i regiony, które zapewniają obsługę stref dostępności.

Funkcja Aplikacje kontenera AKS Web App for Containers
Obsługa strefy dostępności Pełny Pełny Pełny

Na przykład aplikacja lub infrastruktura skonfigurowana do uruchamiania pojedynczego wystąpienia stanie się niedostępna, jeśli problem występuje w strefie dostępności, w której jest hostowany sprzęt. Aby w pełni korzystać z obsługi strefy dostępności, należy wdrożyć obciążenia z minimalną konfiguracją trzech wystąpień kontenera rozłożonych między strefy.

Kontrole kondycji i samonaprawiania

Punkty końcowe kontroli kondycji mają kluczowe znaczenie dla niezawodnego obciążenia. Jednak tworzenie tych punktów końcowych jest tylko połowę rozwiązania. Druga połowa kontroluje, co robi platforma hostingu i jak, gdy występują błędy.

Aby lepiej odróżnić typy sond kondycji, przyjrzyj się wbudowanym typom sond z platformy Kubernetes:

  • Uruchamianie. Sprawdza, czy aplikacja została pomyślnie uruchomiona.
  • Gotowość. Sprawdza, czy aplikacja jest gotowa do obsługi żądań przychodzących.
  • Żywość. Sprawdza, czy aplikacja jest nadal uruchomiona i odpowiada.

Innym ważnym zagadnieniem jest częstotliwość żądań kontroli kondycji z aplikacji (stopień szczegółowości wewnętrznej). Jeśli masz długi interwał między tymi żądaniami, możesz nadal obsługiwać ruch, dopóki wystąpienie nie zostanie uznane za w złej kondycji.

Większość aplikacji obsługuje kontrole kondycji za pośrednictwem protokołu HTTP(S). Jednak niektóre mogą wymagać innych protokołów, takich jak TCP lub gRPC, aby wykonać te kontrole. Należy pamiętać o tym podczas projektowania systemu kontroli kondycji.

Aplikacje kontenera AKS Web App for Containers
Sondy uruchamiania ✅ ✅ Częściowa obsługa
Sondy gotowości ✅ ✅ ❌
Sondy liveness ✅ ✅ ✅
Stopień szczegółowości interwału Sekundy Sekundy 1 minuta
Obsługa protokołu HTTP(S)
TCP		 HTTP(S)
TCP
gRPC		 HTTP(S)

Testy kondycji są najłatwiejsze do zaimplementowania w usłudze Web App for Containers. Istnieją pewne ważne zagadnienia:

  • Jego sondy startowe są wbudowane i nie można ich zmieniać. Wysyła żądanie HTTP do portu początkowego kontenera. Każda odpowiedź z aplikacji jest uznawana za pomyślne rozpoczęcie.
  • Nie obsługuje sond gotowości. Jeśli sonda uruchamiania zakończy się pomyślnie, wystąpienie kontenera zostanie dodane do puli wystąpień w dobrej kondycji.
  • Wysyła kontrolę kondycji w interwałach jednominutowych. Nie można zmienić interwału.
  • Minimalny próg, który można ustawić dla wystąpienia w złej kondycji, który ma zostać usunięty z wewnętrznego mechanizmu równoważenia obciążenia, wynosi dwie minuty. Wystąpienie w złej kondycji pobiera ruch przez co najmniej dwie minuty po awarii sprawdzania kondycji. Wartość domyślna tego ustawienia to 10 minut.

Z drugiej strony usługi Container Apps i AKS są znacznie bardziej elastyczne i oferują podobne opcje. Jeśli chodzi o konkretne różnice, usługa AKS udostępnia następujące opcje przeprowadzania kontroli kondycji, które nie są dostępne w usłudze Container Apps:

automatyczne naprawianie

Aby zidentyfikować nieprawidłowe wystąpienie kontenera i przestać wysyłać do niego ruch, to początek. Następnym krokiem jest zaimplementowanie automatycznego naprawiania. Automatyczne naprawianie to proces ponownego uruchamiania aplikacji w celu odzyskania sprawności po stanie złej kondycji. Poniżej przedstawiono porównanie trzech usług kontenerów:

  • W usłudze Web App for Containers nie ma możliwości ponownego uruchomienia wystąpienia kontenera natychmiast po awarii sprawdzania kondycji. Jeśli wystąpienie nadal kończy się niepowodzeniem przez jedną godzinę, zostanie zastąpione przez nowe wystąpienie. Istnieje inna funkcja, nazywana autonaprawieniem, która monitoruje i uruchamia ponownie wystąpienia. Nie jest to bezpośrednio związane z kontrolami kondycji. Używa różnych metryk aplikacji, takich jak limity pamięci, czas trwania żądania HTTP i kody stanu.
  • Usługa Container Apps i usługa AKS automatycznie próbują ponownie uruchomić wystąpienie kontenera, jeśli sonda liveness osiągnie zdefiniowany próg niepowodzenia.

Wdrożenia aplikacji bez przestojów

Możliwość wdrażania i zastępowania aplikacji bez powodowania przestojów dla użytkowników ma kluczowe znaczenie dla niezawodnego obciążenia. Wszystkie trzy usługi kontenerów opisane w tym artykule obsługują wdrożenia bez przestojów, ale na różne sposoby.

Aplikacje kontenera AKS Web App for Containers
Strategia bez przestojów Aktualizacja krocząca Aktualizacja stopniowa oraz wszystkie inne strategie platformy Kubernetes Miejsca wdrożenia

Należy pamiętać, że architektury aplikacji muszą również obsługiwać wdrożenie bez przestojów. Aby uzyskać wskazówki, zobacz Temat Azure Well-Architected Framework ( Dobrze zaprojektowana struktura platformy Azure).

Limity zasobów

Innym ważnym składnikiem niezawodnego środowiska udostępnionego jest kontrola nad użyciem zasobów (na przykład procesora CPU lub pamięci) kontenerów. Należy unikać scenariuszy, w których jedna aplikacja pobiera wszystkie zasoby i pozostawia inne aplikacje w złym stanie.

Aplikacje kontenera AKS Web App for Containers
Limity zasobów (procesor CPU lub pamięć) Na aplikację/kontener Na aplikację/kontener
Na przestrzeń nazw		 Według planu usługi App Service
  • Web App for Containers: możesz hostować wiele aplikacji (kontenerów) w jednym planie usługi App Service. Można na przykład przydzielić plan z dwoma rdzeniami procesora CPU i 4 GiB pamięci RAM, w którym można uruchamiać wiele aplikacji internetowych w kontenerach. Nie można jednak ograniczyć jednej z aplikacji do określonej ilości procesora CPU lub pamięci. Wszyscy konkurują o te same zasoby planu usługi App Service. Jeśli chcesz odizolować zasoby aplikacji, musisz utworzyć dodatkowe plany usługi App Service.
  • Container Apps: w środowisku można ustawić limity procesora CPU i pamięci na aplikację. Ograniczasz się jednak do zestawu dozwolonych kombinacji procesora CPU i pamięci. Na przykład nie można skonfigurować jednego procesora wirtualnego i 1 GiB pamięci, ale można skonfigurować jedną procesor wirtualny i 2 GiB pamięci. Środowisko usługi Container Apps jest analogiczne do przestrzeni nazw platformy Kubernetes.
  • AKS: Możesz wybrać dowolną kombinację procesorów wirtualnych i pamięci, o ile węzły mają sprzęt do jej obsługi. Możesz również ograniczyć zasoby na poziomie przestrzeni nazw, jeśli chcesz podzielić klaster w ten sposób.

Dobrze zaprojektowana struktura pod kątem niezawodności

Ten artykuł koncentruje się na głównych różnicach między funkcjami usług kontenerów na platformie Azure. Jeśli chcesz przejrzeć pełne wskazówki dotyczące niezawodności dla określonej usługi, zobacz następujące artykuły:

Podsumowanie

Dobrze zaprojektowane rozwiązania stanowią podstawę dla pomyślnych obciążeń. Mimo że architektury mogą być dostosowywane w miarę zwiększania się obciążenia, a zespoły postępują w swoich podróżach w chmurze, niektóre decyzje, szczególnie w przypadku sieci, są trudne do odwrócenia bez znaczących przestojów lub ponownego wdrożenia.

Ogólnie rzecz biorąc, podczas porównywania usług kontenerów platformy Azure pojawia się motyw: usługa AKS udostępnia najbardziej podstawową infrastrukturę, oferując w ten sposób największą konfigurowalność i rozszerzalność. Ilość obciążeń operacyjnych i złożoność jest bardzo zmienna dla obciążeń usługi AKS. Niektóre zespoły mogą znacznie zmniejszyć obciążenie operacyjne przy użyciu dodatków i rozszerzeń zarządzanych przez firmę Microsoft, a także funkcji automatycznego uaktualniania. Inni klienci mogą preferować pełną kontrolę nad klastrem w celu wykorzystania pełnej rozszerzalności platformy Kubernetes i ekosystemu CNCF. Na przykład, chociaż firma Microsoft oferuje rozwiązanie Flux jako zarządzane rozszerzenie GitOps, wiele zespołów decyduje się zamiast tego samodzielnie skonfigurować i obsługiwać usługę ArgoCD.

Zespoły obciążeń, które na przykład nie wymagają aplikacji CNCF, mają mniej doświadczenia w operacjach lub wolą skupić się na funkcjach aplikacji, mogą preferować ofertę PaaS. Zalecamy, aby najpierw rozważyli usługę Container Apps.

Mimo że usługi Container Apps i Web App for Containers to oferty PaaS, które zapewniają podobne poziomy infrastruktury zarządzanej przez firmę Microsoft, kluczową różnicą jest to, że usługa Container Apps jest bliżej platformy Kubernetes i zapewnia dodatkowe natywne funkcje chmury na potrzeby odnajdywania usług, automatycznego skalowania opartego na zdarzeniach, integracji języka Dapr i nie tylko. Jednak zespoły, które nie potrzebują tych możliwości i znają modele sieci i wdrażania usługi App Service, mogą preferować usługę Web App for Containers.

Uogólnienia mogą ułatwić zawężenie listy usług kontenerów platformy Azure do rozważenia. Należy jednak pamiętać, że musisz również zweryfikować wybór, sprawdzając szczegółowo poszczególne wymagania i pasując do zestawów funkcji specyficznych dla usługi.

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ć niepubliczne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Następne kroki