Freigeben über

Verwalten von Clustern moderner Anwendungsplattformen

  • Artikel

Das Cloud Adoption Framework bietet eine Hauptmethodik zur cloudunabhängigen Definition von Betriebsverwaltungsprozessen. Mit dieser Anleitung können Sie eine Baseline für die Betriebsverwaltung und weitere spezielle Betriebsschichten einrichten. Dies gilt auch für Organisationen, die über eine Mischung aus IaaS- (Infrastructure as a Service), PaaS- (Platform as a Service) und Containerworkloads verfügen. In diesem Artikel erfahren Sie, welche Komponenten Sie für die Containerverwaltung in Ihren vorhandenen Betrieb integrieren müssen. Außerdem werden die Vorteile einer Integration von Azure Kubernetes Service (AKS) in Ihre Containerverwaltungsstrategie beschrieben.

Ausrichtung auf die Anforderungen der Betriebsverwaltung

Container entfernen Abhängigkeiten auf mehreren Infrastrukturebenen, wodurch die Funktionen zur Betriebsverwaltung verbessert werden. Zur Umsetzung dieser Verbesserungen kann es erforderlich sein, die gesamte Cloudverwaltungsstrategie, angefangen bei der Geschäftsausrichtung, zu überarbeiten.

Zum Erstellen geeigneter Betriebsverwaltungsmethoden ist es notwendig zu wissen, wie Container in Cloudeinführungsplänen verwendet werden und welchen Nutzen Sie aus der Umstellung auf Containerworkloads erzielen.

  • Sollen in Ihrer Cloudplattform mehrere Technologielösungen, wie Container, IaaS und PaaS, genutzt werden?
  • Unterstützen zentrale Teams den Betrieb und die Verwaltung der Container- oder AKS-Plattform? Soll die Verantwortung dafür auf die einzelnen Workloadteams übertragen werden?
  • Unterstützen zentrale Teams den Betrieb und die Verwaltung der Workloads, die in den einzelnen Containern oder Pods ausgeführt werden? Soll die Verantwortung dafür auf die einzelnen Workloadteams übertragen werden?
  • Werden für unternehmenskritische Workloads Container verwendet?
  • Werden Container zur Kostensenkung nur für weniger kritische Workloads oder Hilfsworkloads verwendet?
  • Wie wichtig sind Leistung und Zuverlässigkeit der einzelnen Workloads?
  • Sind Ihre Anwendungen im Container zustandslos? Muss der Zustand beibehalten werden, um die Workloads in den Containern zu schützen und wiederherzustellen?

Die Antworten auf diese Fragen bilden die Grundlage für eine optimale Integration von Containern und AKS in Ihre Betriebsverwaltungsstrategie.

Betriebsbaseline

Durch das Implementieren einer Betriebsbaseline erhalten Sie zentralen Zugriff auf die Tools, die für den Betrieb und die Verwaltung aller Ressourcen in Ihrer Cloudumgebung erforderlich sind. Falls Sie für Ihre Nicht-Containerressourcen über keine Betriebsbaseline verfügen, können Sie die in der Verwaltungsmethodik definierte Betriebsbaseline implementieren.

Die Betriebsbaseline sollte Tools und Konfigurationen für Transparenz, Überwachung, betriebsbezogene Compliance, Optimierung sowie Protection & Recovery beinhalten.

Betriebsverwaltungsbaseline

Die in den vorherigen Artikeln beschriebene Betriebsbaseline bietet keine Unterstützung für Ihre Container oder AKS-Plattform. Sie stellt jedoch die Grundlage für Tools bereit, wie z. B. Azure Monitor, Azure Backup und weitere Tools, die auf die Unterstützung für Container erweitert werden kann.

Wird der Großteil Ihres Portfolios in Containern gehostet, sollten Sie die Integration des im folgenden Abschnitt beschriebenen speziellen Plattformbetriebs in Ihre Betriebsbaseline erwägen.

Plattformbetrieb

Sofern es sich bei dieser Implementierung nicht um die erste bzw. einzige Bereitstellung Ihrer Organisation in der Cloud handelt, ist eine Betriebsbaseline empfehlenswert. In diesem Abschnitt werden einige Tools beschrieben, die bei der Verwaltung von Container- oder AKS-Bereitstellung nützlich sind.

Bestand und Transparenz

Überwachungscontainer und AKS-Cluster nutzen die Tools, Dashboards und Warnungen Ihrer Betriebsbaseline. Allerdings können weitere Konfigurationen erforderlich sein, um die Daten aus Ihren Containern zu den Betriebsüberwachungstools wie Azure Monitor für Container zu übertragen. Informationen zum Sammeln von Daten, die für das Hinzufügen des Container- und AKS-Plattformbetriebs zu Ihrer Betriebsbaseline erforderlich sind, finden Sie in der Übersicht über Azure Monitor für Container.

Nachdem Sie Azure Monitor für das Sammeln von Daten zu Containern konfiguriert haben, können Sie die folgenden Bereiche als Teil der zentralen Verwaltungsprozesse überwachen:

  • Identifizieren von Clustern, die in verschiedenen Regionen ausgeführt werden und im Idealfall an einen Dienststruktureintrag gebunden sind, und Identifizieren von wichtigen Fakten zu diesen Clustern
    • Identifizieren des Clusterknotenpools, des Netzwerks und der Speichertopologien dieser Cluster
    • Identifizieren der Schichtung von AKS-Version und Knotenimageversion
  • Identifizieren der Ressourcenverwendung der Clusterknoten (Prozess, Arbeitsspeicher und Speicher)
  • Identifizieren von Containern, die auf den Knoten ausgeführt werden, sowie deren Anteil an der Knotenauslastung
  • Einblicke in das Verhalten von Clustern bei durchschnittlicher und maximaler Last. So können Sie benötigte Kapazitäten ermitteln und die maximale Last bestimmen, die der Cluster toleriert.
  • Konfigurieren von Warnungen, sodass Sie proaktiv benachrichtigt werden oder erfasst wird, wenn die CPU- und Speicherauslastung in Knoten oder Containern die von Ihnen definierten Schwellenwerte überschreitet oder wenn eine Änderung des Integritätszustands im Cluster beim Rollup der Infrastruktur- oder Knotenintegrität erfolgt
  • Verwenden von Abfragen zum Erstellen von gemeinsamen Warnungen, Dashboards und ausführlichen Analysen

Diese Daten unterstützen auch die Arbeit von Workloadbetriebsteams, indem detaillierte Informationen zu den auf der Containerplattform ausgeführten Workloads bereitgestellt werden:

  • Sie können die Ressourcenauslastung von Workloads überprüfen, die unabhängig von den Standardprozessen, die den Pod unterstützen, im Host ausgeführt werden.
  • Integrieren mit Prometheus zur Anzeige von Anwendungsmetriken
  • Überwachen Sie Containerworkloads, die auf der AKS-Engine lokal und der AKS-Engine in Azure Stack bereitgestellt werden.
  • Überwachen von Containerworkloads, die in Azure Red Hat OpenShift bereitgestellt sind.
  • Überwachen von Containerworkloads, die in Kubernetes mit Azure Arc-Aktivierung (Vorschau) bereitgestellt sind.

Betriebsbezogene Compliance

In einer Containerumgebung finden Patching-, Optimierungs- und Dimensionierungsvorgänge auf unterschiedlichen Ebenen statt. Je nach Betriebsansatz befinden sich die jeweiligen Operatoren in unterschiedlichen Teams. Zur Aufrechterhaltung der betriebsbezogenen Compliance überwacht ein Operator die Nutzung, passt die Größe der Ressourcen entsprechend einer Leistung/Kosten-Abwägung an und führt zur Minimierung von Risiken und Konfigurationsabweichungen die Patchverwaltung der zugrunde liegenden Systeme aus. Zentrale IT-Organisationen neigen dazu, diese Aufgaben als Teil der Betriebsbaseline für IaaS- und PaaS-Lösungen bereitzustellen.

In einer Clusterumgebung in Azure werden diese Aufgaben auf mehreren Ebenen ausgeführt: auf der Ebene des AKS-Clusters, des Knotenimages und des Betriebssystems des Knotens. Diese Betriebsaufgaben hängen immer stärker vom Verständnis und der Arbeitsbeziehung der Workloads ab, die in den Clustern oder in einzelnen Knotenpools ausgeführt werden. Mithilfe der folgenden Informationen können Sie beurteilen, ob und wie Sie Ihre Containerumgebungen betreiben möchten:

  • Werden Dimensionierungs- und Patchingvorgänge des AKS-Clusters, des Knotenimages oder des Knotenbetriebssystems als Teil der Bereitstellungspipeline für die Anwendung bereitgestellt oder hängen von der Anwendungsarchitektur oder -Konfiguration ab, sollte die betriebsbezogene Compliance für eine möglichst präzise Steuerung an das Workloadteam übertragen werden. Da Workloads häufig von Orchestrierungsfunktionen abhängig sind, stellt dieses Muster die gängigste Vorgehensweise dar. Eine unerwartete Änderung der AKS-Version oder des Knotenimages könnte andernfalls schwerwiegende Auswirkungen auf die Workload oder deren Runtimetools besitzen.
  • Für die weniger gängigen zentralen Cluster, die ein Portfolio von Workloads und eine Vielzahl von Anwendungen unterstützen, können Aufgaben der betriebsbezogenen Compliance weiter im Zuständigkeitsbereich des zentralen Betriebsteams bleiben. Mithilfe der folgenden Anleitungen können Sie diese Aufgaben für alle Cluster bereitstellen. Das regelmäßige Ausführen dieser Aufgaben ermöglicht einen plattformspezifischen Betrieb. Ein zentraler Betriebsansatz birgt ein erhebliches Risiko. Daher müssen Upgrades in Präproduktionsumgebungen sorgfältig getestet, geplante Wartungen eingehalten sowie Notfallpläne für nicht konforme Workloads erstellt werden. Ein fehlerhaftes Upgrade kann einen Single Point of Failure darstellen bzw. eine Workload, für die kein Upgrade ausgeführt werden kann, kann dazu führen, dass ein Cluster nicht mehr unterstützt wird. Planen und verwalten Sie daher Cluster mit mehreren Instanzen mit der erforderlichen Sorgfalt.

Führen Sie für beide Clustertypen die folgenden Anleitungen zu Upgrades sowie Updates von Knotenimages und des Knotenbetriebssystems aus:

Schutz und Wiederherstellung

AKS-Knoten sind grundsätzlich kurzlebig und werden daher nicht auf eine Weise gesichert, die eine einzelne Wiederherstellung ermöglicht. Zur Wiederherstellung nach einem Incident müssen Workloads je nach Ausmaß möglicherweise in einem neuen Knotenpool oder sogar in einem neuen Cluster erneut bereitgestellt werden.

  • Fügen Sie Ihrem Cluster eine Betriebszeit-SLA hinzu.
  • Bei hohen SLAs sollten Sie für zusätzlichen Schutz ggf. die bewährten Methoden für BCDR in mehreren Regionen beachten.
  • Da Cluster keine Zustandsdaten enthalten sollten, wird die Wiederherstellung des externen Zustands mithilfe der vorhandenen Anleitung der Betriebsbaseline verarbeitet. Enthalten Ihre Cluster Zustandsinformationen, führen Sie die bewährten Methoden zum Speichern aus, und erstellen Sie für einzelne Workloads eine Strategie zur Sicherung und Wiederherstellung dieser Daten. Die Verwendung von Tools wie Velero ist ein Beispiel für plattformspezifischen Betrieb, durch den die Betriebsbaseline erweitert wird.
    • Werden Zustandsinformationen in Ihrem Portfolio von Anwendungen auf inkonsistente Weise angewendet, sollte das zentrale Betriebsteam nicht beide Lösungen beibehalten. Erstellen Sie stattdessen einen Standard für den gewünschten Zustand der Toolkette für alle Container, und übertragen Sie gleichzeitig den Workloadbetriebsteams die Zuständigkeit für alternative Wiederherstellungslösungen. Auf diese Weise behalten die Entwickler ihre Freiheit beim Entwurfsdesign, die zentralen Kosten bleiben gering und es entsteht ein Anreiz für Workloadteams zur Kostensenkung durch Erfüllen des Standards.

Workloadbetrieb

Im Abschnitt zum Plattformbetrieb oben werden gängige Fragen zur Verwaltung von AKS-Clustern aufgezeigt. Sind Kubernetes-Cluster eine Technologieplattform, die zentral verwaltet werden soll? Oder handelt es sich dabei um ein Workloadtool, das von den Teams verwaltet werden soll, die die einzelnen Workloads besitzen? Diese Frage wird in unterschiedlichen Organisationen unterschiedlich beantwortet. Was jedoch auf die meisten Organisationen zutrifft, ist der Wunsch, dass Container und AKS so konzipiert werden, dass Workloadteams die einzelnen Workloads flexibler betreiben können. Außerdem sollen für diese Workloads bestimmte Features bereitgestellt werden, die in deren Architektur zum Vorteil der Anwendungsbesitzer und -kunden genutzt werden können.

Der Workloadbetrieb kann auf Ihrer vorhandenen Betriebsbaseline und dem plattformspezifischen Betrieb aufbauen. Sie können einen AKS-Cluster auch über einen vollständig dezentralisierten Workloadbetrieb sicher betreiben. In beiden Fällen gilt: Wenn Sie den Betrieb zur Konzentration auf bestimmte Ergebnisse für eine bestimmte Workload erhöhen müssen, können Sie das Azure Well-Architected Framework​ und die Microsoft Azure Well-Architected-Bewertung nutzen. Damit können Sie die Typen der Betriebsprozesse und die für die Workload zu nutzenden Tools sehr genau festlegen.

Nächster Schritt: Ihr nächster Migrationsdurchlauf

Nachdem die Migration der modernen Anwendungsplattform abgeschlossen ist, kann das Cloudeinführungsteam mit der nächsten szenariospezifischen Migration beginnen. Wenn Sie zusätzliche Plattformen migrieren möchten, können Sie für die nächste Migration oder Bereitstellung von modernen Anwendungsplattformen nochmals auf diese Artikelreihe zurückgreifen.