In diesem speziellen Blog wird beschrieben, wie Volterra Benutzern hilft, ihre Applications und Infrastruktur wie eine Flotte zu betreiben. Wir erläutern, wie unser auf Steuerungsebenen basierender Ansatz den Betrieb einer großen Anzahl von App-Clustern erleichtert, und vergleichen ihn mit anderen Managementebenenansätzen für mehrere Cluster wie Google Anthos, Azure Arc, Rancher usw.
Sie fragen sich jetzt vielleicht, ob wir nur eine Marketingmasche machen und unser Multi-Cluster-Management als Flottenbetrieb bezeichnen! Ansätze für Multi-Cluster-Management und Flottenbetrieb zielen auf unterschiedliche Anwendungsfälle ab und unterscheiden sich grundlegend in ihrer Architektur. Ein Multi-Cluster-Ansatz ist für Szenarien gedacht, in denen relativ wenige Cluster vorhanden sind und der Benutzer diese Infrastruktur-Cluster mithilfe eines konsistenten Betriebsmodells verwalten möchte. Der Flottenansatz hingegen ist für Szenarien mit großen Clustern (z. B. K8s-Cluster in Robotern, der Automobilindustrie, industriellen Gateways, Dutzenden öffentlichen Cloud-Regionen usw.) konzipiert und der Benutzer möchte auf diesen großen Clustern dieselbe Application und dasselbe Netzwerk/die gleiche Sicherheit bereitstellen. In den nächsten beiden Abschnitten werden der Multi-Cluster- und der Flottenbetriebsansatz ausführlicher beschrieben und verglichen.
Ein Multi-Cluster-Management-Ansatz ist für Anwendungsfälle gedacht, bei denen relativ wenige Cluster von einem einzelnen Team verwaltet werden. Beispiele für solche Szenarien sind Dutzende von Clustern in einigen Verfügbarkeitszonen, um den Explosionsradius zu reduzieren. Ebenso können Benutzer sich für die Einrichtung mehrerer Cluster in einigen Regionen entscheiden, um regulatorischen Anforderungen gerecht zu werden.
Die folgenden zwei Beispiele veranschaulichen die Funktionsweise von Multi-Cluster-Lösungen (auf hoher Ebene):
Betrachten wir als Beispiel die Application mithilfe eines Multicluster-Ansatzes von Rancher, wie in Abbildung 1 dargestellt. Bei einem Multi-Cluster-Ansatz wählt der Kunde die Zielsites für die Application nacheinander aus. Dieser Ansatz, bei dem die Zielsites einzeln ausgewählt werden, funktioniert, wenn Sie über mehrere Cluster verfügen. Allerdings ist dieser Ansatz nicht für beispielsweise tausend Cluster ausgelegt.
Abbildung 2 zeigt am Beispiel von Rancher, wie die Beobachtbarkeit in einem Multi-Cluster-Ansatz funktioniert. Bei einem Multi-Cluster-Ansatz muss der Kunde nacheinander auf jeden Cluster doppelklicken, um den Status der bereitgestellten Pods sowie die CPU- und Speicherressourcenauslastung anzuzeigen. Dieser Ansatz, bei dem die Zielstandorte einzeln beobachtet werden, eignet sich für eine kleine Anzahl von Clustern, jedoch nicht für die Verwaltung einer großen Anzahl von Clustern.
Cluster 1:
Cluster 2:
Ein naheliegender Ansatz zur Lösung des im ersten Beispiel beschriebenen Problems wäre, eine Art Automatisierung zu schreiben, die die Aufgaben für jeden der Cluster wiederholt. Wenn beispielsweise ein neuer Cluster hinzugefügt wird, könnte das Skript den folgenden Vorgang ausführen, um eine neue Application bereitzustellen (z. B. „checkoutservice“):
exportiere KUBECONFIG=~/Dokumente/kubeconfig/ce01-ashburn-aws-staging
kubectl apply -f checkoutservice.yaml
Allerdings muss für jeden Vorgang (Bereitstellung, Upgrade, Richtlinie, Ressourcenreservierung usw.) eine Automatisierung erstellt werden. Diese Automatisierung muss nicht nur die einzelnen Vorgänge über viele Cluster hinweg ausführen, sondern sich auch um die Behandlung von Fehlerbedingungen kümmern. Darüber hinaus wird die Automatisierung bei komplexen Szenarien – z. B. Betatests auf einer Teilmenge von Clustern oder fortlaufende Upgrades auf allen Clustern – immer komplexer. Dies haben wir schon früh im Prozess erkannt und eine verteilte Steuerungsebene erstellt, die die gesamte Funktionalität bereitstellt – und zwar mithilfe des im Folgenden beschriebenen Flottenbetriebsansatzes.
Flottenbetrieb bedeutet, dass der Kunde seine Absicht für die Flotte einmal deklarativ definiert und das System die Verantwortung dafür übernimmt, sicherzustellen, dass die betroffenen Sites mit der definierten Absicht übereinstimmen. Beispiele für Absichten sind die Version der Application , die Version der Infrastruktursoftware (z. B. die Version des Betriebssystems), die Netzwerkrichtlinie, die Sicherheitsrichtlinie und die Ressourcenreservierung.
Sobald die Absicht umgesetzt ist, können Benutzer über das System den Status und die Gesundheit der Flotte einsehen. Dies bedeutet, dass die Benutzer eine aggregierte Ansicht des Zustands der Infrastruktur und Applications an allen Standorten der Flotte in einer einzigen Ansicht erhalten, was die betriebliche Komplexität für das Betriebsteam des Kunden reduziert. Benutzer müssen nicht jede Site oder jeden Cluster einzeln anklicken, um den Zustand zu bestimmen und Automatisierungstools zum Aggregieren der Informationen zu schreiben.
Der Flottenbetriebsansatz von Volterra besteht aus drei Hauptkomponenten – Segmentierung, Konfiguration und Beobachtbarkeit, die wir in den folgenden Abschnitten besprechen werden.
Benutzer verfügen in der Flotte häufig über einen Mix aus Sites, beispielsweise Entwicklungs-, Test- und Produktionsrechensites. Aufgrund von Organisationsrichtlinien, z. B. dass Entwicklungs-Workloads nur auf Entwicklungs-Sites ausgeführt werden, müssen unterschiedliche Workloads einem bestimmten Site-Segment zugewiesen werden. Wir ermöglichen Benutzern, Sites flexibel mit einem Label zu versehen, das aus zwei Teilen besteht: Schlüssel und Wert. Beispiele hierfür sind:
Sobald die Sites markiert sind, können Benutzer mithilfe von Schlüssel-Wert-Bedingungen für Labels eine „virtuelle Site“ definieren. In einem Multi-Cloud-Szenario können Benutzer ihre Sites beispielsweise als „Dev“, „Pre-Prod“ und „Prod“ kennzeichnen. Die folgende Abbildung 3 zeigt ein Beispiel für einen Anwendungsfall in der Robotik unter Verwendung der zuvor beschriebenen Label-Key-Werte.
Hier ist ein Konfigurationsausschnitt zu Volterra, wo der Benutzer die Syntax „blend/go-sdk“ verwenden kann, um eine virtuelle Site zu erstellen. In diesem speziellen Beispiel wurden die einzelnen Websites mit dem Label key=ves.io/country und dem Label-Wert ves-io-jpn getaggt.
Benutzer sind an ein Betriebsmodell gewöhnt, bei dem Segmente ihrer Flotte a priori definiert werden und ihre Sites dann zum Zeitpunkt der Bereitstellung markiert werden, um in die Flotte aufgenommen zu werden. Virtuelle Sites fügen sich perfekt in das vorhandene Betriebsmodell der Benutzer ein. Wenn eine neue Site mit dem entsprechenden Tag bereitgestellt wird, wird sie automatisch in die zuvor definierte virtuelle Site aufgenommen, ohne dass zusätzliche manuelle Schritte erforderlich sind. Darüber hinaus erkennt Volterra vorab bereitgestellte Informationen wie den Hardwarehersteller oder den öffentlichen Cloud-Typ, um System-Tags vorab auszufüllen. Benutzer können diese automatisch erkannten Tags optional zum Definieren ihrer virtuellen Sites verwenden.
Die Möglichkeiten zur Flottenkonfiguration lassen sich am besten anhand der folgenden drei Beispiele beschreiben:
Wenn der Flotte eine neue Site mit dem entsprechenden Label hinzugefügt wird, werden die neuen Sites automatisch der virtuellen Site hinzugefügt (in diesem Beispiel „jpn-all-sites“), und die Flottenkonfiguration (d. h. in diesem Beispiel die Kuard-Bereitstellung) wird automatisch auf die neu hinzugefügte Site angewendet, wodurch die Belastung der Betriebsteams verringert und menschliche Fehler vermieden werden.
Virtuelle Sites und virtuelle Kubernetes (vK8s) werden nicht nur für die Konfiguration verwendet, sondern auch, um den Zustand verteilter Sites in der Flotte zu aggregieren. Im Vergleich zu anderen Lösungen, bei denen Benutzer Tools schreiben müssten, um den Status jeder Site einzeln abzurufen und die Informationen zusammenzufassen, ist dies ein wirklich leistungsstarkes Tool. Das System fasst den Gesundheitszustand aller Standorte automatisch in einer einzigen Anzeige zusammen und reduziert so die betriebliche Komplexität für das Betriebsteam des Kunden. Der erfasste Integritätsstatus umfasst viele Aspekte – wie den Bereitstellungsstatus der Application , die Site-Integrität, die Application usw.
Benutzer können sich auf einer Karte einen schnellen Überblick über den Zustand aller ihrer Standorte verschaffen, wie im nächsten Screenshot gezeigt. Die Farbe zeigt an, ob der Gesundheitswert über 75 (grün) liegt, zwischen 40 und 75 (orange) liegt und rot, wenn er unter 40 liegt. Der Integritätswert ist ein Gesamtwert, der sich aus Konnektivität, Zuverlässigkeit, Sicherheit und Leistung (d. h. Ressourcenverbrauch) zusammensetzt.
Benutzer können sich außerdem eine Gesamtansicht der Konnektivität aller ihrer Standorte sowie des Standortzustands anzeigen lassen. Der Verbindungsstatus jeder Verbindung, die die Standorte mit dem Volterra-Backbone verbindet, wird ebenfalls in Abbildung 10 dargestellt. Der Benutzer kann basierend auf dem Integritätsstatus auf Links mit schlechter Leistung klicken, um detaillierte Statistiken zu Anforderungen und Fehlern anzuzeigen und etwaige Verbindungsprobleme zu beheben, wie in Abbildung 11 dargestellt.
Als Nächstes kann der Benutzer aggregierte Informationen über die CPU- und Speicherlastverteilung auf allen Sites anzeigen. Diese Informationen sind für die IT oder Site-Administratoren hilfreich, um zu erkennen, welche Sites stark ausgelastet sind und bei denen die Gefahr einer Ressourcenknappheit besteht. Site-Administratoren können Warnmeldungen einrichten, um benachrichtigt zu werden, wenn der Ressourcenverbrauch bestimmte Schwellenwerte überschreitet. In diesem Screenshot können die Benutzer sehen, dass die Hälfte der Sites mehr als 75 % des verfügbaren Speichers verbraucht. Sie müssen weder auf einzelne Sites klicken noch zusätzliche Tools schreiben, um diese Informationen zu erhalten.
Kontinuierliche Überprüfungsfunktionen für das Flottenobjekt liefern den Status der POD-Bereitstellungen – wie viele PODs bereitgestellt wurden, in Bearbeitung sind oder fehlgeschlagen sind. Nach der Bereitstellung können Benutzer auch den Integritätsstatus der Pods anzeigen – ob sie ausgeführt werden, auf ein Image warten, nicht genügend Arbeitsspeicher vorhanden ist usw.
Darüber hinaus können sich Benutzer eine Gesamtansicht der Wirksamkeit der Sicherheitsrichtlinie anzeigen lassen und Treffer auf allen ihren Websites erhalten, wie im nächsten Screenshot zu sehen ist.
Um mehr darüber zu erfahren, wie Volterras Flottenbetriebsansatz zur Verwaltung einer Flotte von 3000 Clustern eingesetzt wurde, sehen Sie sich Volterras Präsentation auf einer Kubernetes-Konferenz an und lesen Sie diesen Blog von Jakub Pavlik.
Im nächsten Blog mit dem Titel „Zeit bis zur Wirkung“ erkläre ich, wie die verteilte Kontrollebene und das Backbone von Volterra dabei helfen, die Konfigurationskonsistenz über global verteilte Standorte hinweg in sehr kurzer Zeit zu verbreiten und sicherzustellen. Bleiben Sie dran!