Ist Kubernetes ein Glas, das halb leer oder halb voll ist? Nun, das hängt davon ab, wie man es betrachtet! Die Mechanik seiner Orchestrierungsfunktionen ist (meiner Meinung nach) ziemlich komplex, und es ist nicht ungewöhnlich, dass selbst erfahrene Praktiker deswegen mit dem Kopf gegen die Wand schlagen. Gleichzeitig habe ich es oft für unerfahrene Benutzer und sogar für Geschäftsfälle empfohlen, in denen die Kapazität für technische Schulden begrenzter ist - mit dem Ziel, intelligenter und nicht härter zu arbeiten. Ich arbeite in einem zweiten Teilzeitjob als Freiberufler und betreue ein System für eine kleine gemeinnützige Organisation. Wenn ich also nicht 8 Stunden am Tag babysitten kann, ist das Leben für uns alle umso besser, je mehr schwere Arbeit ich auf K8s abwälzen kann. Und selbst wenn ich für ein großes Unternehmen arbeite, in dem ich 8 Stunden am Tag für den Babysitterdienst bezahlt werde, würde ich lieber die Leistung von K8s nutzen, um das meiste davon für mich zu erledigen. Das ist die Perspektive des halbvollen Glases: Betrachten Sie K8s als einen Verbündeten, der Ihnen das Leben leichter machen soll. Erklären Sie, was Sie wollen, und lassen Sie es tun, was es am besten kann.
Da dieser Ansatz allzu simpel erscheinen mag, möchte ich auch auf unsere Tendenz hinweisen, die Dinge übermäßig komplex zu gestalten. Zum Beispiel, wenn wir eine Lösung für eine "Zukunftssicherung", die noch gar nicht in Sicht ist, zu sehr ausreizen oder wenn wir das Rad neu erfinden, anstatt auf bewährte Werkzeuge zurückzugreifen, die bereits speziell für die Aufgabe entwickelt wurden. Das Eintauchen in das Plattform-Engineering ist da keine Ausnahme, aber darauf werden wir in einem späteren Artikel näher eingehen.
K8s ist ein leistungsfähiger und komplexer Organismus, aber denken Sie daran, dass viele unserer Branchenkollegen viele Stunden damit verbracht haben, es zu etwas zu machen, das "einfach funktioniert", und wie beim Autofahren lernt man am besten aus der Praxis.
Ich habe Kubernetes zum ersten Mal im Jahr 2019 kennengelernt - an der Front des Linode-Kundensupportteams - als wir die Linode Kubernetes Engine (LKE) veröffentlichten. Es war ein "Sink or Swim"-Moment, den wir nicht vermeiden konnten, weil die Nachfrage der Nutzer einfach zu groß war. Wir mussten dieses Produkt unterstützen, d. h. wir mussten es erlernen und - noch besser - Fehler beheben! Auch wenn es manchmal frustrierend war, gehörten diese Erfahrungen zu den wertvollsten in meiner Laufbahn.
In diesem Artikel werden wir einige Strategien zum Erlernen und Verwalten von Kubernetes erkunden, die auf realen Erfahrungen wie den meinen basieren.
Learning by Doing
Der beste Weg, die Plattform wirklich zu verstehen, ist das Erstellen und brechen Dinge. Die Kombination von Dokumentation und Tutorials ist ein guter Weg, um einen funktionierenden Cluster in die Hände zu bekommen. Legen Sie Ihre Manifeste in einem Git-Repository ab und Sie haben eine Vorlage, auf die Sie immer wieder zurückgreifen können. Als Nächstes sollten Sie einen interessanten Weg finden, es zu zerstören. Das könnte bedeuten, dass Sie einen Freund oder Mitarbeiter einen Versuch machen lassen, so dass Sie keine Ahnung haben, woher das Problem kommt, bis Sie mit der Diagnose beginnen. Eine andere Methode, die ich verwendet habe, besteht darin, etwas Komplizierteres zu tun als das, was in der Anleitung gezeigt wird. Nehmen wir zum Beispiel an, dass Sie den CKAD-Kurs der Linux Foundation absolvieren. Dort werden Sie vielleicht angewiesen, einen vereinfachten Cluster mit nur einer Steuerebene und einem Arbeitsknoten zu erstellen. Versuchen Sie stattdessen, einen Cluster mit drei Control-Plane-Knoten für hohe Verfügbarkeit und drei Worker-Knoten erfolgreich zu booten. Als ob das nicht schon schwierig genug wäre, versuchen Sie, eine VPC zu implementieren und die Netzwerkadressierung des Clusters anzupassen, um Kollisionen im IP-Raum zu vermeiden. Selbst wenn Sie nach einiger Zeit frustriert das Handtuch werfen, werden Sie viel mehr gelernt haben, als Sie es sonst getan hätten. Dies sind nur zwei Beispiele aus meiner eigenen Erfahrung. Der Himmel ist die Grenze.
Darüber hinaus können Tools wie Minikube oder Kind sehr hilfreich für lokale Experimente sein, bevor Sie etwas in der Cloud anfassen. Unabhängig davon, wie Sie bei der Fehlersuche und -behebung in Ihrem Cluster vorgehen, sollten Sie auf jeden Fall eine Dokumentation hinterlassen. Das Aufschreiben ist gut für Ihr Gedächtnis, da es Sie dazu zwingt, die Schritte und Lösungen zu artikulieren. Wenn Sie die Zeit haben, diese Dokumentation zu veröffentlichen, können Sie nicht nur mit Ihrer hervorragenden Methodik zur Fehlerbehebung angeben, sondern auch Ihren Kollegen helfen.
Fehlersuche als Lernweg
Was die Methodik der Fehlerbehebung angeht, so gibt es keine "beste Praxis", sondern nur "Ihre Praxis", d. h. Sie sollten den Weg finden, der für Sie am besten funktioniert - was auch immer das ist. Wichtig ist, dass Sie die Absicht haben, diesen Muskel für sich selbst aufzubauen, und es wird mit der Zeit einfacher. Die besten Problemlöser, die ich kennengelernt habe, sind durch jahrelanges Üben genau dieser Vorgehensweise zu den besten geworden, und deshalb kann ich ihnen alles vor die Füße werfen. In der Folge sind sie auch die schwammigsten Lernenden.
Hier sind einige Techniken, die für mich am besten funktionieren:
- Teilen und erobern: Das Problem in zwei Hälften teilen und systematisch mögliche Ursachen ausschließen. Während es für manche einfacher ist, systematisch den Stapel hochzuklettern, habe ich in der Regel Erfolg, wenn ich mich gleich auf das stürze, was ich zuerst ausschließen kann. Ist das ein Widerspruch zu den guten Ratschlägen der anderen? Möglicherweise! Aber mich interessiert mehr, was für mich funktioniert.
- Monitoring und Beobachtbarkeit sind Ihre Freunde, und das gilt auch für Fehler: Metriken, Logs und Traces können ein ganzheitliches Bild des Systems zeichnen, und noch besser, ein ganzheitliches Bild des Problems! Prometheus und Grafana sind de facto der Standard für die Überwachung und bieten eine gute Grundlage für die Auswahl von Log-Aggregations- und Tracing-Tools. In der realen Welt ist man jedoch nicht immer mit einem vollständigen Observability-Stack gesegnet - manchmal ist das Beste, was man bekommen kann, Prometheus und Grafana mit einigen Remote-Zielen zum Scrapen. Glücklicherweise reicht das in den meisten Fällen immer noch aus, und ob mit oder ohne, behandeln Sie Fehlermeldungen als Ihren Freund! Sicherlich sind einige hilfreicher als andere, aber nichtsdestotrotz ist dies eine Rückmeldung des Systems mit der Information, dass etwas schief gelaufen ist.
- Stellen Sie das Problem nach: Stellen Sie das Problem so weit wie möglich in einer anderen Umgebung nach. Dies kann eine Fülle von Informationen über die Ursache liefern, die Ihnen die Tür zur Lösung öffnen. Es bedeutet auch, dass Sie eine Testumgebung haben, mit der Sie gefahrlos experimentieren können. Einer der vielen Gründe, warum es eine gute Praxis ist, die Möglichkeiten von Infrastructure as Code (IaC) zu nutzen, ist die Möglichkeit, diese Umgebung bei Bedarf schnell wiederherzustellen oder zu zerstören. Selbst wenn dies bedeutet, dass Sie es selbst schreiben müssen, kann es in Situationen, in denen die Umgebung vorher nicht kodifiziert war, ein wenig mehr Zeit im Voraus sparen, um später viel mehr Zeit zu haben.
- Führen Sie ein Fehlerbehebungsprotokoll: Sie sind vielleicht mit dem Konzept eines Architekturentscheidungsprotokolls vertraut. Was hindert Sie daran, ein ähnliches Konzept auf die Fehlersuche anzuwenden? Nichts! Und es braucht auch keine besondere Formatierung oder Konvention. Führen Sie einfach ein Protokoll über die einzelnen Schritte der Fehlerbehebung. Das kann nützlich sein, wenn Sie die Dinge, die Sie bereits ausgeschlossen haben, noch einmal überprüfen oder bestätigen müssen. Im besten Fall können Sie später darauf zurückgreifen, um die Lösung zu dokumentieren und zu erklären, wie Sie zu dieser Lösung gekommen sind. Wenn Sie in der Lage sind, die einzelnen Schritte und die dahinter stehende Logik zu formulieren, können Sie sich besser an sie erinnern. Außerdem wird es sich für jeden, der Ihre Dokumentation liest, als nützlich erweisen. Ein guter Kandidat für eine solche Dokumentation ist eine interne Wissensdatenbank oder sogar ein öffentlich zugänglicher Blog, um andere zu unterrichten.
Wenn Sie mit besonders schwierigen Problemen konfrontiert sind, können Sie die Fehlerbehebung als Lernchance begreifen, was langfristig zu einer Verbesserung Ihrer Problemlösungskompetenz führt und die Art und Weise, wie Sie Ihre Infrastruktur verwalten, verbessert. Teams, die ihre Debugging-Prozesse verfeinern und wiederholen, sind besser gerüstet, um die Leistungsfähigkeit von Kubernetes zu nutzen.
Einsatz einfacher, zuverlässiger Technik
Das Cloud-Native-Ökosystem (und die Cloud-Landschaft insgesamt) bietet eine Fülle von Tools und Frameworks zum Zusammenfügen. Die Möglichkeiten, was Sie bauen können, sind nahezu endlos! Dieser Gedanke kann jedoch oft zu einigen großen Fallstricken führen: zu viele Tools, zu viel Komplexität und zu viele technische Schulden. Glücklicherweise lässt sich diese Falle mit ein wenig Disziplin und einer bestimmten Einstellung leicht vermeiden: Weniger ist mehr. Die beste Technik ist die wartungsfreundlichste und stabilste Technik, und Sie werden feststellen, dass Ihre Benutzer dem zustimmen. Wenn Sie auf eine Leiter klettern müssten, um auf das Dach eines Hauses zu gelangen, würden Sie nicht wollen, dass sie so übertechnisiert ist, dass Sie Zweifel haben, ob Sie sie richtig benutzen. Das wäre ja beängstigend!
Es gibt keinen Stolz, eine Codebasis zu pflegen, die so kompliziert ist, dass sie niemand lesen kann. Es gibt keine Goldmedaille oder Trophäe für den Aufbau eines Systems, das so komplex ist, dass fast niemand es benutzen kann. Was wir wollen, sind Dinge, die funktionieren, die stabil sind und die wir zuverlässig und korrekt verwenden können, ohne uns noch mehr Mühe zu geben. Einfachheit ist hier Ihr Freund. Denken Sie auch daran, dass ein Cloud Native Design Pattern ein Muster ist, das schnelle Veränderungen zulässt. Ihre Anwendungsarchitektur wird im Laufe der Zeit ganz natürlich an Komplexität gewinnen, wenn sie sich weiterentwickelt - es gibt also keinen Grund, diese Entwicklung zu forcieren. Mit einem minimalistischen Ansatz in Verbindung mit einem modularen Cloud-nativen Design können Teams schlankere und sicherere Systeme haben und Bereitstellungen, Wartung und Fehlerbehebung rationalisieren.
Darüber hinaus trägt eine einfache Gestaltung dazu bei, das Risiko von Fehlkonfigurationen zu verringern, die die Leistung beeinträchtigen und/oder die Angriffsfläche für Sicherheitslücken vergrößern.
Kubernetes selbst ist eine Abstraktion. Wir könnten es nicht "Cloud Native" nennen, wenn es das nicht wäre, aber die Menge an unnötigen Abstraktionen in Schach zu halten bedeutet, dass Ingenieure weniger Zeit damit verbringen, die zugrunde liegende Komplexität zu verwalten, und mehr Zeit damit verbringen, sich auf die Wertschöpfung zu konzentrieren. Ich stehe hier zu meiner eigenen Meinung, die dem "All-you-can-eat"-Ansatz zuwiderläuft, denn die fortschrittlichsten Innovationen, die ich im Laufe meiner Karriere gesehen habe, stammen von Unternehmen, die den "strengen Diät"-Ansatz verinnerlicht haben: diejenigen, die sich auf die Beherrschung der Grundlagen konzentriert haben, so dass sie sicher und zuverlässig einige sehr innovative Produkte entwickeln können, die sehr komplexe Probleme lösen.
Die Beherrschung von Kubernetes fortsetzen
Mit einer Kombination aus praktischer Erfahrung, einer soliden Methodik zur Fehlerbehebung und einem durchdachten Tooling-Ansatz lässt sich Kubernetes viel leichter beherrschen. Lernen durch Handeln (anstatt nur zu lesen) hilft dabei, Problemlösungsfähigkeiten zu erlernen, die im realen Betrieb entscheidend sind. Bei der Fehlersuche geht es nicht nur darum, Fehler zu beheben, sondern auch darum, das eigene Verständnis zu verfeinern, die Dokumentation zu verbessern und einen systematischen Ansatz zu entwickeln, mit dem sich künftige Herausforderungen leichter lösen lassen. Und die Vereinfachung Ihres Kubernetes-Stacks durch die Minimierung unnötiger Abstraktionen reduziert den kognitiven Aufwand und erleichtert die Verwaltung im Laufe der Zeit.
Wie viele erfahrene Praktiker gelernt haben, ist ein schlanker und gut strukturierter Cluster einfacher zu warten und zu skalieren als ein Cluster, der mit Tools überladen ist, die die Komplexität erhöhen, ohne klare Vorteile zu bieten. Letztendlich geht es beim Erfolg mit Kubernetes nicht darum, jedes neue Tool auf dem Markt zu verwenden, sondern zu wissen, welche davon langfristig einen echten Mehrwert bieten.
Wenn Sie mehr über Kubernetes erfahren möchten, können Sie sich den KubeFM-Podcast ansehen, der auf YouTube oder unten zu finden ist.
Kommentare