Wir erstellen eine Kubernetes-Plattform in Pinterest

Im Laufe der Jahre haben 300 Millionen Nutzer von Pinterest über 200 Milliarden Pins auf mehr als 4 Milliarden Boards erstellt. Um diese riesige Nutzerbasis und die umfangreiche Content-Datenbank zu bedienen, hat das Portal Tausende von Services entwickelt, angefangen bei Microservices, die von einigen CPUs bewältigt werden können, bis hin zu gigantischen Monolithen, die auf einem gesamten Park virtueller Maschinen laufen. Und so kam der Zeitpunkt, an dem der Blick des Unternehmens auf k8s fiel. Was hat Pinterest an „dem Würfel“ angezogen? Darüber erfahren Sie in unserer Übersetzung des neuesten Artikels aus dem Blog von Pinterest Engineering.

Also, Hunderte Millionen Nutzer und Hunderte von Milliarden Pins. Um diese riesige Nutzerbasis und die umfassende Content-Datenbank zu bedienen, haben wir Tausende von Services entwickelt, angefangen bei Microservices, die von einigen CPUs bewältigt werden können, bis hin zu gigantischen Monolithen, die auf einem gesamten Park virtueller Maschinen laufen. Darüber hinaus haben wir verschiedene Frameworks, die ebenfalls CPU-Ressourcen, Speicher oder Zugriff auf Ein- und Ausgabeoperationen benötigen können.

Im Rahmen der Unterstützung dieses Werkzeug-Zoo sieht sich das Entwicklungsteam mit einer Reihe von Problemen konfrontiert:

• Die Ingenieure haben keinen einheitlichen Weg, um die Arbeitsumgebung zu starten. Stateless-Services, Stateful-Services und Projekte in aktiver Entwicklung basieren auf völlig unterschiedlichen Technologiestacks. Dies führte zur Erstellung eines gesamten Schulungskurses für Ingenieure und erschwert erheblich die Arbeit unseres Infrastrukturteams.
• Entwickler, die über einen eigenen Park virtueller Maschinen verfügen, erzeugen eine enorme Belastung für die internen Administratoren. Infolgedessen ziehen sich so einfache Operationen wie das Aktualisieren des Betriebssystems oder der AMI über Wochen und Monate. Dies führt zu einer erhöhten Belastung in scheinbar ganz alltäglichen Situationen.
• Herausforderungen bei der Erstellung globaler Infrastrukturmanagement-Tools über bestehenden Lösungen. Die Situation wird zusätzlich erschwert, da es nicht einfach ist, die Eigentümer der virtuellen Maschinen zu finden. Das heißt, wir wissen nicht, ob wir diese Ressourcen sicher für andere Teile unserer Infrastruktur nutzen können.

Container-Orchestrierungssysteme sind eine Möglichkeit, das Management von Workloads zu vereinheitlichen. Sie eröffnen Ihnen Wege zur Steigerung der Entwicklungsgeschwindigkeit und vereinfachen das Management der Infrastruktur, da alle im Projekt involvierten Ressourcen durch ein zentrales System verwaltet werden.

Abbildung 1: Infrastrukturprioritäten (Zuverlässigkeit, Entwicklerproduktivität und Effizienz).

Das Cloud Management Platform-Team bei Pinterest lernte 2017 K8s kennen. In der ersten Hälfte von 2017 dokumentierten wir einen Großteil unserer Produktionsressourcen, einschließlich API und all unseren Webserver. Danach führten wir eine sorgfältige Bewertung verschiedener Container-Orchestrierungslösungen, Clusteraufbau und -betrieb durch. Ende 2017 entschieden wir uns für Kubernetes. Es war flexibel genug und wurde von der Entwickler-Community gut unterstützt.

Bis zu diesem Zeitpunkt haben wir unsere eigenen Tools zur initialen Clusterbereitstellung auf Basis von Kops entwickelt und bestehende Infrastrukturkomponenten auf Kubernetes migriert – wie Netzwerk, Sicherheit, Metriken, Protokollierung, Identitätsmanagement und den Datenverkehr. Außerdem haben wir ein System zur Modellsimulation von Workloads für unsere Ressource implementiert, dessen Komplexität vor den Entwicklern verborgen bleibt. Derzeit konzentrieren wir uns darauf, die Stabilität des Clusters zu gewährleisten, es zu skalieren und neue Kunden anzubinden.

Kubernetes: Der Weg von Pinterest

Die Einführung von Kubernetes in einem so großen Maßstab wie bei Pinterest als Plattform, die von unseren Ingenieuren geschätzt wird, brachte viele Herausforderungen mit sich.

Als großes Unternehmen haben wir erhebliche Mittel in Infrastrukturwerkzeuge investiert. Dazu gehören Sicherheitswerkzeuge, die Zertifikate verwalten und Schlüssel verteilen, Komponenten zur Verkehrsüberwachung, Systeme zur Dienstprotokollierung sowie Komponenten für Sichtbarkeit, Protokollversand und Metriken. All dies wurde nicht aus Zufall zusammengestellt: Wir durchliefen den üblichen Prozess des Ausprobierens und Lernens. Deshalb wollten wir all diese Tools in die neue Infrastruktur auf Kubernetes integrieren, anstatt das alte Rad auf einer neuen Plattform neu zu erfinden. Dieser Ansatz erleichterte die Migration erheblich, da die gesamte Anwendungsunterstützung bereits vorhanden war und nicht neu geschaffen werden musste.

Andererseits sind die Vorhersagemodelle für Lasten in Kubernetes selbst (zum Beispiel Deployments, Jobs und DaemonSets) für unser Projekt nicht ausreichend. Diese Usability-Probleme stellen erhebliche Hindernisse für den Übergang zu Kubernetes dar. Zum Beispiel haben wir gehört, wie Entwickler von Diensten sich über das Fehlen oder die falsche Konfiguration von Ingress beschweren. Wir hatten auch mit der falschen Verwendung von Template-Engines zu kämpfen, als Hunderte von Kopien mit identischer Spezifikation und Aufgabe erstellt wurden, was zu schrecklichen Debugging-Problemen führte.

Es war auch sehr schwierig, verschiedene Versionen im selben Cluster zu unterstützen. Stellen Sie sich die Komplexität des Supports für Kunden vor, wenn Sie in mehreren Versionen derselben Ausführungsumgebung arbeiten müssen, mit all ihren Problemen, Bugs und Updates.

Benutzerdefinierte Ressourcen und Controller von Pinterest

Um unseren Ingenieuren die Einführung von Kubernetes zu erleichtern, sowie die Infrastruktur zu vereinfachen und ihre Leistung zu beschleunigen, haben wir unsere eigenen Definitionen von benutzerdefinierten Ressourcen (CRD) entwickelt.

CRDs bieten folgende Funktionalitäten:

1. Kombination verschiedener nativer Kubernetes-Ressourcen, sodass sie als eine einzige Last fungieren. Zum Beispiel umfasst die Ressource PinterestService ein Deployment, einen Ingress-Dienst und eine ConfigMap. Das ermöglicht Entwicklern, sich keine Gedanken über die DNS-Konfiguration zu machen.
2. Implementierung der notwendigen Unterstützung für Anwendungen. Der Benutzer sollte sich nur auf die Spezifikation des Containers gemäß seiner Geschäftslogik konzentrieren, während der CRD-Controller alle erforderlichen Init-Container, Umgebungsvariablen und Pod-Spezifikationen implementiert. Dies sorgt für ein grundlegend anderes Komfortniveau für Entwickler.
3. CRD-Controller verwalten auch den Lebenszyklus eigener Ressourcen und verbessern die Verfügbarkeit des Debuggings. Dies umfasst die Abstimmung der gewünschten und tatsächlichen Spezifikationen, die Aktualisierung des CRD-Status sowie die Protokollierung von Ereignissen und mehr. Ohne CRDs müssten Entwickler eine Vielzahl von Ressourcen verwalten, was nur die Fehleranfälligkeit erhöhen würde.

Hier ist ein Beispiel für PinterestService und eine interne Ressource, die von unserem Controller verwaltet wird:

Wie oben zu sehen ist, müssen wir, um den Benutzercontainer zu unterstützen, einen Initialisierungscontainer und mehrere Ergänzungen integrieren, um Sicherheit, Sichtbarkeit und den Umgang mit Netzwerktrafik zu gewährleisten. Darüber hinaus haben wir Konfigurationskarten-Vorlagen erstellt und die Unterstützung von PVC-Vorlagen für Batch-Jobs implementiert sowie das Tracking zahlreicher Umgebungsvariablen für die Verfolgung von Identitäten, Ressourcennutzung und das Sammeln von „Müll“ realisiert.

Es ist schwer vorstellbar, dass Entwickler diese Konfigurationsdateien manuell ohne Unterstützung von CRD schreiben möchten, ganz zu schweigen von der weiteren Wartung und Fehlersuche der Konfigurationen.

Workflow für die Bereitstellung von Anwendungen

Das obige Bild zeigt, wie man eine benutzerdefinierte Ressource von Pinterest in einem Kubernetes-Cluster bereitstellt:

1. Entwickler interagieren mit unserem Kubernetes-Cluster über die CLI und die Benutzeroberfläche.
2. CLI- und UI-Tools extrahieren YAML-Konfigurationsdateien des Workflows und andere Build-Eigenschaften (dasselbe Versions-ID) aus Artifactory, bevor sie an den Job Submission Service gesendet werden. Dieser Schritt stellt sicher, dass nur funktionierende Versionen im Cluster bereitgestellt werden.
3. JSS ist ein Gateway für verschiedene Plattformen, einschließlich Kubernetes. Hier erfolgt die Benutzerauthentifizierung, die Vergabe von Quoten und eine partielle Überprüfung der Konfiguration unseres CRD.
4. Nach der Überprüfung des CRD auf der JSS-Seite werden die Informationen an die API der K8s-Plattform gesendet.
5. Unser CRD-Controller verfolgt Ereignisse aller benutzerdefinierten Ressourcen. Er wandelt CR in native K8s-Ressourcen um, fügt erforderliche Module hinzu, setzt die entsprechenden Umgebungsvariablen und führt weitere Hilfsarbeiten aus, um sicherzustellen, dass die Containeranwendungen ausreichende infrastrukturelle Unterstützung erhalten.
6. Anschließend übergibt der CRD-Controller die gewonnenen Daten an die Kubernetes-API, damit sie vom Scheduler verarbeitet und in Betrieb genommen werden.

Hinweis: Dieser Release-Workflow für das Deployment wurde für die ersten Benutzer der neuen k8s-Plattform erstellt. Momentan befinden wir uns im Prozess der Verbesserung dieses Verfahrens, um es vollständig mit unserem neuen CI/CD zu integrieren. Das bedeutet, dass wir nicht alle Informationen zu Kubernetes bereitstellen können. Wir freuen uns darauf, unsere Erfahrungen zu teilen und über die Fortschritte des Teams in dieser Hinsicht in unserem nächsten Blogbeitrag „Building a CI/CD platform for Pinterest“ zu berichten.

Arten von speziellen Ressourcen

Basierend auf den spezifischen Anforderungen von Pinterest haben wir die folgenden CRDs entwickelt, die für verschiedene Workflows geeignet sind:

• PinterestService sind seit langem funktionierende stateless Services. Viele unserer zentralen Systeme basieren auf einer Reihe solcher Services.
• PinterestJobSet modelliert vollständige Batch-Jobs. In Pinterest gibt es ein verbreitetes Szenario, bei dem mehrere Jobs dieselben Container parallel starten, unabhängig von anderen ähnlichen Prozessen.
• PinterestCronJob wird häufig in Verbindung mit kleinen, periodischen Lasten eingesetzt. Dies ist eine Shell für die native Ausführung von Cron mit den Sicherheits-, Verkehrs-, Log- und Metrik-Mechanismen von Pinterest.
• PinterestDaemon enthält Infrastruktur-Daemons. Diese Familie wächst weiter, da wir immer mehr Unterstützung für unsere Cluster hinzufügen.
• PinterestTrainingJob umfasst die Prozesse von Tensorflow und Pytorch und bietet während der Ausführung denselben Unterstützungsgrad wie alle anderen CRDs. Da Tensorflow und andere Systeme für maschinelles Lernen bei Pinterest aktiv eingesetzt werden, war es sinnvoll, eine eigene CRD dafür zu entwickeln.

Außerdem arbeiten wir an PinterestStatefulSet, das bald für Datenspeicher und andere stateful Systeme angepasst wird.

Unterstützung der Ausführungsumgebung

Wenn ein Anwendungsmodul in Kubernetes gestartet wird, erhält es automatisch ein Zertifikat zur Identifizierung seiner selbst. Dieses Zertifikat wird verwendet, um auf den Geheimspeicher zuzugreifen oder um über mTLS mit anderen Diensten zu kommunizieren. In der Zwischenzeit wird der Container-Init-Konfigurator sowie der Daemon alle erforderlichen Abhängigkeiten vor dem Start der Containeranwendung laden. Wenn alles bereit ist, registrieren der Sidecar-Traffic und der Daemon die IP-Adresse des Moduls in unserem Zookeeper, damit Kunden es finden können. All dies funktioniert, da das Netzwerkmodul bereits vor dem Start der Anwendung konfiguriert wurde.

Die obigen Beispiele zeigen typische Unterstützungsvarianten für Workloads zur Laufzeit. Für andere Arten von Workloads könnte etwas andere Unterstützung erforderlich sein, doch alle werden in Form von Pod-Level-Sidecars, Node- oder VM-Level-Daemons bereitgestellt. Wir sorgen dafür, dass all dies innerhalb der Verwaltungsinfrastruktur bereitgestellt und zwischen den Anwendungen abgestimmt wird, was schließlich die technische Belastung und den Kundenservice erheblich reduziert.

Testen und QA

Wir haben eine End-to-End-Testpipeline auf der bereits vorhandenen Testinfrastruktur von Kubernetes aufgebaut. Diese Tests gelten für alle unsere Cluster. Unsere Pipeline hat viele Überarbeitungen durchlaufen, bevor sie Teil des Produktclusters wurde.

Neben den Testsystemen haben wir Überwachungs- und Alarmsysteme, die ständig den Zustand der Systemkomponenten, den Ressourcenverbrauch und andere wichtige Kennzahlen überwachen und uns nur bei Bedarf über notwendige menschliche Eingriffe informieren.

Alternativen

Wir haben einige Alternativen zu benutzerdefinierten Ressourcen betrachtet, wie beispielsweise Mutationszugriffskontrollen und Template-Systeme. All diese beinhalten jedoch erhebliche betriebliche Herausforderungen, weshalb wir den Weg der CRD gewählt haben.

Der Mutationszugriffskontroller wurde zur Einführung von Sidecars, Umgebungsvariablen und anderer Unterstützung während der Ausführung verwendet. Er hatte jedoch mit verschiedenen Problemen zu kämpfen, etwa bei der Bindung von Ressourcen und dem Management ihres Lebenszyklus, während solche Probleme bei CRD nicht auftreten.

Hinweis: Vorlagen-Systeme, wie Helm-Diagramme, werden auch häufig verwendet, um Anwendungen mit ähnlichen Konfigurationen zu starten. Allerdings sind unsere Arbeitsanwendungen zu vielfältig, um sie mit Vorlagen zu verwalten. Während des kontinuierlichen Deployments werden bei der Verwendung von Vorlagen zudem zu viele Fehler auftreten.

Kommende Arbeiten

Derzeit haben wir es mit einer gemischten Last auf all unseren Clustern zu tun. Um solche Prozesse unterschiedlicher Art und Größe zu unterstützen, arbeiten wir in den folgenden Bereichen:

• Die Clustergruppe verteilt große Anwendungen auf verschiedene Cluster, um Skalierbarkeit und Stabilität zu gewährleisten.
• Sicherstellung von Stabilität, Skalierbarkeit und Sichtbarkeit des Clusters, um eine Verbindung zwischen Anwendung und SLA zu schaffen.
• Ressourcen- und Quotenmanagement, damit die Anwendungen sich nicht gegenseitig behindern und der Umfang des Clusters von uns kontrolliert werden kann.
• Neue CI/CD-Plattform zur Unterstützung und Bereitstellung von Anwendungen in Kubernetes.

Quelle: habr.com