{"id":39016,"date":"2019-10-31T22:27:21","date_gmt":"2019-10-31T19:27:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/7-luchshih-praktik-po-ekspluatatsii-kontejnerov-po-versii-google\/"},"modified":"2019-10-31T22:27:21","modified_gmt":"2019-10-31T19:27:21","slug":"7-luchshih-praktik-po-ekspluatatsii-kontejnerov-po-versii-google","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/7-luchshih-praktik-po-ekspluatatsii-kontejnerov-po-versii-google","title":{"rendered":"7 besten Praktiken f\u00fcr das Container-Management laut Google","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hinweis.<\/b>: Der Autor des Originalartikels ist Th\u00e9o Chamley, Architekt f\u00fcr Cloud-L\u00f6sungen bei Google. In diesem Beitrag f\u00fcr den Google Cloud Blog pr\u00e4sentiert er eine kurze Zusammenfassung aus einem detaillierteren Leitfaden seines Unternehmens mit dem Titel \u201eBest Practices f\u00fcr den Betrieb von Containern<\/a><\/noindex>\u201c. Darin haben Experten von Google die besten Praktiken f\u00fcr den Betrieb von Containern im Zusammenhang mit der Nutzung von Google Kubernetes Engine und dar\u00fcber 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?<\/i><\/p>\n

\"7<\/a><\/noindex><\/p>\n

Kubernetes Engine<\/a><\/noindex> (ein auf Kubernetes basierender Dienst zum Ausf\u00fchren containerisierter Anwendungen in Google Cloud \u2014 Anmerk. d. \u00dc.<\/b>)<\/i> \u2014 ist eine der besten M\u00f6glichkeiten, um Workloads zu betreiben, die skalierbar sind. Kubernetes<\/a><\/noindex> Es wird einen reibungslosen Betrieb der meisten Anwendungen gew\u00e4hrleisten, sofern sie containerisiert sind. Aber wenn Sie m\u00f6chten, dass Ihre Anwendung leicht zu verwalten ist und alle Vorteile von Kubernetes nutzen m\u00f6chten, m\u00fcssen Sie die besten Praktiken befolgen. Diese erleichtern den Betrieb der Anwendung, deren Monitoring und Debugging und erh\u00f6hen gleichzeitig die Sicherheit.<\/p>\n

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\u00f6chte, sollte das Material lesen. Best Practices f\u00fcr den Betrieb von Containern<\/a><\/noindex>, sowie auf unseren fr\u00fcheren Beitrag<\/a><\/noindex> zur Erstellung von Containern.<\/p>\n

1. Nutzen Sie die nativen Container-Mechanismen f\u00fcr das Logging.<\/h2>\n

\nWenn die Anwendung in einem Kubernetes-Cluster betrieben wird, ist nicht viel f\u00fcr die Protokolle n\u00f6tig. Ein zentrales Logging-System ist wahrscheinlich bereits im eingesetzten Cluster integriert. Bei Verwendung von Kubernetes Engine ist daf\u00fcr Stackdriver Logging<\/a><\/noindex>. (Hinweis.<\/b>verantwortlich. Wenn Sie eine eigene Kubernetes-Installation verwenden, empfehlen wir unser Open-Source-L\u00f6sung \u2014 loghouse<\/a><\/noindex>.)<\/i> Erschweren Sie sich nicht das Leben und nutzen Sie die nativen Container-Logging-Mechanismen. Schreiben Sie Logs in stdout und stderr \u2014 sie werden automatisch erfasst, gespeichert und indiziert.<\/p>\n

Auf Wunsch k\u00f6nnen Sie die Logs auch in JSON-Format<\/a><\/noindex>. Dieser Ansatz erm\u00f6glicht es, problemlos Metadaten hinzuzuf\u00fcgen. Und zusammen mit diesen Metadaten wird in Stackdriver Logging die M\u00f6glichkeit entstehen, nach Logs mit diesen Metadaten zu suchen.<\/p>\n

2. Stellen Sie sicher, dass die Container stateless und immutable sind.<\/h2>\n

\nF\u00fcr das korrekte Funktionieren von Containern in einem Kubernetes-Cluster m\u00fcssen sie stateless und immutable sein. Wenn diese Bedingungen erf\u00fcllt sind, kann Kubernetes seine Aufgaben erledigen, indem es Anwendungsentit\u00e4ten nach Bedarf erstellt und zerst\u00f6rt.<\/p>\n

Stateless<\/i> bedeutet, dass alle Zust\u00e4nde (dauerhafte Daten jeglicher Art) au\u00dferhalb des Containers gespeichert werden. Abh\u00e4ngig von den Anforderungen k\u00f6nnen unterschiedliche Arten von externen Speicherl\u00f6sungen eingesetzt werden: Cloud Storage<\/a><\/noindex>, Persistente Disk<\/a><\/noindex>, Redis<\/a><\/noindex>, Cloud SQL<\/a><\/noindex> oder andere verwaltete Datenbanken. (Hinweis.<\/b>: Weitere Informationen dazu finden Sie auch in unserem Artikel \u201eOperatoren f\u00fcr Kubernetes: wie man stateful Anwendungen startet<\/a><\/noindex>\u00bb.)<\/i><\/p>\n

Immutable<\/i> bedeutet, dass der Container w\u00e4hrend seiner Lebensdauer nicht ver\u00e4ndert wird: keine Updates, Patches, \u00c4nderungen an der Konfiguration. Wenn Sie den Anwendungscode aktualisieren oder einen Patch anwenden m\u00fcssen, erstellen Sie ein neues Image und deployen Sie es. Es wird empfohlen, die Containerkonfiguration (z. B. den Listening-Port, Umgebungsoptionen usw.) extern zu lagern \u2013 in Secrets<\/a><\/noindex> und ConfigMaps<\/a><\/noindex>. Diese k\u00f6nnen ohne die Notwendigkeit, ein neues Container-Image zu erstellen, aktualisiert werden. F\u00fcr einfache Pipelines zur Image-Erstellung kann Cloud Build<\/a><\/noindex>. (Hinweis.<\/b>: Wir verwenden dazu ein Open Source-Tool dapp<\/a><\/noindex>.)<\/i><\/p>\n

\"7
\nBeispiel f\u00fcr die Aktualisierung der Deployment-Konfiguration in Kubernetes mithilfe von ConfigMap, die in Pods als Konfiguration eingebunden ist.<\/i><\/p>\n

3. Vermeiden Sie privilegierte Container.<\/h2>\n

\nSie starten Ihre Anwendungen doch nicht als Root auf Ihren Servern, oder? Wenn ein Angreifer Zugriff auf die Anwendung erh\u00e4lt, erlangt er Root-Rechte. Dieselben \u00dcberlegungen gelten auch daf\u00fcr, dass privilegierte Container nicht gestartet werden. Wenn es erforderlich ist, die Host-Einstellungen zu \u00e4ndern, kann dem Container spezifische Capabilities festzulegen.<\/i> mit der Option securityContext<\/code><\/a><\/noindex> in Kubernetes. Wenn \u00c4nderungen an den sysctls<\/i>, hat Kubernetes eine separate Annotation<\/a><\/noindex> daf\u00fcr. Insgesamt versuchen Sie, so viel wie m\u00f6glich init-<\/a><\/noindex> und Sidecar-Container f\u00fcr solche privilegierten Operationen zu nutzen. Sie ben\u00f6tigen keine Erreichbarkeit f\u00fcr internen oder externen Traffic.<\/p>\n

Wenn Sie einen Cluster verwalten, k\u00f6nnen Sie die Pod-Sicherheitsrichtlinie<\/a><\/noindex> f\u00fcr Einschr\u00e4nkungen bei der Verwendung privilegierter Container nutzen.<\/p>\n

4. Vermeiden Sie das Ausf\u00fchren unter root.<\/h2>\n

\nZu privilegierten Containern wurde bereits gesagt, aber es w\u00e4re noch besser, wenn Sie zus\u00e4tzlich dazu keine Anwendungen innerhalb des Containers als Root ausf\u00fchren. Wenn ein Angreifer eine Remote-Sicherheitsanf\u00e4lligkeit mit Codeausf\u00fchrung in einer Anwendung mit Root-Rechten findet, k\u00f6nnte er durch eine derzeit unbekannte Verwundbarkeit den Container verlassen und Root-Rechte auf dem Host erlangen.<\/p>\n

Der beste Weg, dies zu vermeiden, besteht darin, vor allem nichts als Root auszuf\u00fchren. Sie k\u00f6nnen hierf\u00fcr die Direktive USER<\/code> in Dockerfile<\/code> oder runAsUser<\/code> in Kubernetes verwendet werden. Der Cluster-Administrator kann auch erzwungene Verhaltenseinstellungen \u00fcber Pod-Sicherheitsrichtlinie<\/a><\/noindex>.<\/p>\n

5. Machen Sie die Anwendung einfach zu \u00fcberwachen<\/h2>\n

\nWie das Logging ist Monitoring ein unverzichtbarer Teil des Anwendungsmanagements. Eine beliebte L\u00f6sung f\u00fcr das Monitoring in der Kubernetes-Community ist Prometheus<\/a><\/noindex> \u2014 ein System, das automatisch Pods und Dienste erkennt, die \u00fcberwacht werden m\u00fcssen. (Hinweis.<\/b>: Siehe auch unseren detaillierten Bericht<\/a><\/noindex> zum Thema Monitoring mit Prometheus und Kubernetes.)<\/i> Stackdriver<\/a><\/noindex> kann Kubernetes-Cluster \u00fcberwachen und beinhaltet seine eigene Version von Prometheus zur Anwendungs\u00fcberwachung.<\/p>\n

\"7
\nDas Kubernetes-Dashboard in Stackdriver<\/i><\/p>\n

Prometheus erwartet, dass die Anwendung Metriken an einen HTTP-Endpunkt weiterleitet. Dazu stehen zur Verf\u00fcgung Prometheus-Clientbibliotheken<\/a><\/noindex>. Ein \u00e4hnliches Format verwenden auch andere Tools wie OpenCensus<\/a><\/noindex> und Istio<\/a><\/noindex>.<\/p>\n

6. Stellen Sie den Gesundheitszustand der Anwendung zur Verf\u00fcgung<\/h2>\n

\nDie Verwaltung einer Anwendung in der Produktion wird durch die F\u00e4higkeit unterst\u00fctzt, ihren Status dem gesamten System mitzuteilen. L\u00e4uft die Anwendung? Ist sie in Ordnung? Ist sie bereit, Verkehr zu empfangen? Wie verh\u00e4lt sie sich? Der gebr\u00e4uchlichste Weg, dieses Problem zu l\u00f6sen, ist die Implementierung von Gesundheitspr\u00fcfungen (health checks)<\/i>. Kubernetes hat zwei Arten davon: Liveness- und Readiness-Probes<\/a><\/noindex>.<\/p>\n

F\u00fcr die Liveness-Probe (Lebensf\u00e4higkeitspr\u00fcfung)<\/i> muss die Anwendung einen HTTP-Endpunkt haben, der eine \u201e200 OK\u201c-Antwort zur\u00fcckgibt, wenn sie funktioniert und ihre Hauptabh\u00e4ngigkeiten erf\u00fcllt sind. F\u00fcr die Readiness-Probe (Bereitschaftspr\u00fcfung)<\/i> Die Anwendung sollte einen anderen HTTP-Endpunkt haben, der eine \u201e200 OK\u201c-Antwort zur\u00fcckgibt, wenn die Anwendung gesund ist, die Initialisierungsschritte abgeschlossen sind und jede g\u00fcltige Anfrage nicht zu einem Fehler f\u00fchrt. Kubernetes wird den Verkehr nur an den Container weiterleiten, wenn die Anwendung gem\u00e4\u00df diesen \u00dcberpr\u00fcfungen bereit ist. Die beiden Endpunkte k\u00f6nnen zusammengefasst werden, wenn es keinen Unterschied zwischen der Lebensf\u00e4higkeit (Liveness) und der Bereitschaft (Readiness) gibt.<\/p>\n

Mehr dazu k\u00f6nnen Sie im entsprechenden Artikel von Sandeep Dinesh, Developer Advocate bei Google, lesen: \u201eKubernetes Best Practices: Einrichtung von Gesundheitschecks mit Readiness- und Liveness-Probes<\/a><\/noindex>\u00bb.<\/p>\n

7. W\u00e4hlen Sie die Version des Images sorgf\u00e4ltig aus<\/h2>\n

\nDie meisten \u00f6ffentlichen und privaten Images verwenden ein Tagging-System, das dem in Best Practices for Building Containers<\/a><\/noindex>\u00e4hnelt. Wenn das Image ein System anwendet, das dem semantischen Versionierung<\/a><\/noindex>\u00e4hnlich ist, m\u00fcssen Sie die spezifischen Anforderungen an das Tagging ber\u00fccksichtigen. Zum Beispiel kann das Tag latest<\/code> h\u00e4ufig zwischen Images wechseln \u2014 darauf kann man sich nicht verlassen, wenn vorhersehbare und reproduzierbare Builds und Installationen ben\u00f6tigt werden.<\/p>\n

Sie k\u00f6nnen das Tag X.Y.Z<\/code> (sie bleiben fast immer unver\u00e4ndert), jedoch sollten Sie in diesem Fall alle Patches und Updates f\u00fcr das Abbild verfolgen. Wenn das verwendete Abbild einen Tag hat X.Y<\/code>, ist das eine gute Wahl f\u00fcr die goldene Mitte. Wenn Sie es ausw\u00e4hlen, erhalten Sie automatisch Patches und basieren gleichzeitig auf einer stabilen Version der Anwendung.<\/p>\n

P.S. vom \u00dcbersetzer<\/h2>\n

\nLesen Sie auch in unserem Blog:<\/p>\n