Kubernetes: Die Betriebskosten, wenn man jeden Nagel mit einem Hammer trifft

größte Lüge in der Technologiewelt der letzten 5-6 Jahre ist: „Stellen Sie Ihre App auf Kubernetes und sie erledigt den Rest.“ Diejenigen, die auf den Konferenzen auf der Bühne stehen, werden Ihnen sagen, wie „selbstheilend“ Kubernetes (K8s) ist und ein hervorragendes Orchestrierungstool ist. Aber niemand erzählt Ihnen von den Kosten der Armee von Ingenieuren, die nötig sind, um dieses Orchester zu leiten.

Die traurige Wahrheit ist, dass Sie nicht Google sind. Sie haben wahrscheinlich auch keine Skalierungsprobleme von Google. Aber wegen der „FOMO“ (Angst, zurückgelassen zu werden) in der Branche versuchen Sie, auch nur eine einfache Website mit einem komplexen System von Atom-U-Boot-Steuerpulten zu verwalten. Schauen wir uns diese unsichtbare „YAML Hell“ -Rechnung

1. Operations von „Tag 2“: Der Traum ist vorbei, die Realität beginnt

Den Kubernetes-Cluster hochzufahren ist der einfache Teil („Tag 1“). Der größte Albtraum beginnt mit den Operationen von „Tag 2“. Den Cluster auf dem neuesten Stand halten, Zertifikatsrotationen, Versionsinkompatibilitäten und Nodes zum Absturz

• Personalkosten: Die Verwaltung von K8s ist an sich schon ein Vollzeitjob. Ist es die Aufgabe Ihrer Entwickler, Code zu schreiben oder zu debuggen, warum Ingress Controller keinen
Traffic weiterleitet?
• Abstraktionsleck: Sie sagen, dass die Hardware von K8 abstrakt ist, aber es ist eine Lüge. In dem Moment, in dem Sie CPU-Limits (`Requests` und `Limits`) falsch setzen, stirbt Ihre Anwendung stillschweigend mit dem Fehler „oomKilled“ (Out of
Memory) ab.
• Netzwerk: Kommunikation zwischen PODs, Service Mesh, CNI-Plugins... Eine einfache HTTP-Anfrage kann plötzlich zu einem unlösbaren Netzwerktechnikproblem

2. Lebenslauforientierte Entwicklung

Wenn ich als skeptischer Experte in ein Unternehmen eintrete, schaue ich mir als Erstes an: Wurde diese Architektur durch die Anforderungen des Jobs auferlegt, oder ist es der Wunsch der Ingenieure, „Kubernetes Expert“ in ihre Lebensläufe zu schreiben?

Wenn Ihre Anwendung in einen einzelnen virtuellen Server (VM) passt und Sie ihn in einen K8s-Cluster mit 3 Knoten aufteilen, lösen Sie nur

3. Sicherheitslücken, die durch Komplexität verursacht werden

Komplexität ist der größte Feind der Sicherheit. Die Standardeinstellungen von Kubernetes sind normalerweise „arbeitsorientiert“, nicht „sicher“

Einen Docker-Container mit Root-Autorität ausführen, Secrets Management (ETCD-Verschlüsselung) oder falsch konfigurierte RBAC-Regeln (Role-Based Access Control) umgehen... Für Hacker ist K8s ein Vergnügungspark, wenn es falsch konfiguriert ist. Um die Sicherheit der K8 zu gewährleisten, benötigen Sie zusätzliche Tools (Trivy, Falco usw.) und zusätzliche Zeit, um sie zu verwalten.

4. Wann ist K8s, wann ist

Also, sollten wir Kubernetes wegwerfen? Nein. Finden wir einfach den richtigen Nagel.

• Microservice Hell: Wenn Sie wirklich mehr als 50 Microservices zu verwalten haben und sie intensiv miteinander sprechen, ist der K8s ein Retter.
• Monolithische Anwendungen: Wenn Sie eine monolithische Anwendung haben, kostet Sie das Dockerisieren und Ausführen auf einem einfachen PaaS (Heroku, DigitalOcean App Platform usw.) oder einem Managed Container Service (AWS ECS) 80% weniger Betriebslast.