Überlegungen zur Ressourcenorganisation für AKS (optional)
Die Überlegungen zur Ressourcenorganisation werden größtenteils von der Plattformumgebung verwaltet. Im Anschluss finden Sie jedoch einige Möglichkeiten, wie sich die Plattformumgebung auf den AKS-Zielzonenbeschleuniger auswirken könnte.
Der gesamte Abonnement- und Ressourcengruppenentwurf, der durch allgemeine Empfehlungen für Zielzonen auf Unternehmensebene bestimmt wird, spielt eine grundlegende Rolle bei der Art und Weise, wie die AKS-Ressourcenorganisation verwaltet wird. Wie unter Organisation von Verwaltungsgruppen und Abonnements beschrieben, werden Verwaltungsgruppen und Abonnements verwendet, um den diesen untergeordneten Ressourcen Richtlinien zuzuweisen, und Abonnements stellen die Verwaltungsgrenze für Governance und Isolation von Ressourcen dar.
Wenn Sie beispielsweise über öffentliche und private Anwendungen verfügen, teilen Sie sie auf verschiedene Abonnements mit den Namen Corp
und Online
auf, und weisen Sie den Abonnements verschiedene Richtlinien zu. Die Corp
-Abonnements verfügen über Richtlinien, die die Erstellung öffentlicher IP-Adressen verhindern. Die Online
-Abonnements lassen Internetkonnektivität zu. Weitere Informationen zu den auf den einzelnen Ebenen im Entwurf einer Zielzone im Unternehmensmaßstab angewendeten Richtlinien, einschließlich der AKS-spezifischen Richtlinien, finden Sie unter Richtlinien in Referenzimplementierungen für Zielzonen im Unternehmensmaßstab.
Überlegungen zum Entwurf
Entscheiden Sie, wer für die Verwaltung der Containerhosts zuständig ist:
Wenn die Hosts zentral verwaltet werden, können Sie die Anzahl von Zielzoneninstanzen reduzieren und Entwickler anweisen, bei der Bereitstellung von Hosts definierte Prozesse zu verwenden sowie gemeinsame Dashboards und Warnungen für Vorgänge auf Workloadebene zu nutzen.
Wenn Workloadteams die Hosts verwalten, benötigen Sie mehr Zielzoneninstanzen für die Segmentierung der Hostumgebungen, damit die Workloadteams ihre Bereitstellungen entsprechend steuern können.
In beiden Fällen weiten Sie diese Überlegung auf angrenzende und verwandte Ressourcen wie Web Application Firewalls, Schlüsseltresore, Pipelineerstellungs-Agents und ggf. auch auf Jumpboxen aus.
Wählen Sie ein Mandantenmodell für Cluster aus:
Workload-betriebener, einzelner Mandant: Ein einzelner Clusterhost, der eine einzelne Workload unterstützt, benötigt wahrscheinlich eine dedizierte Zielzone, um eine Segmentierung und Steuerung durch die Workloadteams zu ermöglichen.
Zentral betriebene, mehrinstanzenfähige Hosts: Wenn Hosts zentral verwaltet werden, ergibt sich ihre betriebliche Effizienz aus der Konsolidierung mehrerer Hosts und mehrerer Workloads in geteilten Zielzonenumgebungen. Durch diese Konsolidierung wird die Anzahl von Zielzonen und Hosts reduziert, die für die Unterstützung eines einzelnen Clusters oder einer einzelnen Workload reserviert sind.
Möglicherweise sind zusätzliche Zielzonen erforderlich, wenn bei der Segmentierung eine Aufteilung nach Region, Geschäftseinheit, Umgebung, Wichtigkeit oder anderen externen Einschränkungen erfolgen muss.
Zentral betriebener, einzelner Mandant: Es ist üblich, für schädliche oder regulierte Workloads, die weiterhin zentral betrieben werden, dedizierte Hosts zu verwenden. Möglicherweise können Sie die betriebliche Effizienz jedoch auch weiterhin erhalten, wenn Sie die unterstützenden Zielzonen konsolidieren.
Wählen Sie auf Grundlage der allgemeinen Skalierung und Ausrichtung von Umgebungen und Hosts, die insgesamt zur Unterstützung der Portfolioanforderungen erforderlich sind, eine Verwaltungsgruppenhierarchie aus:
- Flache Struktur zur Unterstützung vieler dedizierter Hosts in dedizierten Umgebungen für dezentralisierte Vorgänge, die von jedem Workloadteam ausgeführt werden.
- Segmentierte Struktur zur Erstellung einer Verwaltungsgruppe für zentral verwaltete Hosts und einer separaten Verwaltungsgruppe für dezentralisierte Vorgänge.
- Hierarchische Struktur, durch die Umgebungen weiter segmentiert werden, um Abrechnungs-, Governance- oder Betriebsanforderungen besser widerzuspiegeln.
Entscheiden Sie, welche Topologie für Containerregistrierungen für die OCI-Artefaktverteilung verwendet werden soll:
- Eine Registrierung pro Workload.
- Eine Registrierung pro Cluster mit mehreren Workloads in der Registrierung.
- Eine Registrierung für alle Cluster in der Zielzone mit mehreren Workloads und Clustern in derselben Registrierung.
- Eine Registrierung für alle Cluster in mehreren Zielzonen mit mehreren Workloads und Clustern in derselben Registrierung.
Legen Sie den Bereich für Containerregistrierungsrichtlinien in Azure Policy fest:
- Erstellen Sie eine Richtlinie auf Abonnementebene, die festlegt, dass alle Hosts in der Zielzone die definierte Registrierung verwenden müssen.
- Erstellen Sie eine präzisere Richtlinie auf Ressourcengruppenebene.
- Erstellen Sie eine umfassendere Richtlinie auf Verwaltungsgruppenebene.
Entwurfsempfehlungen
- Definieren Sie einen Benennungs- und Markierungsstandard, der auf alle in Azure bereitgestellten Containerressourcen angewendet werden soll. Dieser sollte mindestens folgende Punkte umfassen:
- Workloadnamen: Identifizieren Sie die Workloads, die von jedem einzelnen Cluster unterstützt werden.
- Clusterressourcen: Identifizieren Sie die Erweiterung der Clusterressourcenausrichtung anhand der vorherigen Überlegungen.
- Betreiber des Hosts: Identifizieren Sie, welches Team für den Betrieb des Hosts verantwortlich ist.
- Workloadnamen: Identifizieren Sie die Workloads, die von jedem einzelnen Cluster unterstützt werden.
- Implementieren Sie eine Richtlinie, die eine bestimmte OCI-Artefaktregistrierung basierend auf der Topologie für Containerregistrierungen Ihrer Organisation erfordert.