Fragen? Antworten! Siehe auch: Alternativlos
Da hat jemand gelesen, wie geil Google angeblich skaliert, und was für einen tollen Zoo aus Microservices Netflix hat. Das brauchen wir hier auch!
Erst glaubten alle, sie bräuchten unbedingt Virtualisierung. Damit sie Server umziehen können. Hat jemals jemand von denen eine VM umgezogen? Eher selten bis gar nicht.
Dann glaubten alle, sie brauchen Kubernetes. Für ihre Flotte von Microservices. Wofür braucht ihr denn so viele Microservices? Isoliert und sandboxt ihr da Operationen voneinander? Nein. Soll das die Cores besser ausnutzen? Warum denn, wieviele User habt ihr denn pro Sekunde? Oh. Zehn? Hrmjanunäh.
Zumindest letzteres kann man über Reddit nicht sagen. Die haben genug Benutzer, um sich über Skalierbarkeit ernsthaft Gedanken machen zu müssen. Und im Allgemeinen flutscht deren Site ja auch, fühlt sich nicht träge an. Aber neulich war die mal für ein paar Stunden weg. Umso erfreulicher, dass es am Ende ein Post-Mortem gab.
Das Ergebnis ist: Sie haben einen Kubernetes-Cluster updaten wollen, und das Update flog ihnen um die Ohren. Naja, äh, kein Ding, denkt ihr euch jetzt vielleicht. Sowas macht man ja immer rollbackbar. Dafür hat man ja Microservices. Damit die einzelnen Einheiten eine möglichst kleine Granularität haben und man da einzeln Herumupdaten kann. Überhaupt sollte Kubernetes ja noch am problemärmsten hoch- und runter-schiebbar sein, denn da liegen ja alle gefährdeten Daten in Pods. Wir reden hier vom Kubernetes selbst, das sie geupdated haben. Würde man denken. Tatsächlich ist es aber so:
But, dear Redditor… Kubernetes has no supported downgrade procedure. Because a number of schema and data migrations are performed automatically by Kubernetes during an upgrade, there’s no reverse path defined.I-de-ale Voraussetzungen für ein Stück kritische Infrastruktur! Diese Enterprise-Fuzzys labern immer rum von wegen Verfügbarkeit und Metriken und setzen dann … sowas ein?!?Tsja. Nächstes Problem: Alle Metriken waren ausgefallen. Heutige Installationen sind so krass ultrakomplex, dass man da ohne Metriken nicht mehr so richtig diagnostizieren kann. Gut, wenn die Metriken ganz weg sind, dann klingt das nach einem Netzwerkproblem. War es dann auch.
At some point, we noticed that our container network interface, Calico, wasn’t working properly.Wieso haben sie das nicht sofort gemerkt, fragt ihr? Tsja. Da fehlte die institutionelle Erfahrung. Die hatten lauter Leute, die wussten, wie sie in ihrem Admin-Interface Dinge klickt. Aber was man tut, wenn das Admin-Interface nicht geht, weil das Netz dazwischen braun ist, das wusste keiner mehr, und inzwischen war die Komplexität so krass gewachsen, dass das wahrscheinlich generell niemand mehr von Hand gucken konnte. Sie haben da tolle selbstreparierende Prozesse gehabt, aber das lief halt wie bei Asimov. Wenn du selbstwartende Dinge baust, geht das Wissen verloren, wie man sie baut und wartet, weil das ja nicht mehr gebraucht wird, und wenn die dann irgendwann doch kaputt gehen, hast du dann halt komplett verloren. So war das auch hier. Sie haben den Pod mit dem Netzwerkmanagement-Kram gekillt und gelöscht und der versuchte sich dann neu zu installieren, aber die Installation hatte halt dasselbe Problem wie die davor.
Also haben sie ein Backup einzuspielen versucht. Aber wie bei Asimov:
Once that was finished, we took on the restore procedure, which nobody involved had ever performed before, let alone on our favorite single point of failure.Das ist generell nicht gut. Ein Backup ist erst dann ein Backup, wenn man es erfolgreich wieder einspielen konnte. Wenn man das nie probiert hat, dann ist das auch kein Backup sondern bloß ein Datenhaufen. This procedure had been written against a now end-of-life Kubernetes version, and it pre-dated our switch to CRI-O, which means all of the instructions were written with Docker in mind.Wie das halt ist, wenn man essentielle Dinge hinten runterfallen lässt, weil das ja alles selbstheilend ist und wir daher nicht so gut vorbereitet sein müssen.Was ich persönlich ja besonders unterhaltsam finde, ist dass sie dann über TLS-Zertifikate stolperten, weil sie ein Backup für Kiste A auf Kiste B eingespielt haben, und dann hatte der ein Zertifikat für die falsche Maschine und Clients wollten nicht mehr connecten.
Aber der eigentliche Kracher an dieser ganzen Story ist, was am Ende der Root Cause war. Achtung, stabil hinsetzen:
The nodeSelector and peerSelector for the route reflectors target the label `node-role.kubernetes.io/master`. In the 1.20 series, Kubernetes changed its terminology from “master” to “control-plane.” And in 1.24, they removed references to “master,” even from running clusters. This is the cause of our outage. Kubernetes node labels.Das ganze Kartenhaus ist eingestürzt, weil Kubernetes aus Wokenessgründen fand, dass da nicht mehr master stehen darf. Kubernetes, muss man an der Stelle wissen, hat ja historisch enorm viel mit Sklaverei zu tun hat. Und wenn man böse Worte nicht mehr verwendet, macht man damit böse Taten in der Vergangenheit rückgängig. Oder so.Deshalb war Reddit kaputt.
Update: Oh und erwähnte ich, dass sie beim Ausführen der veralteten Dokumentation, wie man Backups einspielt, merkten, dass eines der Kommandozeilentools seit dem die Argumente umbenannt hatte? Was zur Hölle ist denn das für eine unprofessionelle Kackscheiße schon wieder! Was denken sich denn bitte solche Leute?! Unseren Scheiß wird schon keiner einsetzen?
Hier ist ein sehr schönes Post Morten von Gitlab über ein Problem, das sie in ihrem Kubernetes-Setup hatten. Die Auflösung am Ende ist recht lustig finde ich.
Das Symptom war, dass ihre User Fehlermeldungen im Browser bekamen. Stellte sich raus, dass die Backends nicht antworteten, also haben die Webservices davor 502-Fehler geworfen.
Nun haben sie da Sensoren, die erkennen sollen, wenn ein Backend weg ist, und das sollte dann aus der Rotation genommen werden. Stellt sich raus: Selbst sauber runtergefahrene Backends blieben in der Rotation.
Am Ende lag es daran, dass Kubernetes den Container runterfahren wollte, und ein SIGTERM schickte, aber die Software in ihrem Docker-Image hatte eine Shell dazwischen und die fraß das SIGTERM. Daraufhin blieb der Container aus Sicht von Kubernetes 30 Sekunden lang "oben", bis Kubernetes nicht mehr warten will und ein SIGKILL schickt, um den Container "unsauber" herunterzufahren.
Interessanterweise reichte es nicht, da ein exec einzubauen in das Shellskript, das ihre Software ausführt. Sie mussten das Dockerfile umstellen.
Ganz blöder Bug, und ich finde es wunderbar, wenn Firmen sowas in Post Mortems veröffentlichen, damit man die Symptome googeln und die Lösung finden kann.
Mir hatte jemand die ursprüngliche Stellenanzeige gemailt, aber die war schon weg, als ich sie verlinken wollte. Das hier ist ein Artikel über die Anzeige.
Nur falls jemand dachte, Kubernetes betreffe ihn nicht.
Lockheed Martin Will Replace F-35’s Faulty Computer System With Cloud-Based ProgramsMich wundert bei sowas ja immer ein bisschen, dass die freiwillig ein Denial of Service im Netzwerk zu einem Denial of Service auf dem ganzen Gerät upgraden. Und in einem beweglichen Gerät ist das Netzwerk wahrscheinlich funk-basiert, d.h. ein Jammer reicht, und die Software kann nicht mehr mit der Cloud reden.
Ach komm, Fefe, ist doch bloß Sputnik.
Stimmt, aber ist halt kein Einzelfall.
Just like almost everything else, military organizations increasingly depend on software, and they are turning to an array of open source cloud tools like Kubernetes and Istio to get the job done, according to a presentation delivered by Nicholas Chaillan, chief software officer for the U.S. Air Force, at KubeCon 2019 in San Diego.Halt, halt, das war erst die halbe Meldung! Geht noch weiter!Those tools have to be deployed in some very interesting places, from weapons systems to even fighter planes. Yes, F-16s are running Kubernetes on the legacy hardware built into those jets.Ja, richtig gelesen! Kubernetes im F-16 und im Waffensystem!Ich weiß ja nicht, wie es euch geht, aber ich mache mir immer weniger Sorgen vor einem 3. Weltkrieg. Die werden ihre Flugzeuge gar nicht hochkriegen im Ernstfall, weil die Gegenseite das so timen wird, dass gerade Active Directory wegen eines Citrix-Patches abgeschaltet ist. (Danke, Carsten)
The Security Audit Working Group managed the audit over a four month time span.OK. Also das ist dann ziemlich katastrophal. Wenn die Auditoren nach vier Monaten Arbeit nur 37 Bugs gefunden haben, bei einem Projekt dieser Größe, dann heißt das im Allgemeinen, dass der Code so komplex und unverständlich war, dass man nicht entscheiden konnte, ob etwas ein Bug ist oder nicht, bis man da eine Woche dran herumgeforscht hat.Leider klingt das auch hier so:
Die Prüfer haben sich allerdings bei der Untersuchung auch nur auf acht Kernkomponenten der Software beschränkt und nur jene Probleme der Implementierung betrachtet, die "offensichtlich falsch" seien. Auch habe der Fokus der Untersuchung eher auf "Breite statt Tiefe" gelegen.Das klingt nach Nebelwand-Jargon für "wir haben nach Bugs gegreppt". Nach Bugs greppen macht man, wenn ein Projekt zu komplex ist, um es in der gegebenen Zeit sinnvoll zu verstehen zu versuchen. Bei vier Monaten Zeit könnt ihr euch ja selbst überlegen, wie krass überkomplex und unterverständlich das Projekt sein muss, damit Auditoren das machen. Der andere Indikator dafür ist "wir haben Fuzzing gemacht".
Die Auditoren kritisieren auch die hohe Komplexität von Kubernetes. Wir erinnern uns: Kubernetes war das Tool, das uns vor der Komplexität von Containern retten sollte. Das ist jetzt selber so komplex, dass es ein Rettungsprojekt braucht.
So wird Kubernetes als System mit "erheblicher Komplexität" bezeichnet. Ebenso seien die Konfiguration und das Deployment nicht trivial. Das wieder liege an "verwirrenden Standardeinstellungen, fehlenden Steuerungselementen und nur implizit definierten Security-Kontrollelementen".Das, meine Damen und Herren, ist das Ergebnis von agilen Methoden in der Softwareentwicklung. Genau das passiert, wenn man ein Projekt agil implementiert. Dann wird solange gefrickelt, bis den Use Case abdeckt, aber die interne Struktur ist Kraut und Rüben, Dokumentation "machen wir später" und sowas wie Codestruktur gibt es nicht oder nur zufällig.[…] So habe die riesige Codebasis große Teile mit nur "minimaler Dokumentation" sowie zahlreiche externe Abhängigkeiten. Außerdem gebe es viele Stellen, an denen bestimmte Programmlogik einfach reimplementiert wird.
Mir ist ja echt schleierhaft, wieso immer noch Leute auf diesen Agil-Hokuspokus reinfallen. Ich hatte gehofft, die Zeit von Wunderheilern und anderem Aberglauben ist vorbei. (Danke, Marian)
a malicious user could use the Kubernetes API server to connect to a backend server to send arbitrary requests, authenticated by the API server's TLS credentials.The API server is the main management entity in Kubernetes. It talks to the distributed storage controller etcd and to kublets, the agents overseeing each node in a cluster of software containers.
Das ist ein Container-Ausbruch-Szenario. Kubernetes ist ja seit Tag 1 Opfer seiner eigenen unnötigen Komplexität. Die Prämisse ist ja eigentlich relativ einfach. Man beschreibt ein System aus mehreren Containern deklarativ und ein Tool baut das dann auf. Ein Tool, um einen Container zu starten, geht in deutlich unter 100k statisches Binary. Ein Tool, um aus einer Beschreibung ein Image zu bauen, und sich die Bestandteile aus dem Internet zu ziehen, ist sagen wir mal 2 MB, da ist dann auch ein fettes OpenSSL mit drin.Aber Kubernetes hat da noch eine monströse Management-Infrastruktur draufgepackt, und alles riesige Go-Binaries natürlich. Ich habe hier gerade mal das aktuelle Kubernetes mit dem aktuellen Go gebaut -- da fallen 1.8 GB Binaries raus. Ja, Gigabytes! Kein Typo! Das ist völlig absurd. Und natürlich geht ohne die Management-Infrastruktur der Rest nicht. Aus meiner Sicht ein Architektur-Fuckup sondergleichen. Auf der anderen Seite tickt Docker ja genau so. Da muss man auch die ganze Zeit einen Docker-Daemon laufen haben. Was die sich dabei wohl gedacht haben? Ich glaube: Der läuft da hauptsächlich aus Branding-Gründen. Damit die Leute den Eindruck haben, Container sei eine hochkomplexe Docker-Tech, keine vergleichsweise einfache Linux-Kernel-Tech.