Hybrydowe wdrażanie klastrów Kubernetes i zarządzanie nimi w usłudze Azure Arc

Ta architektura referencyjna pokazuje, jak usługa Azure Arc rozszerza zarządzanie klastrem Kubernetes i konfigurację między centrami danych klientów, lokalizacjami brzegowymi i wieloma środowiskami chmury.

Architektura

Pobierz plik programu Visio z tą architekturą.

Przepływ pracy

Architektura składa się z następujących aspektów:

• Platforma Kubernetes z obsługą usługi Azure Arc. Dołączanie i konfigurowanie klastrów Kubernetes wewnątrz platformy Azure lub spoza niej przy użyciu platformy Kubernetes z obsługą usługi Azure Arc. Gdy klaster Kubernetes jest dołączony do usługi Azure Arc, jest przypisany identyfikator usługi Azure Resource Manager i tożsamość zarządzana.
• Azure Kubernetes Service. Hostowanie klastrów Kubernetes na platformie Azure w celu zmniejszenia złożoności i nakładu pracy związanego z zarządzaniem klastrem Kubernetes.
• Lokalny klaster Kubernetes. Dołączanie klastrów Kubernetes z certyfikatem CLOUD Native Computing Foundation (CNCF), które są hostowane w środowiskach lokalnych lub w chmurze innych firm.
• Azure Policy. Wdrażanie zasad dla klastrów Kubernetes z obsługą usługi Arc i zarządzanie nimi.
• Azure Monitor. Obserwuj i monitoruj klastry Kubernetes z obsługą usługi Arc.

Składniki

• Azure Arc to most, który rozszerza platformę Azure, umożliwiając tworzenie aplikacji i usług, które mogą być uruchamiane w centrach danych, na brzegu i w środowiskach wielochmurowych.
• Azure Kubernetes Service (AKS) to zarządzana usługa do wdrażania i skalowania klastrów Kubernetes.
• Usługa Azure Policy umożliwia osiągnięcie zgodności chmury w czasie rzeczywistym na dużą skalę z spójnym ładem zasobów.
• Usługa Azure Monitor zapewnia kompleksową obserwację aplikacji, infrastruktury i sieci.

Szczegóły scenariusza

Za pomocą usługi Azure Arc można zarejestrować klastry Kubernetes hostowane poza platformą Microsoft Azure. Następnie możesz użyć narzędzi platformy Azure do zarządzania tymi klastrami wraz z klastrami hostowanymi w usłudze Azure Kubernetes Service (AKS).

Potencjalne przypadki użycia

Przykładowe typowe zastosowania tej architektury:

• Zarządzanie lokalnymi klastrami i klastrami Kubernetes hostowanymi w usłudze AKS na potrzeby spisu, grupowania i tagowania.
• Monitorowanie klastrów Kubernetes w środowiskach hybrydowych za pomocą usługi Azure Monitor.
• Używanie usługi Azure Policy do wdrażania i wymuszania zasad dla klastrów Kubernetes w środowiskach hybrydowych.
• Wdrażanie i wymuszanie metodyki GitOps przy użyciu usługi Azure Policy.

Zalecenia

W poniższych sekcjach przedstawiono zalecenia dotyczące większości scenariuszy. Firma Microsoft zaleca, aby postępować zgodnie z nimi, chyba że masz wymóg, który je zastępuje.

Rejestracja klastra

Możesz zarejestrować dowolny aktywny klaster PLATFORMy Kubernetes CNCF. Aby uzyskać dostęp do klastra i roli administratora klastra w klastrze, potrzebny jest plik kubeconfig , aby wdrożyć agentów Kubernetes z obsługą usługi Arc. Interfejs wiersza polecenia platformy Azure (interfejs wiersza polecenia platformy Azure) służy do wykonywania zadań rejestracji klastra. Użytkownik lub jednostka usługi używana dla poleceń az login i az connectedk8s connect wymaga uprawnień do odczytu i zapisu w typie zasobu Microsoft.Kubernetes/connectedClusters. Rola klastra Kubernetes — dołączanie usługi Azure Arc ma te uprawnienia i może służyć do przypisań ról w jednostce użytkownika lub jednostce usługi. Program Helm 3 jest wymagany do dołączania klastra korzystającego z rozszerzenia connectedk8s. Interfejs wiersza polecenia platformy Azure w wersji 2.3 lub nowszej jest wymagany do zainstalowania rozszerzeń interfejsu wiersza polecenia platformy Kubernetes z obsługą usługi Azure Arc.

Agenci usługi Azure Arc dla platformy Kubernetes

Platforma Kubernetes z obsługą usługi Azure Arc składa się z kilku agentów (nazywanych również operatorami), które są uruchamiane w klastrze wdrożonym w przestrzeni nazw azure-arc :

• deployment.apps/config-agent. Obserwuje połączony klaster pod kątem zasobów konfiguracji kontroli źródła, które są stosowane w klastrze, i aktualizuje stan zgodności.
• deployment.apps/controller-manager. Operator operatorów, który organizuje interakcje między składnikami usługi Azure Arc.
• deployment.apps/metrics-agent. Zbiera metryki od innych agentów usługi Arc, aby upewnić się, że ci agenci wykazują optymalną wydajność.
• deployment.apps/cluster-metadata-operator. Zbiera metadane klastra, wersję klastra, liczbę węzłów i wersję agenta usługi Azure Arc.
• deployment.apps/resource-sync-agent. Synchronizuje wcześniej wymienione metadane klastra z platformą Azure.
• deployment.apps/clusteridentityoperator. Utrzymuje certyfikat tożsamości usługi zarządzanej (MSI), który jest używany przez innych agentów do komunikowania się z platformą Azure.
• deployment.apps/flux-logs-agent. Zbiera dzienniki z operatorów strumienia, które są wdrażane w ramach konfiguracji kontroli źródła.
• deployment.apps/extension-manager. Instaluje i zarządza cyklem życia rozszerzeń chart programu Helm.
• deployment.apps/kube-azure-ad-proxy. Służy do uwierzytelniania żądań wysyłanych do klastra przy użyciu Połączenie klastra.
• deployment.apps/clusterconnect-agent. Agent zwrotnego serwera proxy, który umożliwia funkcji łączenia klastra w celu zapewnienia dostępu do serwera apiserver klastra. Jest to opcjonalny składnik, który jest wdrażany tylko wtedy, gdy funkcja łączenia klastra jest włączona w klastrze.
• deployment.apps/guard. Serwer elementów webhook uwierzytelniania i autoryzacji używany do kontroli dostępu opartej na rolach (RBAC) firmy Microsoft. Jest to opcjonalny składnik, który jest wdrażany tylko wtedy, gdy funkcja azure-rbac jest włączona w klastrze.

Aby uzyskać więcej informacji, zobacz Połączenie klastra Kubernetes z obsługą usługi Azure Arc.

Monitorowanie klastrów przy użyciu usługi Azure Monitor Container Insights

Monitorowanie kontenerów ma kluczowe znaczenie. Usługa Azure Monitor Container Insights zapewnia zaawansowane środowisko monitorowania dla klastrów aparatów AKS i AKS. Możesz również skonfigurować usługę Azure Monitor Container Insights, aby monitorować klastry Kubernetes z obsługą usługi Azure Arc, które są hostowane poza platformą Azure. Zapewnia to kompleksowe monitorowanie klastrów Kubernetes na platformie Azure, lokalnie i w środowiskach chmury innych firm.

Usługa Azure Monitor Container Insights może zapewnić widoczność wydajności, zbierając metryki pamięci i procesora z kontrolerów, węzłów i kontenerów, metryki dostępne na platformie Kubernetes za pośrednictwem interfejsu programowania aplikacji metryki (API). Gromadzone są też dzienniki kontenerów. Po włączeniu monitorowania z klastrów Kubernetes metryki i dzienniki są automatycznie zbierane przez konteneryzowaną wersję agenta usługi Log Analytics. Metryki są zapisywane w magazynie metryk, a dane dziennika są zapisywane w magazynie dzienników skojarzonym z obszarem roboczym usługi Log Analytics. Aby uzyskać więcej informacji na temat usługi Azure Monitor Container Insights, zobacz Omówienie usługi Azure Monitor Container Insights.

Szczegółowe informacje o kontenerze usługi Azure Monitor można włączyć dla co najmniej jednego wdrożenia platformy Kubernetes przy użyciu skryptu programu PowerShell lub skryptu powłoki Bash.

Aby włączyć monitorowanie klastrów Kubernetes z obsługą usługi Arc, zobacz Włączanie monitorowania klastra Kubernetes z obsługą usługi Azure Arc

Używanie usługi Azure Policy do włączania wdrażania aplikacji opartych na metodyce GitOps

Użyj usługi Azure Policy, aby wymusić, że każdy zasób Microsoft.Kubernetes/connectedclusters lub zasób Microsoft.ContainerService/managedClusters ma określony zasób Microsoft.KubernetesConfiguration/fluxConfigurations. Można na przykład zastosować konfigurację punktu odniesienia do jednego lub kilku klastrów lub wdrożyć określone aplikacje w wielu klastrach. Aby użyć usługi Azure Policy, wybierz definicję z wbudowanych definicji usługi Azure Policy dla platformy Kubernetes z obsługą usługi Azure Arc, a następnie utwórz przypisanie zasad.

Podczas tworzenia przypisania zasad ustaw zakres na grupę zasobów platformy Azure lub subskrypcję. Ustaw również parametry dla utworzonej funkcji fluxConfiguration . Po utworzeniu przypisania aparat zasad zidentyfikuje wszystkie połączone zasobycluster lub managedCluster znajdujące się w zakresie, a następnie zastosuje fluxConfiguration do każdego z nich.

Jeśli używasz wielu repozytoriów źródłowych dla każdego klastra (na przykład jednego repozytorium dla centralnego operatora IT/klastra i innych repozytoriów dla zespołów aplikacji), aktywuj je przy użyciu wielu przypisań zasad i skonfiguruj każde przypisanie zasad, aby używać innego repozytorium źródłowego.

Aby uzyskać więcej informacji, zobacz Wdrażanie aplikacji stale na dużą skalę przy użyciu konfiguracji platformy Flux w wersji 2 i usługi Azure Policy.

Wdrażanie aplikacji przy użyciu metodyki GitOps

GitOps to praktyka deklarowania żądanego stanu konfiguracji kubernetes (wdrożeń, przestrzeni nazw itd.) w repozytorium źródłowym, takim jak repozytorium Git lub Helm, zasobniki lub usługa Azure Blob Storage. Następnie następuje sondowanie i ściąganie wdrożenia tych konfiguracji w klastrze przy użyciu operatora.

Połączenie między klastrem a co najmniej jednym repozytorium źródłowym jest włączone przez wdrożenie rozszerzenia microsoft.flux w klastrze. Właściwości zasobu fluxConfiguration reprezentują miejsce i sposób przepływu zasobów Kubernetes z repozytorium źródłowego do klastra. Dane fluxConfiguration są przechowywane w spoczynku w bazie danych usługi Azure Cosmos DB w celu zapewnienia poufności danych.

Agent flux-config, który działa w klastrze, jest odpowiedzialny za oglądanie nowych lub zaktualizowanych zasobów rozszerzenia fluxConfiguration w zasobie Kubernetes z obsługą usługi Azure Arc, do wdrażania aplikacji z repozytorium źródłowego i propagowania wszelkich aktualizacji, które są wprowadzane do fluxConfiguration. Można nawet utworzyć wiele zasobów fluxConfiguration przy użyciu zakresu przestrzeni nazw w tym samym klastrze Kubernetes z obsługą usługi Azure Arc, aby uzyskać wiele dzierżaw.

Repozytorium źródłowe może zawierać dowolne prawidłowe zasoby kubernetes, w tym przestrzenie nazw, konfigurację Mapy, wdrożenia i zestawy DaemonSet. Może również zawierać wykresy helm do wdrażania aplikacji. Typowe scenariusze repozytorium źródłowego obejmują definiowanie konfiguracji bazowej dla organizacji, która może obejmować typowe role i powiązania kontroli dostępu opartej na rolach (RBAC), agentów monitorowania, agentów rejestrowania i usług w całym klastrze.

Można również zarządzać większą kolekcją klastrów wdrożonych w środowiskach heterogenicznych. Możesz na przykład mieć jedno repozytorium, które definiuje konfigurację punktu odniesienia dla organizacji, a następnie zastosować je do wielu klastrów Kubernetes jednocześnie. Aplikacje można również wdrażać w klastrze z wielu repozytoriów źródłowych.

Aby uzyskać więcej informacji, zobacz Deploy applications using GitOps with Flux v2 (Wdrażanie aplikacji przy użyciu metodyki GitOps z platformą Flux w wersji 2).

Topologia, sieć i routing

Agenci usługi Azure Arc wymagają następujących protokołów/portów/adresów URL ruchu wychodzącego w celu działania:

Aby uzyskać pełną listę adresów URL w usługach Azure Arc, zobacz Wymagania dotyczące sieci usługi Azure Arc.

Kwestie wymagające rozważenia

Te zagadnienia implementują filary struktury Azure Well-Architected Framework, która jest zestawem wytycznych, które mogą służyć do poprawy jakości obciążenia. Aby uzyskać więcej informacji, zobacz Microsoft Azure Well-Architected Framework.

Niezawodność

Niezawodność zapewnia, że aplikacja może spełnić zobowiązania podjęte przez klientów. Aby uzyskać więcej informacji, zobacz Omówienie filaru niezawodności.

• W większości przypadków lokalizacja wybrana podczas tworzenia skryptu instalacji powinna być regionem świadczenia usługi Azure znajdującym się geograficznie najbliżej zasobów lokalnych. Pozostałe dane są przechowywane w lokalizacji geograficznej platformy Azure zawierającej określony region, co może mieć wpływ na wybór regionu, jeśli masz wymagania dotyczące rezydencji danych. Jeśli awaria wpłynie na region świadczenia usługi Azure, z którym jest połączona maszyna, awaria nie ma wpływu na połączoną maszynę, ale operacje zarządzania korzystające z platformy Azure mogą nie zostać ukończone. Aby zapewnić odporność w przypadku awarii regionalnej, najlepiej, jeśli masz wiele lokalizacji zapewniających geograficznie nadmiarową usługę, aby połączyć maszyny w każdej lokalizacji z innym regionem świadczenia usługi platformy Azure. Aby zapoznać się z dostępnymi regionami, zapoznaj się z tematem Obsługiwane regiony dla platformy Kubernetes z obsługą usługi Azure Arc.
• Upewnij się, że usługi, do których odwołuje się odwołanie w sekcji Architektura, są obsługiwane w regionie, w którym wdrożono usługę Azure Arc.

Zabezpieczenia

Zabezpieczenia zapewniają ochronę przed celowymi atakami i nadużyciami cennych danych i systemów. Aby uzyskać więcej informacji, zobacz Omówienie filaru zabezpieczeń.

• Kontrola dostępu oparta na rolach platformy Azure umożliwia zarządzanie dostępem do platformy Kubernetes z obsługą usługi Azure Arc na platformie Azure i w środowiskach lokalnych korzystających z tożsamości firmy Microsoft. Aby uzyskać więcej informacji, zobacz Use Azure RBAC for Kubernetes Authorization (Używanie kontroli dostępu opartej na rolach platformy Azure na potrzeby autoryzacji na platformie Kubernetes).
• Firma Microsoft zaleca użycie jednostki usługi, która ma ograniczone uprawnienia do dołączania klastrów Kubernetes do usługi Azure Arc. Ta praktyka jest przydatna w potokach ciągłej integracji/ciągłego wdrażania, takich jak Azure Pipelines i GitHub Actions. Aby uzyskać więcej informacji, zobacz Tworzenie jednostki usługi z obsługą usługi Azure Arc.
• Aby uprościć zarządzanie jednostką usługi, można użyć tożsamości zarządzanych w usłudze AKS. Jednak klastry muszą być tworzone przy użyciu tożsamości zarządzanej, a istniejące klastry (w tym klastry platformy Azure i klastry lokalne) nie mogą być migrowane do tożsamości zarządzanych. Aby uzyskać więcej informacji, zobacz Używanie tożsamości zarządzanych w usłudze Azure Kubernetes Service.

Optymalizacja kosztów

Optymalizacja kosztów dotyczy sposobów zmniejszenia niepotrzebnych wydatków i poprawy wydajności operacyjnej. Aby uzyskać więcej informacji, zobacz Omówienie filaru optymalizacji kosztów.

Ogólne zagadnienia dotyczące kosztów opisano w sekcji Zasady optymalizacji kosztów w witrynie Microsoft Azure Well-Architected Framework.

Doskonałość operacyjna

Doskonałość operacyjna obejmuje procesy operacyjne, które wdrażają aplikację i działają w środowisku produkcyjnym. Aby uzyskać więcej informacji, zobacz Omówienie filaru doskonałości operacyjnej.

• Przed skonfigurowaniem klastrów Kubernetes z włączoną usługą Azure Arc zapoznaj się z limitami subskrypcji usługi Azure Resource Manager i limitami grup zasobów, aby zaplanować liczbę klastrów.
• Użyj programu Helm, narzędzia do tworzenia pakietów typu open source, aby zainstalować cykle życia aplikacji Kubernetes i zarządzać nimi. Podobnie jak w przypadku menedżerów pakietów systemu Linux, takich jak APT i Yum, program Helm służy do zarządzania wykresami Kubernetes, które są pakietami wstępnie skonfigurowanych zasobów Kubernetes.

Współautorzy

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

Główny autor:

• Pieter de Bruin | Starszy menedżer programu

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

Następne kroki

• Dokumentacja usługi Azure Arc
• Dokumentacja platformy Kubernetes z obsługą usługi Azure Arc
• Dokumentacja usługi Azure Kubernetes Service
• Dokumentacja usługi Azure Policy
• Dokumentacja usługi Azure Monitor
• Połączenie klastra Kubernetes z obsługą usługi Azure Arc

Powiązane zasoby

Powiązane wskazówki dotyczące hybrydowego:

• Projektowanie architektury hybrydowej
• Opcje hybrydowe platformy Azure
• Zagadnienia dotyczące projektowania aplikacji hybrydowych
• Wdrażanie aplikacji hybrydowej z danymi lokalnymi, które skaluje wiele chmur

Powiązane architektury:

• Architektura linii bazowej dla usługi AKS w usłudze Azure Stack HCI
• Architektura sieci dla usługi AKS w usłudze Azure Stack HCI
• Optymalizowanie administrowania wystąpieniami programu SQL Server w środowiskach lokalnych i wielochmurowych przy użyciu usługi Azure Arc
• Monitorowanie przedsiębiorstwa za pomocą usługi Azure Monitor