👩‍👧‍👦 🚠 🤲🏼 "Lass uns Kubernetes benutzen!" Sie haben jetzt 8 Probleme 🍂 🗿 🎉

Wenn Sie Docker verwenden, scheint der nächste logische Schritt darin zu bestehen, zu Kubernetes zu wechseln, es sind K8s, oder? Nun, nehmen wir an. Lösungen für 500 Softwareentwickler, die gleichzeitig eine einzige Anwendung entwickeln, unterscheiden sich jedoch erheblich von Lösungen für 50 Personen. Und die Lösung für ein Team von 5 Programmierern ist eine ganz andere Geschichte.

Wenn Sie in einem kleinen Team arbeiten, ist Kubernetes höchstwahrscheinlich nichts für Sie. Es wird Ihnen viel Schmerz im Austausch für äußerst bescheidene Vorteile bringen.
Mal sehen, warum das passieren kann.

Jeder mag die "beweglichen Teile"

Kubernetes bewegt sich und verändert viel: Konzepte, Subsysteme, Prozesse, Maschinen, Code ... Und das alles bedeutet viele Schwierigkeiten.

Mehrere Autos

Kubernetes ist ein verteiltes System: Es verfügt über einen Host-Computer, der den Rest, die Arbeiter, steuert. Jede Maschine führt Arbeiten in Containern aus.
Es handelt sich also bereits um mindestens zwei physische oder virtuelle Maschinen, die nur erforderlich sind, damit sie funktionieren. Aber in der Tat bekommen Sie ... nur ein Auto. Wenn Sie skalieren wollen (dort ist der Hund begraben!), Benötigen Sie drei, vier oder vielleicht sogar siebzehn virtuelle Maschinen.

Sehr, sehr viel Code

Die Kubernetes-Codebasis Anfang März 2020 umfasst mehr als 580.000 Codezeilen für unterwegs. Und dies ist nur sauberer Code, ausgenommen Kommentare, Leerzeilen und Herstellerpakete. Die Sicherheitsüberprüfung 2019 beschreibt die Codebasis wie folgt:
„Die Kubernetes-Codebasis bietet erheblichen Verbesserungsbedarf. Es ist groß und komplex, enthält große Codeabschnitte mit minimaler Dokumentation und einer Vielzahl von Abhängigkeiten, einschließlich Systemen, die nicht Teil von Kubernetes sind. Auch in der Codebasis gibt es viele Fälle von Neuimplementierung von Logik, die in unterstützenden Bibliotheken zentralisiert werden könnten, was die Komplexität verringern, Korrekturen vereinfachen und die Dokumentlast in verschiedenen Bereichen der Codebasis verringern würde. “
Um ehrlich zu sein, kann das Gleiche für viele andere große Projekte gesagt werden, aber dieser gesamte Code sollte korrekt funktionieren, wenn Sie nicht möchten, dass Ihre Anwendung fehlschlägt.

Architektonische, betriebliche, konfigurative und konzeptionelle Komplexität

Kubernetes ist ein umfassendes System mit vielen verschiedenen Diensten, Systemen und mehr.
Bevor Sie Ihre einzige Anwendung starten können, müssen Sie die folgende, stark vereinfachte Architektur bereitstellen (das Originalbild stammt aus der Kubernetes-Dokumentation):

Die K8s-Konzeptdokumentation enthält viele rein „lehrreiche“ Dinge, wie z. B. den folgenden Ausschnitt:

In Kubernetes, an EndpointSlice contains references to a set of network endpoints. The EndpointSlice controller automatically creates EndpointSlices for a Kubernetes Service when a selector is specified. These EndpointSlices will include references to any Pods that match the Service selector. EndpointSlices group network endpoints together by unique Service and Port combinations.
By default, EndpointSlices managed by the EndpointSlice controller will have no more than 100 endpoints each. Below this scale, EndpointSlices should map 1:1 with Endpoints and Services and have similar performance.

Eigentlich verstehe ich, worum es geht, aber achte darauf, wie viele Konzepte du lernen musst: EndpointSlice, Service, Selector, Pod, Endpoint.

Und - ja, die meiste Zeit werden Sie nicht alle diese Funktionen nutzen. Daher benötigen Sie die meiste Zeit überhaupt keine Kubernetes.

Hier ist ein weiterer zufälliger Ausschnitt:

Standardmäßig kann an einen ClusterIP- oder NodePort-Dienst gesendeter Datenverkehr an eine beliebige Backend-Adresse für den Dienst weitergeleitet werden. Seit Kubernetes 1.7 war es möglich, "externen" Datenverkehr an die Pods weiterzuleiten, die auf dem Knoten ausgeführt werden, der den Datenverkehr empfangen hat. Dies wird jedoch für ClusterIP-Dienste nicht unterstützt, und komplexere Topologien - wie z. B. zonales Routing - waren nicht möglich. Die Funktion "Diensttopologie" behebt dieses Problem, indem der Dienstersteller eine Richtlinie für das Weiterleiten des Datenverkehrs basierend auf den Knotenbezeichnungen für den Ursprungs- und den Zielknoten definieren kann.

Folgendes sagt die Sicherheitsüberprüfung dazu:

Kubernetes — , . , Kubernetes — , , , .

Je mehr Sie bei Kubernetes erhalten, desto schwieriger wird der normale Entwicklungsprozess: Sie benötigen all diese Konzepte (Pod, Bereitstellung, Service usw.), damit Ihr Code funktioniert. Daher müssen Sie ein vollwertiges K8-System fördern, auch nur zum Testen über eine virtuelle Maschine oder verschachtelte Docker-Container.

Und da es schwieriger wird, Ihre Anwendung lokal auszuführen, wird die Entwicklung durch viele Optionen zur Lösung dieses Problems erschwert, von einer Bench-Umgebung über das Proxying eines lokalen Prozesses in einen Cluster (ich habe dieses Tool vor einigen Jahren geschrieben ) bis hin zum Proxying eines Remote-Prozesses auf einen lokalen Computer ...

Sie können Wählen Sie eine Option, aber keine davon ist perfekt. Der einfachste Weg, Kubernetes überhaupt nicht zu verwenden.

Microservices (das ist eine schlechte Idee)

Ein sekundäres Problem besteht darin, dass Sie diese vielen Dienste schreiben müssen, da Ihr System es Ihnen ermöglicht, viele Dienste auszuführen. Schlechte Idee.
Verteilte Anwendungen sind schwer zu schreiben. In der Tat stören die mehr bewegliche Teile, desto mehr werden diese Probleme bei der Arbeit.

Verteilte Anwendungen sind schwer zu debuggen. Sie benötigen eine völlig neue Art von Debugging- und Protokollierungswerkzeugen, mit denen Sie immer noch weniger als die Protokolle einer monolithischen Anwendung erhalten.

Microservices ist eine der Skalierungstechniken in Unternehmen: Wenn Sie 500 Entwickler haben, die eine produktive Website bedienen, ist es sinnvoll, die Kosten eines verteilten Großsystems in Kauf zu nehmen, wenn Entwicklungsteams unabhängig arbeiten können. Somit erhält jedes Team von 5 Personen einen einzelnen Microservice und gibt vor, dass alle anderen Microservices externe Services sind, denen Sie nicht vertrauen sollten.

Wenn Ihr gesamtes Team aus 5 Personen besteht, Sie über 20 Mikrodienste verfügen und die Umstände höherer Gewalt Sie nicht zwingen, ein verteiltes System zu erstellen, haben Sie sich irgendwo verrechnet. Anstelle von 5 Personen pro 1 Microservice, wie in großen Unternehmen, erhalten Sie 0,25 Personen.

Ist Kubernetes überhaupt nicht nützlich?

Skalierung

Kubernetes können nützlich sein, wenn Sie ernsthafte Skalierbarkeit benötigen. Mal sehen, welche Alternativen Sie haben:

Sie können VMs in der Cloud erwerben. Sie verfügen über bis zu 416 virtuelle CPUs und 8 TB RAM, was einer völlig schmeichelhaften Leistung entspricht. Es wird Sie einen hübschen Cent kosten, aber es wird sehr einfach zu tun sein.
Viele einfache Webanwendungen können mit Diensten wie Heroku auf relativ einfache Weise skaliert werden.

Es wird natürlich davon ausgegangen, dass eine Erhöhung der Anzahl der funktionierenden VMs auch in Ihre Hände spielt:

Die meisten Anwendungen erfordern keine signifikante Skalierung, sie verfügen über eine ausreichend hochwertige Optimierung.
Der Engpass bei der Skalierung der meisten Webanwendungen sind Datenbanken, keine Web-Worker

Verlässlichkeit

Je mehr bewegliche Teile vorhanden sind, desto größer ist die Gefahr, dass ein Fehler auftritt.
Kubernetes-Funktionen, die durch eine erhöhte Zuverlässigkeit (Integritätsprüfungen, fortlaufende Bereitstellungen) verbessert werden, können in vielen Fällen bereits integriert oder viel einfacher implementiert werden. Beispielsweise kann nginx Integritätsprüfungen für Arbeitsprozesse durchführen, und Sie können Docker-Autoheal oder ähnliches verwenden, um diese Prozesse automatisch neu zu starten.

Wenn Sie besonders über Ausfallzeiten besorgt sind, sollte der erste Gedanke, der Sie besuchen wird, nicht lauten: "Wie reduziere ich Ausfallzeiten bei der Bereitstellung von 1 Sekunde auf 1 Millisekunde?", Sondern "Wie stelle ich sicher, dass Änderungen am Datenbankschema ein Rollback ermöglichen, wenn ich." irgendwo irgendwo? "
Und wenn Sie zuverlässige Web-Worker ohne einen einzigen Computer als Fehlerquelle benötigen, gibt es viele Möglichkeiten, dies ohne Kubernetes zu implementieren.

Best Practices?

Tatsächlich gibt es in der Natur keine Best Practices. Es gibt nur Best Practices für jede spezifische Situation. Wenn also etwas im Trend liegt und beliebt ist, bedeutet dies keineswegs, dass es speziell für Sie die richtige Wahl ist.
In einigen Fällen ist Kubernetes die beste Option. Der Rest ist Zeitverschwendung.

Sofern Sie nicht das dringende Bedürfnis nach all diesen Komplexitäten verspüren, verfügen Sie über eine große Auswahl an Tools, mit denen Sie Ihre Probleme lösen können: Docker Compose für eine Maschine, Hashicorp's Nomad für die Orchestrierung, Heroku und ähnliche Systeme für die Skalierung sowie Shakemake für die Berechnung von Pipelines.

Nachwort aus dem Editor

Als Cloud-Anbieter begegnen wir regelmäßig einer Vielzahl von Kunden, von kleinen Startups bis zu großen Unternehmen mit komplexen Geschäftsprozessen und damit verbundenen Infrastrukturanforderungen. Unabhängig davon, wie gut die Technologie ist, wird es immer Präzedenzfälle geben, bei denen ihre Anwendung zu unnötigen Schwierigkeiten führt. Sie sollten immer von der Situation ausgehen und die Vor- und Nachteile der verfügbaren Optionen sorgfältig abwägen. Der Autor des Artikels hat seine Farben etwas verdickt, aber seine Botschaft ist ganz klar: Manchmal lohnt es sich, sich von Trends abzuwenden und Ihr Projekt unvoreingenommen zu bewerten, um die richtige Entscheidung zu treffen. Dies spart den Entwicklern Kraft und die Verwendung von Unternehmensressourcen macht sie angemessener.

"Lass uns Kubernetes benutzen!" Sie haben jetzt 8 Probleme