Zustandsbehaftete Workloads in Azure Kubernetes Service (AKS)

Dieser Artikel bietet einen Überblick über die Ausführung und Migration zustandsbehafteter Workloads auf Azure Kubernetes Service (AKS): Entwurfsmuster, Speicheroptionen und Migrationspfade für Datenbanken und zustandsbehaftete Dienste.

Was sind zustandsbehaftete Arbeitslasten?

Eine zustandsbehaftete Workload ist eine Anwendung, die beständigen Datenspeicher verwendet, um den Zustand für mehrere Instanzen zu erhalten und ein nahtloses und personalisiertes Benutzererlebnis sicherzustellen. Dieses Design ist von entscheidender Bedeutung für Dienste wie Onlinebanking, Onlineeinkäufe und E-Mail, bei denen Datenkonsistenz, Sitzungsverlauf und Zuverlässigkeit kritisch sind. Zustandsbehaftete Workloads bieten zudem Effizienz bei Hochleistungs- und nahezu Echtzeit-Verarbeitungsszenarien, die von erweiterten Funktionen wie Failover und Wiederherstellung profitieren und so die Geschäftskontinuität sicherstellen.

Zwar bieten zustandsbehaftete Workloads viele Vorteile, sie stellen aber auch bestimmte Herausforderungen dar. Beispielsweise nutzen zustandsbehaftete Workloads häufig komplexe Verarbeitungsmuster, die zu erhöhtem Mehraufwand und höheren Leistungskosten führen können. Es ist wichtig, dass Sie die spezifischen Anforderungen Ihrer Anwendung verstehen und berücksichtigen, um das richtige Gleichgewicht zwischen Zustandsbehaftung und Zustandslosigkeit zu ermitteln.

Angesichts der entscheidenden Rolle von zustandsbehafteten Workloads bietet Azure mehrere Ansätze, um sie effektiv auszuführen. In diesem Abschnitt werden bewährte Methoden für die Bereitstellung zustandsbehafteter Workloads in Azure Kubernetes Service (AKS) beschrieben, um Entwicklern und Organisationen dabei zu helfen, die am besten geeignete Option für ihre Anforderungen auszuwählen.

Migrieren zustandsbehafteter Workloads zu AKS

Wenn Sie vorhandene zustandsbehaftete Anwendungen zu AKS migrieren, folgen Sie diesem kurzen Migrationsleitfaden, um Risiken zu verringern und die Bereitstellung zu beschleunigen:

  1. Bewerten der Speicher- und Verfügbarkeitsanforderungen: Dokument-IOPS, Durchsatz, Latenz, Haltbarkeit und HA-Anforderungen für Ihre Daten. Ermitteln Sie, ob für Ihre Workload Blockspeicher (Azure Disk), Dateispeicher (Azure Files) oder spezialisierter, CSI-gestützter Speicher benötigt wird.
  2. Wählen Sie einen CSI-Treiber und eine Speichertopologie aus: Wählen Sie den AKS-unterstützten CSI-Treiber aus, der diesen Anforderungen entspricht (z. B. Azure Datenträger-CSI für Blockspeicher, Azure Files CSI für freigegebene Dateispeicherung oder einen CSI eines Drittanbieters für erweiterte Features). Überprüfen Sie, ob Volume-Snapshots und Replikationsanforderungen unterstützt werden.
  3. Bereitstellen mithilfe von StatefulSets oder einem Operator: Migrieren Sie Replikate mit StatefulSets, oder verwenden Sie einen Datenbankoperator, um Failover, Mitgliedschaft und Sicherungen zu verwalten. Validieren Sie das Verhalten bei Wiederherstellung, Failover und Rolling-Upgrade in einer Testumgebung vor der Produktivumschaltung.

Weitere Informationen finden Sie unter Überlegungen zum Migrieren zustandsbehafteter Workloads zu AKS.

Häufige zustandsbehaftete Migrationsszenarien

  • PostgreSQL: Bewerten sie Speicher-IOPS- und HA-Anforderungen, wählen Sie block- oder CSI-gesicherten replizierten Speicher und stellen Sie mit einem StatefulSet- oder einem PostgreSQL-Operator bereit. Siehe PostgreSQL-Anleitungen.
  • MongoDB: Validieren Sie Write-Concern, Journaling und die Replica-Set-Topologie; wählen Sie Speicher aus, der die Anforderungen an Durchsatz und Dauerhaftigkeit erfüllt, und stellen Sie ihn mithilfe von StatefulSets oder des MongoDB-Operators bereit. Siehe MongoDB-Anleitung.

Zustandsbehaftetes Kubernetes-Framework – Foundation-Stapel

Das zustandsorientierte Kubernetes-Framework beginnt mit einem gemeinsamen Basis-Stack. Verwenden Sie in diesem Fall den KATE-Stapel , einen beliebten, standardisierten Stapel, der für viele Infrastrukturprojekte verwendet wird. Der KATE-Stapel verwendet die folgenden Open-Source-Tools:

Die AKS-Richtlinien implementieren ArgoCD oder Terraform nicht, da sie für Day 1-Operationen konzipiert sind. Wenn Ihre Bereitstellung wächst und sich die Anforderungen weiterentwickeln, sollte es für Sie jedoch einfacher sein, ArgoCD und Terraform zu integrieren, da die Anleitungen Teile des KATE-Stacks verwenden.

Zustandsbehaftetes Kubernetes-Framework für Azure

Mit dem eingerichteten Foundation-Stapel müssen wir nun das Framework verbessern, um zustandsbehaftete Workloads in Azure zu unterstützen, insbesondere durch die Integration der wesentlichen Ressourcen für die Ausführung der Dateninfrastruktur in Azure Kubernetes Service (AKS).

Die Unterstützung komplexer zustandsbehafteter Workloads, z. B. Datenbanken oder Nachrichtenwarteschlangen, erfordert Speicherfunktionen, die kurzlebige Optionen überschreiten. Insbesondere benötigen Sie Systeme, die eine erhöhte Resilienz und Verfügbarkeit bieten, um verschiedene Ereignisse zu behandeln, z. B. Anwendungsfehler oder Workload-Neuzuweisungen an verschiedene Hosts. Sie können diese Resilienz erreichen, indem Sie das Subsystem PersistentVolume verwenden, das drei miteinander verbundene Kubernetes-Ressourcen umfasst: PersistentVolumes, PersistentVolumeClaims und StorageClasses. Dieses Subsystem stellt eine API für Benutzer und Administratoren bereit, um die Details zu abstrahieren, wie der Speicher bereitgestellt und genutzt wird.

Die meisten zustandsbehafteten Workloads benötigen Daten aus Geheimnissen, z. B. Verbindungszeichenfolgen, Benutzernamen, Kennwörter und Zertifikate. Azure Key Vault bietet einen sicheren Speicher für Geheimnisse, in dem wir die erforderlichen Geheimnisse für zustandsbehaftete Frameworks speichern.

Wir benötigen auch einen Kubernetes-Controller oder Kubernetes-Operator, wie den Secrets Store CSI-Treiber oder den Operator für externe Geheimnisse, um Geheimnisse geheimer Speicher als Kubernetes-Geheimnisse zu synchronisieren.

Screenshot eines Diagramms mit dem zustandsbehafteten Kubernetes-Framework für Azure.

Entwerfen und Bereitstellen von zustandsbehafteten Workloads in Azure

Wenn Sie eine vorhandene zustandsbehaftete Arbeitslast zu AKS migrieren, starten Sie mit dem Einstieg in die Migration zustandsbehafteter Arbeitslasten zu AKS, um migrationsspezifische Bewertungs- und Validierungsschritte zu überprüfen.

Die folgenden Abschnitte enthalten Links zu Entwurfs- und Bereitstellungsinformationen für Szenarien mit zustandsbehafteten Workloads in Azure.

MongoDB

PostgreSQL

Valkey

Apache Airflow

Apache Kafka mit Strimzi

GitHub-Aktionen mit Azure Files

Note

Obwohl StatefulSets zwar persistente Identitäten und persistenten Speicher bereitstellen, werden Azure Spot-Knotenpools für geschäftskritische zustandsbehaftete Workloads nicht empfohlen. Spot-VMs können mit nur kurzer Vorankündigung verdrängt werden, wenn Azure Kapazität zurückfordert, was zu einer abrupten Beendigung von Knoten und potenziellen Verzögerungen bei der Volumewiederherstellung oder der Pod-Neuplanung führt. Verwenden Sie für Workloads, die von beständigen Daten und hoher Verfügbarkeit abhängen, reguläre Knotenpools und geeignete Speicherresilienzmechanismen. Azure Spot-Knotenpools sollten nur für unterbrechbare Workloads reserviert werden, die einen unerwarteten Knotenausfall verkraften können.

Beitragende

Microsoft pflegt diesen Artikel. Die folgenden Mitwirkenden haben es ursprünglich geschrieben:

  • Don High | Leitender Kundeningenieur
  • Colin Mixon | Produktmanager
  • Erin Schaffer | Inhaltsentwickler 2
  • Last updated on