Hallo, Habr-Bewohner! Kubernetes ist eines der Schlüsselfaktoren des modernen Cloud-Ökosystems. Diese Technologie gewährleistet Zuverlässigkeit, Skalierbarkeit und Robustheit der containerisierten Virtualisierung. John Arundel und Justin Domingus erläutern das Kubernetes-Ökosystem und stellen bewährte Lösungen für alltägliche Probleme vor. Schritt für Schritt werden Sie Ihre eigene cloudbasierte Anwendung entwickeln und eine Infrastruktur für deren Unterstützung aufbauen, die Entwicklungsumgebung einrichten und eine Continuous Deployment-Pipeline konfigurieren, die Ihnen bei der Arbeit an zukünftigen Anwendungen helfen wird.
• Sie starten mit Containern und Kubernetes bei Null: Es sind keine besonderen Vorkenntnisse erforderlich. • Sie starten eigene Cluster oder wählen einen verwalteten Kubernetes-Service von Amazon, Google usw. • Sie nutzen Kubernetes zur Verwaltung des Lebenszyklus von Containern und Ressourcenverbrauch. • Sie optimieren Cluster hinsichtlich Kosten, Leistung, Verfügbarkeit, Kapazität und Skalierbarkeit. • Sie lernen die besten Tools für die Entwicklung, das Testen und das Bereitstellen Ihrer Anwendungen kennen. • Sie wenden aktuelle Branchenpraktiken zur Gewährleistung von Sicherheit und Kontrolle an. • Sie implementieren in Ihrem Unternehmen DevOps-Prinzipien, damit die Entwicklerteams flexibler, schneller und effizienter arbeiten können.
Für wen ist das Buch gedacht
Das Buch richtet sich in erster Linie an Mitarbeiter der Verwaltungsabteilungen, die für Server, Anwendungen und Dienste verantwortlich sind, sowie an Entwickler, die entweder neue Cloud-Services erstellen oder bestehende Anwendungen nach Kubernetes und in die Cloud migrieren. Keine Sorge, es ist nicht erforderlich, mit Kubernetes und Containern umgehen zu können – wir werden Sie alles lehren.
Erfahrene Kubernetes-Nutzer werden ebenfalls viele wertvolle Informationen finden: Hier werden vertieft Themen wie RBAC, kontinuierliche Bereitstellung, Verwaltung von vertraulichen Daten und Beobachtbarkeit behandelt. Wir hoffen, dass sich auf den Seiten des Buches auch etwas Interessantes für Sie findet, unabhängig von Ihren Fähigkeiten und Erfahrungen.
Auf welche Fragen antwortet das Buch
Während der Planung und dem Schreiben 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 absoluten Einsteigern. Im Folgenden sind einige Fragen aufgeführt, deren Antworten die Menschen in dieser Ausgabe gerne sehen würden.
- „Ich interessiere mich dafür, warum ich Zeit mit dieser Technologie verbringen sollte. Welche Probleme kann sie mir und meinem Team helfen zu lösen?“
- „Kubernetes scheint interessant zu sein, hat aber eine ziemlich hohe Einstiegshürde. Es ist nicht schwer, ein einfaches Beispiel vorzubereiten, aber das weitere Administrieren und Debuggen macht mir Angst. Wir würden uns verlässliche Ratschläge wünschen, 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 man dasselbe auf verschiedene Arten tun kann, wie erkennt man dann, welche Methode besser ist? Wie wählt man aus?“
Und vermutlich die wichtigste Frage von allen:
- „Wie kann ich Kubernetes nutzen, 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 sehr nützlich. Zu den Konfigurationswerten gehören normalerweise Parameter, die für eine bestimmte Umgebung ausgelegt sind, DNS-Adressen von Drittanbieterdiensten und Anmeldedaten zur Authentifizierung.
Natürlich kann man all dies direkt im Code unterbringen, aber dieser Ansatz ist nicht flexibel genug. Beispielsweise müsste man, um einen Konfigurationswert zu ändern, den Code erneut kompilieren und bereitstellen. Eine viel bessere Lösung wäre es, die Konfiguration vom Code zu trennen und sie entweder aus einer Datei oder aus 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 Pod-Specification 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 ausführlich und betrachten einige praktische Ansätze zur Verwaltung von Konfigurationen und vertraulichen Daten anhand eines Demonstrationsanwendungsbeispiels.
Aktualisierung von Pod-Schalen bei Änderungen an der Konfiguration
Stellen Sie sich vor, dass in Ihrem Cluster eine Bereitstellung vorhanden ist und Sie einige Werte in deren ConfigMap ändern möchten. 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-Schalen mit einem eleganten Trick neu laden. Fügen Sie die folgende Annotation zu den Spezifikationen Ihrer Bereitstellung hinzu:
checksum/config: {{ include (print $.Template.BasePath "\/configmap.yaml") .
| sha256sum }}Nun enthält das Bereitstellungsschema die Prüfziffer der Konfigurationseinstellungen: Bei einer Änderung der Einstellungen wird die Summe aktualisiert. Wenn Sie den Befehl helm upgrade ausführen, stellt Helm fest, dass die Spezifikation der Bereitstellung geändert wurde, und startet alle Pod-Schalen neu.
Vertrauliche Daten in Kubernetes
Wir wissen bereits, dass das Objekt ConfigMap einen flexiblen Mechanismus zur Speicherung und zum Zugriff auf Konfigurationsdaten im Cluster bietet. Die meisten Anwendungen enthalten jedoch Informationen, die geheim und vertraulich sind: Zum Beispiel Passwörter oder API-Schlüssel. Diese können auch in einer ConfigMap gespeichert werden, aber diese Lösung ist nicht ideal.
Stattdessen bietet Kubernetes ein spezielles Typobjekt an, das zur Speicherung vertraulicher Daten gedacht ist: Secret. Im Folgenden betrachten wir ein Beispiel, wie dieses Objekt in unserer Demonstrationsanwendung verwendet werden kann.
Schauen Sie sich zunächst das Kubernetes-Manifests 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 IT-Bereich sehr nützlich. Ähnlich wie bei ConfigMap können in einem Secret-Objekt viele Schlüssel-Werte-Paare untergebracht werden. Hier verwenden wir der Einfachheit halber nur ein Paar „Schlüssel – Wert“.
Verwendung von Secret-Objekten als Umgebungsvariablen
Ähnlich wie bei ConfigMap kann das Secret-Objekt in einem Container als Umgebungsvariable oder als Datei auf seiner Festplatte bereitgestellt werden. Im folgenden Beispiel weisen wir einer Umgebungsvariable einen Wert aus dem Secret zu:
spezi:
container:
- name: demo
image: cloudnatived/demo:hello-secret-env
ports:
- containerPort: 8888
env:
- name: GREETING
valueFrom:
secretKeyRef:
name: demo-secret
key: magicWordFühren Sie den folgenden Befehl im Repository demo aus, um die Manifeste anzuwenden:
kubectl apply -f hello-secret-env/k8s/
deployment.extensions "demo" konfiguriert
Secret "demo-secret" erstelltWie zuvor, leiten Sie den lokalen Port zum Deployment weiter, um das Ergebnis in Ihrem Browser zu sehen:
kubectl port-forward deploy/demo 9999:8888
Leitet von 127.0.0.1:9999 -> 8888 weiter
Leitet von [::1]:9999 -> 8888 weiterBeim Öffnen der Adresse :9999/ sollten Sie Folgendes sehen:
Das geheime Wort ist "xyzzy"
Speichern von Secret-Objekten in Dateien
In diesem Beispiel werden wir das Secret-Objekt als Datei an den Container anbinden. Der Code befindet sich im Ordner hello-secret-file des Repositories demo.
Um das Secret als Datei anzubinden, verwenden wir das folgende Deployment:
spezi:
container:
- 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-secretWie 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 an. Im Feld mountPath ist "/secrets" angegeben, sodass Kubernetes in diesem Ordner eine Datei für jedes "Schlüssel-Wert"-Paar erstellt, das im Secret-Objekt definiert ist.
In unserem Beispiel haben wir nur ein "Schlüssel-Wert"-Paar mit dem Namen magicWord definiert, weshalb das Manifest im Container eine Datei "/secrets/magicWord" mit vertraulichen Daten erstellt, die ausschließlich lesbar ist.
Wenn Sie dieses Manifest auf die gleiche Weise anwenden wie im vorherigen Beispiel, sollte dasselbe Ergebnis herauskommen:
Das geheime Wort ist "xyzzy"
Lesen von Secret-Objekten
Im vorherigen Abschnitt haben wir den Befehl kubectl describe verwendet, um den Inhalt der ConfigMap anzuzeigen. Kann man das gleiche mit Secrets tun?
kubectl describe secret/demo-secret
Name: demo-secret
Namespace: default
Labels:
Annotations:
Type: Opaque
Daten
====
magicWord: 5 bytesBitte beachten Sie, dass die eigentlichen Daten nicht angezeigt werden. Secret-Objekte in Kubernetes sind vom Typ Opaque: Das bedeutet, dass ihr Inhalt nicht in der Ausgabe von kubectl describe, in Protokolldateien und im Terminal angezeigt wird, sodass vertrauliche Informationen nicht versehentlich offengelegt werden können.
Um die codierte Version sensibler 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: Opaquebase64
Was ist eHl6enk=, das so gar nicht wie unser Ausgangswert aussieht? Tatsächlich handelt es sich um ein Secret-Objekt, das in base64 codiert ist. Base64 ist ein Kodierungsschema für beliebige Binärdaten in Form einer Zeichenkette.
Da sensible Informationen binär sein können und nicht zur Ausgabe geeignet sind (wie zum Beispiel bei einem TLS-Verschlüsselungsschlüssel), werden Secret-Objekte immer im base64-Format gespeichert.
Der Text beHl6enk= ist die base64-codierte Version unseres geheimen Wortes xyzzy. Das kann überprüft werden, wenn Sie im Terminal den Befehl base64 --decode ausführen:
echo "eHl6enk=" | base64 --decode
xyzzyObwohl Kubernetes Sie vor der versehentlichen Ausgabe sensibler Daten im Terminal oder in Protokolldateien schützt, können diese Daten im base64-Format abgerufen und anschließend dekodiert werden, wenn Sie Lesezugriff auf Secret-Objekte in einem bestimmten Namensraum haben.
Wenn Sie einen Text in base64 kodieren möchten (zum Beispiel um ihn in ein Secret zu integrieren), verwenden Sie den Befehl base64 ohne Argumente:
echo xyzzy | base64
eHl6enkKZugriff auf Secret-Objekte
Wer kann Secret-Objekte lesen und bearbeiten? Das wird durch RBAC festgelegt – ein Zugriffssteuerungsmechanismus (wir werden dies ausführlich im Unterabschnitt „Einführung in die rollenbasierte Zugriffsverwaltung“ auf Seite 258 diskutieren). Wenn Sie einen Cluster verwenden, in dem das RBAC-System nicht vorhanden oder nicht aktiviert ist, sind alle Ihre Secret-Objekte für alle Benutzer und Container zugänglich (später erklären wir, warum Sie keinen produktiven Cluster ohne RBAC haben sollten).
Passives Verschlüsseln von Daten
Und was ist mit denen, die Zugriff auf die etcd-Datenbank haben, in der Kubernetes seine gesamten Informationen speichert? Können sie sensible Daten lesen, ohne über die Berechtigung für die Lesezugriffe auf Secret-Objekte über die API zu verfügen?
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 Personen mit direktem Zugriff auf die Datenbank nicht gelesen werden können. Zum Entschlüsseln wird ein Schlüssel benötigt, der nur beim Kubernetes API-Server vorhanden ist. In einem korrekt 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 das Flag experimental-encryption-provider-config nicht sehen, ist die passive Verschlüsselung nicht aktiviert. Wenn Sie Google Kubernetes Engine oder andere Kubernetes-Verwaltungsdienste verwenden, werden Ihre Daten mit einem anderen Mechanismus verschlüsselt, sodass das Flag fehlt. Fragen Sie Ihren Kubernetes-Anbieter, ob der Inhalt von etcd verschlüsselt wird.
Speicherung vertraulicher Daten
Es gibt bestimmte Kubernetes-Ressourcen, die niemals aus dem Cluster gelöscht werden sollten: zum Beispiel besonders wichtige Objekte wie Secrets. Sie können eine Ressource mit einer Annotation, die der Helm-Dispatcher bereitstellt, vor der Löschung schützen:
kind: Secret
metadata:
annotations:
"helm.sh/resource-policy": keepStrategien zum Umgang mit Secret-Objekten
Im vorherigen Abschnitt wurden vertrauliche Daten sofort nach der Speicherung im Cluster vor unbefugtem Zugriff geschützt. In den Manifestdateien wurden sie jedoch als Klartext gespeichert.
Sie sollten niemals vertrauliche Informationen in Dateien speichern, die sich im Versionskontrollsystem befinden. Wie können Sie also solche Informationen sicher verwalten und speichern, bevor Sie sie auf das Kubernetes-Cluster anwenden?
Sie können beliebige Tools oder Strategien auswählen, um mit vertraulichen Daten in Ihren Anwendungen zu arbeiten, aber Sie müssen mindestens die folgenden Fragen beantworten.
- Wo sollten vertrauliche Daten gespeichert werden, damit sie hochverfügbar sind?
- Wie machen Sie vertrauliche Daten für Ihre aktiven Anwendungen zugänglich?
- Was sollte mit Ihren Anwendungen geschehen, wenn Sie vertrauliche Daten ersetzen oder bearbeiten?
Über die Autoren
John Arundel ist ein Berater mit 30 Jahren Erfahrung in der Computerindustrie. Er hat mehrere Bücher geschrieben und arbeitet mit vielen Unternehmen aus verschiedenen Ländern zusammen, um sie in Fragen der cloudbasierten Infrastruktur und Kubernetes zu beraten. In seiner Freizeit surft er gerne, schießt gut mit der Pistole und spielt leidenschaftlich Klavier. Er lebt in einem märchenhaften Cottage in Cornwall, England.
Justin Domingus ist Systemadministrationsingenieur und arbeitet in einer DevOps-Umgebung mit Kubernetes und Cloud-Technologien. Er verbringt gerne Zeit im Freien, trinkt Kaffee, geht Krabben fangen und sitzt am Computer. Er lebt in Seattle, Washington, zusammen mit seiner großartigen Katze und seiner noch großartigeren Frau, die auch seine beste Freundin Adrienne ist.
» Mehr über das Buch erfahren Sie auf
»
»
Für die Bewohner von Chabro Rabatt von 25% mit dem Gutschein — Kubernetes
Nach der Bezahlung der gedruckten Version des Buches wird ein elektronisches Buch an die E-Mail-Adresse gesendet.
Quelle: habr.com
