Erstellen einer Kubernetes-Plattform auf Pinterest

Im Laufe der Jahre haben die 300 Millionen Nutzer von Pinterest mehr als 200 Milliarden Pins auf mehr als 4 Milliarden Pinnwänden erstellt. Um diese Benutzerarmee und die umfangreiche Inhaltsbasis zu bedienen, hat das Portal Tausende von Diensten entwickelt, die von Mikrodiensten reichen, die von wenigen CPUs verwaltet werden können, bis hin zu riesigen Monolithen, die auf einer ganzen Flotte virtueller Maschinen ausgeführt werden. Und dann kam der Moment, in dem der Blick des Unternehmens auf K8s fiel. Warum sah der „Würfel“ auf Pinterest gut aus? Dies erfahren Sie aus unserer Übersetzung eines aktuellen Artikels von Blog Pinterest Engineering.

Also Hunderte Millionen Benutzer und Hunderte Milliarden Pins. Um diese Armee von Benutzern und die riesige Inhaltsbasis zu bedienen, haben wir Tausende von Diensten entwickelt, die von Mikrodiensten reichen, die von wenigen CPUs verwaltet werden können, bis hin zu riesigen Monolithen, die auf ganzen Flotten virtueller Maschinen ausgeführt werden. Darüber hinaus verfügen wir über eine Vielzahl von Frameworks, die möglicherweise auch CPU-, Speicher- oder I/O-Zugriff erfordern.

Bei der Pflege dieses Zoos an Tools steht das Entwicklungsteam vor einer Reihe von Herausforderungen:

• Es gibt keine einheitliche Methode für Ingenieure, eine Produktionsumgebung zu betreiben. Stateless Services, Stateful Services und Projekte in aktiver Entwicklung basieren auf völlig unterschiedlichen Technologie-Stacks. Dies führte zur Schaffung eines kompletten Schulungskurses für Ingenieure und erschwert zudem die Arbeit unseres Infrastrukturteams erheblich.
• Entwickler mit einer eigenen Flotte virtueller Maschinen stellen eine enorme Belastung für interne Administratoren dar. Daher dauern einfache Vorgänge wie die Aktualisierung des Betriebssystems oder des AMI Wochen und Monate. Dies führt zu einer erhöhten Arbeitsbelastung in scheinbar ganz alltäglichen Situationen.
• Schwierigkeiten bei der Erstellung globaler Infrastrukturmanagement-Tools zusätzlich zu bestehenden Lösungen. Erschwerend kommt hinzu, dass es nicht einfach ist, die Besitzer virtueller Maschinen zu finden. Das heißt, wir wissen nicht, ob diese Kapazität sicher für den Betrieb in anderen Teilen unserer Infrastruktur genutzt werden kann.

Container-Orchestrierungssysteme sind eine Möglichkeit, das Workload-Management zu vereinheitlichen. Sie ermöglichen eine höhere Entwicklungsgeschwindigkeit und vereinfachen das Infrastrukturmanagement, da alle am Projekt beteiligten Ressourcen von einem zentralen System verwaltet werden.

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

Das Cloud Management Platform-Team von Pinterest entdeckte K8s im Jahr 2017. Bis zum ersten Halbjahr 2017 hatten wir die meisten unserer Produktionskapazitäten dokumentiert, einschließlich der API und aller unserer Webserver. Anschließend führten wir eine gründliche Bewertung verschiedener Systeme zur Orchestrierung von Containerlösungen, zum Aufbau von Clustern und zur Arbeit mit ihnen durch. Gegen Ende 2017 haben wir uns für den Einsatz von Kubernetes entschieden. Es war recht flexibel und wurde in der Entwicklergemeinschaft weitgehend unterstützt.

Bisher haben wir unsere eigenen Cluster-Boot-Tools auf Basis von Kops entwickelt und bestehende Infrastrukturkomponenten wie Netzwerk, Sicherheit, Metriken, Protokollierung, Identitätsmanagement und Datenverkehr nach Kubernetes migriert. Wir haben außerdem ein Workload-Modellierungssystem für unsere Ressource implementiert, dessen Komplexität den Entwicklern verborgen bleibt. Jetzt konzentrieren wir uns darauf, die Stabilität des Clusters sicherzustellen, ihn zu skalieren und neue Kunden anzubinden.

Kubernetes: Der Pinterest-Weg

Der Einstieg in Kubernetes im Maßstab von Pinterest als Plattform, die unsere Ingenieure lieben würden, war mit vielen Herausforderungen verbunden.

Als großes Unternehmen haben wir stark in Infrastrukturtools investiert. Beispiele hierfür sind Sicherheitstools, die die Zertifikatsverarbeitung und Schlüsselverteilung übernehmen, Verkehrskontrollkomponenten, Serviceerkennungssysteme, Sichtbarkeitskomponenten sowie Protokoll- und Metrikverteilungskomponenten. All dies wurde aus einem bestimmten Grund gesammelt: Wir sind den normalen Weg des Versuchs und Irrtums gegangen und wollten deshalb all diese Geräte in die neue Infrastruktur auf Kubernetes integrieren, anstatt das alte Rad auf einer neuen Plattform neu zu erfinden. Insgesamt vereinfachte dieser Ansatz die Migration, da die gesamte Anwendungsunterstützung bereits vorhanden ist und nicht von Grund auf neu erstellt werden muss.

Andererseits reichen die Lastprognosemodelle in Kubernetes selbst (wie Bereitstellungen, Jobs und Daemon-Sets) für unser Projekt nicht aus. Diese Usability-Probleme stellen große Hindernisse für den Umstieg auf Kubernetes dar. Wir haben beispielsweise gehört, dass sich Dienstentwickler über fehlende oder falsche Anmeldeeinstellungen beschwert haben. Wir sind auch auf die fehlerhafte Verwendung von Template-Engines gestoßen, als Hunderte von Kopien mit derselben Spezifikation und Aufgabe erstellt wurden, was zu alptraumhaften Debugging-Problemen führte.

Außerdem war es sehr schwierig, verschiedene Versionen im selben Cluster zu verwalten. Stellen Sie sich die Komplexität des Kundensupports vor, wenn Sie gleichzeitig in mehreren Versionen derselben Laufzeitumgebung mit all ihren Problemen, Fehlern und Updates arbeiten müssen.

Pinterest-Benutzereigenschaften und Verantwortliche

Um unseren Ingenieuren die Implementierung von Kubernetes zu erleichtern und unsere Infrastruktur zu vereinfachen und zu beschleunigen, haben wir unsere eigenen benutzerdefinierten Ressourcendefinitionen (CRDs) entwickelt.

CRDs bieten die folgende Funktionalität:

1. Kombinieren verschiedener nativer Kubernetes-Ressourcen, sodass sie als eine einzige Arbeitslast funktionieren. Beispielsweise umfasst die PinterestService-Ressource eine Bereitstellung, einen Anmeldedienst und eine Konfigurationskarte. Dadurch müssen sich Entwickler keine Gedanken über die Einrichtung von DNS machen.
2. Implementieren Sie die erforderliche Anwendungsunterstützung. Der Benutzer muss sich entsprechend seiner Geschäftslogik nur auf die Containerspezifikation konzentrieren, während der CRD-Controller alle erforderlichen Init-Container, Umgebungsvariablen und Pod-Spezifikationen implementiert. Dies bietet Entwicklern einen grundlegend anderen Komfort.
3. CRD-Controller verwalten außerdem den Lebenszyklus nativer Ressourcen und verbessern die Debug-Verfügbarkeit. Dazu gehören der Abgleich gewünschter und tatsächlicher Spezifikationen, die Aktualisierung des CRD-Status, die Pflege von Ereignisprotokollen und vieles mehr. Ohne CRD wären Entwickler gezwungen, mehrere Ressourcen zu verwalten, was die Fehlerwahrscheinlichkeit nur erhöhen würde.

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

Wie Sie oben sehen können, müssen wir zur Unterstützung eines benutzerdefinierten Containers einen Init-Container und mehrere Add-ons integrieren, um Sicherheit, Sichtbarkeit und Netzwerkverkehr bereitzustellen. Darüber hinaus haben wir Konfigurationskartenvorlagen erstellt und Unterstützung für PVC-Vorlagen für Batch-Jobs sowie die Verfolgung mehrerer Umgebungsvariablen implementiert, um Identität, Ressourcenverbrauch und Speicherbereinigung zu verfolgen.

Es ist schwer vorstellbar, dass Entwickler diese Konfigurationsdateien ohne CRD-Unterstützung von Hand schreiben möchten, geschweige denn die Konfigurationen weiter pflegen und debuggen.

Arbeitsablauf für die Anwendungsbereitstellung

Das Bild oben zeigt, wie Sie eine benutzerdefinierte Pinterest-Ressource in einem Kubernetes-Cluster bereitstellen:

1. Entwickler interagieren mit unserem Kubernetes-Cluster über die CLI und die Benutzeroberfläche.
2. Die CLI/UI-Tools rufen die Workflow-Konfigurations-YAML-Dateien und andere Build-Eigenschaften (gleiche Versions-ID) von Artifactory ab und übermitteln sie dann an den Job Submission Service. Durch diesen Schritt wird sichergestellt, dass nur Produktionsversionen an den Cluster geliefert werden.
3. JSS ist ein Gateway für verschiedene Plattformen, einschließlich Kubernetes. Hier erfolgt die Authentifizierung des Benutzers, die Vergabe von Kontingenten und eine teilweise Überprüfung der Konfiguration unseres CRD.
4. Nach der Überprüfung des CRD auf der JSS-Seite werden die Informationen an die k8s-Plattform-API gesendet.
5. Unser CRD-Controller überwacht Ereignisse auf allen Benutzerressourcen. Es konvertiert CRs in native k8s-Ressourcen, fügt die erforderlichen Module hinzu, legt die entsprechenden Umgebungsvariablen fest und führt andere Supportarbeiten durch, um sicherzustellen, dass containerisierte Benutzeranwendungen über ausreichende Infrastrukturunterstützung verfügen.
6. Der CRD-Controller übergibt die empfangenen Daten dann an die Kubernetes-API, damit sie vom Scheduler verarbeitet und in die Produktion übernommen werden können.

Beachten: Dieser Vorab-Workflow der Bereitstellung wurde für die ersten Benutzer der neuen k8s-Plattform erstellt. Wir sind derzeit dabei, diesen Prozess zu verfeinern, um ihn vollständig in unser neues CI/CD zu integrieren. Das bedeutet, dass wir Ihnen nicht alles rund um Kubernetes erzählen können. Wir freuen uns darauf, unsere Erfahrungen und die Fortschritte des Teams in dieser Richtung in unserem nächsten Blogbeitrag „Aufbau einer CI/CD-Plattform für Pinterest“ zu teilen.

Arten von Spezialressourcen

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

• PinterestService sind zustandslose Dienste, die schon seit langem laufen. Viele unserer Kernsysteme basieren auf einer Reihe solcher Dienste.
• PinterestJobSet modelliert Batch-Jobs im gesamten Zyklus. Ein häufiges Szenario auf Pinterest ist, dass mehrere Jobs unabhängig von anderen ähnlichen Prozessen dieselben Container parallel ausführen.
• PinterestCronJob wird häufig in Verbindung mit kleinen periodischen Lasten verwendet. Dies ist ein Wrapper für die native Cron-Arbeit mit Pinterest-Unterstützungsmechanismen, die für Sicherheit, Datenverkehr, Protokolle und Metriken verantwortlich sind.
• PinterestDaemon umfasst Infrastruktur-Daemons. Diese Familie wächst weiter, da wir unseren Clustern mehr Unterstützung bieten.
• PinterestTrainingJob erstreckt sich auf Tensorflow- und Pytorch-Prozesse und bietet das gleiche Maß an Laufzeitunterstützung wie alle anderen CRDs. Da Pinterest Tensorflow und andere maschinelle Lernsysteme aktiv nutzt, hatten wir einen Grund, ein separates CRD um sie herum zu erstellen.

Wir arbeiten auch an PinterestStatefulSet, das bald für Data Warehouses und andere Stateful-Systeme angepasst wird.

Laufzeitunterstützung

Wenn ein Anwendungs-Pod auf Kubernetes ausgeführt wird, erhält er automatisch ein Zertifikat, um sich zu identifizieren. Dieses Zertifikat wird verwendet, um auf geheime Speicher zuzugreifen oder über mTLS mit anderen Diensten zu kommunizieren. In der Zwischenzeit laden der Container Init Configurator und Daemon alle erforderlichen Abhängigkeiten herunter, bevor die Containeranwendung ausgeführt wird. Wenn alles fertig ist, registrieren der Traffic-Sidecar und der Daemon die IP-Adresse des Moduls bei unserem Zookeeper, damit Clients es finden können. All dies funktioniert, da das Netzwerkmodul vor dem Start der Anwendung konfiguriert wurde.

Die oben genannten Beispiele sind typische Beispiele für die Laufzeitunterstützung von Workloads. Andere Arten von Workloads erfordern möglicherweise eine etwas andere Unterstützung, sie werden jedoch alle in Form von Sidecars auf Pod-Ebene, Daemons auf Knotenebene oder auf Ebene virtueller Maschinen bereitgestellt. Wir stellen sicher, dass all dies innerhalb der Verwaltungsinfrastruktur bereitgestellt wird und anwendungsübergreifend konsistent ist, was letztendlich den Aufwand in Bezug auf technische Arbeit und Kundensupport erheblich reduziert.

Tests und Qualitätssicherung

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

Zusätzlich zu den Testsystemen verfügen wir über Überwachungs- und Alarmsysteme, die ständig den Status von Systemkomponenten, den Ressourcenverbrauch und andere wichtige Indikatoren überwachen und uns nur benachrichtigen, wenn menschliches Eingreifen erforderlich ist.

Alternativen

Wir haben uns einige Alternativen zu benutzerdefinierten Ressourcen angesehen, beispielsweise Mutationszugriffscontroller und Vorlagensysteme. Da sie jedoch alle mit erheblichen betrieblichen Herausforderungen verbunden sind, haben wir uns für den CRD-Weg entschieden.

Ein mutationaler Zulassungscontroller wurde verwendet, um Sidecars, Umgebungsvariablen und andere Laufzeitunterstützung einzuführen. Es gab jedoch verschiedene Probleme, wie z. B. die Ressourcenbindung und das Lebenszyklusmanagement, wo solche Probleme bei CRD nicht auftreten.

Hinweis: Auch Vorlagensysteme wie Helm-Charts werden häufig zum Ausführen von Anwendungen mit ähnlichen Konfigurationen verwendet. Allerdings sind unsere Arbeitsanwendungen zu vielfältig, als dass wir sie über Vorlagen verwalten könnten. Auch bei der kontinuierlichen Bereitstellung treten zu viele Fehler bei der Verwendung von Vorlagen auf.

Kommende Arbeit

Derzeit haben wir es mit einer gemischten Auslastung aller unserer Cluster zu tun. Zur Unterstützung solcher Prozesse unterschiedlicher Art und Größe sind wir in folgenden Bereichen tätig:

• Eine Sammlung von Clustern verteilt große Anwendungen auf verschiedene Cluster, um Skalierbarkeit und Stabilität zu gewährleisten.
• Gewährleistung der Stabilität, Skalierbarkeit und Sichtbarkeit des Clusters, um Anwendungskonnektivität und SLAs zu schaffen.
• Verwalten von Ressourcen und Kontingenten, damit Anwendungen nicht miteinander in Konflikt geraten und die Größe des Clusters von unserer Seite kontrolliert wird.
• Eine neue CI/CD-Plattform zur Unterstützung und Bereitstellung von Anwendungen auf Kubernetes.

Source: habr.com