🥇Buch „Kubernetes für DevOps“

Hallo, Habr-Bewohner! Kubernetes ist eines der zentralen Elemente der modernen Cloud-Ökosysteme. Diese Technologie bietet Zuverlässigkeit, Skalierbarkeit und Widerstandsfähigkeit in der Container-Virtualisierung. John Arundel und Justin Domingus präsentieren das Kubernetes-Ökosystem und teilen bewährte Lösungen für alltägliche Probleme. Schritt für Schritt entwickeln Sie Ihre eigene cloudbasierte Anwendung und schaffen eine Infrastruktur zu ihrer Unterstützung, richten Ihre Entwicklungsumgebung ein und implementieren eine kontinuierliche Bereitstellungspipeline, die Ihnen bei der Arbeit an Ihren zukünftigen Anwendungen helfen wird.

• Beginnen Sie mit Containern und Kubernetes von Grund auf: Sie benötigen keine speziellen Vorkenntnisse, um das Thema zu erlernen. • Starten Sie Ihre eigenen Cluster oder wählen Sie einen verwalteten Kubernetes-Dienst von Amazon, Google und anderen Anbietern. • Nutzen Sie Kubernetes, um den Lebenszyklus von Containern und den Ressourcengebrauch zu verwalten. • Optimieren Sie Cluster hinsichtlich Kosten, Leistung, Verfügbarkeit, Kapazität und Skalierbarkeit. • Entdecken Sie die besten Werkzeuge für die Entwicklung, das Testen und die Bereitstellung Ihrer Anwendungen. • Nutzen Sie aktuelle Branchenpraktiken für Sicherheit und Kontrolle. • Implementieren Sie DevOps-Prinzipien in Ihrem Unternehmen, damit Entwicklungsteams flexibler, schneller und effizienter arbeiten können.

Für wen das Buch gedacht ist

Das Buch richtet sich hauptsächlich an Mitarbeiter von Verwaltungsabteilungen, die für Server, Anwendungen und Dienste verantwortlich sind, sowie an Entwickler, die entweder neue Cloud-Dienste aufbauen oder bestehende Anwendungen nach Kubernetes und in die Cloud migrieren. Keine Sorge, Sie müssen nicht mit Kubernetes und Containern vertraut sein – wir bringen Ihnen alles bei.

Erfahrene Kubernetes-Nutzer werden ebenfalls auf wertvolle Inhalte stoßen: Das Buch behandelt vertieft Themen wie RBAC, Continuous Deployment, das Management von sensiblen Daten und Observability. Wir hoffen, dass auch für Sie, unabhängig von Ihren Fähigkeiten und Erfahrungen, etwas Interessantes in den Seiten des Buches zu finden ist.

Welche Fragen beantwortet das Buch?

Während der Planung und Erstellung des Buches haben wir mit Hunderten von Menschen über Cloud-Technologien und Kubernetes gesprochen, sowohl mit Führungspersönlichkeiten und Experten der Branche als auch mit völligen Einsteigern. Im Folgenden sind einige Fragen aufgeführt, auf deren Antworten sie in diesem Werk hoffen.

„Ich frage mich, warum ich Zeit in diese Technologie investieren sollte. Welche Probleme wird sie mir und meinem Team helfen zu lösen?“
„Kubernetes klingt interessant, hat aber eine ziemlich hohe Einstiegshürde. Es ist einfach, ein einfaches Beispiel vorzubereiten, aber die weitere Verwaltung und Fehlersuche schrecken ab. Wir würden gerne zuverlässige Ratschläge darüber erhalten, wie Menschen Kubernetes-Cluster unter realen Bedingungen verwalten und mit welchen Problemen wir wahrscheinlich konfrontiert werden.“
Ein subjektiver Rat wäre hilfreich. Das Kubernetes-Ökosystem bietet neuen Teams zu viele Optionen zur Auswahl. Wenn es mehrere Wege gibt, um dasselbe zu erreichen, wie kann man dann entscheiden, welcher der beste ist? Wie wählt man aus?

Und wahrscheinlich die wichtigste Frage von allen:

„Wie kann ich Kubernetes einsetzen, ohne den Betrieb meines Unternehmens zu stören?“

Ausschnitt. Konfiguration und Objekte Secret

Die Möglichkeit, die Logik einer Kubernetes-Anwendung von ihrer Konfiguration (d.h. von allen Werten oder Einstellungen, die sich im Laufe der Zeit ändern können) zu trennen, ist äußerst nützlich. Zu den Konfigurationswerten gehören typischerweise Parameter, die für eine bestimmte Umgebung bestimmt sind, DNS-Adressen von Drittanbieterdiensten und Anmeldeinformationen für die Authentifizierung.

Natürlich kann alles direkt im Code untergebracht werden, aber dieser Ansatz ist nicht flexibel genug. Beispielsweise müsste bei einer Änderung des Konfigurationswerts der Code neu kompiliert und bereitgestellt werden. Eine viel bessere Lösung wäre es, die Konfiguration vom Code zu trennen und sie aus einer Datei oder Umgebungsvariablen zu lesen.

Kubernetes bietet mehrere verschiedene Möglichkeiten zur Verwaltung von Konfigurationen. Erstens können Sie Werte über Umgebungsvariablen an die Anwendung übergeben, die in der Spezifikation des Pod-Containers angegeben sind (siehe Abschnitt „Umgebungsvariablen“ auf S. 192). Zweitens können Konfigurationsdaten direkt in Kubernetes gespeichert werden, indem Sie die Objekte ConfigMap und Secret verwenden.

In diesem Kapitel untersuchen wir diese Objekte im Detail und betrachten einige praktische Ansätze zur Verwaltung von Konfigurationen und sensiblen Daten am Beispiel einer Demoversion.

Aktualisierung von Pod-Containern bei Änderungen der Konfiguration

Stellen Sie sich vor, Sie haben in Ihrem Cluster ein Deployment und möchten einige Werte in dessen ConfigMap ändern. Wenn Sie ein Helm-Chart verwenden (siehe Abschnitt „Helm: Paketmanager für Kubernetes“ auf S. 102), können Sie Änderungen an der Konfiguration automatisch erkennen und Ihre Pod-Container mit einem eleganten Trick neu starten. Fügen Sie die folgende Annotation in die Spezifikation Ihres Deployments ein:

checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") .
       | sha256sum }}

Jetzt enthält die Bereitstellungsvorlage eine Prüfziffer für die Konfigurationsparameter: Bei Änderungen werden die Prüfziffern aktualisiert. Wenn Sie den Befehl helm upgrade ausführen, erkennt Helm, dass sich die Bereitstellungsspezifikation geändert hat, und startet alle Pod-Hüllen neu.

Vertrauliche Daten in Kubernetes

Wir wissen bereits, dass das ConfigMap-Objekt einen flexiblen Mechanismus zum Speichern und Zugreifen auf Konfigurationsdaten im Cluster bietet. Viele Anwendungen besitzen jedoch Informationen, die geheim und vertraulich sind: zum Beispiel Passwörter oder API-Keys. Man kann diese auch in ConfigMap speichern, aber diese Lösung ist nicht ideal.

Stattdessen bietet Kubernetes ein spezielles Objekttyp an, das zur Speicherung vertraulicher Daten gedacht ist: Secret. Schauen wir uns an einem Beispiel an, wie dieses Objekt in unserer Demoversion verwendet werden kann.

Zunächst sehen Sie sich das Kubernetes-Manifest für das Secret-Objekt an (siehe hello-secret-env/k8s/secret.yaml):

apiVersion: v1
kind: Secret
metadata:
    name: demo-secret
stringData:
    magicWord: xyzzy

In diesem Beispiel hat der geheime Schlüssel magicWord den Wert xyzzy (en.wikipedia.org/wiki/Xyzzy_(computing)). Das Wort xyzzy ist im Computerbereich sehr nützlich. Ähnlich wie bei ConfigMap können in einem Secret viele Schlüssel und Werte gespeichert werden. Hier verwenden wir zur Vereinfachung nur ein Schlüsselpaar.

Verwendung von Secrets als Umgebungsvariablen

Genau wie bei ConfigMap kann ein Secret-Objekt in einem Container als Umgebungsvariable oder als Datei auf dessen Speicher bereitgestellt werden. Im folgenden Beispiel weisen wir einer Umgebungsvariablen einen Wert aus einem Secret zu:

spec:
   containers:
       - name: demo
          image: cloudnatived/demo:hello-secret-env
          ports:
             - containerPort: 8888
          env:
             - name: GREETING
               valueFrom:
               secretKeyRef:
                  name: demo-secret
                  key: magicWord

Führen Sie den folgenden Befehl im demo-Repository aus, um die Manifeste anzuwenden:

kubectl apply -f hello-secret-env/k8s/
deployment.extensions "demo" konfiguriert
secret "demo-secret" erstellt

Wie zuvor leiten Sie den lokalen Port an das Deployment weiter, um das Ergebnis in Ihrem Browser zu sehen:

kubectl port-forward deploy/demo 9999:8888
Forwarding from 127.0.0.1:9999 -> 8888
Forwarding from [::1]:9999 -> 8888

Wenn Sie die Adresse öffnen localhost:9999/ sollten Sie Folgendes sehen:

Das magische Wort ist "xyzzy"

Speichern von Secret-Objekten in Dateien

In diesem Beispiel binden wir ein Secret-Objekt als Datei in den Container ein. Der Code befindet sich im Ordner hello-secret-file des Demo-Repositorys.

Um ein Secret als Datei einzubinden, verwenden wir das folgende Deployment:

spec:
   containers:
       - name: demo
          image: cloudnatived/demo:hello-secret-file
          ports:
              - containerPort: 8888
          volumeMounts:
              - name: demo-secret-volume
                mountPath: "/secrets/"
                readOnly: true
   volumes:
      - name: demo-secret-volume
        secret:
           secretName: demo-secret

Wie im Abschnitt „Erstellen von Konfigurationsdateien aus ConfigMap-Objekten“ auf S. 240 beschrieben, erstellen wir ein Volume (in diesem Fall demo-secret-volume) und binden es im Abschnitt volumeMounts an den Container. Im Feld mountPath ist "/secrets" angegeben, daher wird Kubernetes in diesem Ordner für jedes „Schlüssel-Wert“-Paar, das im Secret-Objekt definiert ist, eine Datei erstellen.

In unserem Beispiel haben wir nur ein „Schlüssel-Wert“-Paar mit dem Namen magicWord definiert, daher wird das Manifest im Container eine Datei "/secrets/magicWord" mit den vertraulichen Daten erstellen, die nur lesbar ist.

Wenn dieses Manifest auf die gleiche Weise angewendet wird wie im vorherigen Beispiel, sollte dasselbe Ergebnis herauskommen:

Das magische Wort ist "xyzzy"

Lesen von Secret-Objekten

Im vorherigen Abschnitt haben wir den Befehl kubectl describe verwendet, um den Inhalt einer ConfigMap anzuzeigen. Kann man dasselbe auch mit einem Secret tun?

kubectl describe secret/demo-secret
Name:          demo-secret

Namespace:      default
Labels:             
Annotations:
Type:               Opaque

Data
====
magicWord: 5   bytes

Bitte beachten Sie, dass die Daten selbst nicht angezeigt werden. Secret-Objekte in Kubernetes haben den Typ Opaque: das bedeutet, dass ihr Inhalt nicht im Ausgabeformat von kubectl describe, den Protokollen und im Terminal angezeigt wird, wodurch eine versehentliche Offenlegung sensibler Informationen verhindert wird.

Um die kodierte Version vertraulicher Daten im YAML-Format anzuzeigen, verwenden Sie den Befehl kubectl get:

kubectl get secret/demo-secret -o yaml
apiVersion: v1
data:
   magicWord: eHl6enk=
kind: Secret
metadata:
...
type: Opaque

base64

Was ist eHl6enk=, es sieht ganz anders aus als unser ursprünglicher Wert? Tatsächlich handelt es sich um ein Secret-Objekt, das in base64 kodiert ist. Base64 ist ein Codierungsschema für beliebige binäre Daten in Form einer Zeichenkette.

Da vertrauliche Informationen binär sein können und nicht für die Ausgabe verfügbar sind (z. B. im Fall eines TLS-Verschlüsselungsschlüssels), werden Secret-Objekte immer im base64-Format gespeichert.

Der Text beHl6enk= ist eine Version unseres geheimen Passworts xyzzy, kodiert in base64. Das kann überprüft werden, indem man im Terminal den Befehl base64 —decode ausführt:

echo "eHl6enk=" | base64 --decode
xyzzy

Obwohl Kubernetes Sie davor schützt, versehentlich vertrauliche Daten im Terminal oder in Logdateien auszugeben, können diese Daten im base64-Format abgerufen und anschließend dekodiert werden, wenn man Leserechte für Secret-Objekte in einem bestimmten Namespace hat.

Wenn Sie einen Text in base64 kodieren müssen (z. B. um ihn in ein Secret einzufügen), verwenden Sie den Befehl base64 ohne Argumente:

echo xyzzy | base64
eHl6enkK

Zugriff auf Secret-Objekte

Wer kann Secret-Objekte lesen und bearbeiten? Dies wird durch RBAC bestimmt – ein Zugangskontrollmechanismus (wir werden dies ausführlich im Abschnitt „Einführung in die rollenbasierte Zugriffskontrolle“ auf S. 258 besprechen). Wenn Sie ein Cluster verwenden, in dem RBAC nicht vorhanden oder nicht aktiviert ist, sind alle Ihre Secret-Objekte für alle Benutzer und Container zugänglich (später erklären wir, dass Sie kein produktives Cluster ohne RBAC haben sollten).

Passives Datenverschlüsselung

Was ist mit denjenigen, die Zugriff auf die Datenbank etcd haben, in der Kubernetes alle seine Informationen speichert? Können sie vertrauliche Daten lesen, ohne die Berechtigung zu haben, Secret-Objekte über die API zu lesen?

Seit Version 1.7 unterstützt Kubernetes die passive Datenverschlüsselung. Das bedeutet, dass vertrauliche Informationen innerhalb von etcd auf der Festplatte in verschlüsselter Form gespeichert werden und selbst von denen, die direkten Zugriff auf die Datenbank haben, nicht gelesen werden können. Zum Entschlüsseln wird ein Schlüssel benötigt, der nur beim Kubernetes API-Server vorhanden ist. In einem richtig konfigurierten Cluster sollte die passive Verschlüsselung aktiviert sein.

So überprüfen Sie, ob die passive Verschlüsselung in Ihrem Cluster aktiviert ist:

kubectl describe pod -n kube-system -l component=kube-apiserver | grep encryption
        --experimental-encryption-provider-config=...

Wenn Sie die Flagge experimental-encryption-provider-config nicht sehen, ist die passive Verschlüsselung nicht aktiviert. Wenn Sie Google Kubernetes Engine oder andere Kubernetes-Management-Dienste verwenden, werden Ihre Daten mit einem anderen Mechanismus verschlüsselt, sodass das Flag nicht vorhanden ist. Fragen Sie Ihren Kubernetes-Anbieter, ob der Inhalt von etcd verschlüsselt wird.

Speicherung vertraulicher Daten

Es gibt Kubernetes-Ressourcen, die niemals aus dem Cluster gelöscht werden sollten, wie beispielsweise besonders wichtige Objekte vom Typ Secret. Sie können eine Ressource vor der Löschung schützen, indem Sie die Annotation verwenden, die vom Helm-Manager bereitgestellt wird:

kind: Secret
metadata:
    annotations:
        "helm.sh/resource-policy": keep

Strategien zur Verwaltung von Secret-Objekten

Im Beispiel aus dem vorherigen Abschnitt wurden sensible Daten vor unbefugtem Zugriff geschützt, sobald sie im Cluster gespeichert waren. In den Manifestdateien wurden sie jedoch als Klartext gespeichert.

Sie sollten niemals vertrauliche Informationen in Dateien speichern, die im Versionskontrollsystem liegen. Wie können Sie solche Informationen also sicher verwalten und speichern, bevor Sie sie auf das Kubernetes-Cluster anwenden?

Sie können beliebige Werkzeuge oder Strategien für den Umgang mit sensiblen Daten in Ihren Anwendungen wählen, aber Sie müssen dennoch mindestens die folgenden Fragen beantworten.

Wo sollten sensible Daten gespeichert werden, damit sie hochverfügbar sind?
Wie können Sie sensible Daten für Ihre aktiven Anwendungen zugänglich machen?
Was sollte mit Ihren Anwendungen geschehen, wenn Sie vertrauliche Daten ersetzen oder bearbeiten?

Über die Autoren

John Arundell ist Berater mit 30 Jahren Erfahrung in der Computerindustrie. Er hat mehrere Bücher geschrieben und arbeitet mit zahlreichen Unternehmen aus verschiedenen Ländern zusammen, indem er sie zu cloudbasierten Infrastrukturen und Kubernetes berät. In seiner Freizeit ist er ein begeisterter Surfer, genießt es, mit einer Pistole zu schießen, und spielt hobbymäßig Klavier. Er lebt in einem malerischen Cottage in Cornwall, England.

Justin Domingus ist Systemadministrator in einer DevOps-Umgebung mit Kubernetes und Cloud-Technologien. Er verbringt gerne Zeit im Freien, trinkt Kaffee, geht Krabben fangen und arbeitet am Computer. Er lebt in Seattle, Washington, mit seiner großartigen Katze und seiner noch großartigeren Frau und besten Freundin Adrienne.

» Weitere Informationen zu dem Buch finden Sie auf der Verlagswebsite
» Inhaltsverzeichnis
» Auszug

Für Habr-Besucher gilt ein Rabatt von 25 % mit dem Code — Kubernetes

Nach Erhalt der Zahlung für die gedruckte Version des Buches wird das E-Book per E-Mail versendet.

Quelle: habr.com