{"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

\n\u0412\u044b \u0432\u0435\u0434\u044c \u043d\u0435 \u0437\u0430\u043f\u0443\u0441\u043a\u0430\u0435\u0442\u0435 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f \u043f\u043e\u0434 root’\u043e\u043c \u043d\u0430 \u0441\u0432\u043e\u0438\u0445 \u0441\u0435\u0440\u0432\u0435\u0440\u0430\u0445, \u0432\u0435\u0440\u043d\u043e? \u0415\u0441\u043b\u0438 \u0437\u043b\u043e\u0443\u043c\u044b\u0448\u043b\u0435\u043d\u043d\u0438\u043a \u043f\u0440\u043e\u043d\u0438\u043a\u043d\u0435\u0442 \u0432 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435, \u043e\u043d \u043f\u043e\u043b\u0443\u0447\u0438\u0442 \u0434\u043e\u0441\u0442\u0443\u043f \u0441 \u043f\u0440\u0430\u0432\u0430\u043c\u0438 root. \u0422\u0435 \u0436\u0435 \u0441\u043e\u043e\u0431\u0440\u0430\u0436\u0435\u043d\u0438\u044f \u0441\u043f\u0440\u0430\u0432\u0435\u0434\u043b\u0438\u0432\u044b \u0438 \u0434\u043b\u044f \u0442\u043e\u0433\u043e, \u0447\u0442\u043e\u0431\u044b \u043d\u0435 \u0437\u0430\u043f\u0443\u0441\u043a\u0430\u0442\u044c \u043f\u0440\u0438\u0432\u0438\u043b\u0435\u0433\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u044b\u0435 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u044b. \u0415\u0441\u043b\u0438 \u0442\u0440\u0435\u0431\u0443\u0435\u0442\u0441\u044f \u0438\u0437\u043c\u0435\u043d\u044f\u0442\u044c \u043d\u0430\u0441\u0442\u0440\u043e\u0439\u043a\u0438 \u043d\u0430 \u0445\u043e\u0441\u0442\u0435, \u043c\u043e\u0436\u043d\u043e \u0432\u044b\u0434\u0430\u0442\u044c \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u0443 \u043a\u043e\u043d\u043a\u0440\u0435\u0442\u043d\u044b\u0435 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

\n\u041e \u043f\u0440\u0438\u0432\u0438\u043b\u0435\u0433\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u044b\u0445 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u0430\u0445 \u0443\u0436\u0435 \u0441\u043a\u0430\u0437\u0430\u043d\u043e, \u043d\u043e \u0431\u0443\u0434\u0435\u0442 \u0435\u0449\u0451 \u043b\u0443\u0447\u0448\u0435, \u0435\u0441\u043b\u0438 \u0432 \u0434\u043e\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u0435 \u043a \u044d\u0442\u043e\u043c\u0443 \u0432\u044b \u043d\u0435 \u0431\u0443\u0434\u0435\u0442\u0435 \u0437\u0430\u043f\u0443\u0441\u043a\u0430\u0442\u044c \u043f\u043e\u0434 root’\u043e\u043c \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f \u0432\u043d\u0443\u0442\u0440\u0438 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u0430. \u0415\u0441\u043b\u0438 \u0437\u043b\u043e\u0443\u043c\u044b\u0448\u043b\u0435\u043d\u043d\u0438\u043a \u043d\u0430\u0439\u0434\u0451\u0442 \u0432 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0438 \u0441 \u043f\u0440\u0430\u0432\u0430\u043c\u0438 root \u0443\u0434\u0430\u043b\u0451\u043d\u043d\u0443\u044e \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u044c \u0441 \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u044c\u044e \u0438\u0441\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u044f \u043a\u043e\u0434\u0430, \u043f\u043e\u0441\u043b\u0435 \u0447\u0435\u0433\u043e \u0441\u043c\u043e\u0436\u0435\u0442 \u0432\u044b\u0439\u0442\u0438 \u0438\u0437 \u043f\u0440\u0435\u0434\u0435\u043b\u043e\u0432 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u0430 \u0447\u0435\u0440\u0435\u0437 \u043f\u043e\u043a\u0430 \u0435\u0449\u0451 \u043d\u0435\u0438\u0437\u0432\u0435\u0441\u0442\u043d\u0443\u044e \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u044c, \u0442\u043e \u043f\u043e\u043b\u0443\u0447\u0438\u0442 root’\u0430 \u043d\u0430 \u0445\u043e\u0441\u0442\u0435.<\/p>\n

\u041b\u0443\u0447\u0448\u0438\u0439 \u043f\u0443\u0442\u044c \u0438\u0437\u0431\u0435\u0436\u0430\u0442\u044c \u044d\u0442\u043e\u0433\u043e \u2014 \u0432 \u043f\u0435\u0440\u0432\u0443\u044e \u043e\u0447\u0435\u0440\u0435\u0434\u044c \u043d\u0435 \u0437\u0430\u043f\u0443\u0441\u043a\u0430\u0442\u044c \u043d\u0438\u0447\u0435\u0433\u043e \u043f\u043e\u0434 root’\u043e\u043c. \u0414\u043b\u044f \u044d\u0442\u043e\u0433\u043e \u043c\u043e\u0436\u043d\u043e \u0432\u043e\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c\u0441\u044f \u0434\u0438\u0440\u0435\u043a\u0442\u0438\u0432\u043e\u0439 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> \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435 \u0434\u043e\u043b\u0436\u043d\u043e \u0438\u043c\u0435\u0442\u044c \u0434\u0440\u0443\u0433\u043e\u0439 HTTP endpoint, \u0432\u043e\u0437\u0432\u0440\u0430\u0449\u0430\u044e\u0449\u0438\u0439 \u043e\u0442\u0432\u0435\u0442 \u00ab200 OK\u00bb, \u0435\u0441\u043b\u0438 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435 \u043d\u0430\u0445\u043e\u0434\u0438\u0442\u0441\u044f \u0432 \u0437\u0434\u043e\u0440\u043e\u0432\u043e\u043c \u0441\u043e\u0441\u0442\u043e\u044f\u043d\u0438\u0438, \u0448\u0430\u0433\u0438 \u043f\u043e \u0438\u043d\u0438\u0446\u0438\u0430\u043b\u0438\u0437\u0430\u0446\u0438\u0438 \u0432\u044b\u043f\u043e\u043b\u043d\u0435\u043d\u044b \u0438 \u043b\u044e\u0431\u043e\u0439 \u043a\u043e\u0440\u0440\u0435\u043a\u0442\u043d\u044b\u0439 \u0437\u0430\u043f\u0440\u043e\u0441 \u043d\u0435 \u043f\u0440\u0438\u0432\u043e\u0434\u0438\u0442 \u043a \u043e\u0448\u0438\u0431\u043a\u0435. Kubernetes \u0431\u0443\u0434\u0435\u0442 \u043d\u0430\u043f\u0440\u0430\u0432\u043b\u044f\u0442\u044c \u0442\u0440\u0430\u0444\u0438\u043a \u043d\u0430 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440 \u0442\u043e\u043b\u044c\u043a\u043e \u0432 \u0441\u043b\u0443\u0447\u0430\u0435 \u0433\u043e\u0442\u043e\u0432\u043d\u043e\u0441\u0442\u0438 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f \u0432 \u0441\u043e\u043e\u0442\u0432\u0435\u0442\u0441\u0442\u0432\u0438\u0438 \u0441 \u044d\u0442\u0438\u043c\u0438 \u043f\u0440\u043e\u0432\u0435\u0440\u043a\u0430\u043c\u0438. \u0414\u0432\u0430 endpoint’\u0430 \u043c\u043e\u0433\u0443\u0442 \u043e\u0431\u044a\u0435\u0434\u0438\u043d\u0435\u043d\u044b, \u0435\u0441\u043b\u0438 \u0440\u0430\u0437\u043d\u0438\u0446\u0430 \u043c\u0435\u0436\u0434\u0443 \u0441\u043e\u0441\u0442\u043e\u044f\u043d\u0438\u044f\u043c\u0438 \u0436\u0438\u0437\u043d\u0435\u0441\u043f\u043e\u0441\u043e\u0431\u043d\u043e\u0441\u0442\u0438 (liveness) \u0438 \u0433\u043e\u0442\u043e\u0432\u043d\u043e\u0441\u0442\u0438 (readiness) \u043d\u0435\u0442.<\/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