Udostępnij za pośrednictwem

Migrowanie obciążenia z usługi Service Fabric do usługi AKS

  • Artykuł

Wiele organizacji przechodzi do konteneryzowanych aplikacji w ramach wypychania w kierunku wdrażania nowoczesnych rozwiązań dotyczących tworzenia aplikacji, najlepszych rozwiązań dotyczących konserwacji i architektur natywnych dla chmury. Ponieważ technologie nadal ewoluują, organizacje muszą ocenić wiele platform aplikacji konteneryzowanych, które są dostępne w chmurze publicznej.

Nie ma jednego uniwersalnego rozwiązania dla aplikacji, ale organizacje często uważają, że usługa Azure Kubernetes Service (AKS) spełnia wymagania wielu aplikacji konteneryzowanych. Usługa AKS to zarządzana usługa Kubernetes, która upraszcza wdrażanie aplikacji za pośrednictwem platformy Kubernetes, zarządzając płaszczyzną sterowania w celu zapewnienia podstawowych usług dla obciążeń aplikacji. Wiele organizacji używa usługi AKS jako podstawowej platformy infrastruktury i obciążeń przejściowych hostowanych na innych platformach do usługi AKS.

W tym artykule opisano sposób migrowania konteneryzowanych aplikacji z usługi Azure Service Fabric do usługi AKS. W tym artykule założono, że znasz usługę Service Fabric, ale interesuje Cię zapoznanie się ze sposobem porównywania jej funkcji i funkcji z usługą AKS. Artykuł zawiera również najlepsze rozwiązania, które należy wziąć pod uwagę podczas migracji.

Porównywanie usługi AKS z usługą Service Fabric

Aby rozpocząć, zapoznaj się z artykułem Wybieranie usługi obliczeniowej platformy Azure wraz z innymi usługami obliczeniowymi platformy Azure. W tej sekcji przedstawiono istotne podobieństwa i różnice, które są istotne dla migracji.

Zarówno usługa Service Fabric, jak i usługa AKS są orkiestratorami kontenerów. Usługa Service Fabric zapewnia obsługę kilku modeli programowania, ale usługa AKS obsługuje tylko kontenery.

  • Modele programowania: usługa Service Fabric obsługuje wiele sposobów pisania usług i zarządzania nimi, w tym kontenerów systemów Linux i Windows, Reliable Services, Reliable Actors, ASP.NET Core i plików wykonywalnych gościa.

  • Kontenery w usłudze AKS: usługa AKS obsługuje kontenery tylko z kontenerami systemu Windows i Linux uruchamianymi w kontenerze środowiska uruchomieniowego kontenera, który jest zarządzany automatycznie.

Zarówno usługa Service Fabric, jak i usługa AKS zapewniają integrację z innymi usługami platformy Azure, takimi jak Azure Pipelines, Azure Monitor, Azure Key Vault i Microsoft Entra ID.

Podstawowe różnice

Podczas wdrażania tradycyjnego klastra usługi Service Fabric zamiast klastra zarządzanego należy jawnie zdefiniować zasób klastra wraz z wieloma zasobami pomocniczymi w szablonach usługi Azure Resource Manager (szablony usługi ARM) lub modułach Bicep. Te zasoby obejmują zestaw skalowania maszyn wirtualnych dla każdego typu węzła klastra, sieciowych grup zabezpieczeń i modułów równoważenia obciążenia. Twoim zadaniem jest upewnienie się, że te zasoby są poprawnie skonfigurowane. Natomiast model hermetyzacji dla klastrów zarządzanych usługi Service Fabric składa się z jednego zasobu klastra zarządzanego. Wszystkie zasoby bazowe dla klastra są abstrakcje i zarządzane przez platformę Azure.

Usługa AKS upraszcza wdrażanie zarządzanego klastra Kubernetes na platformie Azure, odciążając obciążenie operacyjne na platformę Azure. Ponieważ usługa AKS jest hostowaną usługą Kubernetes, platforma Azure obsługuje krytyczne zadania, takie jak monitorowanie kondycji infrastruktury i konserwacja. Platforma Azure zarządza węzłami głównymi platformy Kubernetes, więc wystarczy zarządzać węzłami agenta i obsługiwać je.

Aby przenieść obciążenie z usługi Service Fabric do usługi AKS, musisz zrozumieć różnice w podstawowej infrastrukturze, aby można było bezpiecznie migrować konteneryzowane aplikacje. W poniższej tabeli porównaliśmy możliwości i funkcje dwóch platform hostingu.

Możliwość lub składnik Service Fabric AKS
Aplikacje niekontenerowane Tak Nie.
Kontenery systemów Linux i Windows Tak Tak
Płaszczyzna sterowania zarządzana przez platformę Azure Nie. Tak
Obsługa obciążeń bezstanowych i stanowych Tak Tak
Umieszczanie węzła roboczego Zestawy skalowania maszyn wirtualnych, skonfigurowane przez klienta Zestawy skalowania maszyn wirtualnych, zarządzane przez platformę Azure
Manifest konfiguracji XML YAML
Integracja z usługą Azure Monitor Tak Tak
Natywna obsługa usług Reliable Services i wzorzec reliable actor Tak Nie.
Stos komunikacji oparty na programie WCF dla usług Reliable Services Tak Nie.
Magazyn trwały Sterownik woluminu usługi Azure Files Obsługa różnych systemów magazynowania, takich jak dyski zarządzane, usługa Azure Files i usługa Azure Blob Storage za pośrednictwem klas magazynu CSI, woluminu trwałego i oświadczeń trwałych woluminów
Tryby sieciowe Integracja z usługą Azure Virtual Network Obsługa wielu wtyczek sieciowych (Azure CNI, kubenet, BYOCNI), zasad sieciowych (Azure, Calico) i kontrolerów ruchu przychodzącego (Kontroler ruchu przychodzącego usługi Application Gateway, NGINX i nie tylko)
Kontrolery ruchu przychodzącego Zwrotny serwer proxy wbudowany w usługę Service Fabric. Pomaga to mikrousługom uruchamianym w klastrze usługi Service Fabric odnajdywać i komunikować się z innymi usługami, które mają punkty końcowe HTTP. Możesz również użyć traefik w usłudze Service Fabric Zarządzany kontroler ruchu przychodzącego NGINX, kontrolery typu open source ruchu przychodzącego BYO i kontrolery komercyjne korzystające z publicznych lub wewnętrznych modułów równoważenia obciążenia zarządzanych przez platformę, takich jak kontroler ruchu przychodzącego NGINX i kontroler ruchu przychodzącego usługi Application Gateway

Uwaga

Jeśli używasz kontenerów systemu Windows w usłudze Service Fabric, zalecamy użycie ich w usłudze AKS, aby ułatwić migrację.

Kroki migracji

Ogólnie rzecz biorąc, kroki migracji z usługi Service Fabric do usługi AKS są następujące.

Diagram przedstawiający kroki migracji z usługi Service Fabric do usługi AKS.

  1. Ustanów architekturę wdrożenia i utwórz klaster usługi AKS. Usługa AKS udostępnia różne opcje konfigurowania dostępu do klastra, skalowalności węzłów i zasobników, dostępu do sieci i konfiguracji oraz nie tylko. Aby uzyskać więcej informacji na temat typowej architektury wdrażania, zobacz Przykładowa architektura. Architektura punktu odniesienia usługi AKS udostępnia również wytyczne dotyczące wdrażania i monitorowania klastra. Konstrukcja usługi AKS udostępnia szablony szybkiego startu do wdrażania klastra AKS na podstawie wymagań biznesowych i technicznych.

  2. Zmiana architektury aplikacji usługi Service Fabric. Jeśli używasz modeli programowania, takich jak Reliable Services lub Reliable Actors, lub jeśli używasz innych konstrukcji specyficznych dla usługi Service Fabric, może być konieczne zmiana architektury aplikacji. Aby zaimplementować zarządzanie stanem podczas migracji z usług Reliable Services, użyj rozproszonego środowiska uruchomieniowego aplikacji (Dapr). Platforma Kubernetes udostępnia wzorce i przykłady migracji z usługi Reliable Actors.

  3. Spakuj aplikację jako kontenery. Program Visual Studio udostępnia opcje generowania pliku Dockerfile i tworzenia pakietów aplikacji jako kontenerów. Wypchnij utworzone obrazy kontenerów do usługi Azure Container Registry.

  4. Zapisz ponownie pliki XML konfiguracji usługi Service Fabric jako pliki YAML kubernetes. Aplikację można wdrożyć w usłudze AKS przy użyciu plików YAML lub jako pakietu przy użyciu pakietów Helm. Aby uzyskać więcej informacji, zobacz Manifest aplikacji i usługi.

  5. Wdróż aplikację w klastrze usługi AKS.

  6. Przenieś ruch do klastra usługi AKS na podstawie strategii wdrażania i monitoruj zachowanie aplikacji, dostępność, wydajność.

Przykładowa architektura

Usługi AKS i Platforma Azure zapewniają elastyczność konfigurowania środowiska pod kątem potrzeb biznesowych. Usługa AKS jest dobrze zintegrowana z innymi usługami platformy Azure. Architektura punktu odniesienia usługi AKS jest przykładem.

Diagram przedstawiający architekturę usługi AKS punktu odniesienia.

Jako punkt wyjścia zapoznaj się z niektórymi kluczowymi pojęciami dotyczącymi platformy Kubernetes, a następnie zapoznaj się z przykładowymi architekturami:

Uwaga

Podczas migracji obciążenia z usługi Service Fabric do usługi AKS można zastąpić element Reliable Actors usługi Service Fabric blokiem konstrukcyjnym aktorów Języka Dapr. Można zastąpić kolekcje Reliable Collections usługi Service Fabric blokiem konstrukcyjnym zarządzania stanem dapr.

Język Dapr udostępnia interfejsy API, które upraszczają łączność mikrousług. Aby uzyskać więcej informacji, zobacz Wprowadzenie do języka Dapr. Zalecamy zainstalowanie języka Dapr jako rozszerzenia usługi AKS.

Manifest aplikacji i usługi

Usługi Service Fabric i AKS mają różne typy plików manifestu aplikacji i usługi. Usługa Service Fabric używa plików XML dla definicji aplikacji i usługi. Usługa AKS używa manifestu pliku YAML kubernetes do definiowania obiektów Kubernetes. Nie ma narzędzi przeznaczonych specjalnie do migrowania pliku XML usługi Service Fabric do pliku YAML kubernetes. Możesz jednak dowiedzieć się, jak działają pliki YAML na platformie Kubernetes, przeglądając następujące zasoby.

Za pomocą programu Helm można zdefiniować sparametryzowane manifesty YAML i utworzyć szablony ogólne, zastępując statyczne, zakodowane na stałe wartościami zastępczymi, które można zastąpić wartościami niestandardowymi dostarczanymi w czasie wdrażania. Wynikowe szablony zawierające wartości niestandardowe są renderowane jako prawidłowe manifesty dla platformy Kubernetes.

Usługa Kustomize wprowadza bezpłatny sposób dostosowywania konfiguracji aplikacji, która upraszcza korzystanie z gotowych aplikacji. Możesz użyć narzędzia Kustomize razem z programem Helm lub alternatywą dla programu Helm.

Aby uzyskać więcej informacji na temat programu Helm i usługi Kustomize, zobacz następujące zasoby:

Sieć

Usługa AKS oferuje dwie opcje dla sieci bazowej:

  • Przeprowadź własną sieć wirtualną platformy Azure, aby aprowizować węzły klastra usługi AKS do podsieci z udostępnionej sieci wirtualnej.

  • Pozwól dostawcy zasobów usługi AKS utworzyć nową sieć wirtualną platformy Azure w grupie zasobów węzła zawierającej wszystkie zasoby platformy Azure używane przez klaster.

Jeśli wybierzesz drugą opcję, platforma Azure zarządza siecią wirtualną.

Usługa Service Fabric nie zapewnia wyboru wtyczek sieciowych. Jeśli używasz usługi AKS, musisz wybrać jedną z następujących opcji:

  • kubenet. Jeśli używasz rozwiązania kubenet, węzły uzyskają adres IP z podsieci sieci wirtualnej platformy Azure. Zasobniki odbierają adres IP z przestrzeni adresowej, która logicznie różni się od podsieci sieci wirtualnej platformy Azure węzłów. Dzięki skonfigurowaniu translatora adresów sieciowych (NAT) zasobniki mogą uzyskać dostęp do zasobów w sieci wirtualnej platformy Azure. Źródłowy adres IP ruchu jest tłumaczony za pośrednictwem translatora adresów sieciowych na podstawowy adres IP węzła. Takie podejście znacznie zmniejsza liczbę adresów IP, które należy zarezerwować w przestrzeni sieciowej, aby zasobniki były używane.

  • Azure CNI. Jeśli używasz interfejsu sieci kontenera (CNI), każdy zasobnik pobiera adres IP z podsieci i można uzyskać do nich bezpośredni dostęp. Te adresy IP muszą być unikatowe w przestrzeni sieciowej i muszą być planowane z wyprzedzeniem. Każdy węzeł ma parametr konfiguracji dla maksymalnej liczby zasobników, które obsługuje. Następnie należy zarezerwować równoważną liczbę adresów IP dla każdego węzła. Takie podejście wymaga większego planowania i często prowadzi do wyczerpania adresów IP lub konieczności ponownego kompilowania klastrów w większej podsieci w miarę wzrostu zapotrzebowania aplikacji. Można skonfigurować maksymalną liczbę zasobników, które można wdrożyć w węźle podczas tworzenia klastra lub tworzenia nowych pul węzłów.

  • Sieć nakładki usługi Azure CNI. Jeśli używasz nakładki usługi Azure CNI, węzły klastra są wdrażane w podsieci usługi Azure Virtual Network. Zasobniki są przypisywane adresy IP z prywatnej trasy CIDR, która logicznie różni się od adresu sieci wirtualnej, która hostuje węzły. Ruch zasobników i węzłów w klastrze używa sieci nakładki. Translator adresów sieciowych używa adresu IP węzła do uzyskania dostępu do zasobów spoza klastra. To rozwiązanie pozwala zaoszczędzić znaczną liczbę adresów IP sieci wirtualnej i ułatwia bezproblemowe skalowanie klastra do dużych rozmiarów. Dodatkową zaletą jest możliwość ponownego użycia prywatnej trasy CIDR w różnych klastrach usługi AKS, co rozszerza przestrzeń adresów IP dostępną dla konteneryzowanych aplikacji w usłudze AKS.

  • Usługa Azure CNI obsługiwana przez cilium. Usługa Azure CNI obsługiwana przez cilium łączy niezawodną płaszczyznę sterowania usługi Azure CNI z płaszczyzną danych Cilium w celu zapewnienia wysokiej wydajności sieci i zwiększonych zabezpieczeń.

  • Przynieś własną wtyczkę CNI. Platforma Kubernetes domyślnie nie udostępnia systemu interfejsu sieciowego. Ta funkcja jest udostępniana przez wtyczki sieciowe. Usługa AKS udostępnia kilka obsługiwanych wtyczek CNI. Aby uzyskać więcej informacji na temat obsługiwanych wtyczek, zobacz Pojęcia dotyczące sieci dla aplikacji w usłudze AKS.

Kontenery systemu Windows obsługują obecnie tylko wtyczkę azure CNI . Dostępne są różne opcje zasad sieciowych i kontrolerów ruchu przychodzącego.

W usłudze AKS można użyć zasad sieci platformy Kubernetes do segregowania i zabezpieczania komunikacji wewnątrz usług, kontrolując, które składniki mogą komunikować się ze sobą. Domyślnie wszystkie zasobniki w klastrze Kubernetes mogą wysyłać i odbierać ruch bez ograniczeń. Aby zwiększyć bezpieczeństwo, możesz użyć zasad sieciowych platformy Azure lub zasad sieci Calico, aby zdefiniować reguły kontrolujące przepływ ruchu między mikrousługami.

Jeśli chcesz użyć usługi Azure Network Policy Manager, musisz użyć wtyczki Azure CNI. Możesz użyć zasad sieci Calico z wtyczką azure CNI lub wtyczką kubenet CNI. Korzystanie z menedżera usługi Azure Network Policy Manager dla węzłów systemu Windows jest obsługiwane tylko w systemie Windows Server 2022. Aby uzyskać więcej informacji, zobacz Zabezpieczanie ruchu między zasobnikami przy użyciu zasad sieciowych w usłudze AKS. Aby uzyskać więcej informacji na temat sieci usługi AKS, zobacz Networking in AKS (Sieć w usłudze AKS).

Na platformie Kubernetes kontroler ruchu przychodzącego działa jako serwer proxy usługi i pośrednik między usługą a światem zewnętrznym, co umożliwia dostęp do usługi przez ruch zewnętrzny. Serwer proxy usługi zwykle udostępnia różne funkcje, takie jak kończenie żądań TLS, routing żądań oparty na ścieżkach, równoważenie obciążenia i funkcje zabezpieczeń, takie jak uwierzytelnianie i autoryzacja. Kontrolery ruchu przychodzącego zapewniają również kolejną warstwę abstrakcji i kontroli routingu ruchu zewnętrznego do usług Kubernetes na podstawie reguł HTTP i HTTPS. Ta warstwa zapewnia bardziej szczegółową kontrolę nad przepływem ruchu i zarządzaniem ruchem.

W usłudze AKS istnieje wiele opcji wdrażania, uruchamiania i obsługi kontrolera ruchu przychodzącego. Jedną z opcji jest kontroler ruchu przychodzącego usługi Application Gateway, który umożliwia używanie bramy aplikacja systemu Azure jako kontrolera ruchu przychodzącego na potrzeby kończenia żądań protokołu TLS, routingu opartego na ścieżkach i zapory dostępu do internetu. Inną opcją jest zarządzany kontroler ruchu przychodzącego NGINX, który zapewnia opcję zarządzaną przez platformę Azure dla powszechnie używanego kontrolera ruchu przychodzącego NGINX. Kontroler ruchu przychodzącego Traefik jest innym popularnym kontrolerem ruchu przychodzącego dla platformy Kubernetes.

Każdy z tych kontrolerów ruchu przychodzącego ma mocne i słabe strony. Aby zdecydować, którego z nich użyć, należy wziąć pod uwagę wymagania aplikacji i środowiska. Upewnij się, że używasz najnowszej wersji programu Helm i masz dostęp do odpowiedniego repozytorium helm podczas instalowania niezarządzanego kontrolera ruchu przychodzącego.

Magazyn trwały

Zarówno usługa Service Fabric, jak i usługa AKS mają mechanizmy zapewniające trwały magazyn do konteneryzowanych aplikacji. W usłudze Service Fabric sterownik woluminu usługi Azure Files, który jest wtyczką woluminu platformy Docker, udostępnia woluminy usługi Azure Files dla kontenerów systemów Linux i Windows. Jest ona spakowana jako aplikacja usługi Service Fabric, którą można wdrożyć w klastrze usługi Service Fabric w celu zapewnienia woluminów dla innych konteneryzowanych aplikacji usługi Service Fabric w klastrze. Aby uzyskać więcej informacji, zobacz Sterownik woluminu usługi Azure Files dla usługi Service Fabric.

Aplikacje działające w usłudze AKS mogą wymagać przechowywania i pobierania danych z trwałego systemu magazynu plików. Usługa AKS integruje się z usługami magazynu platformy Azure, takimi jak dyski zarządzane platformy Azure, Azure Files, Blob Storage i Azure NetApp Storage (ANF). Integruje się również z systemami magazynowania innych firm, takimi jak Rook i GlusterFS za pośrednictwem sterowników interfejsu MAGAZYNU kontenerów (CSI).

CSI to standard, który umożliwia uwidacznianie systemów magazynowania bloków i plików w konteneryzowanych obciążeniach na platformie Kubernetes. Dostawcy magazynu innego niż Microsoft korzystający z interfejsu CSI mogą zapisywać, wdrażać i aktualizować wtyczki, aby uwidocznić nowe systemy magazynowania na platformie Kubernetes lub ulepszać istniejące, bez konieczności zmiany podstawowego kodu Kubernetes i oczekiwania na jego cykle wydania.

Obsługa sterowników magazynu CSI w usłudze AKS umożliwia natywne korzystanie z tych usług magazynu platformy Azure:

  • Dyski platformy Azure. Za pomocą usługi Azure Disks można utworzyć zasób Kubernetes DataDisk. Dyski mogą korzystać z usługi Azure Premium Storage, która jest wspierana przez dyski SSD o wysokiej wydajności lub magazyn w warstwie Standardowa platformy Azure, który jest wspierany przez dyski HDD lub dyski SSD w warstwie Standardowa. W przypadku większości obciążeń produkcyjnych i programistycznych należy używać magazynu w warstwie Premium. Dyski platformy Azure są instalowane jako ReadWriteOnce i są dostępne tylko dla jednego węzła w usłudze AKS. W przypadku woluminów magazynu, do których jednocześnie może uzyskiwać dostęp wiele zasobników, użyj usługi Azure Files.

    Natomiast usługa Service Fabric obsługuje tworzenie klastra lub typu węzła korzystającego z dysków zarządzanych, ale nie aplikacji, które dynamicznie tworzą dołączone dyski zarządzane za pomocą podejścia deklaratywnego. Aby uzyskać więcej informacji, zobacz Deploy a Service Fabric cluster node type with managed data disks (Wdrażanie typu węzła klastra usługi Service Fabric przy użyciu dysków danych zarządzanych).

  • Azure Files. Za pomocą usługi Azure Files można zainstalować udział SMB 3.0 lub 3.1 wspierany przez konto usługi Azure Storage do zasobników. Usługa Azure Files umożliwia udostępnianie danych między wieloma węzłami i zasobnikami. Usługa Azure Files może używać magazynu w warstwie Standardowa platformy Azure obsługiwanego przez dyski HDD w warstwie Standardowa lub Azure Premium Storage wspierane przez dyski SSD o wysokiej wydajności.

    Usługa Service Fabric udostępnia sterownik woluminu usługi Azure Files jako wtyczkę woluminu platformy Docker, która udostępnia woluminy usługi Azure Files dla kontenerów platformy Docker. Usługa Service Fabric udostępnia jedną wersję sterownika dla klastrów systemu Windows i jeden dla klastrów systemu Linux.

  • Blob Storage. Za pomocą usługi Blob Storage można zainstalować magazyn obiektów blob (lub magazyn obiektów) jako system plików w kontenerze lub zasobniku. Usługa Blob Storage umożliwia klastrowi usługi AKS obsługę aplikacji, które współpracują z dużymi zestawami danych bez struktury, takimi jak dane plików dziennika, obrazy lub dokumenty oraz obciążenia HPC. W przypadku pozyskiwania danych do usługi Azure Data Lake Storage można bezpośrednio zainstalować magazyn i używać go w usłudze AKS bez konfigurowania innego tymczasowego systemu plików. Usługa Service Fabric nie obsługuje żadnego mechanizmu instalowania magazynu obiektów blob w trybie deklaratywnym.

Aby uzyskać więcej informacji na temat opcji magazynu, zobacz Magazyn w usłudze AKS.

Monitorowanie aplikacji i klastra

Zarówno usługa Service Fabric, jak i usługa AKS zapewniają natywną integrację z usługą Azure Monitor i jej usługami, takimi jak Log Analytics. Monitorowanie i diagnostyka mają kluczowe znaczenie dla opracowywania, testowania i wdrażania obciążeń w dowolnym środowisku chmury. Monitorowanie obejmuje monitorowanie infrastruktury i aplikacji.

Możesz na przykład śledzić sposób używania aplikacji, akcje podejmowane przez platformę usługi Service Fabric, wykorzystanie zasobów za pośrednictwem liczników wydajności oraz ogólną kondycję klastra. Te informacje umożliwiają diagnozowanie i rozwiązywanie problemów oraz zapobieganie ich występowaniu w przyszłości. Aby uzyskać więcej informacji, zobacz Monitorowanie i diagnostyka usługi Service Fabric. Podczas hostowania i obsługi konteneryzowanych aplikacji w klastrze usługi Service Fabric należy skonfigurować rozwiązanie do monitorowania kontenerów w celu wyświetlania zdarzeń i dzienników kontenerów.

Jednak usługa AKS ma wbudowaną integrację z usługami Azure Monitor i Container Insights, która została zaprojektowana do monitorowania wydajności konteneryzowanych obciążeń wdrożonych w chmurze. Usługa Container Insights zapewnia widoczność wydajności, zbierając metryki pamięci i procesora z kontrolerów, węzłów i kontenerów, które są dostępne na platformie Kubernetes za pośrednictwem interfejsu API metryk.

Po włączeniu monitorowania z klastrów Kubernetes metryki i dzienniki kontenerów są automatycznie zbierane za pośrednictwem konteneryzowanej wersji agenta usługi Log Analytics dla systemu Linux. Metryki są wysyłane do bazy danych metryk w usłudze Azure Monitor. Dane dziennika są wysyłane do obszaru roboczego usługi Log Analytics. Dzięki temu można pobierać dane monitorowania i telemetrii zarówno dla klastra usługi AKS, jak i konteneryzowanych aplikacji, które są na nim uruchamiane. Aby uzyskać więcej informacji, zobacz Monitorowanie usługi AKS za pomocą usługi Azure Monitor.

Alternatywnie lub rozwiązanie towarzyszące dla usługi Container Insights można skonfigurować klaster usługi AKS w celu zbierania metryk w usłudze zarządzanej Azure Monitor dla rozwiązania Prometheus. Za pomocą tej konfiguracji można zbierać i analizować metryki na dużą skalę przy użyciu rozwiązania do monitorowania zgodnego z rozwiązaniem Prometheus, które jest oparte na projekcie Prometheus . W pełni zarządzana usługa umożliwia analizowanie wydajności monitorowanej infrastruktury i obciążeń przy użyciu języka zapytań Prometheus (PromQL ). Umożliwia również odbieranie alertów bez konieczności obsługi podstawowej infrastruktury.

Usługa zarządzana usługi Azure Monitor dla rozwiązania Prometheus jest składnikiem metryk usługi Azure Monitor. Zapewnia ona większą elastyczność w typach danych metryk, które można zbierać i analizować przy użyciu usługi Azure Monitor. Metryki prometheus udostępniają niektóre funkcje z metrykami platformy i niestandardowymi, ale mają dodatkowe funkcje, aby lepiej obsługiwać narzędzia open source, takie jak PromQLi Grafana.

Usługę zarządzaną usługi Azure Monitor dla rozwiązania Prometheus można skonfigurować jako źródło danych zarówno dla platformy Azure Managed Grafana, jak i własnego narzędzia Grafana, które można uruchomić na maszynie wirtualnej platformy Azure. Aby uzyskać więcej informacji, zobacz Use Azure Monitor managed service for Prometheus as data source for Grafana using managed system identity (Używanie usługi zarządzanej usługi Azure Monitor dla rozwiązania Prometheus jako źródła danych dla narzędzia Grafana przy użyciu tożsamości systemu zarządzanego).

Dodatki dla usługi AKS

Podczas migracji z usługi Service Fabric do usługi AKS należy rozważyć użycie dodatków i rozszerzeń. Usługa AKS zapewnia dodatkowe obsługiwane funkcje klastrów za pośrednictwem dodatków i rozszerzeń, takich jak Skalowanie automatyczne oparte na zdarzeniach (KEDA) kubernetes i GitOps Flux v2. Wiele innych integracji udostępnianych przez projekty open source i inne firmy są często używane z usługą AKS. Zasady pomocy technicznej usługi AKS nie obejmują integracji typu open source i innych firm. Aby uzyskać więcej informacji, zobacz Dodatki, rozszerzenia i inne integracje z usługą AKS.

Współautorzy

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

Autorzy zabezpieczeń:

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

Następne kroki