🥇Die 7 besten Praktiken für den Betrieb von Containern laut Google

Hinweis.: Der Autor des Originalartikels ist Théo Chamley, Architekt für Cloud-Lösungen bei Google. In diesem Beitrag für den Google Cloud Blog präsentiert er eine kurze Zusammenfassung aus einem detaillierteren Leitfaden seines Unternehmens mit dem Titel „Best Practices für den Betrieb von Containern“. Darin haben Experten von Google die besten Praktiken für den Betrieb von Containern im Zusammenhang mit der Nutzung von Google Kubernetes Engine und darüber hinaus gesammelt und ein breites Spektrum von Themen angesprochen: von Sicherheit bis Monitoring und Logging. Welche Praktiken sind also laut Google bei der Arbeit mit Containern am wichtigsten?

Kubernetes Engine (ein auf Kubernetes basierender Dienst zum Ausführen containerisierter Anwendungen in Google Cloud — Anmerk. d. Ü.) — ist eine der besten Möglichkeiten, um Workloads zu betreiben, die skalierbar sind. Kubernetes Es wird einen reibungslosen Betrieb der meisten Anwendungen gewährleisten, sofern sie containerisiert sind. Aber wenn Sie möchten, dass Ihre Anwendung leicht zu verwalten ist und alle Vorteile von Kubernetes nutzen möchten, müssen Sie die besten Praktiken befolgen. Diese erleichtern den Betrieb der Anwendung, deren Monitoring und Debugging und erhöhen gleichzeitig die Sicherheit.

In diesem Artikel werfen wir einen Blick auf die Dinge, die Sie wissen sollten und was zu tun ist, damit Container in Kubernetes effektiv funktionieren. Wer tiefer in die Details eintauchen möchte, sollte das Material lesen. Best Practices für den Betrieb von Containern, sowie auf unseren früheren Beitrag zur Erstellung von Containern.

1. Nutzen Sie die nativen Container-Mechanismen für das Logging.

Wenn die Anwendung in einem Kubernetes-Cluster betrieben wird, ist nicht viel für die Protokolle nötig. Ein zentrales Logging-System ist wahrscheinlich bereits im eingesetzten Cluster integriert. Bei Verwendung von Kubernetes Engine ist dafür Stackdriver Logging. (Hinweis.verantwortlich. Wenn Sie eine eigene Kubernetes-Installation verwenden, empfehlen wir unser Open-Source-Lösung — loghouse.) Erschweren Sie sich nicht das Leben und nutzen Sie die nativen Container-Logging-Mechanismen. Schreiben Sie Logs in stdout und stderr — sie werden automatisch erfasst, gespeichert und indiziert.

Auf Wunsch können Sie die Logs auch in JSON-Format. Dieser Ansatz ermöglicht es, problemlos Metadaten hinzuzufügen. Und zusammen mit diesen Metadaten wird in Stackdriver Logging die Möglichkeit entstehen, nach Logs mit diesen Metadaten zu suchen.

2. Stellen Sie sicher, dass die Container stateless und immutable sind.

Für das korrekte Funktionieren von Containern in einem Kubernetes-Cluster müssen sie stateless und immutable sein. Wenn diese Bedingungen erfüllt sind, kann Kubernetes seine Aufgaben erledigen, indem es Anwendungsentitäten nach Bedarf erstellt und zerstört.

Stateless bedeutet, dass alle Zustände (dauerhafte Daten jeglicher Art) außerhalb des Containers gespeichert werden. Abhängig von den Anforderungen können unterschiedliche Arten von externen Speicherlösungen eingesetzt werden: Cloud Storage, Persistente Disk, Redis, Cloud SQL oder andere verwaltete Datenbanken. (Hinweis.: Weitere Informationen dazu finden Sie auch in unserem Artikel „Operatoren für Kubernetes: wie man stateful Anwendungen startet».)

Immutable bedeutet, dass der Container während seiner Lebensdauer nicht verändert wird: keine Updates, Patches, Änderungen an der Konfiguration. Wenn Sie den Anwendungscode aktualisieren oder einen Patch anwenden müssen, erstellen Sie ein neues Image und deployen Sie es. Es wird empfohlen, die Containerkonfiguration (z. B. den Listening-Port, Umgebungsoptionen usw.) extern zu lagern – in Secrets und ConfigMaps. Diese können ohne die Notwendigkeit, ein neues Container-Image zu erstellen, aktualisiert werden. Für einfache Pipelines zur Image-Erstellung kann Cloud Build. (Hinweis.: Wir verwenden dazu ein Open Source-Tool dapp.)

Beispiel für die Aktualisierung der Deployment-Konfiguration in Kubernetes mithilfe von ConfigMap, die in Pods als Konfiguration eingebunden ist.

3. Vermeiden Sie privilegierte Container.

Sie betreiben doch keine Anwendungen unter root auf Ihren Servern, oder? Wenn ein Angreifer in die Anwendung eindringt, erhält er root-Rechte. Die gleichen Überlegungen gelten, um privilegierte Container nicht zu starten. Wenn Änderungen an den Einstellungen des Hosts erforderlich sind, können Sie dem Container spezifische Capabilities festzulegen. mit der Option securityContext in Kubernetes. Wenn Änderungen an den sysctls, hat Kubernetes eine separate Annotation dafür. Insgesamt versuchen Sie, so viel wie möglich init- und Sidecar-Container für solche privilegierten Operationen zu nutzen. Sie benötigen keine Erreichbarkeit für internen oder externen Traffic.

Wenn Sie einen Cluster verwalten, können Sie die Pod-Sicherheitsrichtlinie für Einschränkungen bei der Verwendung privilegierter Container nutzen.

4. Vermeiden Sie das Ausführen unter root.

Es wurde bereits über privilegierte Container gesprochen, doch es wird noch besser, wenn Sie zusätzlich dazu keine Anwendungen unter Root innerhalb des Containers ausführen. Wenn ein Angreifer eine Remote-Sicherheitsanfälligkeit in einer Anwendung mit Root-Rechten findet, die eine Codeausführung ermöglicht, kann er möglicherweise durch eine noch unbekannte Schwachstelle den Container verlassen und Root-Zugriff auf dem Host erlangen.

Der beste Weg, dies zu vermeiden, besteht darin, zunächst nichts unter Root auszuführen. Dazu kann die Direktive USER in Dockerfile oder runAsUser in Kubernetes verwendet werden. Der Cluster-Administrator kann auch erzwungene Verhaltenseinstellungen über Pod-Sicherheitsrichtlinie.

5. Machen Sie die Anwendung einfach zu überwachen

Wie das Logging ist Monitoring ein unverzichtbarer Teil des Anwendungsmanagements. Eine beliebte Lösung für das Monitoring in der Kubernetes-Community ist Prometheus — ein System, das automatisch Pods und Dienste erkennt, die überwacht werden müssen. (Hinweis.: Siehe auch unseren detaillierten Bericht zum Thema Monitoring mit Prometheus und Kubernetes.) Stackdriver kann Kubernetes-Cluster überwachen und beinhaltet seine eigene Version von Prometheus zur Anwendungsüberwachung.

Das Kubernetes-Dashboard in Stackdriver

Prometheus erwartet, dass die Anwendung Metriken an einen HTTP-Endpunkt weiterleitet. Dazu stehen zur Verfügung Prometheus-Clientbibliotheken. Ein ähnliches Format verwenden auch andere Tools wie OpenCensus und Istio.

6. Stellen Sie den Gesundheitszustand der Anwendung zur Verfügung

Die Verwaltung einer Anwendung in der Produktion wird durch die Fähigkeit unterstützt, ihren Status dem gesamten System mitzuteilen. Läuft die Anwendung? Ist sie in Ordnung? Ist sie bereit, Verkehr zu empfangen? Wie verhält sie sich? Der gebräuchlichste Weg, dieses Problem zu lösen, ist die Implementierung von Gesundheitsprüfungen (health checks). Kubernetes hat zwei Arten davon: Liveness- und Readiness-Probes.

Für die Liveness-Probe (Lebensfähigkeitsprüfung) muss die Anwendung einen HTTP-Endpunkt haben, der eine „200 OK“-Antwort zurückgibt, wenn sie funktioniert und ihre Hauptabhängigkeiten erfüllt sind. Für die Readiness-Probe (Bereitschaftsprüfung) Die Anwendung sollte einen anderen HTTP-Endpunkt haben, der eine „200 OK“-Antwort zurückgibt, wenn die Anwendung gesund ist, die Initialisierungsschritte abgeschlossen sind und eine gültige Anfrage keinen Fehler verursacht. Kubernetes leitet den Verkehr nur an den Container weiter, wenn die Anwendung gemäß diesen Prüfungen einsatzbereit ist. Zwei Endpunkte können zusammengelegt werden, wenn zwischen den Zuständen der Lebensfähigkeit (liveness) und der Einsatzbereitschaft (readiness) kein Unterschied besteht.

Mehr dazu können Sie im entsprechenden Artikel von Sandeep Dinesh, Developer Advocate bei Google, lesen: „Kubernetes Best Practices: Einrichtung von Gesundheitschecks mit Readiness- und Liveness-Probes».

7. Wählen Sie die Version des Images sorgfältig aus

Die meisten öffentlichen und privaten Images verwenden ein Tagging-System, das dem in Best Practices for Building Containersähnelt. Wenn das Image ein System anwendet, das dem semantischen Versionierungähnlich ist, müssen Sie die spezifischen Anforderungen an das Tagging berücksichtigen. Zum Beispiel kann das Tag latest häufig zwischen Images wechseln — darauf kann man sich nicht verlassen, wenn vorhersehbare und reproduzierbare Builds und Installationen benötigt werden.

Sie können das Tag X.Y.Z (sie bleiben fast immer unverändert), jedoch sollten Sie in diesem Fall alle Patches und Updates für das Abbild verfolgen. Wenn das verwendete Abbild einen Tag hat X.Y, ist das eine gute Wahl für die goldene Mitte. Wenn Sie es auswählen, erhalten Sie automatisch Patches und basieren gleichzeitig auf einer stabilen Version der Anwendung.