Inhalt
Kubernetes ist die führende Orchestrierungsplattform für Container-Umgebungen. Mit ihr können Entwickler und Betreiber skalierbare, zuverlässige und effiziente Anwendungen verwalten. Die Plattform verfügt über eine Vielzahl von Funktionen, die eine einfache und automatisierte Verwaltung von Container-Anwendungen ermöglichen.
Wie bei jeder anderen leistungsstarken Technologie gibt es auch hier Best Practices und Fallstricke, die es zu kennen gilt. In unserem heutigen Blogpost erläutern wir Ihnen die 12 häufigsten „Dos and Don’ts“ in der Welt der Kubernetes-Container.
Wir zeigen Ihnen, welche Best Practices es gibt, damit Sie häufige Fehler vermeiden können. Darüber hinaus erhalten Sie wertvolle Tipps zur optimalen Konfiguration und Verwaltung Ihrer Kubernetes-Umgebung. So können Sie Ihre Kenntnisse erweitern und Ihre Container-Orchestrierung auf die nächste Stufe bringen.
6 Kubernetes Best Practices
Bevor wir auf die Fallstricke und typischen Fehler bei der Container-Orchestrierung schauen, widmen wir uns den bewährten Methoden für die erfolgreiche Arbeit mit Kubernetes.
-
Do: Leichtgewichtige Container-Images verwenden
Schlanke Basisimages tragen dazu bei, die Containergröße zu reduzieren und die Angriffsfläche für potenzielle Sicherheitsrisiken zu minimieren. Für eine leichtgewichtige Container-Image-Alternative bieten sich zum Beispiel die Alpine-Images an. Darüber hinaus empfehlen wir bei der Cluster-Erstellung Flatcar OS, das speziell für Container-Workloads optimiert ist. Dieses Betriebssystem bietet eine sichere und effiziente Grundlage für den Betrieb von Containern. Weitere Informationen dazu finden Sie in unserem Blogpost „Flatcar: Das Betriebssystem für Kubernetes erklärt“.Für die Container-Workloads sollten nur notwendige Bibliotheken und Tools installiert werden. So wird der Speicherverbrauch minimiert, was die Effizienz der Container weiter steigert. Schließlich ermöglicht eine schlanke Container-Umgebung eine bessere Skalierbarkeit und Anpassungsfähigkeit an unterschiedliche Workloads. Zudem ist somit ein geringer Wartungsaufwand des Deployments gegeben, was ein Debugging vereinfacht. - Do: Anwendungen voneinander isolieren Um Isolation und Sicherheit zu gewährleisten, sollte jede Anwendung in einem eigenen Container betrieben werden. Diese Trennung verhindert, dass Probleme oder Sicherheitslücken in einer Anwendung die anderen Anwendungen beeinträchtigen. Zudem ermöglicht die Isolation eine bessere Kontrolle über die Ressourcen, die jeder Container verwendet. Durch die getrennte Ausführung der Anwendungen und die zusätzliche Einschränkung des Zugriffs zwischen den Anwendungen durch Network Policies wird das Risiko von Sicherheitsvorfällen erheblich reduziert. Dazu trägt auch die Beschränkung der exponierten internen Dienste durch IP-Whitelisting auf dem NGINX Ingress bei. Insgesamt wird mit dieser Kubernetes Best Practice die Gesamtstabilität der Container-Umgebung verbessert.
- Do: Zwei-Faktor-Authentisierung für den Cluster-Zugriff Die Zwei-Faktor-Authentisierung (2FA) ist eine effektive Methode, um die Sicherheit des Cluster-Zugriffs signifikant zu erhöhen. Durch die Implementierung von 2FA im Rahmen des Identity & Access Managements wird der Zugang zusätzlich abgesichert und das Risiko von unbefugten Zugriffen minimiert. In unserer Dokumentation „PSKE - Einrichten von OIDC/2FA auf PSKE“ finden Sie eine detaillierte Anleitung zur Implementierung einer 2FA-Lösung in Ihrem Kubernetes-Cluster. Diese zusätzliche Sicherheitsebene ist definitiv ein Do für Kubernetes und trägt dazu bei, den Schutz Ihrer sensiblen Daten und Container zu gewährleisten.
- Do: Container überwachen Ein Monitoring- und Logging-Stack ermöglicht es, die Performance und Verfügbarkeit der Multi-Container-Umgebungen kontinuierlich zu überwachen. Durch diese Überwachung können potenzielle Probleme frühzeitig erkannt und behoben werden, bevor sie den Betrieb beeinträchtigen. Im Falle von Fehlern oder Unregelmäßigkeiten bieten die Container-Logs wertvolle Einblicke, um gezielt zu debuggen. Dadurch wird die Betriebssicherheit erhöht und die Reaktionszeit bei Störungen deutlich verkürzt.
- Do: Umgebungsvariablen für Konfigurationen Die Verwendung von Umgebungsvariablen für Konfigurationen in Multi-Container-Umgebungen ermöglicht eine einfache und flexible Anpassung der Container-Konfiguration ohne Änderungen am Code. Das erleichtert die Verwaltung von Konfigurationen über verschiedene Umgebungen wie Entwicklung, Test und Produktion hinweg. Umgebungsvariablen fördern zudem die Wiederverwendbarkeit von Containern, da dieselben Images in verschiedenen Szenarien eingesetzt werden können. Und nicht zuletzt erhöht die Trennung von Konfiguration und Code die Sicherheit, da sensible Informationen wie Passwörter oder API-Schlüssel nicht im Quellcode enthalten sind.
- Do: Read-only-Dateisysteme Änderungen am Dateisystem sind eine häufige Fehlerquelle. Ein Read-only-Dateisystem minimiert das Risiko von unerwarteten Verhaltensweisen und erleichtert die Fehlersuche. Es trägt dazu bei, den Angriffsvektor deutlich zu reduzieren, was die Sicherheit in einer Multi-Container-Umgebung erhöht. Read-only-Dateisysteme sind daher ein Best Practice in der Containerisierung. Sie erhöhen nicht nur die Sicherheit, sondern verbessern auch die Reproduzierbarkeit, reduzieren die Fehleranfälligkeit und steigern die Ressourceneffizienz.
6 häufige Kubernetes Fails
Welche häufigen Fehler gibt es bei der Arbeit mit Kubernetes? Diese Dinge gilt es im Umgang mit Containern zu vermeiden.
- Don’t: Ressourcengrenzen ignorierenDas Ignorieren von Ressourcengrenzen für Container ist ein häufiger Fehler, der die Stabilität der gesamten Container-Umgebung gefährden kann. In Kubernetes können für jeden Pod Ressourcenanforderungen (requests) und Limits (limits) für CPU und RAM definiert werden.Diese Werte sind entscheidend, um sicherzustellen, dass jeder Pod genau die Ressourcen erhält, die er benötigt, ohne dass er zu viele oder zu wenige Ressourcen beansprucht. Wenn keine Ressourcenanforderungen gesetzt sind, kann es vorkommen, dass Pods mehr CPU oder Speicher verbrauchen, als eigentlich notwendig ist. Eine solche unvorhersehbare Nutzung der Cluster-Ressourcen kann zu Engpässen, Leistungsproblemen oder sogar dem Absturz (Out Of Memory Killer or OOM) von Pods führen.
- Don’t: Wichtige Daten im Container persistierenAnwendungsdaten in Containern zu speichern, ist ein klares Don’t für Kubernetes. Es besteht das Risiko, dass diese Daten bei einem Container-Neustart oder -Absturz verloren gehen. Um Datenverlust zu vermeiden, ist es zwar essenziell, dass alle kritischen Daten persistiert werden, jedoch sollte das eben nicht in den Containern selbst erfolgen.RWX-Volumes sind hier ein sicherer Lösungsansatz, um Daten unabhängig von der Laufzeit der Container zu persistieren. Der große Vorteil liegt darin, dass diese in einer Multi-Container-Umgebung von allen Containern gemountet werden können. Weitere Informationen zur Implementierung von NFS-Shares über RWX-Volumes und deren Verwendung in Multi-Container-Umgebungen finden Sie in unserer Dokumentation „Read-Write-Many-Volumes (RWX via plusstorage NFS (v2))“.
- Don’t: Große, monolithische Container nutzenDie Aufteilung der Anwendungen in kleinere, spezialisierte Container ermöglicht eine klare Trennung der einzelnen Container, wodurch die Verwaltung und Skalierung jedes Containers vereinfacht wird. Diese Isolation verringert zudem das Risiko, dass ein Problem in einem Container die gesamten Multi-Container-Umgebungen beeinträchtigt. Ganz nebenbei erhöht man dadurch auch die Flexibilität, denn mit der Isolation ist es möglich, Updates und Änderungen nur an einzelnen Containern vorzunehmen. Einen gesamten Software-Stack als monolithischen Container zu deployen, ist daher ein klares Don’t und gehört nicht zu den Kubernetes Best Practices.
- Don’t: Updates ignorierenWir empfehlen, Container- und Basis-Images sowie die Kubernetes-Version regelmäßig zu aktualisieren, um potenzielle Sicherheitslücken zu schließen. Dass trägt dazu bei, die Stabilität und Sicherheit Ihrer Multi-Container-Umgebungen zu gewährleisten. In unserer Dokumentation „PSKE Managed Kubernetes“ erfahren Sie, wie Sie automatische Updates für Ihr Cluster einrichten können. Konfigurierbare Wartungsfenster helfen dabei, den Update-Prozess reibungslos und ohne Unterbrechungen im Betrieb durchzuführen.
- Don’t: Verschiedene Container-Image-Versionen verwenden Durch das Fixieren von Versionen ist sichergestellt, dass ein Container immer mit exakt den gleichen Bibliotheken, Tools und Konfigurationen ausgeführt wird, egal wann oder auf welcher Plattform. Versionssprünge können unvorhergesehene Auswirkungen haben. Durch den Einsatz einer spezifischen Version lässt sich das Risiko von Kompatibilitätsproblemen und Ausfällen reduzieren. Wenn ein Problem auftritt, kann leichter zurückverfolgt werden, welche Version zum Zeitpunkt des Fehlers verwendet wurde. Durch die Verwendung fester Versionen wird die Zusammenarbeit im Team erleichtert, da jeder Entwickler mit derselben Container-Image-Version arbeitet.
- Don’t: Sensible Daten in Container-Images speichernFür sensible Daten ist es empfehlenswert, dedizierte Tools wie HashiCorp Vault oder ähnliche Secret-Management-Tools zu nutzen, um notwendige Credentials zu speichern und zu verwalten. Mittels einer REST-API des Secret-Management-Tools und einer Token-basierten Authentifizierung kann dann innerhalb einer Multi-Container-Umgebung darauf zugegriffen werden.Dies ermöglicht eine bessere Kontrolle und vereinfacht die Auditierung. Um sicherzustellen, dass nur autorisierte Benutzer Zugriff auf das Secret-Management-Tool haben, kann eine Rollen-basierte Zugriffskontrolle (RBAC) implementiert werden.
Jetzt mit Managed Kubernetes loslegen!
Wenn Sie in Zukunft Kubernetes-Fehler vermeiden und stattdessen einfach und selbständig mit Kubernetes arbeiten möchten, lohnt sich ein Blick auf Managed Kubernetes bei plusserver. Lassen Sie sich persönlich beraten oder starten Sie direkt Ihren unverbindlichen Test.
Unsere ausführliche Dokumentation enthält viele weitere Kubernetes Best Practices und begleitet Sie von der Bestellung bis zu ambitionierten Projekten.
Über den Autor
Sebastian Knop ist seit Januar 2017 bei plusserver tätig. Seit 2022 widmet er sich als DevOps Engineer Kubernetes der Weiterentwicklung der plusserver Kubernetes Engine (PSKE).
Weiterführende Inhalte
Blog
OpenStack und Kubernetes: Ziemlich gute Freunde?
Erfahren Sie hier, wie OpenStack und Kubernetes Unternehmen voranbringen.
Blog
Die plusserver Kubernetes Engine im Test
Heise testete unsere plusserver Kubernetes Engine intensiv, fokussiert auf Kubernetes-Härtung.
Blog
Was ist DevSecOps? Sicherheit in DevOps integrieren
DevSecOps macht IT-Sicherheit zum essentiellen Teil der Entwicklung und Bereitstellung von Anwendungen.
