Wie Kubernetes DevOps-Praktiken unterstützt

Die Vorteile von Kubernetes für DevOps

Ein agiles Rahmenwerk ist die Grundlage für den DevOps-Lieferzyklus der meisten Organisationen. Kubernetes als Werkzeug für verteilte Orchestrierung passt zu einer agilen Praxis und die serviceorientierte Architektur sowie das objektorientierte Framework unterstützen agile Prinzipien.

DevOps deckt in der Regel jeden Schritt im Lebenszyklus einer Software ab (Abbildung 2), von der Planung und vom Build bis hin zur Bereitstellung und Überwachung.

Kubernetes minimiert den Aufwand für die Infrastruktur zur Bereitstellung von DevOps und verbessert gleichzeitig die Automatisierung, Skalierbarkeit und Anwendungselastizität. Metriken für das Steuern der Kubernetes-Implementierung können in eine allgemeine Analyse- oder AIOps-Strategie für die Anwendung einfließen. DevOps-Teams können Richtlinien für die Ausfallsicherheit und Skalierung über Kubernetes festlegen und verbringen weniger Zeit mit der manuellen Verwaltung dieser Faktoren in der Produktion.

Kubernetes ermöglicht es Administratoren, Anwendungen überall bereitzustellen, ohne sich um die zugrunde liegende Infrastruktur kümmern zu müssen. Diese Abstraktionsebene ist ein großer Vorteil für Unternehmen, die Container betreiben. Ein Container läuft innerhalb von Kubernetes immer gleich. Somit kann eine Firma Anwendungen mit dem gleichen Maß an Kontrolle bereitstellen, unabhängig davon, ob die Container in einer Cloud, zum Beispiel für den Zugriff durch Remote-Mitarbeiter oder in der lokalen Infrastruktur ausgeführt werden.

Innerhalb von Kubenetes wird alles als Code behandelt. Infrastruktur- und Anwendungsschichten werden als deklarative und portable Konfigurationsanweisungen geschrieben und in einem Repository gespeichert. Kubernetes verwaltet diese Konfigurationsressourcen als versionierte Artefakte. Administratoren schreiben Konfigurationsänderungen, wie zum Beispiel ein Wartungs-Update, in Kubernetes in den Code und stellen sie bereit, statt sie manuell zu implementieren. Dadurch sparen Administratoren Zeit, da sie diese Routineaufgaben nicht mehr händisch durchführen müssen.

Kubernetes ermöglicht auch ausgefeilte Bereitstellungstechniken, wie zum Beispiel das Testen in der Produktion und Release Rollbacks. Entwickler können somit eine Codeänderung schnell ausrollen, ein Schlüsselelement einer DevOps-Strategie.

Innerhalb von Kubernetes

Kubernetes betreibt Container über Pods und Knoten. Ein Pod betreibt einen oder mehrere Container. Pods können aus Gründen der Skalierung und Ausfallsicherheit redundant aufgebaut sein. Die Pods laufen wiederum auf Knoten. Knoten sind in der Regel in einem Cluster gruppiert und abstrahieren die physischen Hardwareressourcen, unabhängig davon, ob sie sich in einem eigenen Rechenzentrum oder in einer Public Cloud befinden.

Kubernetes kann als Hybridlösung ausgeführt werden – On-Premises oder in der Cloud. Die bessere Zusammenarbeit durch das Ausführen von Kubernetes in der Cloud hilft besonders DevOps-Teams, die an einem anderen Standort sitzen.

Zudem ist Kubernetes eine Open-Source-Technologie. Ursprünglich von Google entwickelt, wird sie nun von der Cloud Native Computing Foundation verwaltet. Da das Tool den Open-Source-Standards folgt, lässt es sich mit verschiedenen Toolchains und anderen Diensten verknüpfen, die in einer DevOps Pipeline zum Einsatz kommen. So verlassen sich viele DevOps-Organisationen auf eine CI/CD-Toolchain (Continuous Integration, Continuous Deployment, kontinuierliche Integration/Bereitstellung), die den Code automatisch von einem Prozessschritt zum nächsten bewegt, einschließlich der Containerisierung.

Kubernetes ändert keine Container, während sie in Betrieb sind. Die Unveränderbarkeit – ein Hauptmerkmal von Kubernetes – ist ein Vorteil, da IT-Administratoren dadurch einen Container während des Betriebs stoppen, neu zuweisen und neu starten können, und zwar mit minimalen Auswirkungen auf Dienste, die nicht im konkreten, bearbeiteten Container laufen.

Nicht zuletzt unterstützt Kubernetes auch Helm Charts (Abbildung 2). Dabei handelt es sich um wiederverwendbare Kubernetes-Pakete, die benötigte Ressourcen auflisten. Administratoren können Helm-Diagramme verwenden, um Anwendungen in mehreren Projekten einheitlich zu konfigurieren. Ohne diese Option der Ressourcenverwaltung müssten die Entwickler die Software für jede Umgebung eigens anpassen.

Die Risiken von Kubernetes für DevOps-Teams

Die hohe Komplexität von Kubernetes kann selbstzerstörerische Dimensionen annehmen. Zwar steigt laut dem VMware State of Kubernetes Report die Popularität von Kubernetes weiter an, doch gibt es in Arbeitsmärkten weltweit einen Mangel an Kubernetes-Fachleuten. Bevor Unternehmen Kubernetes in ihrem DevOps-Team einsetzen, sollten sie nicht nur Kubernetes Proof-of-Concept- oder Pilotprojekte aufbauen (PoC), sondern auch in die Ausbildung ihrer Mitarbeiter investieren.

Die Organisationen sollten sich auch dessen bewusst sein, wie Kubernetes Ressourcen abstrahiert und verschiedenen Containern zuweist. Multi-Tenancy erhöht die Komplexität bei der Bereitstellung von Diensten.

Jede Umgebung hat ihre eigenen Anforderungen und Sicherheitsmechanismen. Wenn jeder Zweig in einem Unternehmen einen eigenen Kubernetes-Cluster und unterstützende Dienstleistungen wie Sicherheitsdienste benötigt, damit ein Tenant die Cluster-Ressourcen nicht monopolisier und die Leistung der anderen Tenants nicht beeinträchtigen kann, dann müssen die Administratoren diese verschiedenen Kubernetes-Setups getrennt nebeneinander verwalten.

Ein weiteres Anliegen ist, dass jeder Mieter nur auf seine jeweiligen Dienste, einschließlich Metriken, Protokolle und Metadaten, zugreifen kann. In der Folge ist der Einsatz von Kubernetes in der Praxis komplizierter, als in der Theorie und in größeren Implementierungen eine Herausforderung.

Eine suboptimale Ressourcennutzung stellt ebenfalls ein Risiko dar. Schlechtes Design und unvorbereitete Cloud-Migrationen verführen IT-Teams dazu, feste Mengen von CPU-, Festplattenpeicher-, Arbeitsspeicher- und Netzwerkressourcen für jeden Dienst bereitzustellen.

Diese Silos führen zu Over-Provisioning, um jederzeit die maximal zu erwartende Auslastung zu ermöglichen. Das wiederum lässt die Ausgaben für die Cloud in die Höhe schießen oder verschwendet Platz auf der eigenen Hardware.

Die Zukunft der DevOps Toolchain für die Orchestrierung

Die DevOps Toolchain ist seit langem als wichtiger Gegenstand der Automatisierung bekannt, sei es durch CI/CD-Tools, skriptgesteuerte Bereitstellung oder eine Kombination aus beidem. Automatisierung ist jedoch nur ein Aspekt verteilter Orchestrierung. Die Zukunft der DevOps-Toolchains ist ganz entschieden auf hybride Szenarien ausgerichtet und unterstützt Legacy-Anwendungen, die sich noch in Rechenzentren befinden, bestehende Anwendungen in der Cloud und Anwendungen, die neu in die Cloud migriert werden.

Diese Anwendungen wiederum werden zunehmend hybride Büros und Remote-Arbeitskräfte – einschließlich der DevOps-Teams – unterstützen, die von überall auf Anwendungen mit schnellen Reaktionszeiten zugreifen sollen.

Damit die DevOps-Toolchain diese Aufgaben erfüllen kann, sollten

• Kubernetes;
• die Automatisierung der Workflow-Dienste;
• Cloud-Ressourcen; und
• DevOps-Praktiken sowie Automatisierungswerkzeuge Teil der Strategie sein.