Was ist eine gute Kontrollebene zum Betreiben einer großen Anzahl von Kubernetes-Clustern?

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.

Multi-Cluster-Ansatz

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):

Konfiguration

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.

Beobachtbarkeit

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.

Volterras Ansatz für den Flottenbetrieb

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.

Flottensegmentierung

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: 

• Label-Schlüssel=Region. Label-Wert = US-West, JP-Nord, JP-Süd
   
• Modelljahr=(2015, 2016, 2017, 2018)
   
• Funktion=(Sprühen, Schweißen)

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.

Flottenkonfiguration

Die Möglichkeiten zur Flottenkonfiguration lassen sich am besten anhand der folgenden drei Beispiele beschreiben: 

• Konfiguration einer Netzwerk-/Sicherheitsrichtlinie – Nehmen wir das Beispiel eines Kunden, der einen neuen Dienst einführt, bei dem jeder Cluster mit einer bestimmten URL kommunizieren können muss, z. B. github.com . Normalerweise verwenden Benutzer Whitelists, was bedeutet, dass Cluster nur bestimmte Ziele erreichen dürfen. Daher müsste die Einführung dieses neuen Dienstes erfordern, dass Benutzer zu jedem Cluster gehen und die Netzwerkrichtlinie ändern, um github.com zur Whitelist hinzuzufügen. Darüber hinaus möchte der Kunde dies zunächst auf einigen Testsites testen, bevor er es auf allen Sites einführt. Um dieses Ziel auf Volterra zu erreichen, definiert der Kunde zunächst eine virtuelle „Test“-Site auf der Volterra SaaS-Konsole, die ein Segment der Flotte auswählt. Der Benutzer definiert dann eine Netzwerkrichtlinie, beispielsweise die Whitelist mit URLs (in diesem Beispiel github.com ), und wendet sie auf die virtuelle Testsite an. Die verteilte Steuerungsebene von Volterra sendet die Netzwerkrichtlinie an die lokale Steuerungsebene an jedem vom virtuellen Standort ausgewählten Standort (wie oben definiert). Die lokale Steuerebene an jedem Standort wendet die Netzwerkrichtlinie an und sammelt Statistiken über die eingehaltenen Regeln pro Standort. Wenn der Kunde zufrieden ist, dass der Dienst wie erwartet funktioniert, kann er die Netzwerkrichtlinie auf die virtuelle „Prod“-Site anwenden, die die verbleibenden Sites in der Flotte auswählt. Hier ist ein Konfigurationsausschnitt mit Json und der Benutzeroberfläche auf dem Volterra-System.

• Upgrade der Infrastruktursoftware – Mithilfe der Flottenkonfigurationsfunktion kann ein Benutzer die Infrastruktursoftware, z. B. die Betriebssystemversion, für die gesamte Flotte (oder ein Segment der Flotte) aktualisieren. Zunächst definiert der Benutzer, ob er das Betriebssystem von Version 1 auf Version 2 aktualisieren möchte. Als Nächstes definiert der Benutzer eine Bereitstellungsstrategie für die gesamte Flotte, beispielsweise ein fortlaufendes Update oder Blau/Grün. Ein Rolling Update bedeutet, dass das Betriebssystem jedes Standorts in der Flotte (oder jedes Flottensegments) nacheinander aktualisiert wird. Eine Blue/Green-Bereitstellungsstrategie bedeutet, dass der Benutzer das Upgrade auf einer Reihe von „blauen“ Sites (z. B. Entwicklungssites) testen und den Zustand mit „grünen“ Sites (z. B. Produktionssites) vergleichen möchte, die nicht aktualisiert wurden. In beiden Fällen sendet die verteilte Steuerebene von Volterra die Softwareversion 2 an die lokale Steuerebene an jedem Standort, der vom virtuellen Standort ausgewählt wurde und in der Bereitstellungsstrategie definiert ist. Die lokale Steuerebene an jedem Standort aktualisiert das Betriebssystem im A/B-Verfahren, d. h. sie erstellt eine neue Partition, stellt die Version 2 in der neuen Partition bereit und ermöglicht dem Kunden, den Zustand zu messen. Wenn die Installation von Version 2 nicht erfolgreich ist, führt das System automatisch ein Rollback auf Version 1 in der ursprünglichen Partition durch. Hier sind einige Screenshots, wie der Benutzer mithilfe des Volterra SaaS-Portals ein Upgrade der Infrastruktursoftware durchführen kann. Der Benutzer kann die aktuelle Version der Infrastruktursoftware und die neueste verfügbare Softwareversion für alle Sites sehen, wie in der nächsten Abbildung dargestellt. Der Benutzer kann bestimmte oder alle Sites problemlos aktualisieren, je nach Betriebsmodell.

• Flottenweite Bereitstellung von Applications – Volterra bietet ein Objekt namens Virtual Kubernetes (vK8s), mit dem Benutzer mithilfe von Kubernetes-APIs Applications in ihrer gesamten Flotte verwalten können. Der Benutzer stellt seine Applications mithilfe von Standardmethoden von Kubernetes (d. h. Kubeconfig-Datei und Kubernetes-APIs) mit einer Bereitstellungsmanifestdatei bereit und gibt das Sitesegment (oder die gesamte Flotte) an, in dem die Application bereitgestellt werden muss. Anschließend übernimmt Volterras Virtual Kubernetes (vK8s) die Verantwortung für die Bereitstellung der Application an jedem Standort (oder in jedem Segment) der Flotte. Wenn während der Application Fehler wie Verbindungs- oder Infrastrukturfehler auftreten, versucht Volterra Virtual Kubernetes die Bereitstellung fortlaufend erneut und befolgt dabei das Kubernetes-Paradigma eines letztendlich konsistenten Modells. Der nächste Screenshot zeigt ein Beispiel dafür, wie der Benutzer eine Application namens „kuard“ (siehe Kubernetes-up-and-running-demo-app ) auf einer virtuellen Site namens „jpn-all-sites“ bereitstellt, die 140 Sites der Flotte auswählt. Um eine neue Bereitstellung hinzuzufügen, muss der Benutzer einfach eine neue Bereitstellung hinzufügen, indem er auf „Bereitstellung hinzufügen“ klickt und den Bereitstellungsort in Bezug auf die virtuelle Site angibt.

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.

Flottenbeobachtung

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.

Zusammenfassung

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!