In diesem Blogbeitrag gehen wir darauf ein, wie MyScale unterbrechungsfreie Kubernetes-Upgrades für seine replizierten Cluster erreicht. Als gehosteter Dienst in der AWS-Cloud und unter Verwendung von Amazon EKS bietet MyScale eine robuste und skalierbare Database-as-a-Service (DBaaS). Wir werden die globale und regionale Architektur von MyScale erkunden, die Herausforderungen des automatischen Skalierens und der Kubernetes-Upgrades angehen und unsere Strategien für nahtlose Migrationen von Benutzerclustern erläutern, während der laufende Betrieb gewährleistet bleibt.
# Erkundung der Architektur von MyScale
MyScale (opens new window) ist ein Database-as-a-Service (DBaaS), das auf der AWS-Cloud-Plattform aufbaut. Alle seine Dienste werden auf dem verwalteten Kubernetes-Dienst von AWS, Amazon EKS (opens new window), bereitgestellt, was MyScale die Möglichkeit gibt, die leistungsstarken Funktionen von Kubernetes voll auszunutzen, wie z.B. Service Discovery, Lastverteilung, automatische Skalierung und Sicherheitsisolierung.
Wie im folgenden Diagramm dargestellt, haben wir eine hochelastische und skalierbare Architektur mit einer globalen Ebene und Webdiensten (opens new window), Benutzerverwaltung, Zahlungsabwicklung usw. entworfen. Darüber hinaus haben wir mehrere regionale Dienste, die sich an verschiedenen geografischen Standorten befinden, wobei jeder regionale Dienst die gleichen Funktionen wie das Erstellen, Verwalten, Upgraden und Löschen von Benutzerclustern sowie die Überwachung der Nutzung und die Bereitstellung von Anwendungsschnittstellen bietet.
Darüber hinaus besteht jeder regionale Dienst aus einer einzelnen Kontrollebene und mehreren Datenplänen.
Die Kontrollebene einer Region ist ihr Gehirn und ist für die Aufgaben- oder Anforderungsverwaltung und -planung verantwortlich. Sie dient auch als Verbindung zwischen dem Datenplan und der globalen Ebene, indem sie die von der globalen Ebene ausgestellten Verwaltungsanfragen akzeptiert und an den entsprechenden Datenplan zur Ausführung weiterleitet. Darüber hinaus ist diese Kontrollebene für die Erfassung von Daten und die Überwachung des Status und der detaillierten Nutzungsdaten jedes Datenplans verantwortlich, um sicherzustellen, dass Benutzercluster ordnungsgemäß auf dem Datenplan ausgeführt werden.
Jede Ebene entspricht einem unabhängigen K8s-Cluster, und unter normalen Umständen erfordert das Erstellen und Verwalten dieser Cluster eine große Anzahl von Cloud-Ressourcen - insbesondere für das Erstellen und Konfigurieren von Kubernetes-Clustern. Wir verwenden Crossplane (opens new window), um Infrastruktur, Anwendungen und Benutzercluster effizient und einheitlich mit Kubernetes-Patterns zu verwalten.
Aufgrund der unterschiedlichen Spezifikationen der Benutzercluster haben wir verschiedene NodeGroups (opens new window) für einzelne Benutzercluster-Spezifikationen und Arbeitslasten erstellt, um die Ressourcennutzung auf dem Datenplan zu maximieren. Mit Hilfe des Cluster Autoscaler (opens new window) haben wir die automatische Skalierung von Kubernetes-Clustern erreicht.
apiVersion: eks.aws.crossplane.io/v1alpha1
kind: NodeGroup
metadata:
name: <eks-nodegroup-name>
spec:
forProvider:
region: us-east-1
clusterNameRef:
name: <eks-cluster-name>
subnets:
- subnet-for-us-east-1a
- subnet-for-us-east-1b
- subnet-for-us-east-1c
labels:
myscale.com/workload: db
myscale.com/instance-type: <myscale-instance-type>
taints:
- key: myscale.com/workload
value: db
effect: NO_EXECUTE
instanceTypes:
- <instance-type>
- <instance-type>
scalingConfig:
maxSize: 100
minSize: 3
# Herausforderungen des automatischen Skalierens in Kubernetes
Die Verwendung von NodeGroups funktionierte anfangs sehr gut, aber mit der Erweiterung der Benutzercluster-Spezifikationen traten zwei Probleme auf:
- Die NodeGroup verteilt sich nicht gleichmäßig über die verfügbaren Zonen, sondern konzentriert die Benutzercluster allmählich in einer der verfügbaren Zonen, wenn diese Cluster erstellt, gelöscht, gestartet und gestoppt werden.
- Das Minimum (
minSize) einer NodeGroup muss immer ungleich Null sein. Wenn es in einigen Fällen auf Null gesetzt wird, z.B. wenn ein Pod eine vorhandene PVC verwendet, wird die automatische Skalierung nicht ausgelöst, und der Pod bleibt dauerhaft ausstehend.
Um eine Lösung für diese Probleme zu finden, haben wir bei der Untersuchung der Cluster Autoscaler-Protokolle und der folgenden Dokumente auf dieses Phänomen hingewiesen:
Protokolle:
Found multiple availability zones for ASG "eks-nodegroup-xxxxxxx-90c4246a-215b-da2a-0ce8-c871017528ab"; using us-east-1a for failure-domain.beta.kubernetes.io/zone label
Dokumente:
- https://aws.github.io/aws-eks-best-practices/cluster-autoscaling/#scaling-from-0 (opens new window)
- https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md#auto-discovery-setup (opens new window)
Basierend auf bewährten Verfahren in den Referenzdokumenten haben wir die ursprüngliche Multi-Availability-Zone in der NodeGroup so geändert, dass sie mehrere Single-Availability-Zone-NodeGroups repräsentiert. Darüber hinaus wurde die Skalierung von Null durch Konfiguration von ASG-Tags implementiert.
Die Konfiguration wird im folgenden YAML-Skript beschrieben:
apiVersion: eks.aws.crossplane.io/v1alpha1
kind: NodeGroup
metadata:
name: <eks-nodegroup-name-for-az1>
spec:
forProvider:
region: us-east-1
clusterNameRef:
name: <eks-cluster-name>
subnets:
- subnet-for-us-east-1a
labels:
myscale.com/workload: db
myscale.com/instance-type: <myscale-instance-type>
tags:
k8s.io/cluster-autoscaler/node-template/label/topology.kubernetes.io/region: us-east-1
k8s.io/cluster-autoscaler/node-template/label/topology.kubernetes.io/zone: us-east-1a
k8s.io/cluster-autoscaler/node-template/label/topology.ebs.csi.aws.com/zone: us-east-1a
k8s.io/cluster-autoscaler/node-template/taint/myscale.com/workload: db:NO_EXECUTE
k8s.io/cluster-autoscaler/node-template/label/myscale.com/workload: db
k8s.io/cluster-autoscaler/node-template/label/myscale.com/instance-type: <myscale-instance-type>
taints:
- key: myscale.com/workload
value: db
effect: NO_EXECUTE
instanceTypes:
- <instance-type>
- <instance-type>
scalingConfig:
maxSize: 100
minSize: 0
# Umgang mit Upgrades von Kubernetes
Wir wurden bald damit beauftragt, unsere K8s-Cluster aufgrund der AWS-Auslaufbenachrichtigung für EKS 1.24 zu aktualisieren. Die Herausforderung bestand darin, vor dem Support-Ende auf die neueste Version zu aktualisieren.
Gemäß dem Veröffentlichungskalender (opens new window) wird AWS dann innerhalb von vierzehn Monaten nach dem Veröffentlichungsdatum dieser neuen Versionen Support bereitstellen.
Wir haben den von AWS bereitgestellten Aktualisierungsprozess anhand der von ihnen bereitgestellten Dokumentation getestet:
- https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html (opens new window)
- https://docs.aws.amazon.com/eks/latest/userguide/update-managed-node-group.html (opens new window)
- https://docs.aws.amazon.com/eks/latest/userguide/managed-node-update-behavior.html (opens new window)
Bei den Tests sind wir auf folgende Probleme gestoßen:
- Es ist nicht möglich, mehrere Versionen gleichzeitig zu aktualisieren; es kann immer nur eine Version auf einmal aktualisiert werden, und maximal drei Versionen können innerhalb eines Jahres aktualisiert werden.
- Die Upgrade-Zeit für die NodeGroup ist relativ lang. Eine einzelne NodeGroup dauert mehrere Minuten, während Pods migriert oder zwangsweise migriert werden.
Häufige Version-Upgrades in Verbindung mit langen Upgrade-Zeiten und erzwungener Pod-Migration könnten potenziell zu einer abnormalen Unterbrechung bestehender Netzwerkverbindungen führen und die Benutzercluster des Datenplans erheblich beeinträchtigen, wodurch Benutzer auf den Systemstatus (opens new window) achten müssen, um mögliche Probleme zu bewältigen.
Um Lösungen für diese Herausforderungen zu finden, haben wir die relevanten AWS EKS-Dokumente studiert und folgende hilfreiche Informationen gefunden:
- Die EKS-Kontrollebene und die NodeGroup können um eine Version abweichen. Ab EKS 1.28 ist eine Abweichung von zwei Versionen zulässig.
- Nachdem die EKS-Kontrollebene aktualisiert wurde, kann eine NodeGroup mit der Version der Kontrollebene erstellt werden, um neben der alten NodeGroup zu existieren, die nicht aktualisiert wurde.
Basierend auf diesen Punkten haben wir folgende Änderungen vorgenommen:
- Wir haben der Konfiguration der vorhandenen NodeGroup ein
instance-version-Label hinzugefügt:
labels:
myscale.com/instance-version: v1.24
- Anschließend haben wir die EKS-Kontrollebene aktualisiert:
apiVersion: eks.aws.crossplane.io/v1beta1
kind: Cluster
metadata:
name: <eks-cluster-name>
spec:
forProvider:
version: "1.25"
Nach Abschluss der Aktualisierung der EKS-Kontrollebene werden wir die alte/vorhandene NodeGroup nicht aktualisieren. Stattdessen erstellen wir eine neue NodeGroup basierend auf der aktualisierten EKS-Kontrollebene-Version und fügen ein Label hinzu, um die Version zu kennzeichnen.
labels:
myscale.com/instance-version: v1.25
Anschließend haben wir die folgende Konfiguration zum Cluster-Controller hinzugefügt, um die Planung von Benutzerclustern während des Übergangszeitraums der Upgrade-Version zu unterstützen:
node_group:
default: v1.25
allowed:
- "v1.25"
- "v1.24"
Jetzt werden neu erstellte Benutzercluster oder Benutzercluster, bei denen Benutzer Version-Upgrades, Neustarts usw. aktiv auslösen, standardmäßig der als v1.25 gekennzeichneten NodeGroup zugeordnet, während andere Cluster unverändert bleiben. Wir haben das Problem der Pod-Migration während des EKS-Upgrades gelöst und es für Benutzer transparent gemacht.
Beachten Sie, dass EKS 1.28 eine Abweichung von zwei Versionen unterstützt - für 1.26 und höher können wir die EKS-Kontrollebene um zwei aufeinanderfolgende Versionen aktualisieren, wodurch die Anzahl der Upgrades halbiert wird.
# Strategie für Upgrades von Benutzerclustern
Einige Benutzercluster werden jedoch immer noch auf der alten v1.24 NodeGroup ausgeführt.
Wann werden diese Cluster migriert?
Bevor wir dieses Problem diskutieren, wollen wir die Benutzercluster zunächst wie folgt kategorisieren:
- Benutzercluster mit mehreren Replikaten
- Benutzercluster mit einem Replikat
Die Replikate für einen Benutzercluster mit mehreren Replikaten befinden sich auf mehreren Knoten in verschiedenen Verfügbarkeitszonen. Neue Benutzeranfragen können an andere Pods durch den Lastenausgleicher geplant werden, sodass die zu migrierenden Pods keine neuen Benutzeranfragen mehr bearbeiten. Sobald die vorhandenen Anfragen verarbeitet sind, kann der Pod migriert werden. Die Migration des Benutzerclusters kann abgeschlossen werden, indem dieser Vorgang wiederholt wird, bis alle Pods in einem Benutzercluster mit mehreren Replikaten migriert wurden.
Der Benutzertyp "Benutzercluster mit einem Replikat" enthält jedoch nur einen einzigen Pod; die Logik des Benutzerclusters mit mehreren Replikaten kann nicht angewendet werden.
Wie gehen wir also mit dieser Migration um? Können wir uns auf die Methode für Benutzercluster mit mehreren Replikaten beziehen und diese wiederverwenden?
Wenn das Replikationsmechanismus von MyScale den Cluster erweitert und Replikate hinzufügt, synchronisieren die neu erstellten Replikate automatisch Daten von den vorhandenen Replikaten, wobei mehrere Replikate gleichzeitig Dienste bereitstellen, nachdem die Datensynchronisierung abgeschlossen ist.
Daher müssen wir nur den zu migrierenden Benutzercluster konfigurieren.
apiVersion: db.myscale.com/v1alpha1
kind: Cluster
metadata:
name: <cluster-name>
spec:
replicas: 1
shards: 1
......
Erweiterung vor der Migration von einem einzelnen Replikat auf ein doppeltes Replikat:
apiVersion: db.myscale.com/v1alpha1
kind: Cluster
metadata:
name: <cluster-name>
spec:
replicas: 2
shards: 1
......
Verwenden Sie dann die Migrationslogik der Benutzercluster mit mehreren Replikaten, um die Migration durchzuführen. Nach Abschluss der Migration skalieren Sie herunter und löschen Sie die zusätzlichen Pods.
Schließlich wurden alle Benutzercluster migriert. Die Pods auf den Knoten der alten NodeGroup wurden alle migriert. Der Cluster Autoscaler löscht automatisch die leeren Knoten in der alten NodeGroup. Wir müssen nur die NodeGroup mit einer Knotengröße von Null überprüfen und löschen. Dieser Prozess hat keine Auswirkungen auf Benutzer, und EKS wurde vollständig auf die neue Version aktualisiert.
# Abschließend
Unsere Reise durch diese architektonischen Herausforderungen und Upgrades hat die Robustheit und Effizienz von MyScale erhöht und eine unterbrechungsfreie Durchführung kritischer Kubernetes-Upgrades gewährleistet. Diese Reise spiegelt unsere Verpflichtung wider, unseren Benutzern ein nahtloses DBaaS-Erlebnis mit hoher Leistung zu bieten.
