{"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 beste Praktiken f\u00fcr den Betrieb von Containern laut Google","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Anmerkung des \u00dcbersetzers.<\/b>: Autor des urspr\u00fcnglichen Artikels 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 eines detaillierteren Leitfadens seines Unternehmens mit dem Titel \u201eBest Practices for Operating Containers<\/a><\/noindex>\u201c. Darin haben Experten von Google die besten Praktiken f\u00fcr den Betrieb von Containern im Kontext der Nutzung von Google Kubernetes Engine und dar\u00fcber hinaus gesammelt und ein breites Themenspektrum behandelt: von Sicherheit \u00fcber Monitoring bis hin zu Logging. Was sind also laut Google die wichtigsten Praktiken im Umgang mit Containern?<\/i><\/p>\n

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

Kubernetes Engine<\/a><\/noindex> (ein auf Kubernetes basierender Service zum Ausf\u00fchren von containerisierten Anwendungen in Google Cloud \u2014 Anm. d. \u00dc.<\/b>)<\/i> \u2014 geh\u00f6rt zu den besten M\u00f6glichkeiten, Workloads zu starten, die skalierbar sind. Kubernetes<\/a><\/noindex> es wird ein reibungsloses Funktionieren der meisten Anwendungen gew\u00e4hrleisten, sofern diese containerisiert sind. Wenn Sie jedoch m\u00f6chten, dass die Anwendung einfach zu verwalten ist und alle Vorteile von Kubernetes nutzen m\u00f6chten, m\u00fcssen Sie bew\u00e4hrte Praktiken befolgen. Diese erleichtern den Betrieb der Anwendung, deren \u00dcberwachung und Fehlersuche und verbessern zudem die Sicherheit.<\/p>\n

In diesem Artikel gehen wir die Liste durch, was Sie wissen und tun sollten, um die effiziente Funktionsweise von Containern in Kubernetes sicherzustellen. Wer tiefer in die Details eintauchen m\u00f6chte, sollte das Material lesen Best Practices for Operating Containers<\/a><\/noindex>, sowie auf unseren fr\u00fcheren Beitrag<\/a><\/noindex> zur Container-Bereitstellung achten.<\/p>\n

1. Verwenden Sie die nativen Mechanismen von Containern f\u00fcr Logging<\/h2>\n

\nWenn die Anwendung in einem Kubernetes-Cluster l\u00e4uft, ben\u00f6tigt man f\u00fcr Logs nicht viel. Ein zentrales Logging-System ist wahrscheinlich bereits in das verwendete Cluster integriert. Bei der Nutzung von Kubernetes Engine ist daf\u00fcr Stackdriver Logging<\/a><\/noindex>. (Anmerkung des \u00dcbersetzers.<\/b>: sollte man sich bei der Nutzung einer eigenen Kubernetes-Installation unser Open-Source-Tool ansehen \u2014 loghouse<\/a><\/noindex>.)<\/i> Machen Sie es sich nicht selbst schwer und nutzen Sie die nativen Logging-Mechanismen von Containern. Schreiben Sie die Logs in stdout und stderr \u2014 diese werden automatisch erfasst, gespeichert und indiziert.<\/p>\n

Wenn gew\u00fcnscht, k\u00f6nnen Sie die Logs auch im JSON-Format<\/a><\/noindex>schreiben. Dieser Ansatz erm\u00f6glicht es, einfach Metadaten hinzuzuf\u00fcgen. Zusammen mit diesen wird in Stackdriver Logging die M\u00f6glichkeit geschaffen, in den Logs mithilfe dieser Metadaten zu suchen.<\/p>\n

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

\nF\u00fcr die ordnungsgem\u00e4\u00dfe Funktion von Containern im Kubernetes-Cluster m\u00fcssen sie stateless und immutable sein. Wenn diese Bedingungen erf\u00fcllt sind, kann Kubernetes seine Arbeit verrichten, indem es Anwendungsentit\u00e4ten erstellt und l\u00f6scht, wann und wo es n\u00f6tig ist.<\/p>\n

Stateless<\/i> bedeutet, dass jeglicher Zustand (dauerhafte Daten jeglicher Art) au\u00dferhalb des Containers gespeichert wird. Dazu k\u00f6nnen je nach Bedarf verschiedene Arten externer Speicher verwendet werden: Cloud Storage<\/a><\/noindex>, Persistent Disks<\/a><\/noindex>, Redis<\/a><\/noindex>, Cloud SQL<\/a><\/noindex> oder andere verwaltete Datenbanken. (Anmerkung des \u00dcbersetzers.<\/b>: Weitere Informationen hierzu finden Sie auch in unserem Artikel \u201eOperatoren f\u00fcr Kubernetes: wie man zustandsbehaftete Anwendungen ausf\u00fchrt<\/a><\/noindex>\u00bb.)<\/i><\/p>\n

Immutable<\/i> bedeutet, dass der Container w\u00e4hrend seiner Lebensdauer nicht modifiziert wird: keine Updates, Patches oder \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 Container-Konfiguration (Port zum Lauschen, Optionen der Ausf\u00fchrungsumgebung usw.) nach au\u00dfen zu verlagern \u2014 in Secrets<\/a><\/noindex> und ConfigMaps<\/a><\/noindex>. Diese k\u00f6nnen aktualisiert werden, ohne dass ein neues Container-Image erstellt werden muss. F\u00fcr die einfache Erstellung von Pipelines zur Erstellung von Images kann man Cloud Build<\/a><\/noindex>. (Anmerkung des \u00dcbersetzers.<\/b>: F\u00fcr diese Zwecke verwenden wir das Open Source-Tool dapp<\/a><\/noindex>.)<\/i><\/p>\n

\"7
\nBeispiel f\u00fcr die Aktualisierung der Deployment-Konfiguration in Kubernetes mit Hilfe 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 in die Anwendung eindringt, erh\u00e4lt er Root-Rechte. Die gleichen \u00dcberlegungen gelten auch daf\u00fcr, keine privilegierten Container zu starten. Wenn Sie \u00c4nderungen an den Host-Einstellungen vornehmen m\u00fcssen, k\u00f6nnen Sie dem Container spezifische Rechte zuweisen. Capabilities festzulegen<\/i> mit der Option securityContext<\/code><\/a><\/noindex> in Kubernetes gegeben werden. Wenn es erforderlich ist, sysctls<\/i>, besitzt Kubernetes eine separate Annotation<\/a><\/noindex> daf\u00fcr. Im Allgemeinen sollten Sie versuchen, so viele wie m\u00f6glich init-<\/a><\/noindex> und Sidecar-Container f\u00fcr solche privilegierten Operationen zu verwenden. Sie ben\u00f6tigen keine Erreichbarkeit f\u00fcr internen oder externen Datenverkehr.<\/p>\n

Wenn Sie den Cluster verwalten, k\u00f6nnen Sie die Pod Security Policy<\/a><\/noindex> f\u00fcr Beschr\u00e4nkungen bei der Verwendung privilegierter Container nutzen.<\/p>\n

4. Vermeiden Sie es, als root auszuf\u00fchren<\/h2>\n

\nEs wurde bereits \u00fcber privilegierte Container gesprochen, aber es w\u00e4re noch besser, wenn Sie zus\u00e4tzlich dazu keine Anwendungen innerhalb des Containers als root ausf\u00fchren. Wenn ein Angreifer in einer Anwendung mit Root-Rechten eine Remote-Sicherheitsanf\u00e4lligkeit entdeckt, die die Ausf\u00fchrung von Code erm\u00f6glicht, und dann durch eine bisher unbekannte Sicherheitsanf\u00e4lligkeit aus dem Container herauskommt, erh\u00e4lt er Root-Rechte auf dem Host.<\/p>\n

Der beste Weg, dies zu vermeiden, besteht zun\u00e4chst darin, nichts als root auszuf\u00fchren. Hierf\u00fcr k\u00f6nnen Sie die Direktive verwenden. USER<\/code> in Dockerfile<\/code> oder runAsUser<\/code> in Kubernetes verwendet werden. Der Cluster-Administrator kann auch ein erzwungenes Verhalten mithilfe von Pod Security Policy<\/a><\/noindex>.<\/p>\n

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

\nWie bei der Protokollierung ist das Monitoring ein unverzichtbarer Bestandteil des Anwendungsmanagements. Eine beliebte L\u00f6sung f\u00fcr das Monitoring in der Kubernetes-Community ist Prometheus<\/a><\/noindex> \u2014 ein System, das Pods und Dienste, die \u00fcberwacht werden m\u00fcssen, automatisch erkennt. (Anmerkung des \u00dcbersetzers.<\/b>: Siehe auch unseren ausf\u00fchrlichen Bericht<\/a><\/noindex> zum Thema Monitoring mit Prometheus und Kubernetes.)<\/i> Stackdriver<\/a><\/noindex> kann Kubernetes-Cluster \u00fcberwachen und enth\u00e4lt eine eigene Version von Prometheus zur \u00dcberwachung von Anwendungen.<\/p>\n

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

erwartet, dass die Anwendung Metriken \u00fcber einen HTTP-Endpunkt bereitstellt. Dazu stehen Prometheus-Client-Bibliotheken<\/a><\/noindex>zur Verf\u00fcgung. Ein \u00e4hnliches Format wird von anderen Tools wie OpenCensus<\/a><\/noindex> und Istio<\/a><\/noindex>.<\/p>\n

6. Machen Sie den Gesundheitszustand der Anwendung zug\u00e4nglich<\/h2>\n

\nDas Management der Anwendung in der Produktion wird durch ihre F\u00e4higkeit unterst\u00fctzt, ihren Status dem gesamten System mitzuteilen. Ist die Anwendung gestartet? Ist sie in Ordnung? Ist sie bereit, Traffic zu akzeptieren? Wie verh\u00e4lt sie sich? Die g\u00e4ngigste L\u00f6sung f\u00fcr dieses Problem ist die Implementierung von Gesundheitspr\u00fcfungen (health checks)<\/i>. Kubernetes hat zwei Typen 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 Antwort von \u201e200 OK\u201c zur\u00fcckgibt, wenn sie funktioniert und ihre grundlegenden Abh\u00e4ngigkeiten erf\u00fcllt sind. F\u00fcr die readiness probe (Bereitschaftspr\u00fcfung)<\/i> Die Anwendung sollte einen anderen HTTP-Endpunkt haben, der eine Antwort \"200 OK\" zur\u00fcckgibt, wenn die Anwendung gesund ist, die Initialisierungsschritte abgeschlossen sind und jede g\u00fcltige Anfrage keinen Fehler verursacht. Kubernetes wird den Traffic nur an den Container weiterleiten, wenn die Anwendung gem\u00e4\u00df diesen \u00dcberpr\u00fcfungen bereit ist. Die beiden Endpunkte k\u00f6nnen kombiniert werden, wenn es keinen Unterschied zwischen den Zust\u00e4nden der Lebensf\u00e4higkeit (liveness) und der Bereitstellung (readiness) gibt.<\/p>\n

Weitere Informationen finden Sie in dem entsprechenden Artikel von Sandeep Dinesh, Developer Advocate bei Google: \u201eKubernetes Best Practices: Gesundheitstests mit Readiness- und Liveness-Proben einrichten<\/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>beschriebenen \u00e4hnlich ist. Wenn das Image ein System anwendet, das nahe am semantischen Versionieren liegt,<\/a><\/noindex>muss die spezifische Tagging-Praxis ber\u00fccksichtigt werden. Zum Beispiel kann das Tag latest<\/code> h\u00e4ufig zwischen Images wechseln \u2014 es ist nicht zuverl\u00e4ssig, wenn Sie vorhersehbare und reproduzierbare Build- und Installationsprozesse ben\u00f6tigen.<\/p>\n

Sie k\u00f6nnen das Tag X.Y.Z<\/code> verwenden (es bleibt fast immer konstant), aber in diesem Fall sollten Sie alle Patches und Updates des Images \u00fcberwachen. Wenn das verwendete Image ein Tag hat X.Y<\/code>, ist das eine gute Zwischenl\u00f6sung. Wenn Sie es w\u00e4hlen, erhalten Sie automatisch alle Patches und st\u00fctzen sich gleichzeitig auf eine stabile Version der Anwendung.<\/p>\n

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

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