Baselinearchitektur für einen AKS-Cluster (Azure Kubernetes Service)

Application Gateway
Container Registry
Firewall
Kubernetes-Dienst
Rollenbasierte Zugriffssteuerung in Azure

In dieser Referenzarchitektur wird eine grundlegende Infrastruktur zum Bereitstellen eines AKS-Clusters (Azure Kubernetes Service) erstellt. Dieser Artikel enthält Empfehlungen für Netzwerk, Sicherheit, Identität, Verwaltung und Überwachung des Clusters basierend auf den Geschäftsanforderungen einer Organisation.

GitHub logo Eine Implementierung dieser Architektur ist hier verfügbar: GitHub: Sichere Baselinereferenzimplementierung von Azure Kubernetes Service (AKS). Sie können diese als Startpunkt verwenden und gemäß Ihren Anforderungen konfigurieren.

Hinweis

Diese Referenzarchitektur erfordert Kenntnisse über Kubernetes und die entsprechenden Konzepte. Wenn Sie Ihr Wissen auffrischen müssen, finden Sie entsprechende Ressourcen unter Verwandte Artikel.

Netzwerktopologie

Bei dieser Architektur wird eine Hub-Spoke-Netzwerktopologie verwendet. Der Hub und die Spokes werden in separaten virtuellen Netzwerken bereitgestellt, die per Peering verbunden sind. Diese Topologie bietet u. a. folgende Vorteile:

  • Getrennte Verwaltung. Sie ermöglicht das Anwenden von Governance und das Steuern des Auswirkungsgrads. Außerdem wird das Konzept der Zielzone mit Aufgabentrennung unterstützt.

  • Minimieren der direkten Verfügbarkeit von Azure-Ressourcen über das öffentliche Internet.

  • Organisationen verwenden häufig regionale Hub-Spoke-Topologien. Hub-Spoke-Netzwerktopologien können in der Zukunft erweitert werden und Workloadisolation erreichen.

  • Alle Webanwendungen sollten einen WAF-Dienst (Web Application Firewall) voraussetzen, der die Steuerung von HTTP-Datenverkehrsflüssen unterstützt.

  • Sie stellt die natürliche Wahl für Workloads dar, die mehrere Abonnements umfassen.

  • Die Architektur bleibt erweiterbar. Um neue Features oder Workloads zu ermöglichen, können neue Spokes hinzugefügt werden, anstatt die Netzwerktopologie komplett neu zu entwerfen.

  • Bestimmte Ressourcen, z. B. eine Firewall und DNS, können über mehrere Netzwerke hinweg gemeinsam genutzt werden.

Hub-spoke network topology

Hub

Der Hub des virtuellen Netzwerks ist der zentrale Punkt für Konnektivität und Einblicke. Innerhalb des Netzwerks werden drei Subnetze bereitgestellt.

Subnetz zum Hosten von Azure Firewall

Azure Firewall ist eine Firewall, die als Dienst bereitgestellt wird. Die Firewallinstanz schützt den ausgehenden Netzwerkdatenverkehr. Ohne diese Sicherheitsebene kann der Datenfluss mit einem böswilligen Drittanbieterdienst kommunizieren, der vertrauliche Unternehmensdaten herausfiltern könnte.

Subnetz zum Hosten eines Gateways

Dieses Subnetz ist ein Platzhalter für ein VPN- oder ExpressRoute-Gateway. Das Gateway stellt Verbindungen zwischen den Routern im lokalen Netzwerk und dem virtuellen Netzwerk bereit.

Subnetz zum Hosten von Azure Bastion

Dieses Subnetz ist ein Platzhalter für Azure Bastion. Sie können Bastion für den sicheren Zugriff auf Azure-Ressourcen verwenden, ohne die Ressourcen im Internet verfügbar zu machen. Dieses Subnetz wird nur für die Verwaltung und den Betrieb genutzt.

Spoke

Das virtuelle Netzwerk am Spoke enthält den AKS-Cluster und andere zugehörige Ressourcen. Der Spoke verfügt über drei Subnetze:

Subnetz zum Hosten von Azure Application Gateway

AzureApplication Gateway ist ein Lastenausgleich für Webdatenverkehr, der auf Schicht 7 betrieben wird. Bei der Referenzimplementierung wird die Application Gateway v2-SKU verwendet, die Web Application Firewall (WAF) aktiviert. WAF schützt eingehenden Datenverkehr vor gängigen Angriffen auf Webdatenverkehr. Die Instanz verfügt über eine öffentliche IP-Konfiguration am Front-End, das die Benutzeranforderungen empfängt. Für Application Gateway ist standardmäßig ein dediziertes Subnetz erforderlich.

Subnetz zum Hosten der Eingangsressourcen

Zum Weiterleiten und Verteilen von Datenverkehr wird Traefik als Eingangscontroller verwendet, der die Kubernetes-Eingangsressourcen bedient. Dieses Subnetz enthält interne Azure-Lastenausgleiche.

Subnetz zum Hosten der Clusterknoten

AKS verwaltet zwei separate Knotengruppen (oder Knotenpools). Der Systemknotenpool hostet Pods, die die Hauptclusterdienste ausführen. Der Benutzerknotenpool führt die Workloads von Contoso und den Eingangscontroller aus, um die eingehende Kommunikation mit der Workload zu ermöglichen. Die Workload ist eine einfache ASP.NET-Anwendung.

Weitere Informationen finden Sie unter Hub-Spoke-Netzwerktopologie in Azure.

Private Link-Verbindungen werden für Azure Container Registry und Azure Key Vault erstellt, damit über private Endpunkte innerhalb des virtuellen Spoke-Netzwerks auf diese Dienste zugegriffen werden kann. Private Link-Endpunkte benötigen kein dediziertes Subnetz und können auch im virtuellen Hub-Netzwerk platziert werden. In der Baselineimplementierung werden sie in einem dedizierten Subnetz innerhalb des virtuellen Spoke-Netzwerks bereitgestellt. Dadurch muss weniger Datenverkehr über die Peeringnetzwerkverbindung abgewickelt werden, die zum Cluster gehörenden Ressourcen befinden sich im gleichen virtuellen Netzwerk, und Sie können mithilfe von Netzwerksicherheitsgruppen präzise Sicherheitsregeln auf Subnetzebene anwenden.

Weitere Informationen finden Sie unter Entscheidungsstruktur für die Private Link-Bereitstellung.

Planen der IP-Adressen

Network topology of the AKS cluster

Der Adressraum des virtuellen Netzwerks sollte groß genug sein, um alle Subnetze aufnehmen zu können. Berücksichtigen Sie alle Entitäten, die Datenverkehr empfangen. Die IP-Adressen für diese Entitäten werden aus dem Adressraum des Subnetzes zugewiesen. Beachten Sie die folgenden Punkte.

  • Aktualisieren

    AKS aktualisiert Knoten regelmäßig, um sicherzustellen, dass die Sicherheitsfeatures und andere Systempatches der zugrunde liegenden virtuellen Computer auf dem neuesten Stand sind. Während eines Upgradevorgangs erstellt AKS einen Knoten, der die Pods temporär hostet, während der Upgradeknoten gesperrt und entladen wird. Diesem temporären Knoten wird eine IP-Adresse aus dem Clustersubnetz zugewiesen.

    Für Pods benötigen Sie abhängig von Ihrer Strategie möglicherweise weitere Adressen. Für rollierende Updates benötigen Sie Adressen für die temporären Pods, die die Workloads ausführen, während die eigentlichen Pods aktualisiert werden. Wenn Sie die Ersetzungsstrategie verwenden, werden Pods entfernt und die neuen erstellt. Daher werden die Adressen, die den alten Pods zugeordnet sind, wiederverwendet.

  • Skalierbarkeit

    Berücksichtigen Sie die Knotenanzahl aller System- und Benutzerknoten sowie deren maximale Skalierbarkeitsgrenzwerte. Angenommen, Sie möchten um 400 % aufskalieren. Für alle horizontal skalierten Knoten benötigen Sie die vierfache Anzahl von Adressen.

    In dieser Architektur kann jeder Pod direkt kontaktiert werden. Daher benötigt jeder Pod eine eigene Adresse. Die Podskalierbarkeit wirkt sich auf die Adressberechnung aus. Diese Entscheidung hängt von der ausgewählten Anzahl von Pods ab, auf die Sie vergrößern möchten.

  • Adressen für Azure Private Link

    Der Faktor für Adressen, die für die Kommunikation mit anderen Azure-Diensten über Private Link erforderlich sind. In dieser Architektur sind den Links zu Azure Container Registry und Key Vault zwei Adressen zugewiesen.

  • Bestimmte Adressen sind für die Verwendung durch Azure reserviert. Sie können nicht zugewiesen werden.

Die obige Liste ist nicht vollständig. Wenn Ihr Entwurf andere Ressourcen aufweist, die sich auf die Anzahl der verfügbaren IP-Adressen auswirken, sollten Sie diese Adressen einplanen.

Diese Architektur ist für eine einzelne Workload konzipiert. Bei mehreren Workloads können Sie die Benutzerknotenpools voneinander und vom Systemknotenpool isolieren. Dies kann zu mehr Subnetzen führen, die jeweils kleiner sind. Außerdem ist die Eingangsressource möglicherweise komplexer. Möglicherweise benötigen Sie mehrere Eingangscontroller, die zusätzliche Adressen erfordern.

Alle Überlegungen zu dieser Architektur finden Sie unter AKS baseline Network Topology (AKS-Baseline-Netzwerktopologie).

Informationen zum Planen der IP-Adressen für einen AKS-Cluster finden Sie unter Planen der IP-Adressierung für Ihren Cluster.

Containerimageverweis

Neben der Workload enthält der Cluster möglicherweise mehrere andere Images, z. B. den Eingangsdatencontroller. Einige dieser Images befinden sich möglicherweise in öffentlichen Registrierungen. Berücksichtigen Sie die folgenden Punkte, wenn Sie diese Images in Ihren Cluster pullen:

  • Der Cluster ist dazu berechtigt, das Image zu pullen.

  • Wenn Sie ein öffentliches Image verwenden, empfiehlt es sich, dieses in eine Containerregistrierung zu importieren, die Ihrem SLO entspricht. Andernfalls unterliegt das Image möglicherweise unerwarteten Verfügbarkeitsproblemen. Dadurch können Betriebsprobleme entstehen, da das Image nicht verfügbar ist, wenn Sie es benötigen. Im Folgenden werden einige Vorteile der Verwendung Ihrer Containerregistrierung anstelle einer öffentlichen Registrierung aufgeführt:

    • Sie können den nicht autorisierten Zugriff auf Ihre Images blockieren.
    • Es liegen keine öffentlichen Abhängigkeiten vor.
    • Sie können auf Imagepullprotokolle zugreifen, um Aktivitäten zu überwachen und Konnektivitätsprobleme zu selektieren.
    • Sie profitieren von integrierter Containerüberwachung und Imagekonformität.

    Eine Option ist Azure Container Registry (ACR).

  • Damit können Sie Images aus autorisierten Registrierungen pullen. Sie können diese Einschränkung über Azure Policy erzwingen. In dieser Referenzimplementierung pullt der Cluster nur Images aus der ACR-Instanz, die als Teil der Architektur bereitgestellt wurde.

Konfigurieren der Computeressourcen für den Basiscluster

In AKS ist jeder Knotenpool einer VM-Skalierungsgruppe zugeordnet. Knoten sind VMs in jedem Knotenpool. Verwenden Sie ggf. eine geringere VM-Größe für den Systemknotenpool, um die Kosten zu minimieren. Diese Referenzimplementierung stellt den Systemknotenpool mit drei DS2_v2-Knoten bereit. Diese Größe reicht aus, um die erwartete Last der Systempods zu erfüllen. Der Betriebssystemdatenträger ist 512 GB groß.

Im Folgenden finden Sie einige Überlegungen zum Benutzerknotenpool:

  • Wählen Sie größere Knoten aus, um die maximale Anzahl der auf einem Knoten festgelegten Pods zu unterstützen. Dadurch wird der Speicherbedarf von Diensten minimiert, die auf allen Knoten ausgeführt werden, z. B. Überwachung und Protokollierung.

  • Stellen Sie mindestens zwei Knoten bereit. Auf diese Weise wird für die Workload ein Hochverfügbarkeitsmuster mit zwei Replikaten verwendet. Mit AKS können Sie die Knotenanzahl ändern, ohne den Cluster neu zu erstellen.

  • Die tatsächlichen Knotengrößen für Ihre Workload sind von den Anforderungen abhängig, die vom Entwurfsteam festgelegt werden. Basierend auf den Geschäftsanforderungen haben wir für die Produktionsworkload DS4_v2 ausgewählt. Um die Kosten zu senken, können Sie die Größe auf DS3_v2 verringern. Dies ist auch die minimale Empfehlung.

  • Wenn Sie die Kapazität für Ihren Cluster planen, gehen Sie davon aus, dass die Workload bis zu 80 % auf den einzelnen Knoten verbrauchen kann. Die verbleibenden 20 % sind für AKS-Dienste reserviert.

  • Legen Sie basierend auf Ihrer Kapazitätsplanung die maximale Anzahl von Pods pro Knoten fest. Wenn Sie versuchen, eine Kapazitätsbaseline einzurichten, beginnen Sie mit dem Wert 30. Passen Sie diesen Wert gemäß den Anforderungen der Workload, der Knotengröße und der IP-Einschränkungen an.

Integrieren von Azure Active Directory für den Cluster

Das Schützen des Zugriffs auf den Cluster und aus diesem heraus ist sehr wichtig. Treffen Sie Entscheidungen hinsichtlich der Sicherheit aus der Perspektive des Clusters:

  • Zugriff von innen: AKS-Zugriff auf Azure-Komponenten wie Netzwerkinfrastruktur, Azure Container Registry und Azure Key Vault. Autorisieren Sie nur solche Ressourcen, auf die der Cluster zugreifen darf.
  • Zugriff von außen: Bereitstellen von Kubernetes-Clusterzugriff für Identitäten. Autorisieren Sie nur externe Entitäten, denen der Zugriff auf den Kubernetes-API-Server und Azure Resource Manager gestattet ist.

AKS-Zugriff auf Azure

Der Zugriff von AKS auf Azure über Azure Active Directory (Azure AD) kann auf zwei Arten verwaltet werden: über Dienstprinzipale oder über verwaltete Identitäten für Azure-Ressourcen.

Von diesen beiden Möglichkeiten werden verwaltete Identitäten empfohlen. Mit Dienstprinzipalen sind Sie für das Verwalten und Rotieren von Geheimnissen zuständig, das manuell oder programmgesteuert erfolgen kann. Bei verwalteten Identitäten übernimmt Azure AD die Verwaltung und Ausführung von Authentifizierung und rechtzeitiger Rotation der Geheimnisse für Sie.

Es wird empfohlen, verwaltete Identitäten zu aktivieren, damit der Cluster über Azure AD mit externen Azure-Ressourcen interagieren kann. Sie können diese Einstellung nur während der Clustererstellung aktivieren. Auch wenn Azure AD nicht sofort verwendet wird, können Sie es später integrieren.

Betrachten wir als Beispiel für den Zugriff von innen unter Verwendung verwalteter Identitäten den Fall, dass der Cluster Images aus einer Containerregistrierung pullen muss. Für diese Aktion muss der Cluster die Anmeldeinformationen der Registrierung abrufen. Eine Möglichkeit besteht darin, diese Informationen in Form eines Kubernetes-Geheimnisobjekts zu speichern und mit imagePullSecrets abzurufen. Diese Vorgehensweise wird aufgrund der hohen Komplexität bei der Sicherheit nicht empfohlen. Sie müssen nicht nur vorab das Geheimnis kennen, sondern dieses auch über die DevOps-Pipeline offenlegen. Ein weiterer Grund ist der betriebliche Mehraufwand für die Verwaltung der Rotation des Geheimnisses. Erteilen Sie stattdessen der verwalteten Identität Ihres Clusters das Zugriffsrecht acrPull für Ihre Registrierung. Mit diesem Ansatz werden beide Probleme behandelt.

In dieser Architektur greift der Cluster auf Azure-Ressourcen zu, die durch Azure AD geschützt sind und Vorgänge ausführen, die verwaltete Identitäten unterstützen. Weisen Sie den verwalteten Identitäten des Clusters über die rollenbasierte Zugriffssteuerung in Azure (Azure Role-Based Access Control, Azure RBAC) Berechtigungen basierend auf den Vorgängen zu, die der Cluster ausführen soll. Der Cluster authentifiziert sich bei Azure AD und erhält dann entsprechend den zugewiesenen Rollen Zugriff, oder der Zugriff wird verweigert. Im Folgenden finden Sie einige Beispiele aus dieser Referenzimplementierung, bei denen dem Cluster in Azure integrierte Rollen zugewiesen wurden:

  • Netzwerkmitwirkender: Ermöglicht dem Cluster das Steuern des virtuellen Spoke-Netzwerks. Diese Rollenzuweisung ermöglicht der dem AKS-Cluster vom System zugewiesenen Identität, im dedizierten Subnetz für die internen Eingangscontrollerdienste zu arbeiten.
  • Herausgeber von Überwachungsmetriken: Ermöglicht dem Cluster das Senden von Metriken an Azure Monitor.
  • AcrPull: Ermöglicht dem Cluster das Pullen von Images aus den angegebenen Azure Container Registry-Instanzen.

Clusterzugriff

Die Azure AD-Integration vereinfacht auch die Sicherheitskonfiguration für den externen Zugriff. Angenommen, ein Benutzer möchte kubectl verwenden. Als ersten Schritt sendet er den Befehl az aks get-credentials, um die Anmeldeinformationen des Clusters zu erhalten. Azure AD authentifiziert die Identität des Benutzers anhand der Azure-Rollen, die zum Abrufen von Clusteranmeldeinformationen berechtigt sind. Weitere Informationen finden Sie unter Verfügbare Clusterrollenberechtigungen.

AKS ermöglicht Kubernetes-Zugriff mithilfe von Azure Active Directory auf zwei Arten: Bei der ersten wird Azure Active Directory als Identitätsanbieter verwendet, der in das native Kubernetes RBAC-System integriert ist. Bei der anderen wird die native Azure RBAC zum Steuern des Clusterzugriffs verwendet. Beide werden nachfolgend beschrieben.

Zuordnen von Kubernetes-RBAC zu Azure Active Directory

Kubernetes unterstützt die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) wie folgt:

  • Ein Satz von Berechtigungen. Dieser wird durch ein Role- oder ClusterRole-Objekt für clusterweite Berechtigungen definiert.

  • Bindungen zum Zuweisen der Benutzer und Gruppen, die die Aktionen ausführen dürfen. Diese werden durch ein RoleBinding- oder CluserRoleBinding-Objekt definiert.

Kubernetes verfügt über einige integrierte Rollen wie „cluster-admin“, „edit“, „view“ usw. Binden Sie diese Rollen an Azure Active Directory-Benutzer und -Gruppen, um den Zugriff über das Unternehmensverzeichnis zu verwalten. Weitere Informationen finden Sie unter Verwenden der rollenbasierten Zugriffssteuerung von Kubernetes mit Azure AD-Integration.

Stellen Sie sicher, dass Ihre Azure AD-Gruppen, die für den Cluster- und Namespacezugriff verwendet werden, in Ihren Azure AD-Zugriffsüberprüfungen enthalten sind.

Verwenden von Azure RBAC für die Kubernetes-Autorisierung

Anstatt native Kubernetes-RBAC (ClusterRoleBindings und RoleBindings) zur Autorisierung mit integrierter ADD-Authentifizierung zu verwenden, können Sie Azure RBAC und Azure-Rollenzuweisungen verwenden, um Autorisierungsprüfungen für den Cluster zu erzwingen. Diese Rollenzuweisungen können sogar im Abonnement- oder Ressourcengruppenbereich hinzugefügt werden. Dadurch erben alle Cluster im Bereich einheitliche Rollenzuweisungen in Bezug auf die Zugriffsberechtigungen auf die Objekte im Kubernetes-Cluster.

Weitere Informationen finden Sie unter Verwenden von Azure RBAC für die Kubernetes-Autorisierung.

Lokale Konten

AKS unterstützt die native Kubernetes-Benutzerauthentifizierung. Der Benutzerzugriff auf Cluster mithilfe dieser Methode wird nicht empfohlen. Sie ist zertifikatsbasiert und wird außerhalb Ihres primären Identitätsanbieters ausgeführt. Dies erschwert eine zentrale Benutzerzugriffssteuerung und -verwaltung. Verwalten Sie den Zugriff auf Ihren Cluster immer über Azure Active Directory, und konfigurieren Sie Ihren Cluster so, dass der lokale Kontozugriff explizit deaktiviert wird.

In dieser Referenzimplementierung wird der Zugriff über lokale Clusterkonten bei der Bereitstellung des Clusters explizit deaktiviert.

Integrieren von Azure Active Directory für die Workload

Ähnlich wie bei verwalteten Azure-Identitäten für den gesamten Cluster können Sie verwaltete Identitäten auch auf Podebene zuweisen. Eine verwaltete Identität für den Pod ermöglicht der gehosteten Workload den Zugriff auf Ressourcen über Azure Active Directory. Beispielsweise speichert die Workload Dateien in Azure Storage. Wenn auf diese Dateien zugegriffen werden muss, authentifiziert sich der Pod selbst bei der Ressource.

In dieser Referenzimplementierung werden verwaltete Podidentitäten durch Azure AD-Podidentitäten umgesetzt.

Bereitstellen von Eingangsressourcen

Kubernetes-Eingangsressourcen leiten den eingehenden Datenverkehr an den Cluster weiter und verteilen ihn. Es gibt zwei Kategorien von Eingangsressourcen:

  • Interner Lastenausgleich Verwaltung durch AKS. Dieses Lastenausgleichsmodul macht den Eingangscontroller über eine private statische IP-Adresse verfügbar. Es dient als einziger Kontaktpunkt, der eingehende Datenflüsse empfängt.

    In dieser Architektur wird Azure Load Balancer verwendet. Der Lastenausgleich befindet sich außerhalb des Clusters in einem dedizierten Subnetz für Eingangsressourcen. Er empfängt Datenverkehr von Azure Application Gateway, wobei die Kommunikation über TLS erfolgt. Weitere Informationen zur TLS-Verschlüsselung für eingehenden Datenverkehr finden Sie unter Eingehender Datenverkehrsfluss.

  • Eingangscontroller. Wir haben uns für Traefik entschieden. Er wird im Benutzerknotenpool im Cluster ausgeführt. Er empfängt Datenverkehr vom internen Lastenausgleich, schließt TLS ab und leitet ihn über HTTP an die Workloadpods weiter.

Der Eingangscontroller ist eine wichtige Komponente des Clusters. Beachten Sie die folgenden Punkte, wenn Sie diese Komponente konfigurieren.

  • Wählen Sie im Rahmen Ihrer Entwurfsentscheidungen einen Bereich aus, in dem der Eingangscontroller zugelassen ist. Beispielsweise können Sie zulassen, dass der Controller nur mit den Pods interagiert, die eine bestimmte Workload ausführen.

  • Vermeiden Sie das Platzieren von Replikaten auf demselben Knoten, um die Last zu verteilen und Geschäftskontinuität zu gewährleisten, wenn ein Knoten ausfällt. Verwenden Sie zu diesem Zweck podAntiAffinity.

  • Beschränken Sie die zu planenden Pods auf den Benutzerknotenpool, indem Sie nodeSelectorsverwenden. Mit dieser Einstellung werden Workload- und Systempods isoliert.

  • Öffnen Sie Ports und Protokolle, die bestimmten Entitäten das Senden von Datenverkehr an den Eingangscontroller ermöglichen. In dieser Architektur empfängt Traefik nur Datenverkehr von Azure Application Gateway.

  • Der Eingangscontroller sollte Signale senden, die die Integrität der Pods angeben. Konfigurieren Sie die Einstellungen readinessProbe und livenessProbe, mit denen die Integrität der Pods im angegebenen Intervall überwacht wird.

  • Beschränken Sie den Zugriff des Eingangsdatencontrollers auf bestimmte Ressourcen und auf die Ausführung bestimmter Aktionen. Diese Einschränkung kann über RBAC-Berechtigungen in Kubernetes implementiert werden. In dieser Architektur wurden Traefik z. B. mithilfe von Regeln im Kubernetes-Objekt ClusterRole Berechtigungen zum Überwachen, Abrufen und Auflisten von Diensten und Endpunkten erteilt.

Hinweis

Die Wahl des geeigneten Eingangsdatencontrollers richtet sich nach den Anforderungen der Workload, den Fähigkeiten des Bedieners und der Unterstützungsfähigkeit der Technologieoptionen. Am wichtigsten ist die Fähigkeit, Ihre SLO-Erwartung zu erfüllen.

Traefik ist eine beliebte Open-Source-Option für einen Kubernetes-Cluster, die in dieser Architektur zur Veranschaulichung ausgewählt wurde. Gezeigt wird die Integration von Drittanbieterprodukten in Azure-Dienste. Die Implementierung zeigt z. B. die Integration von Traefik in eine verwaltete Azure AD-Podidentität und Azure Key Vault.

Eine weitere Möglichkeit ist der Eingangsdatencontroller von Azure Application Gateway, der auch gut in AKS integriert ist. Neben den Funktionen als Eingangsdatencontroller bietet er weitere Vorteile. Beispielsweise unterstützt Application Gateway den Einstiegspunkt des virtuellen Netzwerks Ihres Clusters. Das bedeutet, dass der in den Cluster eingehende Datenverkehr beobachtet werden kann. Wenn Sie über eine Anwendung verfügen, die WAF erfordert, ist Application Gateway eine gute Wahl, da es in WAF integriert ist. Außerdem bietet es die Möglichkeit, einen TLS-Abschluss durchzuführen.

Routereinstellungen

Der Eingangscontroller verwendet Routen, um das Ziel von Datenverkehr zu bestimmen. Routen geben den Quellport an, an dem der Datenverkehr empfangen wurde, sowie Informationen zu den Zielports und Protokollen.

Im Folgenden finden Sie ein Beispiel aus dieser Architektur:

Traefik verwendet den Kubernetes-Anbieter, um Routen zu konfigurieren. annotations, tls und entrypoints geben an, dass Routen über HTTPS bedient werden. middlewares gibt an, dass nur Datenverkehr aus dem Subnetz von Azure Application Gateway zulässig ist. Für die Antworten wird Gzip-Codierung verwendet, sofern der Client diese akzeptiert. Da Traefik den TLS-Anschluss ausführt, erfolgt die Kommunikation mit den Back-End-Diensten über HTTP.

apiVersion:networking.k8s.io/v1
kind: Ingress
metadata:
  name: aspnetapp-ingress
  namespace: a0008
  annotations:
    kubernetes.io/ingress.allow-http: "false"
    kubernetes.io/ingress.class: traefik-internal
    traefik.ingress.kubernetes.io/router.entrypoints: websecure
    traefik.ingress.kubernetes.io/router.tls: "true"
    traefik.ingress.kubernetes.io/router.tls.options: default
    traefik.ingress.kubernetes.io/router.middlewares: app-gateway-snet@file, gzip-compress@file
spec:
  tls:
  - hosts:
      - bu0001a0008-00.aks-ingress.contoso.com
  rules:
  - host: bu0001a0008-00.aks-ingress.contoso.com
    http:
      paths:
      - path: /
        backend:
          service:
            name: aspnetapp-service
            port: 
              name: http

Schützen des Datenflusses im Netzwerk

Der Netzwerkdatenfluss kann in diesem Kontext wie folgt kategorisiert werden:

  • Eingehender Datenverkehr: Vom Client zu der im Cluster ausgeführten Workload.

  • Ausgehender Datenverkehr: Von einem Pod oder Knoten im Cluster zu einem externen Dienst.

  • Datenverkehr zwischen Pods: Für die Kommunikation zwischen den Pods. Dieser Datenverkehr umfasst die Kommunikation zwischen dem Eingangscontroller und der Workload. Wenn Ihre Workload mehrere Anwendungen umfasst, die im Cluster bereitgestellt wurden, würde auch die Kommunikation zwischen diesen Anwendungen in diese Kategorie fallen.

  • Verwaltungsdatenverkehr: Der Datenverkehr zwischen dem Client und dem Kubernetes-API-Server.

Cluster traffic flow

Diese Architektur verfügt über mehrere Sicherheitsebenen, um alle Arten von Datenverkehr zu schützen.

Eingehender Datenverkehrsfluss

Die Architektur akzeptiert nur mit TLS verschlüsselte Anforderungen vom Client. TLS v1.2 ist die minimal zulässige Version, die einen eingeschränkten Satz von Chiffren umfasst. Für die Servernamensanzeige (SNI) ist „strict“ aktiviert. End-to-End-TLS wird über Application Gateway eingerichtet, wobei zwei verschiedene TLS-Zertifikate verwendet werden, wie in dieser Abbildung dargestellt.

TLS termination

  1. Der Client sendet eine HTTPS-Anforderung an den Domänennamen: bicycle.contoso.com. Dieser Name wird über einen DNS-A-Datensatz der öffentlichen IP-Adresse von Azure Application Gateway zugeordnet. Dieser Datenverkehr wird verschlüsselt, um sicherzustellen, dass der Datenverkehr zwischen dem Clientbrowser und dem Gateway nicht überprüft oder geändert werden kann.

  2. Application Gateway verfügt über eine integrierte Web Application Firewall (WAF) und handelt den TLS-Handshake für bicycle.contoso.com aus, sodass nur sichere Chiffren möglich sind. Application Gateway ist ein TLS-Abschlusspunkt, erzwingt die Verarbeitung von WAF-Überprüfungsregeln und führt Routingregeln aus, mit denen der Datenverkehr an das konfigurierte Back-End weitergeleitet wird. Das TLS-Zertifikat wird in Azure Key Vault gespeichert. Der Zugriff erfolgt über eine benutzerseitig zugewiesene verwaltete Identität, die in Application Gateway integriert ist. Weitere Informationen zu diesem Feature finden Sie unter TLS-Terminierung mit Key Vault-Zertifikaten.

  3. Der Datenverkehr von Application Gateway zum Back-End wird erneut mit einem anderen TLS-Zertifikat (Platzhalter für *.aks-ingress.contoso.com) verschlüsselt, während er an den internen Lastenausgleich weitergeleitet wird. Durch diese erneute Verschlüsselung wird sichergestellt, dass kein unsicherer Datenverkehr in das Clustersubnetz gelangt.

  4. Der Eingangscontroller empfängt den verschlüsselten Datenverkehr über den Lastenausgleich. Der Controller ist ein weiterer TLS-Abschlusspunkt für *.aks-ingress.contoso.com, der den Datenverkehr über HTTP an die Workloadpods weiterleitet. Die Zertifikate werden in Azure Key Vault gespeichert und mit dem Container Storage Interface-Treiber (CSI) im Cluster eingebunden. Weitere Informationen finden Sie unter Hinzufügen einer Geheimnisverwaltung.

Sie können End-to-End-TLS-Datenverkehr vollständig an jedem Hop im Pfad zum Workloadpod implementieren. Messen Sie unbedingt die Leistung, die Latenz und eventuelle betriebliche Auswirkungen, wenn Sie sich entscheiden, den Datenverkehr zwischen Pods zu schützen. Für die meisten Cluster mit nur einem Mandanten und ordnungsgemäßer RBAC auf Steuerungsebene sowie ausgereiften Verfahren für den Lebenszyklus der Softwareentwicklung reicht eine TLS-Verschlüsselung bis zum Eingangsdatencontroller und der Schutz mit Web Application Firewall (WAF) aus. Dadurch werden der Aufwand bei der Verwaltung von Workloads und die Auswirkungen auf die Netzwerkleistung minimiert. Ihre Workload- und Complianceanforderungen geben vor, wo der TLS-Abschluss erfolgt.

Ausgehender Datenverkehrsfluss

Für die Zero-Trust-Steuerung und die Möglichkeit, den Datenverkehr zu überprüfen, wird der gesamte ausgehende Datenverkehr aus dem Cluster über Azure Firewall geleitet. Sie können dies mithilfe von benutzerdefinierten Routen (User-Defined Route, UDR) implementieren. Der nächste Hop auf der Route ist die private IP-Adresse von Azure Firewall. Hier entscheidet Azure Firewall, ob der ausgehende Datenverkehr blockiert oder zugelassen wird. Diese Entscheidung basiert auf den spezifischen Regeln, die in Azure Firewall definiert sind, oder auf den integrierten Threat Intelligence-Regeln.

Hinweis

Wenn Sie einen öffentlichen Lastenausgleich als öffentlichen Punkt für den eingehenden und ausgehenden Datenverkehr über Azure Firewall mit benutzerdefinierten Routen verwenden, tritt möglicherweise ein asymmetrisches Routing auf. Diese Architektur nutzt interne Lastenausgleiche in einem dedizierten Eingangssubnetz hinter Application Gateway. Durch diesen Entwurf wird nicht nur die Sicherheit verbessert, es werden auch Bedenken bezüglich des asymmetrischen Routings beseitigt. Alternativ können Sie den eingehenden Datenverkehr vor oder nach Ihrer Application Gateway-Instanz über Ihre Azure Firewall-Instanz weiterleiten. Dieser Ansatz ist in den meisten Fällen nicht erforderlich und wird nicht empfohlen. Weitere Informationen über das asymmetrische Routing finden Sie unter Integrieren von Azure Firewall mit Azure Load Balancer Standard.

Eine Ausnahme von der Zero-Trust-Steuerung ist, wenn der Cluster mit anderen Azure-Ressourcen kommunizieren muss, z. B. wenn er ein aktualisiertes Image aus der Containerregistrierung abrufen muss. Die empfohlene Vorgehensweise ist die Verwendung von Azure Private Link. Der Vorteil besteht darin, dass bestimmte Subnetze den Dienst direkt erreichen. Außerdem wird der Datenverkehr zwischen dem Cluster und dem Dienst nicht im öffentlichen Internet verfügbar gemacht. Ein Nachteil ist, dass Private Link eine zusätzliche Konfiguration erfordert, anstatt den Zieldienst über seinen öffentlichen Endpunkt zu verwenden. Außerdem unterstützen nicht alle Azure-Dienste oder SKUs Private Link. In diesen Fällen sollten Sie im Subnetz einen Dienstendpunkt aktivieren, um auf den Dienst zuzugreifen.

Wenn Private Link oder Dienstendpunkte keine Option sind, können Sie andere Dienste über deren öffentliche Endpunkte erreichen und den Zugriff über Azure Firewall-Regeln und die in den Zieldienst integrierte Firewall steuern. Da dieser Datenverkehr über die statische IP-Adresse der Firewall geleitet wird, kann diese Adresse der Liste zugelassener IP-Adressen des Diensts hinzugefügt werden. Ein Nachteil ist, dass Azure Firewall zusätzliche Regeln benötigt, um sicherzustellen, dass nur Datenverkehr aus einem bestimmten Subnetz zugelassen wird.

Datenverkehr zwischen Pods

Standardmäßig kann ein Pod Datenverkehr von jedem anderen Pod im Cluster annehmen. Mit NetworkPolicy von Kubernetes wird der Netzwerkdatenverkehr zwischen Pods eingeschränkt. Wenden Sie Richtlinien mit Bedacht an, da es andernfalls vorkommen kann, dass ein wichtiger Netzwerkdatenfluss blockiert wird. Erlauben Sie bestimmte Kommunikationspfade nur, wenn sie wirklich erforderlich sind, z. B. den Datenverkehr zwischen dem Eingangscontroller und der Workload. Weitere Informationen finden Sie unter „Netzwerkrichtlinien“.

Aktivieren Sie die Netzwerkrichtlinie bei der Bereitstellung des Clusters, da sie später nicht mehr hinzugefügt werden kann. Es gibt einige Auswahlmöglichkeiten an Technologien, die NetworkPolicy implementieren. Die Azure-Netzwerkrichtlinie wird empfohlen. Sie erfordert Azure Container Networking Interface (CNI). Weitere Informationen hierzu finden Sie im nachstehenden Hinweis. Zu den anderen Möglichkeiten gehört mit der Calico-Netzwerkrichtlinie eine bekannte Open-Source-Option. Verwenden Sie Calico, wenn Sie clusterweite Netzwerkrichtlinien verwalten müssen. Calico wird nicht durch den Azure-Standardsupport abgedeckt.

Weitere Informationen finden Sie unter Unterschiede zwischen Azure- und Calico-Richtlinien und zwischen ihren Funktionen.

Hinweis

AKS unterstützt die folgenden Netzwerkmodelle: kubenet und Azure Container Networking Interface (CNI). CNI ist das fortgeschrittenere der beiden Modelle und wird benötigt, um die Azure-Netzwerkrichtlinie zu aktivieren. Bei diesem Modell erhält jeder Pod eine IP-Adresse aus dem Adressraum des Subnetzes. Ressourcen innerhalb desselben Netzwerks (oder mittels Peering verbundene Ressourcen) können direkt über ihre IP-Adresse auf die Pods zugreifen. NAT ist für das Routing dieses Datenverkehrs nicht erforderlich. CNI ist somit leistungsfähig, da keine zusätzlichen Netzwerküberlagerungen vorhanden sind. Außerdem bietet die Schnittstelle eine bessere Sicherheitskontrolle, da sie die Verwendung der Azure-Netzwerkrichtlinie ermöglicht. Im Allgemeinen wird CNI empfohlen. CNI bietet Teams eine präzise Kontrolle der kontrollierten Ressourcen. CNI ermöglicht zudem mehr skalierte Pods als kubenet. Treffen Sie diese Wahl mit Umsicht, da andernfalls der Cluster erneut bereitgestellt werden muss. Informationen zu den Modellen finden Sie unter Vergleich der Netzwerkmodelle.

Verwaltungsdatenverkehr

Im Rahmen der Clusterausführung empfängt der Kubernetes-API-Server Datenverkehr von Ressourcen, die Verwaltungsvorgänge im Cluster durchführen möchten, z. B. Anforderungen zum Erstellen von Ressourcen oder zum Skalieren des Clusters. Beispiele für diese Ressourcen sind der Build-Agent-Pool in einer DevOps-Pipeline, ein Bastion-Subnetz und die eigentlichen Knotenpools. Anstatt diesen Verwaltungsdatenverkehr von allen IP-Adressen zu akzeptieren, verwenden Sie das AKS-Feature für autorisierte IP-Bereiche, um nur Datenverkehr von Ihren autorisierten IP-Adressbereichen an den API-Server zuzulassen.

Weitere Informationen finden Sie unter Definieren der vom API-Server autorisierten IP-Bereiche.

Hinzufügen einer Geheimnisverwaltung

Speichern Sie Geheimnisse in einem verwalteten Schlüsselspeicher wie Azure Key Vault. Der Vorteil besteht darin, dass der verwaltete Speicher die Rotation von Geheimnissen übernimmt, starke Verschlüsselung bietet, ein Zugriffsüberwachungsprotokoll bereitstellt und zentrale Geheimnisse von der Bereitstellungspipeline fern hält.

Azure Key Vault ist gut mit anderen Azure-Diensten integriert. Verwenden Sie die integrierten Funktionen dieser Dienste für den Zugriff auf Geheimnisse. Ein Beispiel für den Zugriff auf TLS-Zertifikate für den eingehenden Datenverkehr durch Azure Application Gateway finden Sie im Abschnitt Eingehender Datenverkehrsfluss.

Zugreifen auf Clustergeheimnisse

Sie müssen vom Pod verwaltete Identitäten verwenden, um einem Pod den Zugriff auf Geheimnisse in einem bestimmten Speicher zu ermöglichen.

Verwenden Sie zum Vereinfachen des Abrufvorgangs den Secrets Store CSI-Treiber. Wenn der Pod ein Geheimnis erfordert, stellt der Treiber eine Verbindung mit dem angegebenen Speicher her, ruft das Geheimnis auf einem Volume ab und bindet dieses Volume im Cluster ein. Der Pod kann das Geheimnis dann aus dem Dateisystem des Volumes abrufen.

Der CSI-Treiber verfügt über viele Anbieter zur Unterstützung verschiedener verwalteter Speicher. In dieser Implementierung wurde der Treiber für Azure Key Vault mit Secrets Store CSI ausgewählt, um das TLS-Zertifikat aus Azure Key Vault abzurufen und in den Pod zu laden, auf dem der Eingangscontroller ausgeführt wird. Dies erfolgt bei der Poderstellung, und auf dem Volume werden sowohl die öffentlichen als auch die privaten Schlüssel gespeichert.

Workloadspeicher

Die in dieser Architektur verwendete Workload ist zustandslos. Wenn Sie den Zustand speichern müssen, wird empfohlen, diesen außerhalb des Clusters persistent zu speichern. Ein Leitfaden zum Workloadzustand überschreitet den Rahmen dieses Artikels.

Weitere Informationen zu Speicheroptionen finden Sie unter Speicheroptionen für Anwendungen in Azure Kubernetes Service (AKS).

Richtlinienverwaltung

Eine effektive Möglichkeit zur Verwaltung eines AKS-Clusters ist das Erzwingen von Governance über Richtlinien. Kubernetes implementiert Richtlinien über den OPA-Gatekeeper. Für AKS werden die Richtlinien über Azure Policy bereitgestellt. Jede Richtlinie wird auf alle Cluster in ihrem Bereich angewendet. Die Azure Policy-Erzwingung wird letztendlich von OPA-Gatekeeper im Cluster verarbeitet, und alle Richtlinienüberprüfungen werden protokolliert. Richtlinienänderungen werden nicht sofort in Ihrem Cluster widergespiegelt. Einige Verzögerungen sind zu erwarten.

Beim Festlegen von Richtlinien wenden Sie diese basierend auf den Anforderungen der Workload an. Beachten Sie folgende Faktoren:

  • Möchten Sie eine Sammlung von Richtlinien (sogenannte Initiativen) festlegen oder einzelne Richtlinien auswählen? Azure Policy bietet zwei integrierte Initiativen: „basic“ und „restricted“. Jede Initiative ist eine Sammlung integrierter Richtlinien, die für einen AKS-Cluster gelten. Es wird empfohlen, eine Initiative auswählen und zusätzliche Richtlinien für den Cluster und die Ressourcen (ACR, Application Gateway, Key Vault und andere) auswählen, die gemäß den Anforderungen Ihrer Organisation mit dem Cluster interagieren.

  • Möchten Sie die Aktion überwachen oder verweigern? Im Überwachungsmodus ist die Aktion zulässig, aber als nicht konform gekennzeichnet. Verwenden Sie Prozesse, um nicht konforme Zustände in regelmäßigen Abständen zu überprüfen und die erforderlichen Maßnahmen zu ergreifen. Im Modus Verweigern wird die Aktion blockiert, da sie gegen die Richtlinie verstößt. Seien Sie vorsichtig bei der Auswahl dieses Modus, da er u. U. so restriktiv ist, dass die Workload nicht funktioniert.

  • Gibt es Bereiche in der Workload, die nicht entwurfsbedingt konform sein sollten? Azure Policy verfügt über die Möglichkeit, Kubernetes-Namespaces anzugeben, die von der Richtlinienerzwingung ausgenommen sind. Es wird empfohlen, Richtlinien weiterhin im Überwachungsmodus anzuwenden, damit Sie diese Instanzen kennen.

  • Verfügen Sie über Anforderungen, die nicht von den integrierten Richtlinien abgedeckt werden? Erstellen Sie in diesen seltenen Fällen eine benutzerdefinierte Azure Policy-Definition, mit der die benutzerdefinierten OPA-Gatekeeper-Richtlinien angewendet werden. Wenden Sie Richtlinien nicht direkt auf den Cluster an.

  • Haben Sie organisationsweite Anforderungen? Wenn dies der Fall ist, fügen Sie diese Richtlinien auf der Verwaltungsgruppenebene hinzu. Ihr Cluster muss auch eigene Workload-spezifische Richtlinien zuweisen, auch wenn die Organisation über generische Richtlinien verfügt.

  • Azure-Richtlinien werden bestimmten Bereichen zugewiesen. Stellen Sie sicher, dass die Richtlinien für die Produktion auch anhand ihrer Präproduktionsumgebung überprüft werden. Andernfalls können bei der Bereitstellung in der Produktionsumgebung unerwartete zusätzliche Einschränkungen auftreten, die in der Präproduktionsumgebung nicht berücksichtigt wurden.

In dieser Referenzimplementierung ist Azure Policy beim Erstellen des AKS-Clusters aktiviert und weist die restriktive Initiative im Überwachungsmodus zu, um Einblick in die Nichtkonformität zu erhalten.

Außerdem werden durch die Implementierung zusätzliche Richtlinien festgelegt, die nicht Teil integrierter Initiativen sind. Diese Richtlinien werden im Modus Verweigern festgelegt. Beispielsweise gibt es eine Richtlinie, um sicherzustellen, dass Images nur aus dem bereitgestellten ACR abgerufen werden. Erstellen Sie ggf. eigene benutzerdefinierte Initiativen. Fassen Sie die Richtlinien, die für Ihre Workload gelten, in einer einzigen Zuweisung zusammen.

Greifen Sie auf die Podprotokolle für alle Pods im gatekeeper-system-Namespace sowie auf die Protokolle für die azure-policy- und azure-policy-webhook-Pods im kube-system-Namespace zu, um zu beobachten, wie Azure Policy innerhalb Ihres Clusters funktioniert.

Skalierbarkeit für Knoten und Pods

Mit zunehmender Nachfrage kann Kubernetes aufskaliert werden, indem vorhandenen Knoten über HPA (horizontale automatische Podskalierung) weitere Pods hinzugefügt werden. Wenn keine weiteren Pods mehr geplant werden können, muss die Anzahl der Knoten über die automatische Skalierung des AKS-Clusters erhöht werden. Eine vollständige Skalierungslösung muss sowohl Podreplikate als auch die Anzahl der Knoten im Cluster skalieren können.

Dazu gibt es zwei Ansätze: automatische Skalierung oder manuelle Skalierung.

Bei der manuellen oder programmgesteuerten Methode müssen Sie die CPU-Auslastung oder benutzerdefinierte Metriken überwachen und entsprechende Warnungen einrichten. Für die Podskalierung kann der Anwendungsbediener die Anzahl von Podreplikaten erhöhen oder verringern, indem er ReplicaSet über Kubernetes-APIs anpasst. Bei der Clusterskalierung besteht eine Möglichkeit darin, benachrichtigt zu werden, wenn beim Kubernetes-Planer ein Fehler auftritt. Eine andere Möglichkeit besteht darin, ausstehende Pods über einen Zeitraum zu beobachten. Sie können die Anzahl der Knoten über die Azure-Befehlszeilenschnittstelle oder das Portal anpassen.

Die automatische Skalierung ist der bevorzugte Ansatz, da einige dieser manuellen Mechanismen in die automatische Skalierung integriert sind.

Grundsätzlich sollten Sie Leistungstests mit einer minimalen Anzahl von Pods und Knoten beginnen. Verwenden Sie diese Werte, um die Baselineerwartung festzulegen. Verwenden Sie dann eine Kombination aus Leistungsmetriken und manueller Skalierung, um Engpässe zu ermitteln und die Reaktion der Anwendung auf Skalierung nachzuvollziehen. Legen Sie schließlich mithilfe dieser Daten die Parameter für die automatische Skalierung fest. Informationen zu einem Leistungsoptimierungsszenario mit AKS finden Sie unter Leistungsoptimierungsszenario: Verteilte Geschäftstransaktionen.

Horizontale automatische Podskalierung

Bei der horizontalen automatischen Podskalierung (Horizontal Pod Autoscaler, HPA) handelt es sich um eine Kubernetes-Ressource, die die Anzahl von Pods skaliert.

Es wird für die HPA-Ressource empfohlen, die Mindest- und Höchstanzahl von Replikaten festzulegen. Diese Werte schränken die Grenzen für die automatische Skalierung ein.

HPA kann anhand der CPU-Auslastung, der Speicherauslastung und benutzerdefinierter Metriken skalieren. Standardmäßig wird nur die CPU-Auslastung berücksichtigt. Die Definition HorizontalPodAutoscaler gibt Zielwerte für diese Metriken an. Beispielsweise wird in der Spezifikation eine CPU-Zielauslastung festgelegt. Während der Ausführung von Pods überprüft der HPA-Controller die CPU-Auslastung der einzelnen Pods mithilfe der Kubernetes-Metrik-API. Er vergleicht diesen Wert mit der Zielauslastung und berechnet ein Verhältnis. Anschließend ermittelt er anhand dieses Verhältnisses, ob Pods überbelegt oder unterbelegt sind. Er überlässt dem Kubernetes-Planer das Zuweisen neuer Pods zu Knoten oder das Entfernen von Pods von Knoten.

Möglicherweise gibt es eine Racebedingung, bei der HPA die Überprüfung durchführt, bevor ein Skalierungsvorgang abgeschlossen ist. Das Ergebnis ist möglicherweise eine falsche Verhältnisberechnung. Ausführliche Informationen finden Sie unter Abkühlung der Skalierung von Ereignissen.

Wenn Ihre Workload ereignisgesteuert ist, stellt KEDA eine beliebte Open-Source-Option dar. Wenn Ihre Workload von einer Ereignisquelle wie einer Nachrichtenwarteschlange gesteuert wird und nicht an CPU oder Speicher gebunden ist, sollten Sie KEDA in Erwägung ziehen. KEDA unterstützt viele Ereignisquellen (oder Scaler). Sie finden die Liste der unterstützten KEDA-Scaler hier einschließlich Azure Monitor Scaler. Dies stellt eine bequeme Möglichkeit zum Skalieren von KEDA-Workloads basierend auf Azure Monitor-Metriken dar.

Automatische Clusterskalierung

Die automatische Clusterskalierung ist eine AKS-Add-On-Komponente, die die Anzahl der Knoten in einem Knotenpool skaliert. Sie sollte bei der Clusterbereitstellung hinzugefügt werden. Für jeden Benutzerknotenpool wird eine separate automatische Clusterskalierung benötigt.

Die automatische Clusterskalierung wird vom Kubernetes-Planer ausgelöst. Wenn der Kubernetes-Planer aufgrund von Ressourcenbeschränkungen einen Pod nicht planen kann, stellt die automatische Skalierung automatisch einen neuen Knoten im Knotenpool bereit. Umgekehrt überprüft die automatische Clusterskalierung die nicht genutzte Kapazität der Knoten. Wenn der Knoten nicht mit der erwarteten Kapazität ausgeführt wird, werden die Pods auf einen anderen Knoten verschoben, und der nicht genutzte Knoten wird entfernt.

Beim Aktivieren der automatischen Skalierung legen Sie die maximale und minimale Anzahl von Knoten fest. Die empfohlenen Werte hängen von der Leistungserwartung der Workload, dem gewünschten Wachstum des Clusters und den Auswirkungen auf die Kosten ab. Die Mindestanzahl ist die reservierte Kapazität für diesen Knotenpool. In dieser Referenzimplementierung wird der Mindestwert aufgrund der einfachen Workload auf 2 festgelegt.

Für den Systemknotenpool beträgt der empfohlene Mindestwert 3.

Entscheidungen zur Geschäftskontinuität

Um die Geschäftskontinuität aufrechtzuerhalten, definieren Sie eine Vereinbarung zum Servicelevel für die Infrastruktur und Ihre Anwendung. Informationen zur Berechnung der monatlichen Betriebszeit finden Sie in der SLA für Azure Kubernetes Service (AKS).

Clusterknoten

Um die Mindestverfügbarkeit für Workloads zu erreichen, sind mehrere Knoten in einem Knotenpool erforderlich. Wenn ein Knoten ausfällt, kann die Anwendung auf einem anderen Knoten im Knotenpool im selben Cluster weiterhin ausgeführt werden. Aus Gründen der Zuverlässigkeit werden für den Systemknotenpool drei Knoten empfohlen. Beginnen Sie für den Benutzerknotenpool mit mindestens zwei Knoten. Wenn Sie eine höhere Verfügbarkeit benötigen, stellen Sie weitere Knoten bereit.

Isolieren Sie Ihre Anwendung von den Systemdiensten, indem Sie sie in einem separaten Knotenpool platzieren. Dadurch werden Kubernetes-Dienste auf dedizierten Knoten ausgeführt und konkurrieren nicht mit Ihrer Workload. Die Verwendung von Tags, Bezeichnungen und Taints wird empfohlen, um den Knotenpool zum Planen der Workload anzugeben.

Für die Zuverlässigkeit ist eine regelmäßige Wartung Ihres Clusters entscheidend, z. B. mit schnellen Updates. Außerdem wird empfohlen, die Integrität der Pods mithilfe von Tests zu überwachen.

Podverfügbarkeit

Sicherstellen von Podressourcen. Es wird dringend empfohlen, in Bereitstellungen Podressourcenanforderungen anzugeben. Der Planer kann den Pod dann ordnungsgemäß planen. Die Zuverlässigkeit nimmt deutlich ab, wenn Pods nicht geplant werden können.

Festlegen von Budgets für die Unterbrechung von Pods. Mit dieser Einstellung wird festgelegt, wie viele Replikate in einer Bereitstellung bei einem Update- oder Upgradereignis außer Betrieb genommen werden können. Weitere Informationen finden Sie unter Budgets für die Unterbrechung von Pods.

Konfigurieren Sie mehrere Replikate in der Bereitstellung, um Unterbrechungen wie Hardwarefehler zu behandeln. Bei geplanten Ereignissen wie Updates und Upgrades kann ein Unterbrechungsbudget sicherstellen, dass die erforderliche Anzahl von Podreplikaten für die erwartete Anwendungslast vorhanden ist.

Festlegen von Ressourcenkontingenten für die Workloadnamespaces. Das Ressourcenkontingent für einen Namespace stellt sicher, dass Podanforderungen und -grenzwerte für eine Bereitstellung ordnungsgemäß festgelegt werden. Weitere Informationen finden Sie unter Durchsetzen von Ressourcenkontingenten.

Hinweis

Das Festlegen von Ressourcenkontingenten auf Clusterebene kann Probleme beim Bereitstellen von Drittanbieter-Workloads verursachen, die nicht über angemessene Anforderungen und Grenzwerte verfügen.

Festlegen von Podanforderungen und -grenzwerten. Durch Festlegen dieser Grenzwerte kann Kubernetes den Pods effizient CPU- oder Arbeitsspeicherressourcen zuweisen und eine höhere Containerdichte auf einem Knoten erreichen. Grenzwerte können durch bessere Hardwarenutzung auch die Zuverlässigkeit mit geringeren Kosten erhöhen.

Um die Grenzwerte abzuschätzen, testen und erstellen Sie eine Baseline. Beginnen Sie mit gleichen Werten für Anforderungen und Grenzwerte. Optimieren Sie diese Werte dann nach und nach, bis Sie einen Schwellenwert festgelegt haben, der eine Instabilität im Cluster verursachen kann.

Diese Grenzwerte können in Ihren Bereitstellungsmanifesten angegeben werden. Weitere Informationen finden Sie unter Festlegen von Podanforderungen und -grenzwerten.

Verfügbarkeitszonen und Unterstützung von mehreren Regionen

Wenn Ihre SLA eine höhere Betriebszeit erfordert, schützen Sie sie vor dem Ausfall in einer Zone. Sie können Verfügbarkeitszonen verwenden, wenn sie von der Region unterstützt werden. Sowohl die Komponenten der Steuerungsebene als auch die Knoten in den Knotenpools können sich dann über Zonen hinweg erstrecken. Wenn eine gesamte Zone nicht verfügbar ist, bleibt ein Knoten in einer anderen Zone innerhalb der Region weiterhin verfügbar. Jeder Knotenpool ist einer separaten VM-Skalierungsgruppe zugeordnet, die Knoteninstanzen und Skalierbarkeit verwaltet. Vorgänge in Skalierungsgruppen und Konfigurationen werden vom AKS-Dienst verwaltet. Hier sind einige Aspekte angegeben, die beim Aktivieren der Verfügbarkeit in mehreren Zonen berücksichtigt werden sollten:

  • Gesamte Infrastruktur. Wählen Sie eine Region aus, die Verfügbarkeitszonen unterstützt. Weitere Informationen finden Sie unter Einschränkungen und regionale Verfügbarkeit. Wenn Sie eine Betriebszeit-SLA erwerben möchten, wählen Sie eine Region aus, die diese Option unterstützt. Bei Verwendung von Verfügbarkeitszonen ist die Betriebszeit-SLA höher.

  • Cluster. Verfügbarkeitszonen können nur beim Erstellen des Knotenpools festgelegt und später nicht mehr geändert werden. Die Knotengrößen sollten in allen Zonen unterstützt werden, damit die gewünschte Verteilung möglich ist. Die zugrunde liegende VM-Skalierungsgruppe stellt die gleiche Hardwarekonfiguration zonenübergreifend bereit.

    Die Unterstützung mehrerer Zonen gilt nicht nur für Knotenpools, sondern auch für die Steuerungsebene. Die AKS-Steuerungsebene erstreckt sich wie die Knotenpools über die angeforderten Zonen. Wenn Sie keine Zonenunterstützung in Ihrem Cluster verwenden, ist nicht gewährleistet, dass sich die Komponenten der Steuerungsebene über mehrere Verfügbarkeitszonen erstrecken.

  • Abhängige Ressourcen. Um alle Vorteile aus den Zonen schöpfen zu können, müssen alle Dienstabhängigkeiten ebenfalls Zonen unterstützen. Wenn ein abhängiger Dienst keine Zonen unterstützt, kann ein Zonenausfall dazu führen, dass bei diesem Dienst ein Fehler auftritt.

Beispielsweise ist ein verwalteter Datenträger in der Zone verfügbar, in der er bereitgestellt wurde. Bei einem Ausfall wird der Knoten möglicherweise in eine andere Zone verschoben, der verwaltete Datenträger wird jedoch nicht mit dem Knoten in diese Zone verschoben.

Der Einfachheit halber wird AKS in dieser Architektur in einer einzelnen Region mit Knotenpools bereitgestellt, die die Verfügbarkeitszonen 1, 2 und 3 umfassen. Andere Ressourcen der Infrastruktur wie z. B. Azure Firewall und Application Gateway werden in derselben Region ebenfalls mit Unterstützung mehrerer Zonen bereitgestellt. Die Georeplikation ist für Azure Container Registry aktiviert.

Mehrere Regionen

Die Aktivierung von Verfügbarkeitszonen ist nicht ausreichend, wenn die gesamte Region ausfällt. Um eine höhere Verfügbarkeit zu erhalten, führen Sie mehrere AKS-Cluster in unterschiedlichen Regionen aus.

  • Verwenden Sie Regionspaare. Ziehen Sie die Verwendung einer CI/CD-Pipeline ein Betracht, die für die Verwendung eines Regionspaars für die Wiederherstellung nach Regionsausfällen konfiguriert ist. Ein Vorteil der Verwendung von Regionspaaren ist die Zuverlässigkeit bei Updates. Azure stellt sicher, dass jeweils nur eine Region im Paar aktualisiert wird. Bestimmte DevOps-Tools wie flux können die Bereitstellung in mehreren Regionen vereinfachen.

  • Wenn eine Azure-Ressource georedundante Redundanz unterstützt, geben Sie den Standort an, an dem sich die sekundäre Datenbank des redundanten Diensts befinden soll. Durch Aktivieren der Georeplikation für Azure Container Registry werden Images beispielsweise automatisch in die ausgewählten Azure-Regionen repliziert, und der Zugriff auf Images wird auch dann fortgesetzt, wenn ein Ausfall in einer Region auftritt.

  • Wählen Sie einen Datenverkehrsrouter aus, der den Datenverkehr abhängig von Ihrer Anforderung über Zonen oder Regionen verteilen kann. In dieser Architektur wird Azure Load Balancer bereitgestellt, da hiermit websitefremder Datenverkehr über Zonen hinweg verteilt werden kann. Wenn Sie Datenverkehr über Regionen hinweg verteilen müssen, sollten Sie Azure Front Door in Erwägung ziehen. Weitere Überlegungen finden Sie unter Auswählen eines Lastenausgleichs.

Hinweis

Wir haben diese Referenzarchitektur um mehrere Regionen in einer Aktiv/Aktiv- und hoch verfügbaren Konfiguration erweitert. Informationen zu dieser Referenzarchitektur finden Sie unter AKS-Baseline für Cluster mit mehreren Regionen.

GitHub logo Eine Implementierung der Architektur mit mehreren Regionen ist auf GitHub: Azure Kubernetes Service (AKS) zur Bereitstellung in mehreren Regionen verfügbar. Sie können diese als Startpunkt verwenden und gemäß Ihren Anforderungen konfigurieren.

Notfallwiederherstellung

Bei einem Ausfall in der primären Region sollten Sie in der Lage sein, schnell eine neue Instanz in einer anderen Region zu erstellen. Hier sind einige Empfehlungen dafür:

  • Verwenden Sie Regionspaare.

  • Eine nicht zustandsbehaftete Workload kann effizient repliziert werden. Wenn Sie den Zustand im Cluster speichern müssen (nicht empfohlen), stellen Sie sicher, dass die Daten in der gekoppelten Region häufig gesichert werden.

  • Integrieren Sie die Wiederherstellungsstrategie, etwa die Replikation in eine andere Region, als Teil der DevOps-Pipeline, um Ihre Service Level-Ziele (Service Level Objectives, SLO) zu erfüllen.

  • Wählen Sie bei der Bereitstellung der einzelnen Azure-Dienste Features aus, die die Notfallwiederherstellung unterstützen. In dieser Architektur ist beispielsweise Azure Container Registry für die Georeplikation aktiviert. Wenn eine Region ausfällt, können Sie weiterhin Images aus dem replizierten Bereich pullen.

Betriebszeit-SLA für Kubernetes-API-Server

AKS kann als kostenloser Dienst verwendet werden, dieser Tarif bietet jedoch keine finanziell abgesicherte SLA. Um diese SLA zu erhalten, müssen Sie Ihrem Kauf eine Betriebszeit-SLA hinzufügen. Es wird empfohlen, diese Option für alle Produktionscluster zu verwenden. Cluster ohne diese Option sollten nur für Präproduktionsclients eingesetzt werden. In Kombination mit Azure-Verfügbarkeitszonen wird die SLA des Kubernetes-API-Servers auf 99,95 % erhöht. Ihre Knotenpools und andere Ressourcen sind unter einer eigenen SLA abgedeckt.

Kompromiss

Für die Bereitstellung der Architektur über Zonen und insbesondere über Regionen hinweg bringen Kostenersparnisse eine geringere Verfügbarkeit mit sich. Einige Replikationsfunktionen wie die Georeplikation in Azure Container Registry sind in Premium-SKUs verfügbar, die jedoch kostenaufwendiger sind. Die Kosten steigen auch, da Bandbreitengebühren anfallen, wenn der Datenverkehr über Zonen und Regionen hinweg übertragen wird.

Rechnen Sie außerdem mit einer zusätzlichen Netzwerklatenz bei der Knotenkommunikation zwischen Zonen oder Regionen. Messen Sie die Auswirkung dieser Architekturentscheidung auf Ihre Workload.

Testen mit Simulationen und erzwungenen Failovern

Stellen Sie Zuverlässigkeit durch erzwungene Failovertests mit simulierten Ausfällen sicher, z. B. durch Herunterfahren eines Knotens und somit Herunterfahren aller AKS-Ressourcen in einer bestimmten Zone, um einen Zonenausfall zu simulieren oder durch Herunterfahren einer externen Abhängigkeit.

Überwachen und Sammeln von Metriken

Azure Monitor Container Insights wird als Tool zur Überwachung und Protokollierung empfohlen, da Sie Ereignisse in Echtzeit anzeigen können. Es erfasst Containerprotokolle von den ausgeführten Pods und aggregiert sie für die Anzeige. Außerdem sammelt es Informationen von der Metrik-API zur Arbeitsspeicher- und CPU-Auslastung, um die Integrität der ausgeführten Ressourcen und Workloads zu überwachen. Sie können damit die Leistung beim Skalieren von Pods überwachen. Ein weiterer Vorteil besteht darin, dass Sie im Azure-Portal problemlos Diagramme und Dashboards konfigurieren können. Es verfügt über die Möglichkeit, Warnungen zu erstellen, die Automation-Runbooks, Azure Functions und andere Dienste auslösen.

Die meisten in Pods gehosteten Workloads geben Prometheus-Metriken aus. Azure Monitor kann Prometheus-Metriken abrufen und visualisieren.

In Kubernetes sind einige Hilfsprogramme von Drittanbietern integriert. Nutzen Sie Protokoll- und Metrikplattformen wie Grafana oder Datadog, wenn Ihre Organisation diese bereits verwendet.

Mit AKS verwaltet Azure einige zentrale Kubernetes-Kerndienste. Protokolle von diesen Diensten sollten nur nach Aufforderung durch den Kundendienst aktiviert werden. Es wird jedoch empfohlen, diese Protokollquellen zu aktivieren, da sie Ihnen helfen können, Clusterprobleme zu beheben:

Aktivieren der Selbstreparatur

Überwachen Sie die Integrität von Pods, indem Sie Live- und Bereitschaftstests festlegen. Wenn ein nicht reagierender Pod erkannt wird, startet Kubernetes den Pod neu. Mit dem Livetest wird ermittelt, ob der Pod fehlerfrei ist. Wenn der Pod nicht antwortet, wird er von Kubernetes neu gestartet. Der Bereitschaftstest ermittelt, ob der Pod zum Empfangen von Anforderungen/Datenverkehr bereit ist.

Hinweis

AKS bietet eine integrierte Selbstreparatur von Infrastrukturknoten mithilfe der automatischen Knotenreparatur.

Sicherheitsupdates

Halten Sie die Kubernetes-Version mit den unterstützten Versionen (N-2) auf dem neuesten Stand. Das Upgrade auf die neueste Version von Kubernetes ist wichtig, da häufig neue Versionen veröffentlicht werden.

Weitere Informationen finden Sie unter Regelmäßiges Update auf die neueste Version von Kubernetes und Durchführen eines Upgrades für einen Azure Kubernetes Service-Cluster (AKS).

Die Benachrichtigung über Ereignisse, die von Ihrem Cluster ausgelöst werden (beispielsweise die Verfügbarkeit einer neuen AKS-Version für Ihren Cluster), kann über das AKS-Systemthema für Azure Event Grid erreicht werden. Von der Referenzimplementierung wird dieses Event Grid-Systemthema bereitgestellt, sodass Sie das Ereignis Microsoft.ContainerService.NewKubernetesVersionAvailable über Ihre Ereignisdatenstrom-Benachrichtigungslösung abonnieren können.

Wöchentliche Updates

AKS stellt neue Knotenimages mit den neuesten Betriebssystem- und Runtime-Updates zur Verfügung. Diese neuen Images werden nicht automatisch angewendet. Sie müssen entscheiden, wie oft die Images aktualisiert werden sollen. Es wird empfohlen, dass Sie einen Prozess zur wöchentlichen Aktualisierung des Basisimages Ihrer Knotenpools einrichten. Weitere Informationen finden Sie unter Upgrade für AKS-Knotenimages (Azure Kubernetes Service) und in den Hinweisen zur AKS-Version.

Tägliche Updates

Zwischen den Upgrades von Images werden Betriebssystem- und Runtimepatches von AKS-Knoten einzeln heruntergeladen und installiert. Eine Installation erfordert möglicherweise einen Neustart der Knoten-VMs. AKS startet Knoten aufgrund ausstehender Updates nicht neu. Richten Sie einen Prozess ein, der Knoten auf die angewendeten Updates überwacht, die einen Neustart erfordern, und den Neustart dieser Knoten auf kontrollierte Weise durchführt. Eine Open-Source-Option ist Kured (Kubernetes Reboot Daemon).

Wenn Sie Ihre Knotenimages mit dem neuesten wöchentlichen Release synchron halten, werden diese gelegentlichen Neustartanforderungen auf ein Minimum reduziert, und gleichzeitig wird die Sicherheit verbessert. Wenn Sie sich lediglich auf Upgrades von Knotenimages verlassen, werden AKS-Kompatibilität und wöchentliche Sicherheitspatches gewährleistet. Obwohl durch die Anwendung täglicher Updates Sicherheitsprobleme schneller behoben werden können, wurden diese nicht unbedingt in AKS getestet. Setzen Sie nach Möglichkeit auf das Upgrade von Knotenimages als primäre wöchentliche Patchstrategie zum Verbessern der Sicherheit.

Sicherheitsüberwachung

Überwachen Sie Ihre Containerinfrastruktur sowohl auf aktive Bedrohungen als auch auf potenzielle Sicherheitsrisiken:

Cluster- und Workloadvorgänge (DevOps)

Hier finden Sie einige Überlegungen dazu. Weitere Informationen finden Sie unter Optimaler Betrieb.

Clusterbootstrapping

Nach Abschluss der Bereitstellung verfügen Sie über einen funktionierenden Cluster. Vor der Bereitstellung von Workloads sind jedoch möglicherweise noch weitere Schritte erforderlich. Der Prozess der Clustervorbereitung wird als Bootstrapping bezeichnet und kann beispielsweise das Bereitstellen von erforderlichen Images auf Clusterknoten, das Erstellen von Namespaces sowie andere Aktionen umfassen, die zur Erfüllung der Anforderungen Ihres Anwendungsfalls oder Ihrer Organisation erforderlich sind.

Um die Lücke zwischen einem bereitgestellten Cluster und einem ordnungsgemäß konfigurierten Cluster zu verkleinern, müssen sich Clusteroperatoren Gedanken zu ihrem individuellen Bootstrappingprozess machen und relevante Ressourcen im Voraus vorbereiten. Wenn also beispielsweise Kured auf jedem Knoten ausgeführt werden muss, bevor Anwendungsworkloads bereitgestellt werden, sollte der Clusteroperator dafür sorgen, dass bereits eine ACR-Instanz mit dem Kured-Zielimage vorhanden ist, bevor der Cluster bereitgestellt wird.

Der Bootstrappingprozess kann mit einer der folgenden Methoden konfiguriert werden:

Hinweis

Diese Methoden funktionieren zwar mit jeder Clustertopologie, die GitOps Flux v2-Clustererweiterung wird jedoch aufgrund von Einheitlichkeit und einfacherer Governance im großen Stil für Flotten empfohlen. Wenn nur einige wenige Cluster verwendet werden, ist GitOps möglicherweise zu komplex. In diesem Fall können Sie den Prozess stattdessen in eine oder mehrere Bereitstellungspipelines integrieren, um die Durchführung des Bootstrappings sicherzustellen. Verwenden Sie die Methode, die am besten zu den Zielen Ihrer Organisation und Ihres Teams passt.

Einer der Hauptvorteile der GitOps Flux v2-Clustererweiterung für AKS besteht darin, dass es praktisch keine Lücke zwischen einem bereitgestellten Cluster und einem Cluster nach dem Bootstrapping gibt. Durch die Erweiterung kann der Cluster bereits mit Bootstrapping gestartet werden, und Sie erhalten eine solide Verwaltungsgrundlage für die Zukunft. Des Weiteren wird die Einbeziehung dieses Bootstrappings als Ressourcenvorlagen unterstützt, um die Ausrichtung an Ihrer IaC-Strategie zu ermöglichen.

Bei Verwendung der Erweiterung wird außerdem kubectl nicht für den Bootstrappingprozess benötigt, und kubectl-basierter Zugriff kann auf Notfallproblemlösungen beschränkt werden. Zwischen Vorlagen für Azure-Ressourcendefinitionen und dem Bootstrapping von Manifesten über die GitOps-Erweiterung können alle normalen Konfigurationsaktivitäten ganz ohne kubectl ausgeführt werden.

Isolieren der Zuständigkeiten für Workloads

Teilen Sie Workloads nach Teams und Ressourcentypen ein, um jeden Teil einzeln verwalten zu können.

Beginnen Sie mit einer einfachen Workload, die die grundlegenden Komponenten enthält, und bauen Sie darauf auf. Eine erste Aufgabe ist die Konfiguration des Netzwerks. Stellen Sie virtuelle Netzwerke für den Hub, die Spokes und die Subnetze in diesen Netzwerken bereit. Beispielsweise verfügt ein Spoke über separate Subnetze für System- und Benutzerknotenpools sowie Eingangsressourcen und ein Subnetz für Azure Firewall im Hub.

Ein weiterer Teil ist das Integrieren der einfach Workload in Azure Active Directory.

Verwenden der Infrastruktur als Code (Infrastructure as Code, IaC)

Wählen Sie nach Möglichkeit eher eine idempotente deklarative Methode als einen imperativen Ansatz aus. Anstatt eine Sequenz von Befehlen zu schreiben, die Konfigurationsoptionen angeben, verwenden Sie eine deklarative Syntax, die die Ressourcen und ihre Eigenschaften beschreibt. Eine Option ist eine ARM-Vorlage (Azure Resource Manager), eine weitere ist Terraform.

Stellen Sie sicher, dass Sie Ressourcen gemäß den geltenden Richtlinien bereitstellen. Wenn Sie z. B. die VM-Größen auswählen, achten Sie auf Kosteneinschränkungen und Optionen für Verfügbarkeitszonen entsprechend den Anforderungen Ihrer Anwendung.

Wenn Sie eine Sequenz von Befehlen schreiben müssen, verwenden Sie die Azure CLI. Diese Befehle behandeln eine Reihe von Azure-Diensten und können mithilfe von Skripts automatisiert werden. Die Azure-Befehlszeilenschnittstelle wird unter Windows und Linux unterstützt. Eine weitere plattformübergreifende Option ist Azure PowerShell. Ihre Auswahl hängt von Ihren Kenntnissen ab.

Speichern Sie Skripts und Vorlagendateien in Ihrem Quellcode-Verwaltungssystem, und verwalten Sie dort die Versionen.

CI/CD für Workloads

Pipelines für Workflow und Bereitstellung müssen kontinuierlich Anwendungen erstellen und bereitstellen können. Updates müssen für den Fall, dass Probleme auftreten, sicher und schnell bereitgestellt und zurückgesetzt werden.

Ihre Bereitstellungsstrategie muss eine zuverlässige und automatisierte CD-Pipeline (Continuous Delivery) aufweisen. Änderungen an den Containerimages für Ihre Workload sollten automatisch im Cluster bereitgestellt werden.

In dieser Architektur haben wir GitHub Actions zum Verwalten des Workflows und der Bereitstellung ausgewählt. Andere verbreitete Optionen sind Azure DevOps Services und Jenkins.

CI/CD für Cluster

Workload CI/CD

Verwenden Sie anstelle eines imperativen Ansatzes wie kubectl Tools, die Cluster- und Repositoryänderungen automatisch synchronisieren. Um den Workflow zu verwalten, z. B. das Release einer neuen Version und die Validierung dieser Version vor der Bereitstellung in der Produktion, sollten Sie einen GitOps-Flow in Erwägung ziehen.

Ein wesentlicher Bestandteil des CI/CD-Flows ist das Bootstrapping eines neu bereitgestellten Clusters. Hierbei ist ein GitOps-Ansatz hilfreich, der es Operatoren ermöglicht, den Bootstrappingprozess im Rahmen der IaC-Strategie deklarativ zu definieren und die Konfiguration automatisch im Cluster anzuwenden.

Bei Verwendung von GitOps wird ein Agent im Cluster bereitgestellt, der sicherstellt, dass der Status des Clusters mit der in Ihrem privaten Git-Repository gespeicherten Konfiguration koordiniert wird. Flux ist ein solcher Agent. Er verwendet einen oder mehrere Operatoren im Cluster, um Bereitstellungen in Kubernetes auszulösen. Flux übernimmt folgende Aufgaben:

  • Überwachen alle konfigurierten Depots
  • Erkennen neuer Konfigurationsänderungen
  • Auslösen von Bereitstellungen
  • Aktualisieren der gewünschten Konfiguration anhand dieser Änderungen

Sie können auch Richtlinien festlegen, die die Bereitstellung dieser Änderungen steuern.

Das folgende Beispiel zeigt die Automatisierung der Clusterkonfiguration mit GitOps und Flux:

GitOps Flow

  1. Ein Entwickler committet Änderungen am Quellcode, z. B. YAML-Konfigurationsdateien, die in einem Git-Repository gespeichert werden. Die Änderungen werden dann auf einen Git-Server gepusht.

  2. flux wird zusammen mit der Workload in einem Pod ausgeführt. flux verfügt nur über Lesezugriff auf das Git-Repository, damit nur Änderungen angewandt werden, die von den Entwicklern angefordert wurden.

  3. flux erkennt Änderungen an der Konfiguration und wendet diese Änderungen mithilfe von kubectl-Befehlen an.

  4. Die Entwickler haben über kubectl keinen direkten Zugriff auf die Kubernetes-API. Richten Sie auf Ihrem Git-Server Branchrichtlinien ein. Dadurch können mehrere Entwickler eine Änderung genehmigen, bevor sie in die Produktion übernommen wird.

GitOps und Flux können zwar manuell konfiguriert werden, die Clustererweiterung GitOps mit Flux v2 vereinfacht jedoch diesen Prozess und bietet eine Reihe zusätzlicher Vorteile – insbesondere eine erhebliche Verkleinerung der Lücke zwischen einem bereitgestellten Cluster und einem Cluster nach dem Bootstrapping. Ihre Einheitlichkeit und die komfortable Wartung im großen Stil machen sie zur empfohlenen Methode für Teams, die für eine große Anzahl von Clustern (eine sogenannte Flotte) zuständig sind.

Bereitstellungsstrategien für Workloads und Cluster

Stellen Sie alle Änderungen (Architekturkomponenten, Workload, Clusterkonfiguration) in mindestens einem AKS-Präproduktionscluster bereit. Dadurch wird die Änderung so simuliert, sodass Probleme vor der Bereitstellung in der Produktion behoben werden können.

Führen Sie Tests/Überprüfungen jeder Phase aus, bevor Sie zur nächsten übergehen, um sicherzustellen, dass Sie Updates auf kontrollierte Weise in die Produktionsumgebung pushen und Unterbrechungen aufgrund unvorhergesehener Bereitstellungsprobleme minimieren können. Diese Bereitstellung sollte einem ähnlichen Muster wie die Produktion folgen und die gleichen GitHub Actions-Pipeline bzw. die gleichen flux-Operatoren verwenden.

Erweiterte Bereitstellungsverfahren wie Blau-Grün-Bereitstellung, A/B-Tests und Canary-Releases erfordern eine weitere Verarbeitung und möglicherweise zusätzliche Tools. Flagger ist eine verbreitete Open-Source-Lösung, die Sie bei der Behandlung Ihrer erweiterten Bereitstellungsszenarien unterstützt.

Kostenverwaltung

Mithilfe des Azure-Preisrechners können Sie die Kosten für die in der Architektur verwendeten Dienste schätzen. Weitere bewährte Methoden finden Sie im Microsoft Azure Well-Architected Framework im Abschnitt Kostenoptimierung.

Bereitstellen

  • Bei der Bereitstellung, Verwaltung und dem Betrieb des Kubernetes-Clusters fallen keine Kosten für AKS an. Die wichtigsten Kostenfaktoren sind die VM-Instanzen sowie die Speicher- und Netzwerkressourcen, die vom Cluster beansprucht werden. Wählen Sie für Systemknotenpools eventuell günstigere VMs aus. Die empfohlene SKU ist DS2_v2.

  • Verwenden Sie für Dev/Test- und Produktionsumgebungen unterschiedliche Konfigurationen. Produktionsworkloads weisen zusätzliche Anforderungen für Hochverfügbarkeit auf und sind kostenintensiver. In der Dev/Test-Umgebung ist dies möglicherweise nicht erforderlich.

  • Fügen Sie für Produktionsworkloads eine Betriebszeit-SLA hinzu. Bei Clustern für Dev/Test- oder experimentelle Workloads, bei denen keine Verfügbarkeit garantiert werden muss, sind Einsparungen möglich. Beispielsweise ist das SLO ausreichend. Wenn Ihre Workload dies unterstützt, sollten Sie auch dedizierte Spot-Knotenpools verwenden, in denen Spot-VMs ausgeführt werden.

    Bewerten Sie bei Nicht-Produktionsworkloads, die Azure SQL-Datenbank oder Azure App Service als Teil der AKS-Workloadarchitektur enthalten, ob Sie berechtigt sind, Azure Dev/Test-Abonnements zu nutzen und Dienstrabatte zu erhalten.

  • Beginnen Sie nicht mit einem überdimensionalen Cluster, um die Skalierungsanforderungen zu erfüllen, sondern stellen Sie einen Cluster mit der Mindestanzahl von Knoten bereit, und aktivieren Sie die Autoskalierung, um die Größe zu überwachen und Entscheidungen über Größenänderungen zu treffen.

  • Legen Sie Podanforderungen und -grenzwerte fest, damit Kubernetes Knotenressourcen mit höherer Dichte zuordnen kann und so die Kapazität der Hardware vollständig genutzt wird.

  • Die Aktivierung der Diagnose im Cluster kann zu höheren Kosten führen.

  • Wenn Ihre Workload über einen längeren Zeitraum verwendet wird, können Sie reservierte VM-Instanzen für ein oder drei Jahre erwerben, um die Knotenkosten zu senken. Weitere Informationen finden Sie unter Reservierte VMs.

  • Verwenden Sie beim Erstellen von Knotenpools Tags. Tags sind nützlich für das Erstellen benutzerdefinierter Berichte, um die anfallenden Kosten zu verfolgen. Mit Tags haben Sie die Möglichkeit, die Gesamtausgaben zu verfolgen und einer Ressource oder einem Team bestimmte Kosten zuzuordnen. Wenn der Cluster von mehreren Teams gemeinsam verwendet wird, erstellen Sie darüber hinaus Berichte zur verbrauchsbasierten Kostenzuteilung pro Consumer, um die gemessenen Kosten für freigegebene Clouddienste zu ermitteln. Weitere Informationen finden Sie unter Angeben von Taint, Bezeichnung oder Tag für einen Knotenpool.

  • Datenübertragungen innerhalb von Verfügbarkeitszonen einer Region sind nicht kostenlos. Wenn die Workload mehrere Regionen umfasst oder Übertragungen zwischen Abrechnungszonen erfolgen, müssen Sie mit zusätzlichen Bandbreitenkosten rechnen. Weitere Informationen finden Sie unter Datenverkehr über Abrechnungszonen und Regionen hinweg.

  • Erstellen Sie Budgets, um innerhalb der durch die Organisation festgelegten Kosteneinschränkungen zu bleiben. Eine Möglichkeit besteht darin, Budgets über Azure Cost Management zu erstellen. Sie können auch Warnungen erstellen, um Benachrichtigungen zu erhalten, wenn bestimmte Schwellenwerte überschritten werden. Weitere Informationen finden Sie unter Erstellen eines Budgets mithilfe einer Vorlage.

Überwachen

Um die Kosten für den gesamten Cluster zu überwachen, sammeln Sie zusammen mit den Computekosten auch Kosteninformationen zu Speicher, Bandbreite, Firewall und Protokollen. Azure bietet verschiedene Dashboards zum Überwachen und Analysieren von Kosten:

Im Idealfall überwachen Sie die Kosten in Echtzeit oder zumindest in regelmäßigen Abständen, um ggf. Maßnahmen schon vor dem Monatsende vorzunehmen, wenn die Kosten bereits berechnet werden. Überwachen Sie außerdem den monatlichen Trend, um das Budget einzuhalten.

Um datenzentrische Entscheidungen zu treffen, legen Sie fest, welche Ressource (granulare Ebene) die meisten Kosten verursacht. Außerdem sollten Sie die Verbrauchseinheiten verstehen, die zur Berechnung der Nutzung der einzelnen Ressourcen verwendet werden. Durch die Analyse von Metriken können Sie beispielsweise feststellen, ob die Plattform zu groß ist. Sie finden die Verbrauchseinheiten in den Azure Monitor-Metriken.

Optimieren

Handeln Sie entsprechend den Empfehlungen, die von Azure Advisor bereitgestellt werden. Es gibt auch andere Möglichkeiten für die Optimierung:

  • Aktivieren Sie die Autoskalierung für den Cluster, um wenig ausgelastete Knoten im Knotenpool zu erkennen und zu entfernen.

  • Wählen Sie eine niedrigere SKU für die Knotenpools aus, wenn die Workload dies unterstützt.

  • Wenn die Anwendung keine Burstskalierung erfordert, legen Sie für den Cluster eine gerade ausreichende Größe fest, indem Sie die Leistungsmetriken im Zeitverlauf analysieren.

  • Skalieren Sie Ihre Benutzerknotenpools auf 0 Knoten, wenn nicht erwartet wird, dass diese ausgeführt werden, sofern von Ihrer Workload unterstützt. Wenn in Ihrem Cluster keine weitere Ausführung von Workloads geplant ist, können Sie darüber hinaus die Start-/Beendigungsfunktion von AKS verwenden, um alle Computekomponenten herunterzufahren, einschließlich des Systemknotenpools und der AKS-Steuerungsebene.

Weitere kostenbezogene Informationen finden Sie unter Azure Kubernetes Service (AKS) – Preise.

Nächste Schritte

Wenn Sie Ihre Kubernetes-Kenntnisse auffrischen möchten, empfehlen wir die Lernpfade Einführung in Kubernetes unter Azure sowie Entwickeln und Bereitstellen von Anwendungen auf Kubernetes von Microsoft Learn.