Azure Arc-Hybridverwaltung und -bereitstellung für Kubernetes-Cluster

Diese Referenzarchitektur veranschaulicht, wie Azure Arc Kubernetes-Clusterverwaltung und -Clusterkonfiguration über Kundenrechenzentren, Edge-Standorte und mehrere Cloudumgebungen hinweg erweitert.

Aufbau

Laden Sie eine Visio-Datei dieser Architektur herunter.

Workflow

Die Architektur umfasst die folgenden Komponenten:

• Kubernetes mit Azure Arc-Unterstützung. Hinzufügen und Konfigurieren von Kubernetes-Clustern innerhalb oder außerhalb von Azure mit einer Azure Arc-aktivierten Kubernetes-Version. Wenn Azure Arc ein Kubernetes-Cluster angefügt wird, wird ihm eine Azure Resource Manager-ID sowie eine verwaltete Identität zugewiesen.
• Azure Kubernetes Service Hosten von Kubernetes-Clustern in Azure, wodurch die Komplexität und der betriebliche Aufwand der Kubernetes-Clusterverwaltung reduziert werden
• Lokaler Kubernetes-Cluster : Anfügen CNCF-zertifizierter (Cloud Native Computing Foundation) Kubernetes-Cluster, die in lokalen oder Drittanbieter-Cloudumgebungen gehostet werden
• Azure Policy . Bereitstellen und Verwalten von Richtlinien für Arc-aktivierte Kubernetes-Cluster.
• Azure Monitor. Beobachten und Überwachen von Arc-aktivierten Kubernetes-Clustern.

Komponenten

• Azure Arc ist eine Brücke, die die Azure-Plattform erweitert und dadurch das Erstellen von Anwendungen und Diensten ermöglicht, die in Rechenzentren, am Edge und in Multicloudumgebungen ausgeführt werden können.
• Azure Kubernetes Service (AKS) ist ein verwalteter Dienst zum Bereitstellen und Skalieren von Kubernetes-Clustern.
• Azure Policy ermöglicht es, Cloudcompliance in Echtzeit im großen Stil mit konsistenter Ressourcengovernance zu erreichen.
• Azure Monitor bietet End-to-End-Einblicke für Ihre Anwendungen, Ihre Infrastruktur und Ihr Netzwerk.

Szenariodetails

Sie können Azure Arc verwenden, um Kubernetes-Cluster zu registrieren, die außerhalb von Microsoft Azure gehostet werden. Anschließend können Sie Azure-Tools verwenden, um diese Cluster zusammen mit Clustern zu verwalten, die in Azure Kubernetes Service (AKS) gehostet werden.

Mögliche Anwendungsfälle

Typische Einsatzmöglichkeiten für diese Architektur sind:

• Verwalten von lokalen Kubernetes-Clustern und in AKS gehosteten Clustern für Inventur, Gruppierung und Tagging
• Verwenden von Azure Monitor zum Überwachen von Kubernetes-Clustern in Hybridumgebungen
• Verwenden von Azure Policy zum Bereitstellen und Erzwingen von Richtlinien für Kubernetes-Cluster in Hybridumgebungen
• Verwenden von Azure Policy zum Bereitstellen und Erzwingen von GitOps

Empfehlungen

Die folgenden Abschnitte enthalten Empfehlungen, die für die meisten Szenarien gelten. Microsoft empfiehlt, sich an diese zu halten, es sei denn, Sie haben Anforderungen, die Vorrang haben.

Clusterregistrierung

Sie können jeden aktiven CNCF-Kubernetes-Cluster registrieren. Sie benötigen eine kubeconfig-Datei, um auf den Cluster und die Rolle des Clusteradministrators auf dem Cluster zuzugreifen, um Kubernetes-Agents mit Arc-Unterstützung bereitstellen zu können. Sie verwenden die Azure CLI (Command-Line Interface, Befehlszeilenschnittstelle), um Aufgaben zur Clusterregistrierung auszuführen. Der für die Befehle az login und az connectedk8s connect verwendete Benutzer- oder Dienstprinzipal muss über die Lese- und Schreibberechtigung für den Ressourcentyp „Microsoft.Kubernetes/connectedClusters“ verfügen. Die Rolle „Kubernetes-Cluster – Azure Arc-Onboarding“ verfügt über diese Berechtigungen und kann für Rollenzuweisungen für den Benutzer- oder Dientsprinzipal verwendet werden. Helm 3 ist für das Onboarding des Clusters erforderlich, der die connectedk8s-Erweiterung verwendet. Azure CLI Version 2.3 oder höher ist erforderlich, um die Azure Arc-aktivierten Erweiterungen für die Kubernetes-Befehlszeilenschnittstelle zu installieren.

Azure Arc-Agents für Kubernetes

Die Kubernetes-Version mit Azure Arc-Unterstützung besteht aus einigen Agents (auch als Operatoren bezeichnet), die in dem Cluster ausgeführt werden, der im Namespace azure-arc bereitgestellt wird:

• deployment.apps/config-agent. Prüft den verbundenen Cluster auf Ressourcen für die Konfiguration der Quellcodeverwaltung, die auf den Cluster angewendet werden, und aktualisiert den Konformitätszustand.
• deployment.apps/controller-manager. Ist ein Operator für Operatoren und koordiniert Interaktionen zwischen Azure Arc-Komponenten.
• deployment.apps/metrics-agent. Erfasst Metriken von anderen Arc-Agents, um sicherzustellen, dass diese Agents eine optimale Leistung aufweisen.
• deployment.apps/cluster-metadata-operator. Erfasst Clustermetadaten: Clusterversion, Knotenanzahl und Version des Azure Arc-Agents.
• deployment.apps/resource-sync-agent. Synchronisiert die oben erwähnten Clustermetadaten mit Azure.
• deployment.apps/clusteridentityoperator. Verwaltet das von anderen Agents für die Kommunikation mit Azure verwendete MSI-Zertifikat (Managed Service Identity, Verwaltete Dienstidentität).
• deployment.apps/flux-logs-agent. Sammelt Protokolle von den bei der Konfiguration der Quellcodeverwaltung bereitgestellten Flux-Operatoren.
• deployment.apps/extension-manager. Installiert Erweiterungs-Helm-Diagramme und verwaltet deren Lebenszyklus.
• deployment.apps/kube-azure-ad-proxy. Wird für die Authentifizierung von Anforderungen verwendet, die mithilfe von Cluster Connect an den Cluster gesendet werden.
• deployment.apps/clusterconnect-agent. Ein Reverseproxy-Agent, der ermöglicht, dass das Cluster Connect-Feature Zugriff auf apiserver des Clusters bereitstellt. Es handelt sich um eine optionale Komponente, die nur dann bereitgestellt wird, wenn das Cluster Connect-Feature im Cluster aktiviert ist.
• deployment.apps/guard. Ein Webhookserver für die Authentifizierung und Autorisierung, der für die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) von Microsoft Entra verwendet wird. Es handelt sich um eine optionale Komponente, die nur dann bereitgestellt wird, wenn das Feature „azure-rbac“ im Cluster aktiviert ist.

Weitere Informationen finden Sie unter Herstellen einer Verbindung für einen Azure Arc-fähigen Kubernetes-Cluster.

Überwachen von Clustern mithilfe von Azure Monitor Container Insights

Die Überwachung ihrer Container ist wichtig. Azure Monitor Container Insights bietet umfassende Überwachungsfunktionen für AKS- und AKS-Engine-Cluster. Sie können Azure Monitor Container Insights auch zum Überwachen außerhalb von Azure gehosteter Kubernetes-Cluster mit Azure Arc-Unterstützung konfigurieren. Dies ermöglicht eine umfassende Überwachung Ihrer Kubernetes-Cluster in Azure, lokal und in Cloudumgebungen von Drittanbietern.

Azure Monitor Container Insights ermöglicht die Visualisierung der Leistung, indem mithilfe der Metrik-API (Anwendungsprogrammierschnittstelle) die in Kubernetes verfügbaren Speicher- und Prozessormetriken von Controllern, Knoten und Containern erfasst werden. Auch Containerprotokolle werden erfasst. Nach der Aktivierung der Überwachung auf Kubernetes-Clustern werden Metriken und Protokolle für Sie automatisch mittels einer Containerversion des Log Analytics-Agents erfasst. Metriken werden in den Metrikspeicher geschrieben, und Protokolldaten werden in den Protokollspeicher geschrieben, der Ihrem Log Analytics-Arbeitsbereich zugeordnet ist. Weitere Informationen zu Azure Monitor Container Insights finden Sie in der Übersicht zu Azure Monitor Container Insights.

Sie können Azure Monitor Container Insights für mindestens eine Bereitstellung von Kubernetes entweder mit einem PowerShell- oder einem Bash-Skript aktivieren.

Informationen zum Aktivieren der Überwachung für Azure Arc-fähige Kubernetes-Cluster finden Sie unter Azure Monitor Container Insights für Azure Arc-fähige Kubernetes-Cluster.

Verwenden von Azure Policy zum Aktivieren der GitOps-basierten Anwendungsbereitstellung

Erzwingen Sie mit Azure Policy, dass auf alle Git-Ops-aktivierten Microsoft.Kubernetes/connectedclusters-Ressourcen oder Microsoft.ContainerService/managedClusters-Ressourcen bestimmte Microsoft.KubernetesConfiguration/fluxConfigurations angewendet werden. Beispielsweise können Sie eine Baselinekonfiguration auf einen oder mehrere Cluster anwenden oder bestimmte Anwendungen auf mehreren Clustern bereitstellen. Um Azure Policy zu verwenden, wählen Sie eine Definition aus den Integrierte Azure Policy-Richtliniendefinitionen für Kubernetes mit Azure Arc-Aktivierung aus, und erstellen Sie dann eine Richtlinienzuweisung.

Legen Sie beim Erstellen der Richtlinienzuweisung den Umfang auf eine Azure-Ressourcengruppe oder ein Abonnement fest. Legen Sie außerdem die Parameter für die fluxConfiguration fest, die erstellt wird. Wenn die Zuweisung erstellt wird, identifiziert die Richtlinien-Engine alle connectedCluster- oder managedCluster-Ressourcen, die im Umfang liegen, und wendet dann auf jede die fluxConfiguration an.

Wenn Sie mehrere Quell-Repositorys für jeden Cluster verwenden (z. B. ein Repository für den zentralen IT-/Cluster-Operator und andere Repositorys für Anwendungsteams), aktivieren Sie diese mithilfe mehrerer Richtlinienzuweisungen, und konfigurieren Sie jede Richtlinienzuweisung für die Verwendung eines anderen Quell-Repositorys.

Weitere Informationen finden Sie unter Konsistentes Bereitstellen von Anwendungen im großen Stil mithilfe von Flux v2-Konfigurationen und Azure Policy.

Bereitstellen von Anwendungen mithilfe von GitOps

GitOps ist die Praxis, den gewünschten Zustand der Kubernetes-Konfiguration (Bereitstellungen, Namespaces usw.) in einem Quell-Repository zu deklarieren, z. B. ein Git- oder Helm-Repository, Buckets oder Azure Blob Storage. Danach folgt eine abruf- und pullbasierte Bereitstellung dieser Konfigurationen für den Cluster mithilfe eines Operators.

Die Verbindung zwischen Ihrem Cluster und einem oder mehreren Quell-Repositorys wird durch Bereitstellen der Erweiterung microsoft.flux in Ihrem Cluster aktiviert. Die fluxConfiguration-Ressourceneigenschaften stellen dar, wohin und wie Kubernetes-Ressourcen vom Quell-Repository an Ihren Cluster weitergeleitet werden sollen. Die fluxConfiguration-Daten werden im Ruhezustand verschlüsselt in einer Azure Cosmos DB-Datenbank gespeichert, um ihre Vertraulichkeit zu gewährleisten.

Der in Ihrem Cluster ausgeführte flux-config-Agent ist für die Überwachung neuer oder aktualisierter fluxConfiguration-Erweiterungsressourcen in der Azure Arc-aktivierten Kubernetes-Ressource, das Bereitstellen von Anwendungen aus dem Quell-Repositorys und das Weitergeben von Updates, die an fluxConfiguration vorgenommen werden, verantwortlich. Sie können sogar mehrere fluxConfiguration-Ressourcen mithilfe des namespace-Bereichs im gleichen Azure Arc-aktiviertem Kubernetes-Cluster erstellen, um Mehrinstanzenfähigkeit zu erzielen.

Das Quell-Repository kann gültige Kubernetes-Ressourcen einschließlich Namespaces, ConfigMaps, Bereitstellungen und DaemonSets enthalten. Es kann auch Helm-Charts für die Bereitstellung von Anwendungen enthalten. Allgemeine Quell-Repository-Szenarien umfassen das Definieren einer Baseline-Konfiguration für Ihre Organisation, die allgemeine RBAC-Rollen (Role-Based Access Control, rollenbasierte Zugriffssteuerung) und -Bindungen, Überwachungs- oder Protokollierungs-Agents und clusterweite Dienste beinhalten kann.

Sie können auch eine größere Sammlung von Clustern verwalten, die in heterogenen Umgebungen bereitgestellt werden können. Beispielsweise können Sie mit einem Repository die Baselinekonfiguration für Ihre Organisation definieren und diese auf mehrere Kubernetes-Cluster gleichzeitig anwenden. Sie können Anwendungen auch aus mehreren Quell-Repositorys in einem Cluster bereitstellen.

Weitere Informationen finden Sie unter Bereitstellen von Anwendungen mithilfe von GitOps mit Flux v2.

Topologie, Netzwerk und Routing

Azure Arc-Agents müssen über die folgenden Protokolle/Ports/ausgehenden URLs verfügen, um zu funktionieren:

Eine vollständige Liste der URLs für Azure Arc-Dienste finden Sie unter Azure Arc-Netzwerkanforderungen.

Überlegungen

Diese Überlegungen beruhen auf den Säulen des Azure Well-Architected Frameworks, d. h. einer Reihe von Grundsätzen, mit denen die Qualität von Workloads verbessert werden kann. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

Zuverlässigkeit

Zuverlässigkeit stellt sicher, dass Ihre Anwendung Ihre Verpflichtungen gegenüber den Kunden erfüllen kann. Weitere Informationen finden Sie in der Überblick über die Säule „Zuverlässigkeit“.

• In den meisten Fällen sollte der Standort, den Sie beim Erstellen des Installationsskripts auswählen, die Azure-Region sein, die Ihren lokalen Ressourcen geografisch am nächsten ist. Die übrigen Daten werden innerhalb der Azure-Geografie gespeichert, in der sich die von Ihnen angegebene Region befindet, was ggf. Auswirkungen auf die Wahl der Region hat, wenn Datenresidenzanforderungen erfüllt werden müssen. Wenn ein Ausfall in der Azure-Region auftritt, mit der Ihr Computer verbunden ist, wirkt sich der Ausfall nicht auf den verbundenen Computer aus. Allerdings können Verwaltungsvorgänge, für die Azure genutzt wird, möglicherweise nicht vollständig ausgeführt werden. Wenn Sie über mehrere Standorte mit einem geografisch redundanten Dienst verfügen, empfiehlt es sich, die Computer an den einzelnen Standorten jeweils mit einer anderen Azure-Region zu verbinden, um im Falle eines regionalen Ausfalls von der Resilienz zu profitieren. Weitere Informationen zu verfügbaren Regionen finden Sie unter Unterstützte Regionen für Azure Arc-aktivierte Kubernetes-Versionen.
• Stellen Sie sicher, dass die Dienste, auf die im Abschnitt Architektur verwiesen wird, in der Region unterstützt werden, in der Azure Arc bereitgestellt wird.

Sicherheit

Sicherheit bietet Schutz vor vorsätzlichen Angriffen und dem Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Übersicht über die Säule „Sicherheit“.

• Mit der rollenbasierten Zugriffssteuerung in Azure (Azure RBAC) können Sie den Zugriff auf Azure Arc-fähige Kubernetes-Versionen in Azure-Umgebungen und lokalen Umgebungen mit Microsoft Entra-Identitäten verwalten. Weitere Informationen finden Sie unter Verwenden von Azure RBAC für die Kubernetes-Autorisierung.
• Microsoft empfiehlt die Verwendung eines Dienstprinzipals mit eingeschränkten Berechtigungen zum Onboarding von Kubernetes-Clustern in Azure Arc. Diese Vorgehensweise ist in CI/CD-Pipelines wie Azure Pipelines und GitHub Actions nützlich. Weitere Informationen finden Sie unter Erstellen eines Azure Arc-fähigen Onboardingdienstprinzipals (Vorschauversion).
• Um die Dienstprinzipalverwaltung zu vereinfachen, können Sie verwaltete Identitäten in AKS verwenden. Allerdings müssen Cluster mithilfe der verwalteten Identität erstellt werden, und die vorhandenen Cluster (einschließlich Azure- und lokaler Cluster) können nicht zu verwalteten Identitäten migriert werden. Weitere Informationen finden Sie unter Verwenden verwalteter Identitäten in Azure Kubernetes Service.

Kostenoptimierung

Bei der Kostenoptimierung geht es um die Suche nach Möglichkeiten, unnötige Ausgaben zu reduzieren und die Betriebseffizienz zu verbessern. Weitere Informationen finden Sie unter Übersicht über die Säule „Kostenoptimierung“.

Allgemeine Überlegungen zu Kosten finden Sie im Microsoft Azure Well-Architected Framework unter Grundsätze der Kostenoptimierung.

Optimaler Betrieb

Die Säule „Optimaler Betrieb“ deckt die Betriebsprozesse ab, die für die Bereitstellung einer Anwendung und deren Ausführung in der Produktion sorgen. Weitere Informationen finden Sie unter Übersicht über die Säule „Optimaler Betrieb“.

• Bevor Sie Ihre Kubernetes-Cluster mit Azure Arc-Unterstützung konfigurieren, machen Sie sich mit den Grenzwerten für Abonnements von Azure Resource Manager sowie mit den Grenzwerten für Ressourcengruppen vertraut, um die Anzahl der Cluster zu planen.
• Verwenden Sie das Open Source-Verpackungstool Helm, um Kubernetes-Anwendungen zu installieren und ihren Lebenszyklus zu verwalten. Ähnlich wie der Linux-Paket-Manager (z. B. APT und Yum) wird Helm zur Verwaltung von Kubernetes-Diagrammen verwendet, bei denen es sich um Pakete aus vorkonfigurierten Kubernetes-Ressourcen handelt.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautor:

• Pieter de Bruin | Senior Program Manager

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte

• Azure Arc-Dokumentation
• Dokumentation zu Kubernetes mit Azure Arc-Unterstützung
• Dokumentation zu Azure Kubernetes Service
• Dokumentation zu Azure Policy
• Azure Monitor-Dokumentation
• Verbinden eines Azure Arc-fähigen Kubernetes-Clusters

Zugehörige Ressourcen

Verwandte Hybridleitfäden:

• Entwurf einer Hybridarchitektur
• Azure-Hybridoptionen
• Überlegungen zum Entwurf von Hybrid-Apps

Verwandte Architekturen:

• Baselinearchitektur für AKS in Azure Stack HCI
• Netzwerkarchitektur für AKS in Azure Stack HCI
• Optimieren der Verwaltung von SQL Server-Instanzen in lokalen und Multicloudumgebungen mithilfe von Azure Arc
• Überwachung für Unternehmen mit Azure Monitor