Freigeben über

Steuern von Lösungen für moderne Anwendungsplattformen

  • Artikel

Das Cloud Adoption Framework bietet eine Methodik für die systematische und inkrementelle Verbesserung der Governance Ihres Cloudportfolios. In diesem Artikel wird veranschaulicht, wie Sie Ihre Governancestrategie auf Kubernetes-Cluster erweitern können, die in Azure oder anderen öffentlichen oder privaten Clouds bereitgestellt werden.

Anfängliche Governancegrundlage

Governance beginnt mit einer anfänglichen Governancegrundlage, die häufig als Governance-MVP bezeichnet wird. Diese Grundlage stellt die grundlegenden Azure-Produkte bereit, die Sie für die Governancebereitstellung in Ihrer Cloudumgebung benötigen.

Bei der anfänglichen Governancegrundlage liegt der Schwerpunkt auf den folgenden Aspekten:

  • Einfaches Hybridnetzwerk und -konnektivität
  • Rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) in Azure für Identität und Zugriffssteuerung
  • Standards für Benennung und Kennzeichnung zur konsistenten Identifizierung von Ressourcen
  • Organisation von Ressourcen mithilfe von Ressourcengruppen, Abonnements und Verwaltungsgruppen
  • Verwenden Sie Azure Policy, um Governancerichtlinien zu erzwingen.

Mit diesen Features der anfänglichen Governancegrundlage können Sie die Instanzen moderner Anwendungsplattformlösungen steuern. Bevor Sie Azure Policy auf Ihre Container anwenden können, müssen Sie der anfänglichen Grundlage jedoch einige Komponenten hinzufügen. Nach der Konfiguration können Sie mit Azure Policy und Ihrer anfänglichen Governancegrundlage die folgenden Containertypen steuern:

Erweitern auf Governancedisziplinen

Sie können die anfängliche Governancegrundlage auf verschiedene Governancedisziplinen erweitern, um für alle Kubernetes-Instanzen eine konsistente und stabile Bereitstellungsmethode sicherzustellen.

Die Governance von Kubernetes-Clustern kann aus fünf unterschiedlichen Perspektiven betrachtet werden.

Governance von Azure-Ressourcen

Die erste Perspektive betrifft Azure-Ressourcen. Es soll sichergestellt werden, dass alle Cluster den Anforderungen Ihrer Organisation entsprechen. Dies umfasst Konzepte wie Netzwerktopologie, private Cluster, RBAC-Rollen für SRE-Teams in Azure, Diagnoseeinstellungen, regionale Verfügbarkeit, Überlegungen zum Knotenpool, Governance von Azure Container Registry, Azure Load Balancer-Optionen, AKS-Add-Ons usw. Auf diese Weise erreichen Sie ein konsistentes Aussehen und Verhalten sowie eine konsistente Topologie der Cluster in Ihrer Organisation. Dies sollte auch das Bootstrapping nach der Clusterbereitstellung umfassen, wie etwa die Auswahl der zu installierenden Sicherheits-Agents und deren Konfiguration.

Snowflake-Cluster lassen sich in jeder zentralen Kapazität schwer steuern. Minimieren Sie Abweichungen zwischen den Clustern, damit Richtlinien gleichmäßig angewendet werden können und anomale Cluster erkannt und nicht verwendet werden. Dies kann auch Technologien zur Bereitstellung von Clustern umfassen, wie etwa ARM, Bicep oder Terraform.

Mit Azure Policy, angewendet auf der Ebene Verwaltungsgruppe/Abonnement, können Sie einige dieser Aspekte umsetzen, jedoch nicht alle.

Governance von Kubernetes-Workloads

Da es sich bei Kubernetes selbst um eine Plattform handelt, besteht die zweite Perspektive aus der Governance von Abläufen innerhalb eines Clusters. Dies umfasst beispielsweise Anleitungen zu Namespaces, Netzwerkrichtlinien, RBAC in Kubernetes, Grenzwerte und Kontingente. Dabei handelt es sich um Governance, die auf Workloads und nicht auf den Cluster angewendet wird. So wird jede Workload einzigartig, da alle Workloads jeweils unterschiedliche Geschäftsprobleme behandeln und auf unterschiedliche Weise mit unterschiedlichen Technologien implementiert werden. Dadurch gibt es möglicherweise kaum noch universell gültige Governancemethoden. Governance wird vielmehr bei der Erstellung/Nutzung von OCI-Artefakten, bei Anforderungen an die Lieferkette, der Nutzung von öffentlichen Containerregistrierungen, der Quarantäne von Images oder der Governance von Bereitstellungspipelines berücksichtigt.

Sie sollten ggf. auch die Standardisierung allgemeiner Tools und Muster erwägen. Stellen Sie Empfehlungen für Technologien wie Helm, Service Mesh, Eingangscontroller, GitOps-Operatoren, persistente Volumes usw. bereit. Dies schließt auch die Governance im Zusammenhang mit der Nutzung verwalteter Podidentitäten und der Ermittlung von Geheimnissen aus Key Vault mit ein.

Hohe Erwartungen bezüglich des Zugriffs auf Telemetriedaten sorgen dafür, dass Workloadbesitzer geeigneten Zugriff auf die Metriken und Daten erhalten, die sie zur Optimierung ihres Produkts benötigen. Gleichzeitig wird sichergestellt, dass Clusteroperatoren zur Verbesserung ihres Dienstangebots auf Systemtelemetriedaten zugreifen können. Da Daten häufig zwischen diesen beiden korreliert werden müssen, sollte der entsprechende Zugriff bei Bedarf mithilfe von Governancerichtlinien gewährleistet werden.

Mit Azure Policy für AKS, angewendet auf der Clusterebene, können Sie einige dieser Aspekte umsetzen, jedoch nicht alle.

Clusteroperator-Rollen (DevOps, SRE)

Die dritte Perspektive ist die Governance im Zusammenhang mit Clusteroperator-Rollen. Wie interagieren SRE-Teams mit Clustern? Welche Beziehung besteht zwischen diesen Teams und den Workloadteams? Sind sie identisch? Clusteroperatoren sollten über ein klar definiertes Playbook für die Selektierung von Clustern verfügen, wie etwa die Art des Zugriffs, den Zugriffsort, die Zugriffsberechtigungen auf die Cluster sowie die Zuweisung dieser Berechtigungen. Stellen Sie sicher, dass die Unterschiede zwischen Workloadoperator und Clusteroperator in diesem Kontext in der Governancedokumentation, in Richtlinien und Schulungsmaterial dargestellt werden. Je nach Organisation können diese auch identisch sein.

Cluster pro Workload vs. viele Workloads pro Cluster

Die vierte Perspektive umfasst die Governance bei mehreren Mandanten. Sollten Cluster ähnliche Anwendungen gruppieren, deren Besitzer per Definition ein einzelnes Workloadteam ist, und die eine einzelne Gruppe von verwandten Workloadkomponenten bilden? Oder sollten Cluster grundsätzlich mehrinstanzenfähig entworfen werden, über mehrere verschiedene Workloads und Workloadbesitzer verfügen und dabei wie ein verwaltetes Dienstangebot innerhalb der Organisation ausgeführt und verwaltet werden? Die Governancestrategien dieser beiden Möglichkeiten unterscheiden sich erheblich voneinander. Deshalb sollten Sie sicherstellen, dass die gewählte Strategie erzwungen wird. Müssen beide Modell unterstützt werden, stellen Sie sicher, dass im Governanceplan klar definiert ist, welche Richtlinien für welchen Clustertyp gelten.

Diese Auswahl sollten Sie bereits während der Strategiephase treffen, da sich daraus erhebliche Auswirkungen auf Personal, Budgetierung und Innovationen ergeben.

Sicherstellen des aktuellen Stands

Die fünfte Perspektive betrifft Vorgänge im Zusammenhang mit der Aktualität von Knotenimages (Patchen) und der Kubernetes-Versionsverwaltung. Wer ist zuständig für Upgrades von Knotenimages, die Nachverfolgung von angewendeten Patches sowie die Nachverfolgung und Erstellung von Wartungsplänen für Kubernetes- und AKS-Common Vulnerabilities and Exposures (CVEs, allgemeine Sicherheitslücken und Schwachstellen)? Workloadteams müssen an der Überprüfung ihrer Lösung für Clusterupgrades beteiligt sein. Sind die Cluster nicht aktuell, werden sie nicht mehr von Azure unterstützt. Eine starke Governance bezüglich der Maßnahmen zur Aufrechterhaltung der Aktualität ist in AKS wichtig – wichtiger als auf den meisten anderen Plattformen in Azure. Dafür ist eine sehr enge Arbeitsbeziehung mit den Anwendungsteams erforderlich sowie Arbeitszeit, die für die (mindestens monatliche) Überprüfung der Workloads reserviert wird, um die Aktualität der Cluster zu gewährleisten. Stellen Sie sicher, dass alle Teams mit einer Abhängigkeit von Kubernetes über die Anforderungen und Kosten dieses Aufwands informiert sind, der sich über die gesamte Nutzung der Plattform erstreckt.

Sicherheitsbaseline

Zur Erhöhung der Sicherheit Ihrer AKS-Cluster können Sie Ihrer Sicherheitsbaseline die folgenden bewährten Methoden hinzufügen:

Identity

Für eine konsistente Identitäts- und Zugriffsverwaltung für alle Kubernetes-Cluster können Sie die folgenden bewährten Methoden auf Ihre Identitätsbaseline anwenden:

Nächster Schritt: Verwalten von Lösungen für moderne Anwendungsplattformen

Die folgenden Artikel enthalten Anleitungen zu bestimmten Aspekten des Cloudeinführungsprozesses, die Ihnen dabei helfen sollen, das Cloudeinführungsszenario erfolgreich abzuschließen.