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, wie Observability bei einem Multi-Cluster-Ansatz am Beispiel von Rancher funktioniert. Bei einem Multi-Cluster-Ansatz klicken Sie auf jeden Cluster einzeln, um den Status der bereitgestellten Pods sowie die Auslastung von CPU und Arbeitsspeicher einzusehen. Diese Methode, Zielstandorte einzeln zu überwachen, eignet sich nur für wenige Cluster, nicht aber für die Verwaltung großer Clusteranzahlen.
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
Automatisierung müssen Sie für jede Operation entwickeln — Bereitstellung, Upgrade, Richtlinie, Ressourcenreservierung und so weiter. Sie muss nicht nur die einzelnen Vorgänge über viele Cluster hinweg ausführen, sondern auch Fehlerfälle zuverlässig abfangen. Bei komplexen Szenarien — etwa Betatests auf ausgewählten Clustern oder rollierende Upgrades über alle Cluster — steigt der Automatisierungsaufwand stark an. Wir haben das früh erkannt und eine verteilte Steuerungsebene geschaffen, die all diese Funktionen über einen Flottenbetriebsansatz bereitstellt, den wir im Folgenden erläutern.
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.
Sie erhalten auf einer Karte einen schnellen Überblick über den Zustand all Ihrer Standorte, wie im nächsten Screenshot zu sehen. Die Farbe zeigt an, ob der Gesundheitswert über 75 (grün), zwischen 40 und 75 (orange) oder unter 40 (rot) liegt. Der Gesundheitswert fasst Konnektivität, Zuverlässigkeit, Sicherheit und Leistung (also Ressourcenverbrauch) zusammen.
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 können Sie aggregierte Informationen zur CPU- und Speicherauslastung aller Standorte anzeigen. Diese Informationen helfen IT- und Standortadministratoren, stark ausgelastete Standorte zu erkennen, die knapp an Ressourcen geraten. Standortadministratoren richten Alerts ein, um bei Überschreiten definierter Schwellenwerte informiert zu werden. Auf dem Screenshot sehen Sie, dass die Hälfte der Standorte mehr als 75 % des verfügbaren Speichers nutzt. Sie müssen keine einzelnen Standorte anklicken oder zusätzliche Werkzeuge programmieren, um diese Übersicht 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!