Mit <kes>+ lesen

Best Practices für Kubernetes in DevOps

Es soll schnell gehen heutzutage – und das geht es auch. Damit „schnell“ aber trotzdem „sicher“ bleibt, ist strategisch wie operativ einige Vorarbeit notwendig. Dieser Artikel erklärt, worauf für eine sichere und effiziente Nutzung von Kubernetes in einem DevOps-Umfeld zu achten ist.

Von Stephen Chin, Belmont (US/CA)

Die zunehmende Komplexität von IT-Infrastrukturen und die Verbreitung von dezentralen Diensten verlangen von Entwicklerteams, dass sie effektive Steuerungsmechanismen implementieren und gleichzeitig eine hohe Verfügbarkeit und Sicherheit gewährleisten. Das gilt umso mehr im schnelllebigen Umfeld von Container-Anwendungen und deren Administration. Die vorliegenden Empfehlungen zur Verwaltung der technischen Container- Infrastruktur (Orchestrierung) mittels des Open-Source-Systems Kubernetes in DevOps-Umgebungen adressieren diese Notwendigkeiten, indem sie gleichzeitig auf die Optimierung des Verhältnisses zwischen Pod und Node, den Schutz der Steuerungsebene, die Anwendungsverfügbarkeit, die Skalierungsplanung und die umfassende Sicherheit der Umgebung konzentrieren.

Der Schlüssel zur Nutzung von Kubernetes liegt darin, verschiedene Typen von Knoten (englisch: Nodes) basierend auf den Workload-Anforderungen zu verwenden – beispielsweise zur CPU- oder Speicheroptimierung. Durch die korrekte Anpassung der Container an das Verhältnis zwischen CPU und Speicher der Knoten können Organisationen ihre Ressourcennutzung optimieren.

Die richtige Anzahl von Pods (ein oder mehrere Software- Container, die garantiert gemeinsam auf demselben Knoten laufen) pro Node zu finden, ist allerdings ein Balanceakt, der die unterschiedlichen Konsummuster der einzelnen Anwendungen oder Services berücksichtigen muss. Die Verteilung der Last auf die Knoten mithilfe von Techniken wie Pod-Topology- Spread-Constraints [1] oder Pod-Anti-Affinity [2] trägt zur Optimierung der Ressourcennutzung und zur Anpassung an die sich ändernde Intensität der Workloads bei.

Schutz der Kubernetes-Steuerungsebene

Die Überwachung der Kubernetes-Steuerungsebene ist von entscheidender Bedeutung – gerade bei verwalteten Kubernetes Services. Auch wenn Cloud-Anbieter eine solide Kontrolle und Stabilität bieten, muss man sich ihrer Grenzen bewusst sein. Eine langsame Steuerungsebene kann das Verhalten des Clusters – einschließlich Planung, Upgrades und Skalierungsvorgängen – erheblich beeinträchtigen.

Selbst bei verwalteten Services gibt es Grenzen zu beachten: Eine übermäßige Nutzung der verwalteten Steuerungsebene kann zu katastrophalen Abstürzen führen. Es ist unerlässlich, immer daran zu denken, dass die Steuerungsebene überlastet werden kann, wenn man sie nicht ordnungsgemäß überwacht und verwaltet.

Optimierung der Anwendungsverfügbarkeit

Die Priorisierung kritischer Services optimiert die Betriebszeit von Anwendungen. Pod-Prioritäten und Servicequalität identifizieren Anwendungen mit hoher Priorität, die ständig laufen müssen – die Kenntnis der Prioritätsstufen ermöglicht die Optimierung von Stabilität und Leistung.

Gleichzeitig verhindert die Pod-Anti-Affinity [2], dass mehrere Replikate desselben Services auf demselben Knoten bereitgestellt werden. Dadurch lässt sich ein Single Point of Failure (SPoF) vermeiden, das heißt: Wenn auf einem Knoten Probleme auftreten, sind die anderen Replikationen nicht betroffen. Außerdem ist es vorteilhaft, für geschäftskritische Anwendungen spezielle Knotenpools einzurichten. Beispielsweise kann ein separater Knotenpool für Ingress-Pods und andere wichtige Services wie Prometheus die Stabilität des Dienstes und die User-Experience erheblich verbessern.

Planen der Skalierung

Unternehmen müssen heute darauf vorbereitet sein, umfangreiche Softwareverteilungen zu bewältigen und das erforderliche Kapazitätswachstum ohne negative Auswirkungen bereitzustellen – und das idealerweise ohne die bestehenden Systeme zum Wachsen zu zwingen. Die automatische Skalierung von Clustern in verwalteten Services kann dabei helfen; dabei ist es aber wichtig, die Grenzen der Clustergröße zu kennen: Ein typischer Cluster kann etwa 100 Knoten umfassen. Sobald diese Grenze erreicht ist, sollte ein weiterer Cluster eingerichtet werden, anstatt den bestehenden zum Wachstum zu zwingen.

Sowohl die vertikale als auch die horizontale Anwendungsskalierung sind zu berücksichtigen. Der Schlüssel liegt darin, das richtige Gleichgewicht zu finden, um die Ressourcen besser nutzen zu können, ohne sie übermäßig zu beanspruchen. Eine horizontale Skalierung und die Replikation oder Duplizierung von Workloads werden im Allgemeinen bevorzugt, allerdings mit dem Vorbehalt, dass dies Auswirkungen auf Datenbankverbindungen und Speicherplatz haben könnte.

Vorbereitung auf Ausfälle

Eine Planung für Ausfälle ist in verschiedenen Bereichen der Anwendungsinfrastruktur inzwischen gang und gäbe. Um sicherzugehen, dass man vorbereitet ist, sollte man Playbooks entwickeln, die unterschiedliche Ausfallszenarien abdecken einschließlich Anwendungs-, Knoten- und Cluster-Ausfällen. Die Implementierung von Strategien wie hochverfügbare Anwendungs-Pods und Pod-Anti-Affinity trägt dazu bei, eine Abdeckung auch bei Ausfällen zu gewährleisten.

Jedes Unternehmen benötigt einen detaillierten Disaster-Recovery-Plan für Cluster-Ausfälle und sollte diesen regelmäßig testen! Bei der Wiederherstellung hilft eine kontrollierte und schrittweise Bereitstellung, um eine Überlastung der Ressourcen zu vermeiden.

Absicherung der Software-Lieferkette

Software-Lieferketten sind durchgehend anfällig für Fehler und missbräuchliche Verwendung (siehe auch [4]). Es ist daher unbedingt notwendig, jeden Schritt der Pipeline zu kontrollieren und sich nicht auf externe Tools und Anbieter zu verlassen, ohne deren Vertrauenswürdigkeit sorgfältig geprüft zu haben.

Zur Kontrolle externer Quellen gehören Maßnahmen wie das Scannen von Binärdateien, die aus Remote-Repositorys stammen, sowie deren Validierung mithilfe von Software-Composition-Analysis (SCA, vgl. [5]). Teams sollten außerdem Qualitäts- und Sicherheitskontrollen in der gesamten Pipeline durchführen, um eine höhere Qualität der gelieferten Software und mehr Vertrauen sowohl seitens der Benutzer als auch innerhalb der Pipeline selbst zu gewährleisten.

Laufzeitsicherheit

Der Einsatz von Admission-Controllern zur Durchsetzung von Regeln (z. B. das Blockieren der Nutzung gesperrter Versionen) trägt zur Laufzeitsicherheit bei. Tools wie OPA Gatekeeper helfen bei der Durchsetzung von Richtlinien, die beispielsweise nur überprüfte Container- Registries für die Bereitstellung zulassen.

Rollenbasierte Zugriffskontrollen sind ebenfalls empfehlenswert, um den Zugang zu Kubernetes-Clustern abzusichern. Andere Lösungen für die Laufzeitsicherheit wiederum können Risiken in Echtzeit erkennen und beheben. Die Isolation von Namespaces sowie Netzwerkrichtlinien helfen dabei, laterale Bewegungen zu blockieren und Workloads innerhalb von Namespaces zu schützen. Man sollte zudem erwägen, kritische Anwendungen auf isolierten Knoten auszuführen, um das Risiko von Container-Escape-Szenarien zu minimieren.

Absicherung der ganzen Umgebung

Wer seine Umgebung sichern will, muss davon ausgehen, dass das Netz ständig angegriffen wird. Um verdächtige Aktivitäten in den Clustern und der Infrastruktur zu erkennen, sind Überwachungstools ebenso wie Maßnahmen zur Laufzeitsicherheit mit voller Transparenz und Workload-Kontrollen empfehlenswert.

Best-of-Breed-Tools sind hilfreich, aber ein starkes Incident-Response-Team mit einem klaren Playbook für Warnmeldungen oder verdächtige Aktivitäten ist unerlässlich! Ähnlich wie bei einem Disaster-Recovery sind auch hier regelmäßige Tests und Maßnahmen erforderlich. Viele Unternehmen setzen überdies Bug-Bounty- Programme oder externe Forscher/Pentester ein, die versuchen, Systeme zum Aufdecken von Schwachstellen zu kompromittieren – die externe Perspektive und die objektive Untersuchung können dabei wertvolle Erkenntnisse liefern.

Kontinuierliches Lernen

Bei der Weiterentwicklung von Systemen und Prozessen ist kontinuierliches Lernen von entscheidender Bedeutung. Das schließt die Erfassung historischer Performance- Daten ein, um Maßnahmen zu bewerten und anzuwenden. Kleine, kontinuierliche Verbesserungen sind üblich – was in der Vergangenheit relevant war, ist es heute möglicherweise nicht mehr.

Die proaktive Überwachung von Performance- Daten kann helfen, Speicher- oder CPU-Lecks in Services oder Performance Probleme in einem Drittanbieter-Tool zu erkennen. Durch die aktive Auswertung von Daten auf Trends und Anomalien lassen sich das Verständnis und die Performance eines Systems verbessern. Eine derartige proaktive Überwachung und Analyse führt zu effektiveren Ergebnissen als das Reagieren auf Echtzeitwarnungen.

Der Mensch ist das schwächste Glied

Automatisierung minimiert, wo immer möglich, die menschliche Beteiligung und manchmal ist das auch gut so – wenn es um Sicherheit geht, ist der Mensch das schwächste Glied. Man sollte deswegen die verschiedenen verfügbaren Automatisierungsmöglichkeiten erkunden, um die beste Lösung für die eigenen spezifischen Prozesse und Definitionen zu finden.

GitOps ist – als Alternative zum Continuous-Delivery-(CD)-Ansatz – mittlerweile beliebt, um Änderungen von der Entwicklung in die Produktion zu übertragen und bietet geläufige Verträge und ein Interface für die Verwaltung von Konfigurationsänderungen. Eine ähnliche Methode verwenden mehrere Repositories für verschiedene Arten von Konfigurationen. Dabei ist es aber wichtig, eine klare Trennung zwischen Entwicklungs-, Staging-und Produktionsumgebungen beizubehalten – auch wenn sie einander ähneln sollten.

KI – Fluch und Segen

KI-gesteuerte Lösungen versprechen vielfältige Perspektiven für die Zukunft, da sie dazu beitragen, die betriebliche Komplexität zu verringern und Aufgaben im Zusammenhang mit Environment-Management, Software-Bereitstellungen und Fehlerbehebung zu automatisieren. Dennoch bleibt menschliches Urteilsvermögen unersetzlich und sollte immer berücksichtigt werden.

Gegenwärtige KI-Systeme stützen sich häufig auf öffentlich zugängliche Informationsquellen, die ungenau, veraltet oder irrelevant sein können – und somit zu fehlerhaften Schlüssen oder Empfehlungen führen können.

In dieser Dualität von Chance und Herausforderung liegt die Notwendigkeit eines klugen Einsatzes von KI: Ein ausgeprägtes Bewusstsein für ihre Grenzen und eine kritische Überprüfung ihrer Ausgaben durch menschliche Expertise sind entscheidend, um die Vorteile der Technologie sicher und effektiv zu nutzen.

Fazit und Ausblick

Die hier vorgestellten Best Practices – von der präzisen Abstimmung zwischen Pods und Nodes bis hin zur Etablierung kontinuierlicher Lernprozesse – unterstreichen die Notwendigkeit wohlüberlegter Strategien und tiefgehender Kenntnisse in der Feinjustierung von Konfigurationen.

Die Zukunft von DevOps erfordert darüber hinaus eine fortschrittliche Anpassungsfähigkeit an die sich rasant entwickelnden Technologien und Anforderungen. Es ist zu erwarten, dass die Bedeutung von menschlichem Fachwissen und strategischer Planung zunehmen wird, um mit der steigenden Komplexität von Infrastrukturen und neuen Herausforderungen Schritt halten zu können. Besonders in kritischen Bereichen wie der Sicherheit, Systemüberwachung und Katastrophenwiederherstellung bleibt die menschliche Expertise unersetzlich.

Literatur

Literatur

[1] Kubernetes, Pod Topology Spread Constraints, Dokumentation, März 2024, https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/

[2] Kubernetes, Affinity and Anti-Affinity, in: Assigning Pods to Nodes, Dokumentation, April 2024, https://kubernetes.io/docs/concepts/scheduling-eviction/assignpod-node/#affinity-and-anti-affinity

[3] Michael Cade, Der Siegeszug agiler Containerisierung, Vorteile von DevOps, Cloud, Kubernetes und IaC – und eine Mahnung zur modernen Datensicherung, <kes> 2021#4, S. 59

[4] Udo Schneider, Der lange dunkle Weg ins Licht, Integrität digitaler Artefakte in der Lieferkette, <kes> 2023#4, S. 46

[5] Evren Eren, DevSecOps (2), Aspekte und Hinweise zur Umsetzung, <kes> 2022#1, S. 20

Diesen Beitrag teilen: