Clustermuster für hohe Verfügbarkeit von Kubernetes

In diesem Artikel wird beschrieben, wie Sie eine hoch verfügbare Kubernetes-basierte Infrastruktur mithilfe des Azure Kubernetes Service (AKS)-Moduls auf Azure Stack Hub erstellen und betreiben. Dieses Szenario ist für Organisationen mit kritischen Workloads in stark eingeschränkten und regulierten Umgebungen üblich. Organisationen in Domänen wie Finanzen, Verteidigung und Regierung.

Kontext und Problem

Viele Organisationen entwickeln cloudeigene Lösungen, die modernste Dienste und Technologien wie Kubernetes verwenden. Obwohl Azure Rechenzentren in den meisten Regionen der Welt bereitstellt, gibt es manchmal Edge-Anwendungsfälle und Szenarien, in denen geschäftskritische Anwendungen an einem bestimmten Ort ausgeführt werden müssen. Zu den Überlegungen gehören:

• Standortempfindlichkeit
• Latenz zwischen der Anwendung und lokalen Systemen
• Bandbreiteneinsparung
• Konnektivität
• Regulatorische oder gesetzliche Anforderungen

Azure, in Kombination mit Azure Stack Hub, behebt die meisten dieser Bedenken. Nachfolgend finden Sie eine umfassende Reihe von Optionen, Entscheidungen und Überlegungen für eine erfolgreiche Implementierung von Kubernetes, die auf Azure Stack Hub ausgeführt werden.

Lösung

Bei diesem Muster wird davon ausgegangen, dass wir mit einer strengen Gruppe von Einschränkungen umgehen müssen. Die Anwendung muss lokal ausgeführt werden, und alle personenbezogenen Daten dürfen keine öffentlichen Clouddienste erreichen. Überwachung und andere Nicht-PII-Daten können an Azure gesendet und dort verarbeitet werden. Auf externe Dienste wie eine öffentliche Containerregistrierung kann zugegriffen werden, jedoch kann der Zugriff durch eine Firewall oder einen Proxyserver gefiltert werden.

Die hier gezeigte Beispielanwendung ist so konzipiert, dass kubernetes-native Lösungen nach Möglichkeit verwendet werden. Dieses Design vermeidet die Anbietersperrung, anstatt plattformeigene Dienste zu verwenden. Als Beispiel verwendet die Anwendung ein selbst gehostetes MongoDB-Datenbank-Back-End anstelle eines PaaS-Diensts oder externen Datenbankdiensts. Weitere Informationen finden Sie in der Einführung in Kubernetes im Azure-Lernpfad.

Das vorherige Diagramm veranschaulicht die Anwendungsarchitektur der Beispielanwendung, die auf Kubernetes auf Azure Stack Hub ausgeführt wird. Die App besteht aus mehreren Komponenten, darunter:

1. Ein AKS Engine-basierter Kubernetes-Cluster auf Azure Stack Hub.
2. Zertifikat-Manager-, das eine Reihe von Tools für die Zertifikatverwaltung in Kubernetes bereitstellt, die verwendet werden, um automatisch Zertifikate von Let's Encrypt anzufordern.
3. Ein Kubernetes-Namespace, der die Anwendungskomponenten für das Front-End (Ratings-Web), die API (Ratings-API) und die Datenbank (ratings-mongodb) enthält.
4. Der Ingress Controller, der HTTP-/HTTPS-Datenverkehr an Endpunkte innerhalb des Kubernetes-Clusters leitet.

Die Beispielanwendung wird verwendet, um die Anwendungsarchitektur zu veranschaulichen. Alle Komponenten sind Beispiele. Die Architektur enthält nur eine einzelne Anwendungsbereitstellung. Um hohe Verfügbarkeit (HA) zu erreichen, führen wir die Bereitstellung mindestens zweimal auf zwei verschiedenen Azure Stack Hub-Instanzen aus – sie können entweder an demselben Standort oder in zwei (oder mehr) verschiedenen Standorten ausgeführt werden:

Dienste wie Azure Container Registry, Azure Monitor und andere werden außerhalb von Azure Stack Hub in Azure oder lokal gehostet. Dieses Hybriddesign schützt die Lösung vor Einem Ausfall einer einzelnen Azure Stack Hub-Instanz.

Komponenten

Die Gesamtarchitektur besteht aus den folgenden Komponenten:

Azure Stack Hub ist eine Erweiterung von Azure, die Workloads in einer lokalen Umgebung ausführen kann, indem Azure-Dienste in Ihrem Rechenzentrum bereitgestellt werden. Wechseln Sie zu Azure Stack Hub–Übersicht, um mehr zu erfahren.

Azure Kubernetes Service Engine (AKS Engine) ist das Modul hinter dem verwalteten Kubernetes-Dienstangebot, Azure Kubernetes Service (AKS), das heute in Azure verfügbar ist. Für Azure Stack Hub ermöglicht uns das AKS-Modul die Bereitstellung, Skalierung und Aktualisierung vollständig bereitgestellter, selbstverwalteter Kubernetes-Cluster mithilfe der IaaS-Funktionen von Azure Stack Hub. Wechseln Sie zu AKS Engine Overview, um mehr zu erfahren.

Wechseln Sie zu Bekannten Problemen und Einschränkungen, um mehr über die Unterschiede zwischen dem AKS-Modul auf Azure und dem AKS-Modul im Azure Stack Hub zu erfahren.

Azure Virtual Network (VNet) wird verwendet, um die Netzwerkinfrastruktur auf jedem Azure Stack Hub für die virtuellen Computer (VMs) bereitzustellen, die die Kubernetes-Clusterinfrastruktur hosten.

Azure Load Balancer wird für den Kubernetes-API-Endpunkt und den Nginx-Eingangscontroller verwendet. Der Lastenausgleich leitet externen Datenverkehr (z. B. Internet) an Knoten und VMs weiter, die einen bestimmten Dienst anbieten.

Azure Container Registry (ACR)- wird verwendet, um private Docker-Images und Helm-Diagramme zu speichern, die für den Cluster bereitgestellt werden. AKS Engine kann sich mithilfe von Microsoft Entra ID bei der Container Registry authentifizieren. Kubernetes erfordert keine ACR. Sie können andere Containerregistrierungen wie Docker Hub verwenden.

Azure Repos ist eine Reihe von Versionssteuerungstools, mit denen Sie Ihren Code verwalten können. Sie können auch GitHub oder andere gitbasierte Repositorys verwenden. Wechseln Sie zu Azure Repos Overview, um mehr zu erfahren.

Azure Pipelines Ist Teil von Azure DevOps Services und führt automatisierte Builds, Tests und Bereitstellungen aus. Sie können auch CI/CD-Lösungen von Drittanbietern wie Jenkins verwenden. Wechseln Sie zu Azure Pipeline Overview, um mehr zu erfahren.

Azure Monitor erfasst und speichert Metriken und Protokolle, einschließlich Plattformmetriken für die Azure-Dienste in der Lösung und Anwendungstelemetrie. Verwenden Sie diese Daten, um die Anwendung zu überwachen, Warnungen und Dashboards einzurichten und die Ursachenanalyse von Fehlern durchzuführen. Azure Monitor ist in Kubernetes integriert, um Metriken von Controllern, Knoten und Containern sowie Containerprotokollen und Masterknotenprotokollen zu sammeln. Wechseln Sie zu Azure Monitor Overview, um mehr zu erfahren.

Azure Traffic Manager ist ein DNS-basierter Datenverkehrslastenausgleich, mit dem Sie den Datenverkehr optimal auf Dienste in verschiedenen Azure-Regionen oder Azure Stack Hub-Bereitstellungen verteilen können. Traffic Manager bietet auch hohe Verfügbarkeit und Reaktionsfähigkeit. Auf die Anwendungsendpunkte muss von außen zugegriffen werden können. Es gibt auch andere lokale Lösungen.

Kubernetes Ingress Controller HTTP(S)-Routen für Dienste in einem Kubernetes-Cluster verfügbar macht. Nginx oder beliebige geeignete Eingangscontroller können zu diesem Zweck verwendet werden.

Helm ist ein Paketmanager für die Kubernetes-Bereitstellung und bietet eine Möglichkeit, verschiedene Kubernetes-Objekte wie Deployments, Services, Secrets, in einem einzigen "Diagramm" zu bündeln. Sie können ein Diagrammobjekt veröffentlichen, bereitstellen, die Versionsverwaltung steuern und aktualisieren. Azure Container Registry kann als Repository zum Speichern verpackter Helmdiagramme verwendet werden.

Entwurfsüberlegungen

Dieses Muster folgt einigen allgemeinen Überlegungen, die in den nächsten Abschnitten dieses Artikels ausführlicher erläutert werden:

• Die Anwendung verwendet Kubernetes-native Lösungen, um die Anbietersperrung zu vermeiden.
• Die Anwendung verwendet eine Microservices-Architektur.
• Azure Stack Hub benötigt keine eingehende Verbindung, ermöglicht aber ausgehende Internetverbindung.

Diese empfohlenen Methoden gelten auch für reale Workloads und Szenarien.

Überlegungen zur Skalierbarkeit

Skalierbarkeit ist wichtig, um Benutzern einen konsistenten, zuverlässigen und leistungsfähigen Zugriff auf die Anwendung zu ermöglichen.

Das Beispielszenario deckt die Skalierbarkeit auf mehreren Ebenen des Anwendungsstapels ab. Hier ist eine allgemeine Übersicht über die verschiedenen Ebenen:

Architekturebene	Betrifft	Wie?
Anwendung	Anwendung	Horizontale Skalierung basierend auf der Anzahl von Pods/Replikaten/Containerinstanzen*
Kluster	Kubernetes-Cluster	Anzahl der Knoten (zwischen 1 und 50), VM-SKU-Größen und Knotenpools (AKS Engine on Azure Stack Hub unterstützt derzeit nur einen einzelnen Knotenpool); Verwenden des Skalierungsbefehls des AKS-Moduls (manuell)
Infrastruktur	Azure Stack Hub	Anzahl der Knoten, Kapazität und Skalierungseinheiten innerhalb einer Azure Stack Hub-Bereitstellung

* Verwendung des Kubernetes Horizontalen Pod-Autoscalers (HPA); automatisierte metrikbasierte Skalierung oder vertikale Skalierung durch Größenanpassung der Containerinstanzen (CPU/Arbeitsspeicher).

Azure Stack Hub (Infrastrukturebene)

Die Azure Stack Hub-Infrastruktur ist die Grundlage dieser Implementierung, da Azure Stack Hub auf physischer Hardware in einem Rechenzentrum ausgeführt wird. Wenn Sie Ihre Hubhardware auswählen, müssen Sie Auswahlmöglichkeiten für CPU, Arbeitsspeicherdichte, Speicherkonfiguration und Anzahl von Servern treffen. Weitere Informationen zur Skalierbarkeit von Azure Stack Hub finden Sie in den folgenden Ressourcen:

• Übersicht über die Kapazitätsplanung für Azure Stack Hub
• Zusätzliche Knoten der Skalierungseinheit im Azure Stack Hub hinzufügen

Kubernetes-Cluster (Clusterebene)

Der Kubernetes-Cluster selbst besteht aus und ist aufgebaut auf Azure (Stack) IaaS-Komponenten, einschließlich Compute-, Speicher- und Netzwerkressourcen. Kubernetes-Lösungen umfassen Master- und Workerknoten, die als VMs in Azure (und Azure Stack Hub) bereitgestellt werden.

• Knoten der Steuerungsebene (Master) stellen die wichtigsten Kubernetes-Dienste und die Orchestrierung von Anwendungsworkloads bereit.
• Auf Workerknoten (Worker) werden Ihre Anwendungsworkloads ausgeführt.

Wenn Sie VM-Größen für die erste Bereitstellung auswählen, gibt es mehrere Überlegungen:

• Kosten – Berücksichtigen Sie bei der Planung der Arbeitsknoten die Gesamtkosten pro virtueller Maschine, die dabei entstehen. Wenn Ihre Anwendungsworkloads beispielsweise begrenzte Ressourcen benötigen, sollten Sie planen, kleinere VMs bereitzustellen. Azure Stack Hub, wie Azure, wird normalerweise auf Verbrauchsbasis in Rechnung gestellt. Daher ist die angemessene Größenanpassung der VMs für Kubernetes-Rollen entscheidend für die Optimierung der Verbrauchskosten.

• Skalierbarkeit – Skalierbarkeit des Clusters wird erreicht, indem die Anzahl der Master- und Workerknoten skaliert oder zusätzliche Knotenpools hinzugefügt werden (noch nicht auf Azure Stack Hub verfügbar). Die Skalierung des Clusters kann basierend auf Leistungsdaten erfolgen, die mithilfe von Container Insights (Azure Monitor + Log Analytics) gesammelt werden.

  Falls für Ihre Anwendung mehr (oder weniger) Ressourcen benötigt werden, können Sie für Ihre aktuellen Knoten das Aufskalieren (oder Abskalieren) durchführen (im Bereich von 1 bis 50 Knoten). Wenn Sie mehr als 50 Knoten benötigen, können Sie einen zusätzlichen Cluster in einem separaten Abonnement erstellen. Sie können die tatsächlichen virtuellen Computer nicht vertikal auf eine andere VM-Größe skalieren, ohne den Cluster erneut bereitzustellen.

  Die Skalierung erfolgt manuell mithilfe der Hilfs-VM des AKS-Moduls, die zum anfänglichen Bereitstellen des Kubernetes-Clusters verwendet wurde. Weitere Informationen finden Sie unter Skalieren von Kubernetes-Clustern

• Kontingente – Berücksichtigen Sie die Kontingente , die Sie beim Planen einer AKS-Bereitstellung auf Ihrem Azure Stack Hub konfigurieren. Stellen Sie sicher, dass für jedes Abonnement die richtigen Pläne und die Kontingente konfiguriert sind. Das Abonnement muss die Menge an Rechenleistung, Speicher und anderen Diensten berücksichtigen, die für Ihre Cluster erforderlich sind, während sie expandieren.

• Anwendungsworkloads - Schauen Sie in das Dokument zu den Kubernetes-Grundkonzepten für Azure Kubernetes Service, um sich über die Cluster- und Workloadkonzepte zu informieren. Dieser Artikel hilft Ihnen, die richtige VM-Größe basierend auf den Berechnungs- und Speicheranforderungen Ihrer Anwendung zu ermitteln.

Anwendung (Anwendungsebene)

Auf der Anwendungsebene verwenden wir Kubernetes Horizontal Pod Autoscaler (HPA). Mit dieser Skalierung kann die Anzahl von Replikaten (Pod-/Containerinstanzen) in unserer Bereitstellung basierend auf unterschiedlichen Metriken (z. B. CPU-Auslastung) erhöht oder verringert werden.

Eine weitere Option besteht darin, Containerinstanzen vertikal zu skalieren. Dies kann erreicht werden, indem die angeforderte und verfügbare Menge an CPU und Arbeitsspeicher für eine bestimmte Bereitstellung geändert wird. Weitere Informationen finden Sie unter Verwalten von Ressourcen für Container auf kubernetes.io.

Überlegungen zu Netzwerk und Konnektivität

Netzwerk und Konnektivität wirken sich auch auf die drei ebenen aus, die zuvor für Kubernetes auf Azure Stack Hub erwähnt wurden. Die folgende Tabelle zeigt die Ebenen und welche Dienste sie enthalten:

Schicht	Betrifft	Was?
Anwendung	Anwendung	Wie kann auf die Anwendung zugegriffen werden? Wird es im Internet verfügbar gemacht?
Kluster	Kubernetes-Cluster	Kubernetes-API, AKS-Engine-VM, Pullen von Containerimages (ausgehend), Senden von Überwachungs- und Telemetriedaten (ausgehend)
Infrastruktur	Azure Stack Hub	Barrierefreiheit der Azure Stack Hub-Verwaltungsendpunkte wie das Portal und Azure Resource Manager-Endpunkte.

Anwendung

Für die Anwendungsschicht ist am wichtigsten zu berücksichtigen, ob die Anwendung über das Internet verfügbar gemacht und zugänglich ist. Aus der Kubernetes-Perspektive bedeutet Internetzugang, dass Sie ein Deployment oder einen Pod mit einem Kubernetes-Service oder einem Ingress-Controller bereitstellen.

Das Verfügbarmachen einer Anwendung mit einer öffentlichen IP über einen Load Balancer oder einen Ingress Controller bedeutet nicht, dass die Anwendung jetzt über das Internet zugänglich ist. Es ist möglich, dass Azure Stack Hub über eine öffentliche IP-Adresse verfügt, die nur im lokalen Intranet sichtbar ist – nicht alle öffentlichen IPs sind wirklich internetgeschützt.

Im obigen Abschnitt wurde der eingehende Datenverkehr für die Anwendung beschrieben. Eine weitere Überlegung für eine erfolgreiche Kubernetes-Bereitstellung betrifft den ausgehenden Datenverkehr. Hier sind einige Anwendungsfälle angegeben, für die ausgehender Datenverkehr erforderlich ist:

• Pullen von Containerimages, die in Docker Hub oder Azure Container Registry gespeichert sind
• Abrufen von Helm-Diagrammen
• Senden von Application Insights-Daten (oder anderen Überwachungsdaten)

Einige Unternehmensumgebungen erfordern möglicherweise die Verwendung von transparenten oder nicht transparenten Proxyservern. Diese Server erfordern eine bestimmte Konfiguration für verschiedene Komponenten unseres Clusters. Die Dokumentation des AKS Engine enthält verschiedene Details zur Einrichtung von Netzwerkproxys. Weitere Informationen finden Sie unter AKS Engine und Proxyserver

Schließlich muss der clusterübergreifende Datenverkehr zwischen Azure Stack Hub-Instanzen fließen. Die Beispielbereitstellung besteht aus einzelnen Kubernetes-Clustern, die auf einzelnen Azure Stack Hub-Instanzen ausgeführt werden. Der Datenverkehr zwischen ihnen, z. B. der Replikationsverkehr zwischen zwei Datenbanken, ist "externer Datenverkehr". Externer Datenverkehr muss entweder über ein Site-to-Site-VPN oder über öffentliche Azure Stack Hub-IP-Adressen weitergeleitet werden, um Kubernetes in zwei Azure Stack Hub-Instanzen zu verbinden:

Cluster

Der Kubernetes-Cluster muss nicht unbedingt über das Internet zugänglich sein. Der relevante Teil ist die Kubernetes-API, die zum Arbeiten eines Clusters verwendet wird, z. B. mithilfe von kubectl. Der Kubernetes-API-Endpunkt muss für alle Benutzer zugänglich sein, die den Cluster betreiben oder Anwendungen und Dienste darüber bereitstellen. Das Thema wird im Abschnitt „Überlegungen zur Bereitstellung (CI/CD)“ unten aus einer DevOps-Perspektive ausführlicher behandelt.

Auf der Clusterebene sollten auch einige Aspekte in Bezug auf ausgehenden Datenverkehr berücksichtigt werden:

• Node-Updates (für Ubuntu)
• Überwachen von Daten (gesendet an Azure LogAnalytics)
• Andere Agents, für die ausgehender Datenverkehr erforderlich ist (je nach Umgebung der einzelnen Bereitsteller)

Planen Sie das endgültige Netzwerkdesign, bevor Sie Ihren Kubernetes-Cluster mithilfe des AKS-Engine bereitstellen. Anstatt ein dediziertes virtuelles Netzwerk zu erstellen, ist es möglicherweise effizienter, einen Cluster in einem vorhandenen Netzwerk bereitzustellen. Sie können beispielsweise eine vorhandene Site-zu-Site-VPN-Verbindung verwenden, die bereits in Ihrer Azure Stack Hub-Umgebung konfiguriert ist.

Infrastruktur

Infrastruktur bezieht sich auf den Zugriff auf die Azure Stack Hub-Verwaltungsendpunkte. Endpunkte umfassen die Mandantenportale und Administratorportale sowie die Administrator- und Mandantenendpunkte des Azure Resource Managers. Diese Endpunkte sind erforderlich, um Azure Stack Hub und seine Kerndienste zu betreiben.

Überlegungen zu Daten und Speicherung

Zwei Instanzen unserer Anwendung werden in zwei einzelnen Kubernetes-Clustern in zwei Azure Stack Hub-Instanzen bereitgestellt. Dieses Design erfordert, dass wir überlegen, wie Daten zwischen ihnen repliziert und synchronisiert werden.

Mit Azure verfügen wir über die integrierte Funktion zum Replizieren von Speicher in mehreren Regionen und Zonen in der Cloud. Derzeit mit Azure Stack Hub gibt es keine nativen Methoden zum Replizieren von Speicher über zwei verschiedene Azure Stack Hub-Instanzen hinweg – sie bilden zwei unabhängige Clouds ohne übergeordnete Möglichkeit, sie als Satz zu verwalten. Die Planung der Resilienz von Anwendungen, die in Azure Stack Hub ausgeführt werden, zwingt Sie, diese Unabhängigkeit in Ihren Anwendungsdesigns und -bereitstellungen zu berücksichtigen.

In den meisten Fällen ist die Speicherreplikation für eine robuste und hoch verfügbare Anwendung, die auf AKS bereitgestellt wird, nicht erforderlich. Sie sollten jedoch unabhängigen Speicher pro Azure Stack Hub-Instanz im Anwendungsentwurf berücksichtigen. Wenn dieses Design ein Problem oder Hindernis für die Bereitstellung der Lösung im Azure Stack Hub darstellt, gibt es mögliche Lösungen von Microsoft-Partnern, die Speicheranhänge bereitstellen. Das Anfügen von Speicher stellt eine Lösung für die übergreifende Speicherreplikation auf mehreren Azure Stack Hub-Instanzen und in Azure dar. Weitere Informationen finden Sie in den Partnerlösungen.

In unserer Architektur wurden diese Ebenen berücksichtigt:

Konfiguration

Die Konfiguration umfasst die Konfiguration von Azure Stack Hub, AKS Engine und dem Kubernetes-Cluster selbst. Die Konfiguration sollte so weit wie möglich automatisiert und als Infrastructure-as-Code in einem Git-basierten Versionssteuerungssystem wie Azure DevOps oder GitHub gespeichert werden. Diese Einstellungen können nicht einfach über mehrere Bereitstellungen hinweg synchronisiert werden. Daher empfehlen wir, Konfigurationen extern zu verwalten und die DevOps-Pipeline zu nutzen.

Anwendung

Die Anwendung sollte in einem Git-basierten Repository gespeichert werden. Wenn eine neue Bereitstellung, Änderungen an der Anwendung oder Notfallwiederherstellung vorhanden sind, kann sie ganz einfach mithilfe von Azure-Pipelines bereitgestellt werden.

Daten

Daten sind die wichtigsten Aspekte bei den meisten Anwendungsdesigns. Anwendungsdaten müssen zwischen den verschiedenen Instanzen der Anwendung synchronisiert bleiben. Daten benötigen auch eine Sicherungs- und Notfallwiederherstellungsstrategie, wenn ein Ausfall vorhanden ist.

Das Erreichen dieses Designs hängt stark von der Technologieauswahl ab. Im Folgenden finden Sie einige Lösungsbeispiele für die Implementierung einer Datenbank in hochgradig verfügbarer Weise auf Azure Stack Hub:

• Bereitstellen einer SQL Server 2016-Verfügbarkeitsgruppe in Azure und Azure Stack Hub
• Bereitstellen einer hochverfügbaren MongoDB-Lösung für Azure und Azure Stack Hub

Überlegungen beim Arbeiten mit Daten an mehreren Standorten sind noch komplexere Überlegungen für eine hochverwendbare und robuste Lösung. Erwägen:

• Latenz und Netzwerkkonnektivität zwischen Azure Stack Hubs.
• Verfügbarkeit von Identitäten für Dienste und Berechtigungen. Jede Azure Stack Hub-Instanz ist in ein externes Verzeichnis integriert. Während der Bereitstellung wählen Sie entweder die Microsoft Entra-ID oder den Microsoft Entra-ID-Partnerverbund aus. Daher besteht das Potenzial, eine einzelne Identität zu verwenden, die mit mehreren unabhängigen Azure Stack Hub-Instanzen interagieren kann.

Geschäftskontinuität und Notfallwiederherstellung

Geschäftskontinuität und Notfallwiederherstellung (BCDR) ist ein wichtiges Thema in Azure Stack Hub und Azure. Der Hauptunterschied besteht darin, dass der Operator im Azure Stack Hub den gesamten BCDR-Prozess verwalten muss. In Azure werden Teile von BCDR automatisch von Microsoft verwaltet.

BCDR wirkt sich auf dieselben Bereiche aus, die im vorherigen Abschnitt Überlegungen zu Daten und Speicher beschrieben wurden:

• Infrastruktur / Konfiguration
• Anwendungsverfügbarkeit
• Anwendungsdaten

Wie im vorherigen Abschnitt erwähnt, sind diese Bereiche die Verantwortung des Azure Stack Hub-Operators und können zwischen Organisationen variieren. Planen Sie BCDR entsprechend Ihren verfügbaren Tools und Prozessen.

Infrastruktur und Konfiguration

In diesem Abschnitt werden die physische und logische Infrastruktur und die Konfiguration von Azure Stack Hub behandelt. Es geht um Aktionen für Administratoren und Mandanten.

Der Azure Stack Hub-Operator (oder Administrator) ist für die Wartung der Azure Stack Hub-Instanzen verantwortlich. Einschließen von Komponenten wie Netzwerk, Speicher, Identität und anderen Themen, die sich außerhalb des Umfangs dieses Artikels befinden. Weitere Informationen zu den Besonderheiten von Azure Stack Hub-Vorgängen finden Sie in den folgenden Ressourcen:

• Wiederherstellen von Daten im Azure Stack Hub mit dem Infrastruktursicherungsdienst
• Aktivieren der Sicherung für Azure Stack Hub über das Administrator-Portal.
• Wiederherstellen von katastrophalen Datenverlusten
• Bewährte Methoden für den Infrastructure Backup-Dienst

Azure Stack Hub ist die Plattform und Fabric, auf der Kubernetes-Anwendungen bereitgestellt werden. Der Anwendungsbesitzer für die Kubernetes-Anwendung ist ein Benutzer von Azure Stack Hub, wobei der Zugriff gewährt wird, um die für die Lösung erforderliche Anwendungsinfrastruktur bereitzustellen. Anwendungsinfrastruktur bedeutet in diesem Fall den Kubernetes-Cluster, der mit dem AKS-Modul und den umgebenden Diensten bereitgestellt wird. Diese Komponenten werden in Azure Stack Hub bereitgestellt, eingeschränkt durch ein Azure Stack Hub-Angebot. Stellen Sie sicher, dass das vom Kubernetes-Anwendungsbesitzer akzeptierte Angebot über ausreichende Kapazität verfügt (ausgedrückt in Azure Stack Hub-Kontingenten), um die gesamte Lösung bereitzustellen. Wie im vorherigen Abschnitt empfohlen, sollte die Anwendungsbereitstellung mithilfe von Infrastructure-as-Code- und Bereitstellungspipelines wie Azure DevOps Azure Pipelines automatisiert werden.

Weitere Informationen zu Azure Stack Hub-Angeboten und -Kontingenten finden Sie unter Azure Stack Hub-Dienste, -Pläne, -Angebote und -Abonnements

Es ist wichtig, die Konfiguration der AKS-Engine einschließlich der zugehörigen Ausgaben sicher zu speichern und aufzubewahren. Diese Dateien enthalten vertrauliche Informationen, die für den Zugriff auf den Kubernetes-Cluster verwendet werden, sodass sie geschützt werden müssen, damit sie nicht für Administratoren verfügbar gemacht werden.

Anwendungsverfügbarkeit

Die Anwendung sollte sich nicht auf Sicherungen einer bereitgestellten Instanz verlassen. Gehen Sie standardmäßig so vor, dass Sie die Anwendung anhand von Infrastructure-as-Code-Mustern vollständig neu bereitstellen. Verwenden Sie für die erneute Bereitstellung beispielsweise Azure DevOps mit Azure Pipelines. Das BCDR-Verfahren sollte die erneute Bereitstellung der Anwendung auf denselben oder einen anderen Kubernetes-Cluster umfassen.

Anwendungsdaten

Anwendungsdaten sind der entscheidende Teil, um Datenverluste zu minimieren. Im vorherigen Abschnitt wurden Techniken zum Replizieren und Synchronisieren von Daten zwischen zwei (oder mehr) Instanzen der Anwendung beschrieben. Abhängig von der Datenbankinfrastruktur (MySQL, MongoDB, MSSQL oder anderen), die zum Speichern der Daten verwendet wird, stehen verschiedene Datenbankverfügbarkeits- und Sicherungstechniken zur Auswahl.

Die empfohlenen Methoden zum Erreichen der Integrität sind die folgenden:

• Eine systemeigene Sicherungslösung für die jeweilige Datenbank.
• Eine Sicherungslösung, die die Sicherung und Wiederherstellung des von Ihrer Anwendung verwendeten Datenbanktyps offiziell unterstützt.

Wichtig

Speichern Sie Ihre Sicherungsdaten nicht in derselben Azure Stack Hub-Instanz, in der sich Ihre Anwendungsdaten befinden. Ein vollständiger Ausfall der Azure Stack Hub-Instanz würde auch Ihre Sicherungen gefährden.

Überlegungen zur Verfügbarkeit

Kubernetes auf Azure Stack Hub, das über die AKS Engine bereitgestellt wird, ist kein verwalteter Dienst. Es handelt sich um eine automatisierte Bereitstellung und Konfiguration eines Kubernetes-Clusters mit Azure Infrastructure-as-a-Service (IaaS). Daher bietet sie die gleiche Verfügbarkeit wie die zugrunde liegende Infrastruktur.

Die Azure Stack Hub-Infrastruktur ist bereits widerstandsfähig gegen Fehler und bietet Funktionen wie Verfügbarkeitsgruppen zum Verteilen von Komponenten über mehrere Fehler- und Updatedomänen. Die zugrunde liegende Technologie (Failoverclustering) verursacht jedoch weiterhin einige Ausfallzeiten für VMs auf einem betroffenen physischen Server, wenn ein Hardwarefehler auftritt.

Es empfiehlt sich, Ihren Kubernetes-Produktionscluster und die Arbeitsauslastung in zwei (oder mehr) Clustern bereitzustellen. Diese Cluster sollten an verschiedenen Standorten oder Rechenzentren gehostet werden und Technologien wie Azure Traffic Manager verwenden, um Benutzer basierend auf der Clusterantwortzeit oder basierend auf der Geografie weiterzuleiten.

Kunden, die über einen einzelnen Kubernetes-Cluster verfügen, stellen in der Regel eine Verbindung mit dem Dienst-IP- oder DNS-Namen einer bestimmten Anwendung her. In einer Multiclusterbereitstellung sollten Kunden eine Verbindung mit einem Traffic Manager-DNS-Namen herstellen, der auf die Dienste/Ingress in jedem Kubernetes-Cluster verweist.

Hinweis

Dieses Muster ist auch eine Best Practice für (verwaltete) AKS-Cluster in Azure.

Der Kubernetes-Cluster selbst, der über das AKS-Modul bereitgestellt wird, sollte aus mindestens drei Masterknoten und zwei Arbeitsknoten bestehen.

Überlegungen zu Identität und Sicherheit

Identität und Sicherheit sind wichtige Themen. Insbesondere, wenn die Lösung unabhängige Azure Stack Hub-Instanzen umfasst. Kubernetes und Azure (einschließlich Azure Stack Hub) verfügen beide über unterschiedliche Mechanismen für die rollenbasierte Zugriffssteuerung (RBAC):

• Azure RBAC steuert den Zugriff auf Ressourcen in Azure (und Azure Stack Hub), einschließlich der Möglichkeit, neue Azure-Ressourcen zu erstellen. Berechtigungen können Benutzern, Gruppen oder Dienstprinzipalen zugewiesen werden. (Ein Dienstprinzipal ist eine von Anwendungen verwendete Sicherheitsidentität.)
• Kubernetes RBAC steuert Berechtigungen für die Kubernetes-API. Beispielsweise sind das Erstellen von Pods und das Auflisten von Pods Aktionen, die für einen Benutzer über RBAC autorisiert (oder verweigert) werden können. Um Benutzern Kubernetes-Berechtigungen zuzuweisen, erstellen Sie Rollen und Rollenbindungen.

Azure Stack Hub-Identität und RBAC

Azure Stack Hub bietet zwei Auswahlmöglichkeiten für Identitätsanbieter. Der verwendete Anbieter hängt von der Umgebung ab und davon, ob sie in einer verbundenen oder getrennten Umgebung ausgeführt wird:

• Microsoft Entra-ID – kann nur in einer verbundenen Umgebung verwendet werden.
• Microsoft Entra ID Federation zu einer traditionellen Active Directory Struktur - kann sowohl in einer verbundenen als auch in einer getrennten Umgebung verwendet werden.

Der Identitätsanbieter verwaltet Benutzer und Gruppen, einschließlich Authentifizierung und Autorisierung für den Zugriff auf Ressourcen. Zugriff auf Azure Stack Hub-Ressourcen wie Abonnements, Ressourcengruppen und einzelne Ressourcen wie VMs oder Load Balancer kann gewährt werden. Um über ein einheitliches Zugriffsmodell zu verfügen, sollten Sie die Verwendung derselben Gruppen (entweder direkt oder geschachtelt) für alle Azure Stack Hubs in Betracht ziehen. Hier ist ein Konfigurationsbeispiel:

Das Beispiel enthält eine dedizierte Gruppe für einen bestimmten Zweck. Um beispielsweise Mitwirkendeberechtigungen für die Ressourcengruppe bereitzustellen, die unsere Kubernetes-Clusterinfrastruktur in einer bestimmten Azure Stack Hub-Instanz enthält (hier "Seattle K8s Cluster Contributor"). Diese Gruppen werden dann in eine allgemeine Gruppe geschachtelt, die die "Untergruppen" für jeden Azure Stack Hub enthält.

Unser Beispielbenutzer verfügt jetzt über "Mitwirkende"-Berechtigungen für beide Ressourcengruppen, die den gesamten Satz von Kubernetes-Infrastrukturressourcen enthalten. Der Benutzer hat Zugriff auf Ressourcen in beiden Azure Stack Hub-Instanzen, da die Instanzen denselben Identitätsanbieter verwenden.

Wichtig

Diese Berechtigungen wirken sich nur auf Azure Stack Hub und einige der darüber bereitgestellten Ressourcen aus. Ein Benutzer, der über diese Zugriffsebene verfügt, kann viel Schaden anrichten, aber nicht auf die Kubernetes IaaS-VMs oder die Kubernetes-API zugreifen, ohne zusätzlichen Zugriff auf die Kubernetes-Bereitstellung zu erhalten.

Kubernetes-Identität und RBAC

Ein Kubernetes-Cluster verwendet standardmäßig nicht denselben Identitätsanbieter wie der zugrunde stehenden Azure Stack Hub. Die virtuellen Computer, die den Kubernetes-Cluster, den Master- und Workerknoten hosten, verwenden den SSH-Schlüssel, der während der Bereitstellung des Clusters angegeben wird. Dieser SSH-Schlüssel ist erforderlich, um eine Verbindung mit diesen Knoten mithilfe von SSH herzustellen.

Die Kubernetes-API (z. B. beim Zugriff mit kubectl) ist auch durch Dienstkonten geschützt, z. B. ein Standarddienstkonto vom Typ „Clusteradministrator“. Die Anmeldeinformationen für dieses Dienstkonto werden zunächst in der datei .kube/config auf Ihren Kubernetes-Masterknoten gespeichert.

Geheimnisverwaltung und Anwendungsanmeldeinformationen

Um geheime Schlüssel wie Verbindungszeichenfolgen oder Datenbankanmeldeinformationen zu speichern, gibt es mehrere Optionen, darunter:

• Azure Key Vault (ein Dienst zur sicheren Verwaltung kryptografischer Schlüssel)
• Kubernetes Geheimnisse
• Drittanbieterlösungen wie HashiCorp Vault (läuft auf Kubernetes)

Speichern Sie geheime Schlüssel oder Anmeldeinformationen nicht in Nur-Text-Dateien, Anwendungscode oder in Skripts. Speichern Sie sie nicht in einem Versionssteuerungssystem. Stattdessen sollte die Bereitstellungsautomatisierung die geheimen Schlüssel nach Bedarf abrufen.

Patchen und Aktualisieren

Der Patch and Update (PNU) Prozess in Azure Kubernetes Service ist teilweise automatisiert. Kubernetes-Versionsupgrades werden manuell ausgelöst, während Sicherheitsupdates automatisch angewendet werden. Zu diesen Updates können Sicherheitskorrekturen für das Betriebssystem oder Kernel-Updates gehören. AKS startet diese Linux-Knoten nicht automatisch neu, um den Updatevorgang abzuschließen.

Der PNU-Prozess für einen Kubernetes-Cluster, der mithilfe des AKS-Moduls auf Azure Stack Hub bereitgestellt wird, ist nicht verwaltet und liegt in der Verantwortung des Clusteroperators.

AKS Engine hilft bei den beiden wichtigsten Aufgaben:

• Upgrade auf eine neuere Kubernetes- und Basisbetriebssystem-Imageversion
• Alleiniges Upgrade des Betriebssystem-Basisimages

Neuere Basisbetriebssystemimages enthalten die neuesten Betriebssystem-Sicherheitsupdates und Kernelupdates.

Der Mechanismus für unbeaufsichtigte Upgrades installiert automatisch Sicherheitsupdates, die veröffentlicht werden, bevor eine neue Basisversion des Betriebssystemabbilds im Azure Stack Hub Marketplace verfügbar ist. Unbeaufsichtigtes Upgrade ist standardmäßig aktiviert und installiert Sicherheitsupdates automatisch, startet jedoch nicht die Kubernetes-Clusterknoten neu. Der Neustart der Knoten kann mit dem Open-Source Kubernetes REboot Daemon (kured))automatisiert werden. Kured überwacht Linux-Knoten, für die ein Neustart erforderlich ist, und kümmert sich dann automatisch um die Neuplanung der laufenden Pods und den Neustartvorgang der Knoten.

Bereitstellungsaspekte (CI/CD)

Azure und Azure Stack Hub machen dieselben REST-APIs des Azure Resource Manager verfügbar. Diese APIs werden wie jede andere Azure-Cloud adressiert (Azure, Azure China 21Vianet, Azure Government). Es kann Unterschiede in API-Versionen zwischen Clouds geben, und Azure Stack Hub bietet nur eine Teilmenge von Diensten. Der URI des Verwaltungsendpunkts unterscheidet sich auch für jede Cloud und jede Instanz von Azure Stack Hub.

Neben den erwähnten subtilen Unterschieden bieten Azure Resource Manager-REST-APIs eine konsistente Möglichkeit, mit Azure und Azure Stack Hub zu interagieren. Die gleichen Tools können hier verwendet werden wie bei jeder anderen Azure-Cloud. Sie können Azure DevOps, Tools wie Jenkins oder PowerShell verwenden, um Dienste in Azure Stack Hub bereitzustellen und zu koordinieren.

Überlegungen

Einer der wichtigsten Unterschiede bei Azure Stack Hub-Bereitstellungen ist die Frage der Barrierefreiheit im Internet. Die Barrierefreiheit im Internet bestimmt, ob ein von Microsoft gehosteter oder selbst gehosteter Build-Agent für Ihre CI/CD-Aufträge ausgewählt werden soll.

Ein selbst gehosteter Agent kann über Azure Stack Hub (als IaaS-VM) oder in einem Netzwerksubnetz ausgeführt werden, das auf Azure Stack Hub zugreifen kann. Wechseln Sie zu Azure Pipelines-Agents, um mehr über die Unterschiede zu erfahren.

Die folgende Abbildung hilft Ihnen zu entscheiden, ob Sie einen selbst gehosteten oder von Microsoft gehosteten Build-Agent benötigen:

• Sind die Azure Stack Hub-Verwaltungsendpunkte über das Internet zugänglich?
  • Ja: Wir können Azure-Pipelines mit von Microsoft gehosteten Agents verwenden, um eine Verbindung mit Azure Stack Hub herzustellen.
  • Nein: Wir benötigen selbst gehostete Agents, die eine Verbindung mit den Verwaltungsendpunkten von Azure Stack Hub herstellen können.
• Ist unser Kubernetes-Cluster über das Internet zugänglich?
  • Ja: Wir können Azure Pipelines mit von Microsoft gehosteten Agents verwenden, um direkt mit dem Kubernetes-API-Endpunkt zu interagieren.
  • Nein: Wir benötigen selbst gehostete Agents, die eine Verbindung mit dem Kubernetes-Cluster-API-Endpunkt herstellen können.

In Szenarien, in denen auf die Azure Stack Hub-Verwaltungsendpunkte und die Kubernetes-API über das Internet zugegriffen werden kann, kann die Bereitstellung einen von Microsoft gehosteten Agent verwenden. Diese Bereitstellung führt wie folgt zu einer Anwendungsarchitektur:

Wenn die Azure Resource Manager-Endpunkte, die Kubernetes-API oder beide nicht direkt über das Internet zugänglich sind, können wir einen selbst gehosteten Build-Agent verwenden, um die Pipelineschritte auszuführen. Dieses Design benötigt weniger Konnektivität und kann nur mit lokaler Netzwerkkonnektivität für Azure Resource Manager-Endpunkte und die Kubernetes-API bereitgestellt werden:

Hinweis

Was ist mit getrennten Szenarien? In Szenarien, in denen entweder Azure Stack Hub oder Kubernetes oder beide nicht über Internetverwaltungsendpunkte verfügen, ist es weiterhin möglich, Azure DevOps für Ihre Bereitstellungen zu verwenden. Sie können entweder einen selbst gehosteten Agentpool (ein DevOps-Agent, der lokal oder auf Azure Stack Hub selbst ausgeführt wird) oder einen vollständig selbst gehosteten Azure DevOps Server lokal verwenden. Der selbst gehostete Agent benötigt nur ausgehende HTTPS(TCP/443)-Internetverbindung.

Das Muster kann einen Kubernetes-Cluster (bereitgestellt und mit dem AKS-Modul orchestriert) für jede Azure Stack Hub-Instanz verwenden. Sie umfasst eine Anwendung, die aus einem Frontend, einem Mid-Tier, Back-End-Diensten (z. B. MongoDB) und einem nginx-basierten Ingress Controller besteht. Anstatt eine datenbank zu verwenden, die im K8s-Cluster gehostet wird, können Sie "externe Datenspeicher" verwenden. Datenbankoptionen umfassen MySQL, SQL Server oder eine beliebige Art von Datenbank, die außerhalb von Azure Stack Hub oder in IaaS gehostet wird. Konfigurationen wie dies befinden sich hier nicht im Gültigkeitsbereich.

Partnerlösungen

Es gibt Microsoft Partner-Lösungen, die die Funktionen von Azure Stack Hub erweitern können. Diese Lösungen wurden bei Bereitstellungen von Anwendungen, die auf Kubernetes-Clustern ausgeführt werden, nützlich gefunden.

Speicher- und Datenlösungen

Wie in Überlegungen zu Daten und Speicherbeschrieben, verfügt Azure Stack Hub derzeit nicht über eine systemeigene Lösung zum Replizieren von Speicher über mehrere Instanzen hinweg. Im Gegensatz zu Azure ist die Funktion zum Replizieren von Speicher in mehreren Regionen nicht vorhanden. In Azure Stack Hub ist jede Instanz eine eigene eindeutige Cloud. Lösungen stehen jedoch von Microsoft-Partnern zur Verfügung, die die Speicherreplikation über Azure Stack Hubs und Azure ermöglichen.

SCALITY

Scality bietet webskalen Speicher, der seit 2009 digitale Unternehmen unterstützt. Der Scality RING, unser softwaredefinierter Speicher, wandelt rohstoffbasierte x86-Server in einen unbegrenzten Speicherpool für jeden Typ von Daten –Datei und Objekt – im Petabyte-Maßstab um.

CLOUDIAN

Cloudian vereinfacht den Unternehmensspeicher mit unbegrenztem skalierbarem Speicher, der massive Datasets in einer einzigen, einfach verwalteten Umgebung konsolidiert.

Nächste Schritte

Weitere Informationen zu konzepten, die in diesem Artikel eingeführt wurden:

• Cloudübergreifende Skalierung und Muster für geografisch verteilte Apps in Azure Stack Hub
• Microservicearchitektur in Azure Kubernetes Service (AKS).

Wenn Sie bereit sind, das Lösungsbeispiel zu testen, fahren Sie mit dem Clusterbereitstellungshandbuch für hohe Verfügbarkeit von Kubernetes-Clusterfort. Das Bereitstellungshandbuch enthält schrittweise Anleitungen zum Bereitstellen und Testen der zugehörigen Komponenten.