foto freepik
Kubernetes und Container haben die IT im Sturm erobert. Denn im Zusammenspiel bieten beide Technologien Unternehmen erhebliche Vorteile. So besteht die Möglichkeit, die Produktivität in der Entwicklung zu verbessern und plattformübergreifend zu arbeiten. Da containerisierte Anwendungen kein eigenes Betriebssystem haben, können sie zudem ohne Modifikation in jeder Umgebung laufen. Ebenso benötigen sie weniger Rechenleistung und Speicher als virtuelle Maschinen. Damit bieten sie Unternehmen substanzielle Einsparpotenziale. Allerdings werden Container umso komplexer, je größer die Anwendung ist. Speziell in Produktionsumgebungen muss die IT-Abteilung oft eine große Zahl von Containern installieren, disponieren und nach Ausfällen wieder hochfahren und mit der Außenwelt verbinden. »Das funktioniert nur mit einer automatisierten Container-Orchestrierung. Und hier kommt Kubernetes ins Spiel«, weiß Jerome Evans, Gründer und Geschäftsführer der firstcolo GmbH.
Flexibilität und Optimierung
Kubernetes ermöglicht die Verwaltung von containerbasierten Anwendungen in einer geclusterten Umgebung verbunden mit der Automatisierung des Container-Managements. Das bedeutet, es automatisiert die Verwaltung und die Steuerung der Container. Verteilte Komponenten und Dienste lassen sich so über Infrastrukturen hinweg miteinander kombinieren. »Nutzer können Anwendungen individuell skalieren, Anpassungen flexibel vornehmen und den Hardwareeinsatz optimieren. Nur in Ausnahmen profitieren Unternehmen nicht von dem System«, so Evans. Die Technologie rief ursprünglich Google ins Leben und spendete sie später zur Weiterentwicklung an die Cloud Native Computing Foundation (CNCF). Kubernetes als Applikation bietet somit im Grunde die Möglichkeit, komplexe Architekturen wie Microservice-Architekturen sehr effizient und sicher bezüglich der Performance und Verfügbarkeit zu managen. »Vor allem im E-Commerce oder komplexeren SaaS-Architekturen lohnt es sich, mit einem Kubernetes Cluster zu orchestrieren«, erläutert der Experte. Zielgruppen können hier – je nach Unternehmensgröße – IT-Entscheider, DevOps Engineers oder IT-Administratoren sein. So unterstützt die Lösung Nutzer, die sich grundlegend mit Deployments der jeweiligen Applikation beschäftigen.
Orientierung an Bedürfnissen
»Viele Unternehmer folgen der immer weiter voranschreitenden Containerisierung der IT-Ebene durch Kubernetes, allerdings gefolgt von dem Wunsch einer einfachen Implementierung«, so Evans. Rund 56 Prozent der Befragten einer repräsentativen Umfrage des Marktforschungsinstituts CCS bevorzugen aufgrund der Komplexität einer solchen IT-Architektur eine vollständige Containerintegration mittels Drittanbieter oder einem Ensemble aus Providern und der eigenen Expertise [1]. Dem zum Vorbild und den Endnutzer in den Fokus genommen, bieten Cloud-Dienstleister Lösungen an, die den Umgang mit Open-Source-Systemen wie beispielsweise firstkube deutlich vereinfachen. Nutzer müssen somit kein umfassendes Know-how mehr vorweisen, um Container verwalten zu können. »Möglich machen dies ein benutzerfreundliches Interface und eine kompetente Beratung durch einen Experten«, fügt der Experte an. User greifen mit firstkube zudem auf alle nötigen Services wie Monitoring, Compute, Networking, sowie Object-, Image-, und Block Storage zentral über ein grafisches Benutzerinterface (GUI) zu.
Erhebliche Effizienzsteigerung
In der Praxis eignet sich die Anwendung von Kubernetes-Clustern vor allem für die Automatisierung des Lebenszyklus eines Onlineshops, da es die manuellen Aufgaben für IT-Administratoren minimiert. So ermöglicht diese Strategie eine engere Integration vom Entwickler in den Deployment-Prozess. Die Effizienzsteigerung erfordert jedoch spezifische Hard Skills, da die Ausrichtung eines Clusters strategisch erfolgen muss. »Vor Projektbeginn stellt sich also die entscheidende Frage, ob die vorhandene Architektur Kubernetes-ready ist. Idealerweise sollte der Onlineshop eine Microservices-Architektur aufweisen oder schrittweise darauf umstellen, um Ordnung, Performance und Verfügbarkeit zu optimieren«, führt Evans an. Die Unterstützung eines Experten ist hier oftmals unerlässlich. Zentrale Vorteile einer Kubernetes-Lösung sind die schnelle Skalierung, erhebliche Effizienzsteigerungen und flexible Verfügbarkeitsanpassungen. Teams können autark an ihren zugewiesenen Containern arbeiten, was in einer Microservices-Architektur besonders vorteilhaft ist. Als Voraussetzung für eine erfolgreiche Kubernetes-Implementierung gilt jedoch immer eine moderne Architektur – vorzugsweise in der Cloud. Zwar bestehen theoretisch auch On-Premises-Optionen, allerdings erfordern sie mehr Anpassungen und Wartungsaufwand. »Insgesamt braucht es jedoch im besten Fall eine passende Beratung und Unterstützung von Experten, um einen reibungslosen Ablauf zu gewährleisten und die umfassenden Vorteile von Kubernetes effektiv zu nutzen«, schließt Evans.
Weitere Informationen über die firstcolo GmbH unter firstcolo.net.
[1] https://www.redhat.com/rhdc/managed-files/cl-containers-kubertnetes-market-dynamics-f29518-202106-en.pdf
Kubernetes: Warum Service Ownership und Prozessautomatisierung unverzichtbar sind
Illustration Absmeier foto freepik
Cloud-Dienste sind in vielen Unternehmen allgegenwärtig. Laut einer Umfrage der Cloud Native Computing Foundation (CNCF) aus dem Jahr 2022 nutzen 79 % der Unternehmen für die Administration ihrer Cloud-Anwendungen Kubernetes (K8s) [1]. Die Einführung dieses intelligenten Werkzeuges stellt viele Organisationen allerdings vor neue Herausforderungen. Vor allem werden neue Tools und Prozesse für die Verwaltung und Überwachung der Container-Ökosysteme benötigt.
Kubernetes ist ein Werkzeug zur Orchestrierung containerbasierter Anwendungen, mit dem sich u. a. die Bereitstellung von Containern, die Verteilung von Workloads und die Verwaltung der Ressourcen automatisieren lässt. Das K8s-Universum ist inzwischen eine der größten Open-Source-Communities; es gibt unzählige Erweiterungen und Lösungen für das Tool. Entsprechend hoch ist die Lernkurve bei Anwendern von Kubernetes, um die Vielfalt und damit verbundenen Risiken zu bewältigen. Drei Techniken sind für die Reaktion auf Vorfälle von unschätzbarem Wert:
- die Implementierung eines Service-Ownership-Ansatzes
- die Automatisierung von Prozessen
- die Nutzung einer Operations-Cloud.
Sie reduzieren die Komplexität für die Ersthelfer und entlasten ohnehin schon überarbeitete IT-Operations-Management-Teams (ITOM-Teams).
Service Ownership zur Problemerkennung
Wie bei praktisch jeder Software ist es unvermeidlich, dass auch mit Kubernetes verwaltete Anwendungen ausfallen oder nicht die erwünschte Leistung erreichen. Aufgrund der Komplexität von K8s fordern viele Incident-Response-Teams oft und frühzeitig die Unterstützung von Fachkräften an. Mit dem Service-Ownership-Ansatz werden die Entwickler und Ingenieure hinter einer Kubernetes-Umgebung erfasst und dokumentiert. Bei einem Incident können mit dem Service-Ownership-Ansatz gezielt geeignete Experten zur Behebung des Problems herangezogen werden. Durch die Verankerung dieser »Code it, Own It«-Mentalität in der Kubernetes-Verwaltung erhalten Mitarbeiter, die sich mit bestimmten Anwendungen oder Diensten weniger gut auskennen, immer sofort einen kompetenten Ansprechpartner.
Ein Service-Ownership-Ansatz bringt weitere Vorteile für das gesamte Unternehmen mit sich: Durch die klare Zuweisung von Verantwortlichkeiten können Probleme effektiver und effizienter gelöst werden, wodurch deutlich weniger Zeit für die Suche nach Zuständigkeiten aufgewendet wird. Dies reduziert die für Fehlersuche und Analyse eines Problems benötigte Anzahl an Mitarbeitenden. In Verbindung mit dem Fachwissen des Service-Verantwortlichen verkürzt sich die mittlere Zeit bis zur Lösung von Problemen (MTTR) erheblich. Auch trägt die Serviceverantwortung zur Qualitätskontrolle bei. Entwickler erhalten einen besseren Einblick in die Funktionsweise ihres Codes in der Produktion. Die Stabilität und Leistungsfähigkeit der Anwendungen erhöhen sich. Das verbessert die Erfahrung aller Beteiligten – auch bei den Kunden.
Mit der Einführung des Service Ownership minimiert sich die Komplexität im Umgang mit Kubernetes-Störungen. Allerdings erfordert dies einen Kulturwandel und eine hohe Akzeptanz innerhalb des Unternehmens. Die Verantwortlichen müssen die Silos aufbrechen, die Entwickler von den Operations- und Incident-Teams trennen.
Prozessautomatisierung für eine schnelle Reaktion
Kommt es in einer Kubernetes-Umgebung zu einem Zwischenfall, fehlt vielen Ersthelfern das Fachwissen oder die Zeit, um die Ursache eines Problems zu verstehen. Sie müssen für die Diagnose oft Ingenieure und Entwickler hinzuziehen.
Die Diagnosephase kann bis zu 85 % der Zeit bei der Reaktion auf einen Incident in Anspruch nehmen und ist damit meist der langwierigste Teil. Für die Diagnose müssen allerdings sehr oft standardisierte und wiederholbare Schritte wie CPU- und Speicherprüfungen oder die Überprüfung der letzten Code-Commits durchgeführt werden. Der Einsatz von Spezialisten für diese Aufgaben stellt einen erheblichen Kostenfaktor dar. Mit jeder Eskalation können die Ingenieure weniger Zeit für die Verbesserung von Services oder Bereitstellung von Innovationen für ein Unternehmen aufwenden. Die Prozessautomatisierung ist ideal für standardisierte und in hohem Maße wiederholbare Diagnose-Workflows.
Bei der Prozessautomatisierung wandeln die Teams die Diagnose-Workflows in sogenannte Runbooks um. Mit diesen Templates können Aufgaben wie die Diagnose von Ressourcen mit einfachen Kommandos gestartet und automatisiert durchgeführt werden. Einmal entwickelt, können Bibliotheken mit definierten Prozess-Runbooks den Incident-Response-Teams zur Verfügung gestellt werden. Ersthelfer können die Aufgabe dann auslösen, ohne technische Unterstützung anfordern zu müssen. Neben der Diagnose lassen sich auch Abhilfemaßnahmen automatisieren, zum Beispiel sich wiederholende Aufgaben wie Server-Neustarts oder das Löschen des Speicher-Caches.
Durch die Anwendung von automatisierten Prozessen sind Incident-Response-Teams in der Lage, in einer Kubernetes-Umgebung eine höhere Anzahl an Vorfällen zu bearbeiten und gleichzeitig die Anzahl der erforderlichen Eingriffe durch Ingenieure zu reduzieren. Es ergeben sich dadurch kürzere Lösungszeiten, weniger störende Eskalationen und mehr Zeit, welche die Ingenieur-Teams in die Entwicklung von Innovationen investieren können.
Nutzung einer Operations-Cloud
Bei der Verwaltung von Kubernetes-Anwendungen und -Umgebungen ist es wichtig, effektive Tools zur schnellen Problemlösung zur Verfügung zu stellen. Eine entscheidende Rolle spielen dabei die Service Ownership und Process Ownership: Diese helfen, robuste Prozesse zur Behebung von Kubernetes-Problemen zu gewährleisten und reduzieren die Komplexität bei der Erkennung und Eskalation von Kubernetes-Problemen Das verringert den Zeitaufwand für manuelle und wiederholbare Arbeitsabläufe.
Sowohl Service Ownership als auch Prozessautomatisierung eignen sich für Low-Code/No-Code-Lösungen zur Diagnose und Behebung von Kubernetes-Vorfällen auf Knopfdruck. Damit beides funktioniert, müssen sie jedoch als Teil einer Operations-Cloud eingesetzt werden. Kubernetes-Umgebungen sind von Natur aus schnellen Veränderungen unterworfen. Mit der kontinuierlichen Aktualisierung der Operations-Cloud können Änderungen hinsichtlich Service-Ownership und Best Practices nahezu in Echtzeit berücksichtigt werden. Zur Systematisierung von Prozessen rund um das Softwaremanagement und die Reaktion auf Vorfälle ist eine Operations-Cloud daher unverzichtbar.
Fazit
Service Ownership, Prozessautomatisierung und die Integration in eine Operations-Cloud unterstützen die Teams dabei, Incidents einzuordnen und zu priorisieren. Probleme können schneller gelöst und wertvolle Entwicklerzeit gespart werden. Auf diese Weise können Unternehmen die Zuverlässigkeit und Konsistenz ihrer Kubernetes-Ökosysteme und -Anwendungen gewährleisten. Das sorgt für zufriedenere Mitarbeiter und Kunden.
Mandi Walls, DevOps Advocate bei PagerDuty
Mandi Walls ist DevOps-Advocate bei PagerDuty. Dort unterstützt sie Technologieunternehmen dabei, ihre Effizienz durch moderne IT-Praktiken bei ungeplanten IT-Vorfälle zu steigern. Sie spricht regelmäßig auf technischen Konferenzen und ist Autorin des Whitepapers »Building a DevOps Culture«, das von O’Reilly veröffentlicht wurde. Ihr Interesse gilt der Entwicklung neuer Tools und Workflows, die den Betrieb großer und komplexer IT-Systeme vereinfachen.
[1] https://www.cncf.io/reports/cncf-annual-survey-2022/
Ordnung im Kubernetes-Chaos: Vor diesen Fehlern müssen sich Admins hüten
Foto Genki Absmeier
Kubernetes hat die Orchestrierung von Containern beherrschbar gemacht. Die Bedienung der Open-Source-Plattform ist allerdings keinesfalls trivial. Die hohe Komplexität verführt im praktischen Einsatz selbst Experten zu Fehlern. Die Folgen können gravierend sein – sind aber vermeidbar.
Kaum ein Administrator kommt heute noch ohne Kubernetes (K8s) aus, um Container zu verwalten. Der große Funktionsumfang der Orchestrierungs-Plattform ist allerdings Fluch und Segen: Einerseits lässt sie praktisch keinen Wunsch im Hinblick auf das Erstellen, Betreiben und Managen von Containern offen. Andererseits verleitet das hohe Komplexitätslevel auch versierte K8s-Administratoren zu Fehlern. Zu den beliebtesten gehören die unbedachte Containerisierung von Applikationen, die Zurückhaltung bei festen Vorgaben hinsichtlich Requests und Limits sowie die mangelnde Abstimmung der Probes auf die Applikationen. Die folgende detaillierte Analyse dieser Fehler soll Administratoren helfen, sie zu erkennen und zu vermeiden.
Chaotische Containerisierung
Der Hype um Container ist ungebrochen. Viele Unternehmen möchten mit ihnen ihre Anwendungen modernisieren. Doch nicht alle Apps eignen sich für den Container-Betrieb. Monolithische Legacy-Anwendungen sind das beste Beispiel dafür, denn sie sind zu groß, zu ressourcenhungrig, schlecht skalierbar und zu unflexibel. Auch Apps, die eine lange Laufzeit erwarten und mit einem unerwarteten Abbruch Probleme haben, sind nicht ideal: Container sind unveränderlich und müssen daher bei Änderungen neu gestartet werden. Um Datenverlust, eingeschränkter Verfügbarkeit und schlechter Performance vorzubeugen, sollten Administratoren nur Anwendungen in Containern ausrollen, die für den Betrieb in einer solchen Umgebung geeignet sind. Feste Vorschriften gibt es nicht, aber grundsätzlich sind Twelve-Factor-Apps ein guter Kompass. Sie umfassen eine Reihe von Regeln und Standards für moderne Applikationen, die auf den Cloud-nativen und verteilten Betrieb in K8s ausgelegt sind. In den meisten Fällen werden Entwickler nicht um ein Redesign herumkommen, denn Kubernetes spielt seine größten Stärken in Verbindung mit Microservices aus.
Besonderes Augenmerk müssen Entwickler zudem auf das Logging legen, das im Zusammenhang mit Containern einige Besonderheiten aufweist. Normalerweise schreiben Applikationen ihre Logs in Dateien. In einer Container-Umgebung geht das allerdings nicht, denn deren Dateisystem ist in der Regel nicht beschreibbar. In den seltenen Fällen, wo es das ist, gehen die Logs aber beim Container-Restart verloren. Aus diesem Grund sollten Entwickler die Standard-Datenströme stdout (Standard Out) und stderr (Standard Error) verwenden, um ihre Logs an die Container-Runtime weiterzuleiten. Sie kann die Logs verarbeiten und falls nötig an einen zentralen Log-Speicher wie ElasticSearch, Loki oder Splunk transferieren.
Renitente Ressourcenplanung
Auch eine unzulängliche Ressourcenplanung bereitet beim Betrieb von Containern große Probleme. In Kubernetes steuern Administratoren deren Verteilung über Requests und Limits. Requests entsprechen den benötigten Ressourcen, die das Orchestrierungs-Tool für die einwandfreie Ausführung eines Containers bereitstellen muss. Limits hingegen stellen Grenzwerte dar, bei deren Erreichen Kubernetes einem Container keine zusätzlichen Ressourcen mehr zuteilt. Jedoch setzt K8s auf die freiwillige Einschränkung, so sind standardmäßig weder Requests noch Limits aktiviert, das heißt jeder Container kann sämtliche Ressourcen eines Cluster-Knotens nutzen.
Verlassen sich Administratoren auf diese Methode, ist keine sinnvolle Ressourcenplanung möglich. Daher ist es Pflicht, diese Einstellungen zu forcieren. Doch auch unter dieser Voraussetzung ist Vorsicht geboten: Durch zu hohe Request-Werte droht eine ineffiziente Ressourcen-Nutzung und es können horrende Kosten entstehen, wenn die Container in einer Cloud-Umgebung laufen. Legen Administratoren sie zu niedrig an, startet die Applikation eventuell erst gar nicht oder läuft zu langsam, weil zu viele andere Container um die Ressourcen konkurrieren (Noisy-Neighbor- Effekt). Auch zu niedrige Limits bergen Gefahren, etwa Performance-Einbußen. Im schlimmsten Fall beendet die Plattform Container, obwohl die nötigen Ressourcen eigentlich vorhanden wären. Zu hohe Limits bergen das Risiko von Speicher- oder CPU-Engpässen, falls mehr Ressourcen angefordert werden, als real zur Verfügung stehen. Dies kann ebenfalls zur negativen Beeinflussung von Applikationen untereinander führen. Im Extremfall verdrängt ein Container den anderen.
Administratoren brauchen für das Feintuning der Ressourcenverteilung also etwas Geschick und Hilfe, etwa von Monitoring-Tools wie Prometheus und Policy-Engines wie OPA-Gatekeeper oder Kyverno. Es ist auf jeden Fall sinnvoll, dass jede Anwendung (oder jeder Container) maximal die Ressourcen erhält, die sie für einen funktionalen Betrieb benötigt.
Problematische Probes
Probes sind konfigurierbare Sensoren, mit denen Administratoren die Funktionsfähigkeit von Containern und den darin enthaltenen Anwendungen oder Microservices prüfen. Kubernetes bietet derer drei: Startup Probes, Readiness Probes und Liveness Probes. Mit ihnen können Administratoren zudem bestimmte Verhaltensmuster für Kubernetes definieren, die das Orchestrierungs-Tool durchsetzt, wenn eine festgelegte Situation eintritt. Der Klassiker ist etwa ein Container-Neustart, wenn eine Applikation nicht mehr korrekt funktioniert. Administratoren müssen die Konfiguration von Probes auf jede Anwendung individuell zuschneiden, daher kommt es oft zu Fehlern.
Startup Probes prüfen, ob ein Container läuft und die Prüfung durch eine weitere Probe überhaupt möglich ist. Ob der Service innerhalb eines Containers betriebsbereit ist, finden Administratoren mit Readiness Probes heraus. Über sie können sie zudem dessen Erreichbarkeit manipulieren. Lässt der Service Interaktionen mit Benutzern oder anderen Services zu, sollten Administratoren diese Probes auf jeden Fall einsetzen. Jedoch sollten sie vorsichtig sein, denn falsche Einstellungen führen an dieser Stelle dazu, dass der Service beispielsweise fehlerfrei läuft, für User aber trotzdem nicht erreichbar ist. Liveness Probes prüfen, ob die Container-Anwendung insgesamt noch korrekt funktioniert. Administratoren müssen dafür allerdings passende Indikatoren bestimmen, sonst drohen unnötige Neustarts des Containers.
Armin Kunaschik ist Senior DevOps Engineer bei Consol.