Steuerebene für verteilte Kubernetes PaaS

(Ankur Singla) (15. November) , 2019)

Autoren : Ankur Singla , Harshad Nakil

Dieser Blog ist der erste in einer Reihe von Blogs, die verschiedene Aspekte dessen abdecken, was wir für den Aufbau und den Betrieb unseres Blogs benötigt haben SaaS -Dienst:

  1. Steuerebene für verteilte Kubernetes PaaS
  2. (globales Service-Mesh für verteilte Anwendungen)
  3. (Plattformsicherheit verteilter Infrastrukturen, Apps und Daten)
  4. (Anwendungs- und Netzwerksicherheit verteilter Cluster)
  5. Beobachtbarkeit auf einer global verteilten Plattform
  6. Betrieb und SRE einer global verteilten Plattform
  7. Golang-Service-Framework für verteilten Mikroservice s

Wie wir in unserem früheren Blog beschrieben haben, bauen unsere Kunden komplexe und vielfältige Geschäftslösungen – wie smart Fertigung, Video-Forensik für die öffentliche Sicherheit, algorithmischer Handel, 5G-Telekommunikationsnetze – und daher müssen wir diesen Anwendungen und ihren Endbenutzern eine stets aktive, vernetzte und zuverlässige Erfahrung bieten.

Seit diesen Anwendungen Unser Plattformteam konnte eine verteilte Steuerungsebene und einen PaaS-Service erstellen, um mehrere Kubernetes-Cluster mit mehreren Mandanten bereitzustellen, zu sichern und zu betreiben. Diese verteilte Steuerebene bietet viele Betriebs-, Skalierungs- und Leistungsvorteile, die wir in unserer Präsentation ( behandeln werden Videolink ) – z Wie man Tausende von Edge-K8s-Clustern mit GitOps verwaltet – und auch als separaten Blog-Beitrag in den kommenden Wochen.

TL; DR (Zusammenfassung)

  1. Wir konnten nicht finden Eine einfach zu verwendende Lösung auf dem Markt, die das Problem der Bereitstellung, Sicherung und des Betriebs mehrerer Anwendungscluster lösen könnte, die auf Cloud-Anbieter, Private Clouds oder mehrere Edge-Standorte verteilt sind.
  2. Wir konnten keine robuste Lösung finden Kubernetes-Distribution oder PaaS (z. B. OpenShift, Cloud Foundry usw.), die eine umfassende Reihe von Sicherheits- und Betriebsdiensten bereitstellten, die für verteilte Cluster erforderlich sind – beispielsweise PKI-basierte Identitäts-, RBAC- und Benutzerzugriffsverwaltung, Geheimnisse und Schlüsselverwaltung zwischen Cloud-Anbietern , Multi-Cluster-Service-Mesh, Beobachtbarkeits- und Überwachungsprotokolle oder Anwendungs- und Netzwerksicherheit.
  3. Anthos (Google), Azure Arc (Microsoft) und Rancher sind Multi-Cluster-Verwaltungsstationen und das Packen mehrerer verschiedener Services ;; Unsere Analyse ergab, dass diese die Anforderungen an Betrieb, Skalierung, Sicherheit und Mandantenfähigkeit, die wir für Anwendungs- und Infrastrukturdienste in mehreren Clustern hatten, nicht gelöst hätten.
  4. Wir mussten unsere eigene verteilte Steuerungsebene für erstellen Unser verwaltetes PaaS, das auf Kubernetes basiert. Wir haben mit Vanilla Kubernetes begonnen und dann wesentliche Änderungen vorgenommen, um die von unseren DevOps- und SRE-Teams benötigten Plattformdienste bereitzustellen. Darüber hinaus mussten wir eine Steuerebene erstellen, um eine große Anzahl verteilter Cluster zu verwalten und Mandantenfähigkeit über heterogene Infrastrukturen (in Edge, unserem Netzwerk und mehreren Cloud-Anbietern) bereitzustellen.

Kubernetes für die App-Verwaltung: Warum & Wie

Wir haben Kubernetes (K8s) als Kern unserer Plattform für die Verwaltung verteilter Anwendungen ausgewählt, da es eine Vielzahl von Funktionen bietet ohne zu streng zu sein – gibt uns Flexibilität bei der Innovation von Dingen, von denen wir glauben, dass sie für unsere Kunden wichtig sind. Wir haben dies als Grundlage für den Aufbau unseres Dienstes verwendet. Mit der wachsenden Beliebtheit von K8s ist es auch einfacher, Entwickler und Betreiber zu finden, die damit vertraut sind.

Das Bereitstellen und Verwalten einer großen Anzahl von Kubernetes-Clustern in Produktionsqualität in einer Hybridumgebung (mehrere Clouds, Netzwerk-POPs und Edge-Standorte) ist jedoch nicht sehr einfach, da es keine Out-of-the-Systeme gibt -box-Lösungen für Kubernetes, die:

  1. heterogene Infrastrukturressourcen mit automatisiertem Clustering, Skalierung und Zero-Touch-Bereitstellung harmonisieren können; Dies war am Rande und in unseren Netzwerk-PoPs besonders schmerzhaft.
  2. Bieten Sie leistungsstarke und zuverlässige Konnektivität über unterschiedliche Standorte hinweg – insbesondere, wenn Sie Cloud-Anbieter überqueren und von Randstandorten kommen.
  3. Lösen Sie die Sicherheit Problem der Datenübertragung, der Daten im Ruhezustand, der Geheimnisse, der Schlüssel und des Netzwerks… alles unterstützt durch eine einheitliche PKI-Identität, die über Edge, Netzwerk und Cloud hinweg funktioniert.
  4. Bietet echte Mandantenfähigkeit – Mandantenisolation und Sicherheitsgarantien – mit der Fähigkeit, Produktions- und Entwicklungs-Workloads für interne und Kundenanforderungen in denselben Clustern auszuführen
  5. Bieten Sie Beobachtbarkeit und Betrieb über verteilte Cluster hinweg, die mit zentralisierten Richtlinien und Absichten verknüpft sind, ohne dass Komplexe erstellt werden müssen Erfassung von Protokollen und Metriken

Nach mehreren Proofs-of-Concept mit mehreren Cloud-Anbietern und Open-Source-Plattformen wie GKE, AKS, EKS und RKE sowie OpenShift und Cloud Foundry wurde uns klar dass keiner von ihnen alle fi treffen konnte ve Anforderungen oben. Aus diesem Grund haben wir uns entschlossen, ein eigenes PaaS zu erstellen – beginnend mit „Vanille“ -Kubernetes und mehrere Ergänzungen – für Identität, Netzwerk, Sicherheit, Mandantenfähigkeit, Protokollierung, Metriken usw. Während wir Kubernetes verwenden, um unsere internen Anforderungen zu erfüllen, Wir mussten einige schwierige Entscheidungen treffen, z. B. diese Kubernetes-Cluster nicht direkt unseren internen Benutzern und / oder Kunden zur Verfügung zu stellen, um ihre Workloads auszuführen (dazu später mehr, da Mandantenfähigkeit ein wichtiges Ziel für uns war).

Zusätzlich zu mehreren neuen Funktionen, die wir hinzufügen mussten, mussten unsere Workloads / Services neben Kunden-Workloads an vielen Standorten am Rande, in unserem Netzwerk und in öffentlichen / privaten Clouds ausgeführt werden. Dies bedeutete, dass wir zusätzliche Funktionen zum Verwalten mehrerer Cluster in mehreren Umgebungen aufbauen mussten. Alle waren über unser globales Netzwerk und unsere verteilten Anwendungsgateways verbunden, um eine vertrauenslose Verbindung und Konnektivität auf Anwendungsebene über diese Cluster hinweg zu gewährleisten.

Die Schwieriger Teil: Mandantenfähigkeit und Multi-Cluster für Kubernetes

Das Erstellen und Betreiben von Anwendungen, die in einem einzelnen Kubernetes-Cluster ausgeführt werden, ist keine triviale Aufgabe, selbst wenn ein von einem Cloud-Anbieter verwalteter Cluster verwendet wird. Aus diesem Grund ist es üblich, dass DevOps- und SRE-Teams ihren Overhead minimieren und sich nicht mit der Komplexität vieler Cluster befassen. Es ist durchaus üblich, dass Teams einen großen Kubernetes-Cluster erstellen und alle Arten von Ressourcen in demselben Cluster platzieren. Dies scheint großartig zu sein, da sie den Betrieb vereinfachen und den Cluster für maximale Recheneffizienz und Kosten ausführen können. Dies ist jedoch aus mehreren Gründen nicht die beste Idee. Erstens unterscheiden sich die Anforderungen an Produktions-Workloads stark vom Dev-Test und vom Staging. Instabile Entwicklungs-Workloads können möglicherweise Probleme für stabilere Produktions-Workloads verursachen.

Zusätzlich zu den Anforderungen an unterschiedliche Workloads, K8s Sicherheit und Isolationsbeschränkungen sind ein weiterer Treiber für Multi-Cluster. Ein typischer Lösungsansatz für die Sicherheit und Ressourcenisolation von K8 besteht darin, unabhängige Cluster für jeden Mandanten mithilfe eines Mandantenmodells hochzufahren. Während dies in der Cloud möglich ist, ist es am Rand nicht möglich, mehrere Cluster auszuführen. Edge-Sites haben Einschränkungen hinsichtlich Rechen- und Speicherressourcen sowie eine eingeschränkte Netzwerkbandbreite, um Protokolle und Metriken für jeden zusätzlichen Cluster an die zentrale Cloud zu senden.

Um das Problem mehrerer Kubernetes-Cluster zu lösen, haben wir Rancher für die zentrale Verwaltung von evaluiert Unsere Kubernetes-Cluster (als wir anfingen, Anthos und Azure Arc existierten nicht) und KubeFed. Die beiden damals verfügbaren Ansätze waren (und heute immer noch dieselbe Situation):

  1. Die Verwaltung mehrerer Cluster (z. B. Rancher) über eine zentrale Konsole hätte uns die Möglichkeit gegeben, mehrere Cluster bereitzustellen Einige dieser Systeme ermöglichten es auch, einen einzelnen Cluster mit Automatisierung für die Konfiguration und Bereitstellung von Anwendungen zu adressieren.
  2. Ein anderer Ansatz ist die Bereitstellung eines Kubernetes KubeFed-Steuerebene (Cluster Federation) kann dazu führen, dass mehrere physische Cluster wie ein Cluster aussehen. Dieses Projekt wurde gerade erst gestartet, als wir es uns angesehen haben, und befindet sich auch heute noch im Alpha-Stadium.

Nach der kürzlichen Ankündigung von GCP Anthos und Azure Arc haben wir unsere ursprüngliche Entscheidung für neu bewertet Aufbau einer verteilten Steuerebene und die Schlussfolgerung war, dass selbst diese beiden neuen Angebote zwei kritische Probleme mit verteilten Clustern nicht hätten lösen können.Diese beiden Schlüsselfunktionen, die wir für unsere Plattform benötigten, waren:

  1. Verwalten mehrerer Cluster als Flotte, um das Problem der Ausführung von Vorgängen über alle oder eine logische Gruppe von Clustern hinweg zu lösen – Vorgänge wie Konfiguration, Bereitstellung, Metriken usw. Dies ist von entscheidender Bedeutung, da wir den Betriebsaufwand für unsere SRE-Teams reduzieren, die Debug-Fähigkeit für unsere DevOps verbessern und die Skalierbarkeit unseres Systems verbessern möchten.
  2. Fähigkeit, eine einzelne physische zu zerlegen Kubernetes-Cluster für Mandantenfähigkeit, ohne dass physische Cluster hochgefahren werden müssen – dies ist besonders wichtig in Umgebungen mit eingeschränkten Ressourcen, in denen keine neuen physischen Cluster nur für Mandantenfähigkeit hinzugefügt werden sollen

Um diese beiden Probleme zu lösen, mussten wir eine neue Technik entwickeln – verteilte Steuerebene -, um den Betriebsaufwand von zu lösen „Mehrere“ Cluster und bieten ein Äquivalent zu „mehreren Clustern“ für die Mandantenfähigkeit bei Ressourcenbeschränkungen d Umgebungen.

Verteilte Steuerungsebene: Wie wir Kubernetes mit mehreren Clustern erreicht haben

Unser Plattformteam hat beschlossen, eine verteilte Steuerungsebene für Kubernetes zu erstellen, die Kubernetes-APIs für die Verwendung durch unser Team verfügbar macht Diese APIs stammen von „virtuellen“ Clustern, die nur in unserer Steuerebene vorhanden sind – einem virtuellen K8s (vK8s) -API-Server für einen virtuellen K8s-Cluster (siehe Abbildung 1 ). Diese Steuerebene ordnet die Absicht des Benutzers mehreren physischen Kubernetes-Clustern zu, die in unserem Edge, unseren Netzwerk-POPs und öffentlichen Cloud-Standorten ausgeführt werden. Diese physischen Cluster sind nur für unsere verteilte Steuerebene und nicht für einen einzelnen Mandanten / Benutzer zugänglich.

Abbildung 1: Verteilte Steuerebene

Diese Steuerebene bietet jedem Mandanten einen oder mehrere „virtuelle“ Anwendungscluster, in denen er seine Anwendung (en) bereitstellen kann ) und basierend auf der Konfiguration wird die Steuerebene sie über mehrere physische Kubernetes-Cluster hinweg replizieren und verwalten. Zusätzlich zu Konfigurations- und Bereitstellungsvorgängen folgen Überwachungsvorgänge auch diesem „virtuellen“ Cluster, ohne dass Tools zum Sammeln und Zerlegen von Daten aus mehreren physischen Clustern erstellt werden müssen.

Nehmen wir eine Beispiel-UI-Anwendung namens productpage Der Benutzer beabsichtigt, es auf drei Standorte verteilt auszuführen – pa2-par, ny8-nyc und ams9-ams mit jeweils 2 Replikaten. Wenn der Benutzer ein vK8s-Objekt erstellt und es an einen virtuellen Cluster anfügt, der sofort einen vK8s-API-Server bereitstellt, der mit Standard-Kubectl verwendet werden kann.

Im nächsten Schritt lädt der Benutzer die Kubeconfig für diese virtuelle Datei herunter Cluster und erstellt Standard-Yaml zur Beschreibung einer K8s-Bereitstellung für die Produktseite.

Nach der Erstellung der Bereitstellungsspezifikation Der Benutzer kann fortfahren, eine Bereitstellung in diesem virtuellen Cluster zu erstellen:

Wenn der Benutzer dies nun überprüft Bei seiner Bereitstellung wurden 6 Replikate mit 2 an jedem Speicherort gestartet (pa2-par, ny8-nyc und ams9-ams).

Die folgende Ausgabe zeigt 2 Pods, die an jedem Standort ausgeführt werden und einem bestimmten physischen Knoten zugeordnet sind.

Dieses einfache Beispiel zeigt, wie trivial es ist, eine Multi-Cluster-Replikation einer App in Minuten zu erhalten ohne Installations- und Verwaltungsaufwand. Zusätzlich zur Zuordnung der Absicht bietet die verteilte Steuerebene auch Beobachtbarkeit für den virtuellen Cluster und nicht auf Einzelclusterbasis.

Verteilte Steuerung und zentrales Management für Mandantenfähigkeit

As Sie können in sehen. Abbildung 2 : Unsere zentralisierte Verwaltungsebene wird von zwei öffentlichen Cloud-Anbietern (jeweils einer Region) ausgeführt – einem in AWS und eine in Azure (aus Redundanzgründen). Diese Verwaltungsebene ermöglicht es unserem SRE, Mieter mit einer harten Mandantenfähigkeit zu erstellen – z. Ein Entwicklungsteam, das an unserem VoltMesh-Service arbeitet, kann ein Mandant sein, und ein Kundenlösungsteam, das an Kunden-POCs arbeitet, kann ein eigener Mandant mit einer eigenen Gruppe von Benutzern sein.

Abbildung 2: Mandantenfähigkeit und Multi-Cluster

Jeder dieser Mandanten kann viele erstellen Namespaces und weisen Sie eine Gruppe von Benutzern zu, die an diesen Namespaces zusammenarbeiten sollen. Diese Namespaces sind keine Kubernetes-Namespaces – sie stellen eine Isolationsgrenze in unserer Plattform mit RBAC-Regeln und IAM-Richtlinien für Benutzer dar.

Wenn ein Benutzer in einem Namespace einen Anwendungscluster erstellen möchte, erstellen sie ein vK8s-Objekt und Dadurch wird wiederum ein vK8s-API-Server in unserer Verwaltungsebene erstellt.Mit diesem vK8s-Objekt kann der Benutzer Bereitstellungen, Stateful Sets, PVCs usw. erstellen. Die Steuerebene stellt sicher, dass diese Vorgänge auf einem oder mehreren physischen Clustern ausgeführt werden, basierend auf Standorten, die dem vK8s-Objekt zugeordnet sind.

Da jeder Mandant und Benutzer Standard-K8-Vorgänge ohne Änderungen verwendet, kann das System mit einer Reihe von Tools kompatibel sein, die bei Bedienern beliebt sind – z Spinnaker, Helm, Jenkins usw.

Gewinne aus einer verteilten Steuerungsebene

Der große Vorteil einer verteilten Steuerungsebene besteht darin, dass der Betriebsaufwand für unsere SRE und DevOps behoben wurde Teams. Sie können jetzt Vorgänge (Konfiguration, Bereitstellung, Überwachung, Richtlinien usw.) in einem virtuellen Cluster ausführen, und die Steuerebene ordnet sie automatisch mehreren physischen Clustern zu. Zusätzlich zur betrieblichen Vereinfachung für mehrere Cluster hat die Steuerebene auch das Sicherheits- und Isolationsproblem für Mandantenfähigkeit gelöst.

Diese verteilte Steuerebene hat auch die Produktivität von Entwicklern verbessert, die neue Funktionen hinzufügen möchten Unsere Plattform – Sie müssen nicht jedes Mal eine neue Automatisierung erstellen, wenn sie neue Funktionen hinzufügen, die sich auf die Konfiguration oder den Betrieb in mehreren Clustern auswirken. Sie verwenden das absichtsbasierte Konfigurationsmodell und die Steuerebene weiß, was zu tun ist. Darüber hinaus können sie weiterhin mit diesem verteilten und mehreren Clusterobjekt – virtuellen Kubernetes – über kubectl und nicht über eine weitere CLI interagieren.

Nachdem Sie dies in unseren Entwicklungs-, Staging- und Produktionsumgebungen ausgeführt haben, um weitere Informationen zu erhalten Vor mehr als einem Jahr haben wir festgestellt, dass diese global verteilte Steuerungsebene (die in unseren Netzwerk-POPs ausgeführt wird) auch erhebliche Vorteile in Bezug auf Skalierung, Leistung und Zuverlässigkeit bietet – etwas, das wir uns in unseren frühen Tagen nicht vollständig vorgestellt hatten. Wir werden diesen Befund in unserer kommenden KubeCon-Präsentation und als separaten Blog-Beitrag in den kommenden Wochen behandeln.

Fortsetzung folgt…

Diese Reihe von Blogs wird verschiedene Aspekte dessen behandeln, was es ist Wir mussten unseren global verteilten SaaS-Service mit vielen Anwendungsclustern in der öffentlichen Cloud, unseren PoPs für private Netzwerke und Edge-Sites aufbauen und betreiben. Als nächstes folgt (Global Service Mesh für verteilte Apps)…