Überlegungen zum Betriebsmanagement für Azure Kubernetes Service

  • Artikel

Kubernetes ist eine relativ neue Technologie, die sich stetig und rasant weiterentwickelt und ein umfassendes Ökosystem mitbringt. Deshalb kann die Verwaltung und der Schutz eine Herausforderung darstellen.

Betriebsbaseline für AKS

Wenn Sie Ihre Azure Kubernetes Service-Lösung (AKS) ordnungsgemäß entwerfen und dabei die Verwaltung und Überwachung im Hinterkopf behalten, sind Sie auf einem guten Weg zu Operational Excellence und Customer Success.

Überlegungen zum Entwurf

Berücksichtigen Sie die folgenden Faktoren:

  • Beachten Sie die AKS-Grenzwerte. Verwenden Sie mehrere AKS-Instanzen, um über diese Grenzwerte skalieren zu können.
  • Informieren Sie sich, wie Sie Workloads logisch in einem Cluster und physisch in separaten Clustern isolieren können.
  • Informieren Sie sich, wie Sie den Ressourcenverbrauch von Workloads steuern können.
  • Informieren Sie sich, wie Sie sicherstellen können, dass Kubernetes die Integrität Ihrer Workloads bewerten kann.
  • Informieren Sie sich über die verschiedenen Größen von virtuellen Computern und wie sich die Größen unterscheiden. Größere VMs können mehr Last verarbeiten. Kleinere VMs können einfacher durch andere ersetzt werden, wenn sie für geplante oder ungeplante Wartungsarbeiten nicht verfügbar sind. Informieren Sie sich auch über Knotenpools und VMs in einer Skalierungsgruppe, die unterschiedliche Größen virtueller Computer im selben Cluster zulässt. Größere VMs sind besser geeignet, da AKS einen geringeren Prozentsatz seiner Ressourcen reserviert, wodurch mehr Ressourcen für Ihre Workloads verfügbar sind.
  • Informieren Sie sich über Möglichkeiten zur Überwachung und Protokollierung für AKS. Kubernetes besteht aus verschiedenen Komponenten, und die Überwachung und Protokollierung sollte einen Einblick in Integrität, Trends und potenzielle Probleme geben.
  • Im Rahmen der Überwachung und Protokollierung können viele Ereignisse von Kubernetes und weiteren Anwendungen generiert werden. Durch Warnungen können Sie besser zwischen verlaufsbezogenen Protokolleinträgen und Einträgen unterscheiden, die sofortige Maßnahmen erfordern.
  • Informieren Sie sich über empfohlene Updates und Upgrades. Für Kubernetes werden Haupt-, Neben-und Patchversionen veröffentlicht. Der Kunde sollte diese Updates durchführen, um gemäß der Richtlinie der Upstreamversion von Kubernetes weiterhin Support zu erhalten. Auf Ebene des Workerhosts sind für Betriebssystemkernel-Patches möglicherweise ein Neustart (den der Kunde durchführen muss) sowie Upgrades auf die neue Betriebssystemversion erforderlich. Zusätzlich zum Ausführen von manuellen Upgrades eines Clusters können Sie für den Cluster auch einen Kanal für automatische Upgrades festlegen.
  • Informieren Sie sich über Ressourcenbeschränkungen des Clusters und einzelner Workloads.
  • Machen Sie sich mit den Unterschieden zwischen der horizontalen automatischen Podskalierung und der automatischen Clusterskalierung vertraut.
  • Richten Sie sicheren Datenverkehr zwischen Pods mithilfe der Netzwerkrichtlinien und des Plug-Ins für Azure-Richtlinien ein.
  • Zur Behandlung von Problemen mit in AKS ausgeführten Anwendungen und Diensten müssen Sie möglicherweise die Protokolle untersuchen, die von diesen Komponenten der Steuerungsebene generiert wurden. Sie sollten Ressourcenprotokolle für AKS aktivieren, da die Protokollierung standardmäßig deaktiviert ist.

Empfehlungen

  • Grundlegendes zu AKS-Grenzwerten:

  • Verwenden Sie die logische Isolation auf Namespace-Ebene, um Anwendungen, Teams, Umgebungen und Geschäftseinheiten voneinander zu trennen. Weitere Informationen finden Sie unter Mehrinstanzenfähigkeit und Clusterisolation. Knotenpools können bei Knoten mit verschiedenen Knotenspezifikationen und bei Wartungsarbeiten wie Kubernetes-Upgrades mit mehreren Knotenpools sinnvoll sein.

  • Planen Sie Ressourcenkontingente auf Namespaceebene, und wenden Sie sie an. Wenn Pods keine Ressourcenanforderungen und -grenzwerte definieren, sollten die Bereitstellung durch Richtlinien oder ähnliche Maßnahmen abgelehnt werden. Dies gilt nicht für kube-system-Pods, da nicht für alle dieser Pods Anforderungen und Grenzwerte möglich sind. Überwachen Sie die Ressourcennutzung, und passen Sie Kontingente nach Bedarf an. Grundlegende Scheduler-Features

  • Fügen Sie Integritätstest zu Ihren Pods hinzu. Stellen Sie sicher, dass Pods die AKS-Integritätstests livenessProbe, readinessProbe und startupProbe enthalten.

  • Verwenden Sie VM-Größen, die groß genug sind, um mehrere Containerinstanzen zu enthalten, damit Sie von erhöhter Dichte profitieren können. Sie sollten jedoch nicht so groß sein, dass Ihr Cluster die Workload eines fehlerhaften Knotens nicht bewältigen kann.

  • Verwenden Sie eine Überwachungslösung. Azure Monitor für Container Insights wird standardmäßig eingerichtet und bietet einfachen Zugriff auf viele Erkenntnisse. Sie können die Prometheus-Integration verwenden, wenn Sie tiefergehende Analysen durchführen möchten oder bereits Erfahrung mit Prometheus haben. Wenn Sie auch eine Überwachungsanwendung in AKS ausführen möchten, sollten Sie ebenso Azure Monitor verwenden, um diese Anwendung zu überwachen.

  • Verwenden Sie Azure Monitor Container Insights Metrikwarnungen, um Benachrichtigungen bereitzustellen, wenn eine direkte Aktion erforderlich ist.

  • Verwenden Sie die Funktion für das automatische Skalieren von Knotenpools gemeinsam mit der horizontalen Autoskalierung für Pods, um Anwendungsanforderungen zu erfüllen und die Last bei Spitzen zu verringern.

  • Verwenden Sie Azure Advisor, um Best-Practice-Empfehlungen für Kosten, Sicherheit, Zuverlässigkeit, exzellente operative Prozesse und Leistung zu erhalten. Verwenden Sie zudem Microsoft Defender for Cloud, um Bedrohungen wie Imagesicherheitsrisiken zu verhindern bzw. zu erkennen.

  • Verwenden Sie den Azure Arc-fähigen Kubernetes-Dienst, um Kubernetes-Cluster, die nicht aus AKS stammen, in Azure mithilfe von z. B. Azure Policy, Defender for Cloud und GitOps zu verwalten.

  • Verwenden Sie Podanforderungen und -grenzwerte, um die Computeressourcen in einem AKS-Cluster zu verwalten. Podanforderungen und -grenzwerte informieren den Kubernetes-Scheduler darüber, welche Computeressourcen einem Pod zugewiesen werden sollen.

Geschäftskontinuität/Notfallwiederherstellung zum Schutz und Wiederherstellen von AKS

Ihr Unternehmen muss geeignete AKS-Funktionen (Azure Kubernetes Service) auf Plattformebene entwickeln, um seine spezifischen Anforderungen zu erfüllen. Diese Anwendungsdienste weisen Anforderungen in Bezug auf Recovery Time Objective (RTO) und Recovery Point Objective (RPO) auf. Es gibt mehrere Überlegungen, die für eine AKS-Notfallwiederherstellung angestellt werden müssen. Ihr erster Schritt besteht darin, eine Vereinbarung zum Servicelevel (SLA) für Ihre Infrastruktur und Anwendung zu definieren. Erfahren Sie mehr über die SLA für Azure Kubernetes Service (AKS). Informationen zu monatlichen Uptimeberechnungen finden Sie im Abschnitt SLA-Details.

Überlegungen zum Entwurf

Berücksichtigen Sie die folgenden Faktoren:

  • Der AKS-Cluster sollte mehrere Knoten in einem Knotenpool verwenden, um ein Mindestmaß an Verfügbarkeit für Ihre Anwendung bereitzustellen.

  • Legen Sie Podanforderungen und -grenzwerte fest. Das Festlegen dieser Grenzen ermöglicht Kubernetes Folgendes:

    • Effiziente Vergabe von CPU- und Arbeitsspeicherressourcen an die Pods.
    • Verwendung einer höheren Containerdichte auf einem Knoten.

    Grenzwerte können durch bessere Hardwarenutzung auch die Zuverlässigkeit mit geringeren Kosten erhöhen.

  • AKS-Eignung für Verfügbarkeitszonen oder Verfügbarkeitsgruppen.

    • Wählen Sie eine Region, die Verfügbarkeitszonen unterstützt.
    • Verfügbarkeitszonen können nur beim Erstellen des Knotenpools festgelegt und später nicht mehr geändert werden. Die Unterstützung mehrerer Zonen gilt nur für Knotenpools.
    • 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.
    • Führen Sie für eine höhere Verfügbarkeit, die über die Möglichkeiten von Verfügbarkeitszonen hinausgeht, mehrere AKS-Cluster in verschiedenen Regionspaaren aus. Wenn eine Azure-Ressource Georedundanz unterstützt, geben Sie den Standort der sekundären Region des redundanten Dienstes an.

  • Sie sollten die Richtlinien für die Notfallwiederherstellung in AKS kennen. Überlegen Sie dann, ob sie für die AKS-Cluster gelten, die Sie für Azure Dev Spaces verwenden.

  • Erstellen Sie beständig Sicherungen für Anwendungen und Daten.

    • Ein nicht zustandsbehafteter Dienst kann effizient repliziert werden.
    • Wenn Sie den Zustand im Cluster speichern müssen, sichern Sie die Daten häufig in der gekoppelten Region. Das ordnungsgemäße Speichern des Zustands im Cluster kann kompliziert sein.

  • Clusterupdate und -wartung

    • Halten Sie Ihren Cluster immer auf dem neuesten Stand.
    • Beachten Sie den Release- und Einstellungsprozess.
    • Planen Sie Ihre Updates und Wartungen.

  • Netzwerkkonnektivität bei einem Failover

    • 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.

  • Geplantes und ungeplantes Failover

    • Wählen Sie bei der Einrichtung der einzelnen Azure-Dienste Features aus, die die Notfallwiederherstellung unterstützen. Diese Architektur ermöglicht beispielsweise Azure Container Registry für die Georeplikation. Sie weiterhin Images aus dem replizierten Bereich pullen, wenn eine Region ausfällt.

  • Verwalten Sie DevOps-Entwicklungsfunktionen, um Ziele für den Servicelevel zu erreichen.

  • Bestimmen Sie, ob Sie eine finanziell abgesicherte SLA für Ihren Kubernetes-API-Serverendpunkt benötigen.

Entwurfsempfehlungen

Im Folgenden finden Sie bewährte Methoden für Ihren Entwurf:

  • Verwenden Sie drei Knoten für den Systemknotenpool. Beginnen Sie für den Benutzerknotenpool mit mindestens zwei Knoten. Wenn Sie eine höhere Verfügbarkeit benötigen, richten Sie weitere Knoten ein.

  • Isolieren Sie Ihre Anwendung von den Systemdiensten, indem Sie sie in einem separaten Knotenpool platzieren. Auf diese Weise werden Kubernetes-Dienste auf dedizierten Knoten ausgeführt und konkurrieren nicht mit anderen Diensten. Verwenden Sie Tags, Bezeichnungen und Taints, um den Knotenpool zum Planen der Workload anzugeben.

  • Für die Zuverlässigkeit ist eine regelmäßige Wartung Ihres Clusters entscheidend, z. B. durch rechtzeitige Updates. Achten Sie auf das Supportfenster der Kubernetes-Versionen in AKS, und planen Sie Ihre Updates. Außerdem wird empfohlen, die Integrität der Pods mithilfe von Tests zu überwachen.

  • Wann immer möglich, entfernen Sie den Dienststatus aus Containern. Verwenden Sie stattdessen einen Azure-Platform-as-a-Service (PaaS), der die Replikation in mehreren Regionen unterstützt.

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

  • Richten Sie mehrere Replikate in der Bereitstellung ein, 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.

  • Ihre Anwendungen nutzen möglicherweise Azure Storage für ihre Daten. Weil Ihre Anwendungen auf mehrere AKS-Cluster in verschiedenen Regionen verteilt sind, müssen Sie dafür sorgen, dass die Speicherinstanzen synchron bleiben. Zwei allgemeine Verfahren zum Replizieren von Speicher sind:

    • Infrastrukturbasierte asynchrone Replikation
    • Anwendungsbasierte asynchrone Replikation

  • Schätzen Sie Podgrenzwerte. 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. Podgrenzwerte können in Ihren Bereitstellungsmanifesten angegeben werden.

    Die integrierten Features bieten eine Lösung für die komplexe Aufgabe der Behandlung von Fehlern und Unterbrechungen in der Dienstarchitektur. Diese Konfigurationen tragen dazu bei, sowohl den Entwurf als auch die Bereitstellung zu automatisieren. Wenn ein Unternehmen einen Standard für SLA, RTO und RPO definiert hat, kann es integrierte Dienste in Kubernetes und Azure verwenden, um seine Geschäftsziele zu erreichen.

  • Legen Sie Budgets für die Unterbrechung von Pods fest. Mit dieser Einstellung wird geprüft, wie viele Replikate in einer Bereitstellung bei einem Update- oder Upgradereignis außer Betrieb genommen werden können.

  • Erzwingen Sie Ressourcenkontingente für die Dienstnamespaces. Das Ressourcenkontingent für einen Namespace stellt sicher, dass Podanforderungen und -grenzwerte für eine Bereitstellung ordnungsgemäß festgelegt werden.

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

  • Speichern Sie Ihre Containerimages in Azure Container Registry (ACR), und erstellen Sie per Georeplikation in jeder AKS-Region eine Instanz der Registry.

  • Verwenden Sie die Betriebszeit-SLA, um eine finanziell gesicherte, höhere SLA für alle Cluster zu ermöglichen, die Produktionsworkloads hosten. Betriebszeit-SLA garantiert eine Verfügbarkeit von 99,95 % des Kubernetes-API-Serverendpunkts für Cluster, die Verfügbarkeitszonen verwenden, und eine Verfügbarkeit von 99,9 % für Cluster, die keine Verfügbarkeitszonen verwenden. Ihre Knoten, Knotenpools und andere Ressourcen sind unter ihrer SLA abgedeckt. AKS bietet eine kostenlose Dienstebene mit einem Servicelevelziel (SLO) von 99,5 % für seine Steuerungsebenenkomponenten. Cluster ohne aktivierte Uptime-SLA sollten nicht für Produktionsworkloads verwendet werden.

  • Verwenden Sie mehrere Regionen und Peeringstandorte für Azure ExpressRoute-Verbindungen.

    Eine redundante hybride Netzwerkarchitektur kann bei einem Ausfall einer Azure-Region oder eines Peering-Anbieterstandorts dazu beitragen, eine unterbrechungsfreie, standortübergreifende Konnektivität zu gewährleisten.

  • Verbinden Sie Regionen mit globalem Peering virtueller Netzwerke. Wenn die Cluster miteinander kommunizieren müssen, verbinden Sie die beiden virtuellen Netzwerke über Peering virtueller Netzwerken miteinander. Diese Technologie verbindet virtuelle Netzwerke miteinander und bietet eine hohe Bandbreite für das Backbone-Netzwerk von Microsoft, auch über geografische Regionen hinweg.

  • Durch Verwendung des TCP-basierten geteilten Anycast-Protokolls stellt Azure Front Door sicher, dass Ihre Endbenutzer sofort mit dem nächstgelegenen Front Door-POP (Point of Presence) verbunden werden. Weitere Features von Azure Front Door sind:

    • TLS-Terminierung
    • Benutzerdefinierte Domäne
    • Web Application Firewall
    • URL Rewrite
    • Sitzungsaffinität

    Überprüfen Sie die Anforderungen des Anwendungsdatenverkehrs, um zu erfahren, welche Lösung sich am besten eignet.