Hallo, Khabro-Bewohner! Kubernetes ist eines der Schlüsselelemente des modernen Cloud-Ökosystems. Diese Technologie bietet Zuverlässigkeit, Skalierbarkeit und Widerstandsfähigkeit bei der Containervirtualisierung. John Arundel und Justin Domingus sprechen über das Kubernetes-Ökosystem und stellen bewährte Lösungen für alltägliche Probleme vor. Schritt für Schritt erstellen Sie Ihre eigene Cloud-native Anwendung und erstellen die Infrastruktur zu deren Unterstützung, richten eine Entwicklungsumgebung und eine kontinuierliche Bereitstellungspipeline ein, die Sie bei der Arbeit an Ihren nächsten Anwendungen unterstützt.
• Beginnen Sie mit den Grundlagen von Containern und Kubernetes: Es sind keine besonderen Erfahrungen erforderlich, um das Thema zu erlernen. • Führen Sie Ihre eigenen Cluster aus oder wählen Sie einen verwalteten Kubernetes-Dienst von Amazon, Google usw. • Verwenden Sie Kubernetes, um den Containerlebenszyklus und den Ressourcenverbrauch zu verwalten. • Optimieren Sie Cluster basierend auf Kosten, Leistung, Ausfallsicherheit, Leistung und Skalierbarkeit. • Lernen Sie die besten Tools zum Entwickeln, Testen und Bereitstellen Ihrer Anwendungen kennen. • Nutzen Sie aktuelle Branchenpraktiken, um Sicherheit und Kontrolle zu gewährleisten. • Implementieren Sie DevOps-Prinzipien in Ihrem gesamten Unternehmen, damit Entwicklungsteams flexibler, schneller und effizienter agieren können.
Für wen ist das Buch?
Das Buch ist vor allem für Mitarbeiter von Verwaltungsabteilungen relevant, die für Server, Anwendungen und Dienste verantwortlich sind, sowie für Entwickler, die entweder neue Cloud-Dienste aufbauen oder bestehende Anwendungen auf Kubernetes und die Cloud migrieren. Keine Sorge, Sie müssen nicht wissen, wie man mit Kubernetes oder Containern arbeitet – wir bringen Ihnen alles bei.
Auch erfahrene Kubernetes-Benutzer profitieren von der ausführlichen Behandlung von Themen wie RBAC, kontinuierlicher Bereitstellung, Verwaltung sensibler Daten und Beobachtbarkeit. Wir hoffen, dass die Seiten des Buches unabhängig von Ihren Fähigkeiten und Erfahrungen auf jeden Fall etwas Interessantes für Sie enthalten.
Welche Fragen beantwortet das Buch?
Während wir das Buch planten und schrieben, diskutierten wir mit Hunderten von Menschen über Cloud-Technologie und Kubernetes und sprachen mit Branchenführern und Experten sowie völligen Neulingen. Nachfolgend finden Sie ausgewählte Fragen, die in dieser Veröffentlichung beantwortet werden sollten.
- „Mich interessiert, warum man sich mit dieser Technologie beschäftigen sollte. Welche Probleme wird es mir und meinem Team bei der Lösung helfen?“
- „Kubernetes scheint interessant zu sein, hat aber eine ziemlich hohe Eintrittsbarriere. Die Vorbereitung eines einfachen Beispiels ist nicht schwierig, die weitere Verwaltung und Fehlerbehebung ist jedoch entmutigend. Wir möchten zuverlässige Ratschläge dazu erhalten, wie Menschen Kubernetes-Cluster in der realen Welt verwalten und auf welche Probleme wir wahrscheinlich stoßen werden.“
- „Subjektive Ratschläge wären hilfreich. Das Kubernetes-Ökosystem bietet neuen Teams zu viele Optionen zur Auswahl. Wenn es mehrere Möglichkeiten gibt, dasselbe zu tun, woher wissen Sie dann, welche die beste ist? Wie trifft man eine Wahl?
Und vielleicht die wichtigste aller Fragen:
- „Wie kann ich Kubernetes nutzen, ohne mein Unternehmen zu stören?“
Auszug. Konfigurations- und Geheimobjekte
Die Möglichkeit, die Logik einer Kubernetes-Anwendung von ihrer Konfiguration (also 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 typischerweise umgebungsspezifische Einstellungen, DNS-Adressen von Drittanbieterdiensten und Authentifizierungsdaten.
Natürlich lässt sich das alles direkt in den Code packen, allerdings ist dieser Ansatz nicht flexibel genug. Wenn Sie beispielsweise einen Konfigurationswert ändern, müssten Sie Ihren Code erneut erstellen und bereitstellen. Eine viel bessere Lösung wäre, die Konfiguration vom Code zu trennen und sie aus einer Datei oder Umgebungsvariablen zu lesen.
Kubernetes bietet verschiedene Möglichkeiten zur Konfigurationsverwaltung. Erstens können Sie Werte über Umgebungsvariablen, die in der Pod-Wrapper-Spezifikation angegeben sind, an die Anwendung übergeben (siehe „Umgebungsvariablen“ auf Seite 192). Zweitens können Konfigurationsdaten mithilfe von ConfigMap- und Secret-Objekten direkt in Kubernetes gespeichert werden.
In diesem Kapitel untersuchen wir diese Objekte im Detail und betrachten einige praktische Ansätze zur Verwaltung von Konfigurations- und sensiblen Daten mithilfe einer Demoanwendung.
Aktualisieren von Pod-Shells, wenn sich die Konfiguration ändert
Stellen Sie sich vor, Sie haben eine Bereitstellung in Ihrem Cluster und möchten einige Werte in seiner ConfigMap ändern. Wenn Sie das Helm-Diagramm verwenden (siehe „Helm: Paketmanager für Kubernetes“ auf Seite 102), können Sie eine Konfigurationsänderung automatisch erkennen und Ihre Pod-Shells mit einem praktischen Trick neu laden. Fügen Sie Ihrer Bereitstellungsspezifikation die folgende Anmerkung hinzu:
checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") .
| sha256sum }}Die Bereitstellungsvorlage enthält jetzt eine Prüfsumme der Konfigurationsparameter: Wenn die Parameter geändert werden, wird die Summe aktualisiert. Wenn Sie helm upgrade ausführen, erkennt Helm, dass sich die Bereitstellungsspezifikation geändert hat, und startet alle Pod-Shells neu.
Sensible Daten in Kubernetes
Wir wissen bereits, dass das ConfigMap-Objekt einen flexiblen Mechanismus zum Speichern und Zugreifen auf Konfigurationsdaten in einem Cluster bietet. Die meisten Anwendungen verfügen jedoch über vertrauliche und vertrauliche Informationen, wie z. B. Passwörter oder API-Schlüssel. Es kann auch in ConfigMap gespeichert werden, diese Lösung ist jedoch nicht ideal.
Stattdessen bietet Kubernetes einen speziellen Objekttyp zum Speichern sensibler Daten: Secret. Schauen wir uns als Nächstes ein Beispiel an, wie dieses Objekt in unserer Demoanwendung verwendet werden kann.
Werfen Sie zunächst einen Blick auf das Kubernetes-Manifest für das Secret-Objekt (siehe hello-secret-env/k8s/secret.yaml):
apiVersion: v1
kind: Secret
metadata:
name: demo-secret
stringData:
magicWord: xyzzy
In diesem Beispiel ist der private Schlüssel von magicWord xyzzy (en.wikipedia.org/wiki/Xyzzy_(computing)). Das Wort xyzzy ist in der Computerwelt im Allgemeinen sehr nützlich. Ähnlich wie bei ConfigMap können Sie mehrere Schlüssel und Werte in einem Secret-Objekt speichern. Der Einfachheit halber verwenden wir hier nur ein Schlüssel-Wert-Paar.
Verwendung geheimer Objekte als Umgebungsvariablen
Wie ConfigMap kann das Secret-Objekt im Container als Umgebungsvariablen oder als Datei auf seiner Festplatte verfügbar gemacht werden. Im folgenden Beispiel weisen wir dem Wert von Secret eine Umgebungsvariable zu:
spec:
containers:
- 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 Demo-Repository aus, um die Manifeste anzuwenden:
kubectl apply -f hello-secret-env/k8s/
deployment.extensions "demo" configured
secret "demo-secret" createdLeiten Sie wie zuvor den lokalen Port an die Bereitstellung weiter, um das Ergebnis in Ihrem Browser anzuzeigen:
kubectl port-forward deploy/demo 9999:8888
Forwarding from 127.0.0.1:9999 -> 8888
Forwarding from [::1]:9999 -> 8888Beim Öffnen einer Adresse :9999/ Sie sollten Folgendes sehen:
The magic word is "xyzzy"
Geheime Objekte in Dateien schreiben
In diesem Beispiel hängen wir das Secret-Objekt als Datei an den Container an. Der Code befindet sich im Ordner hello-secret-file des Demo-Repositorys.
Um Secret als Datei zu verbinden, verwenden wir die folgende Bereitstellung:
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-secretWie im Unterabschnitt „Erstellen von Konfigurationsdateien aus ConfigMap-Objekten“ auf S. 240 erstellen wir ein Volume (in diesem Fall demo-secret-volume) und mounten es im Abschnitt „volumeMounts“ der Spezifikation in den Container. Das Feld mountPath ist /secrets, daher erstellt Kubernetes in diesem Ordner eine Datei für jedes im Secret-Objekt definierte Schlüssel/Wert-Paar.
In unserem Beispiel haben wir nur ein Schlüssel-Wert-Paar namens magicWord definiert, sodass das Manifest eine einzelne schreibgeschützte Datei /secrets/magicWord mit vertraulichen Daten im Container erstellt.
Wenn Sie dieses Manifest auf die gleiche Weise wie im vorherigen Beispiel anwenden, sollten Sie das gleiche Ergebnis erhalten:
The magic word is "xyzzy"
Geheime Objekte lesen
Im vorherigen Abschnitt haben wir den Befehl kubectl discover verwendet, um den Inhalt einer ConfigMap anzuzeigen. Kann das Gleiche auch mit Secret gemacht werden?
kubectl describe secret/demo-secret
Name: demo-secret
Namespace: default
Labels: <none>
Annotations:
Type: Opaque
Data
====
magicWord: 5 bytesBitte beachten Sie, dass die Daten selbst nicht angezeigt werden. Geheime Objekte in Kubernetes sind vom Typ „Opaque“, was bedeutet, dass ihr Inhalt nicht in der Kubectl-Beschreibungsausgabe, in Protokolleinträgen oder im Terminal angezeigt wird, wodurch es unmöglich ist, versehentlich vertrauliche Informationen preiszugeben.
Um eine codierte YAML-Version vertraulicher Daten 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 unterscheidet eHl6enk= völlig von unserem ursprünglichen Wert? Dies ist eigentlich ein Secret-Objekt, dargestellt in Base64-Kodierung. Base64 ist ein Schema zum Kodieren beliebiger Binärdaten als Zeichenfolge.
Da vertrauliche Informationen möglicherweise binär sind und nicht ausgegeben werden (wie es bei einem TLS-Verschlüsselungsschlüssel der Fall ist), werden Secret-Objekte immer im Base64-Format gespeichert.
Der Text beHl6enk= ist die Base64-kodierte Version unseres Geheimwortes xyzzy. Sie können dies überprüfen, indem Sie den Befehl base64 –decode im Terminal ausführen:
echo "eHl6enk=" | base64 --decode
xyzzyWährend Kubernetes Sie also vor der versehentlichen Ausgabe sensibler Daten im Terminal oder in Protokolldateien schützt, können diese Daten mit Base64ing verarbeitet und anschließend dekodiert werden, wenn Sie über Leseberechtigungen für Secret-Objekte in einem bestimmten Namespace verfügen.
Wenn Sie einen Text mit Base64 kodieren müssen (um ihn beispielsweise in ein Secret einzufügen), verwenden Sie den Befehl base64 ohne Argumente:
echo xyzzy | base64
eHl6enkKZugriff auf geheime Objekte
Wer kann geheime Objekte lesen und bearbeiten? Dies wird durch RBAC bestimmt, einen Zugriffskontrollmechanismus (wir werden ihn im Unterabschnitt „Einführung in die rollenbasierte Zugriffskontrolle“ auf Seite 258 ausführlich besprechen). Wenn Sie einen Cluster ausführen, der nicht über RBAC verfügt oder nicht aktiviert ist, stehen alle Ihre Secret-Objekte allen Benutzern und Containern zur Verfügung (wir erklären später, dass Sie keine Produktionscluster ohne RBAC haben sollten).
Passive Datenverschlüsselung
Was ist mit denen, die Zugriff auf die etcd-Datenbank haben, in der Kubernetes alle seine Informationen speichert? Können sie sensible Daten lesen, ohne die Erlaubnis zum Lesen geheimer Objekte über die API zu haben?
Seit Version 1.7 unterstützt Kubernetes die passive Datenverschlüsselung. Dies bedeutet, dass vertrauliche Informationen in etcd verschlüsselt auf der Festplatte gespeichert werden und selbst von Personen mit direktem Zugriff auf die Datenbank nicht gelesen werden können. Zum Entschlüsseln benötigen Sie einen Schlüssel, über den nur der Kubernetes-API-Server verfügt. In einem ordnungsgemäß konfigurierten Cluster sollte die passive Verschlüsselung aktiviert sein.
So können Sie überprüfen, ob die passive Verschlüsselung in Ihrem Cluster funktioniert:
kubectl describe pod -n kube-system -l component=kube-apiserver |grep encryption
--experimental-encryption-provider-config=...Wenn das Flag „experimental-encryption-provider-config“ nicht angezeigt wird, 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 nicht vorhanden ist. Erkundigen Sie sich bei Ihrem Kubernetes-Anbieter, ob etcd-Inhalte verschlüsselt sind.
Speicherung vertraulicher Daten
Es gibt einige Kubernetes-Ressourcen, die niemals aus dem Cluster entfernt werden sollten, z. B. hochsensible Secret-Objekte. Sie können eine Ressource mithilfe einer vom Helm-Manager bereitgestellten Anmerkung vor dem Löschen schützen:
kind: Secret
metadata:
annotations:
"helm.sh/resource-policy": keepGeheime Objektverwaltungsstrategien
Im Beispiel aus dem vorherigen Abschnitt wurden sensible Daten unmittelbar nach der Speicherung im Cluster vor unbefugtem Zugriff geschützt. In Manifestdateien wurden sie jedoch als Klartext gespeichert.
Sie sollten niemals vertrauliche Informationen in Dateien ablegen, die einer Versionskontrolle unterliegen. Wie können Sie diese Informationen sicher verwalten und speichern, bevor Sie sie auf Ihren Kubernetes-Cluster anwenden?
Sie können beliebige Tools und Strategien für den Umgang mit sensiblen Daten in Ihren Anwendungen wählen, müssen aber dennoch mindestens die folgenden Fragen beantworten.
- Wo sollen sensible Daten gespeichert werden, damit sie gut zugänglich sind?
- Wie machen Sie sensible Daten für Ihre aktiven Anwendungen zugänglich?
- Was soll mit Ihren Anwendungen passieren, wenn Sie sensible Daten ersetzen oder bearbeiten?
Über die Autoren
John Arundel ist ein Berater mit 30 Jahren Erfahrung in der Computerbranche. Er hat mehrere Bücher geschrieben und arbeitet mit vielen Unternehmen aus verschiedenen Ländern zusammen, wo er sie zu Cloud-nativer Infrastruktur und Kubernetes berät. In seiner Freizeit surft er gerne, ist ein guter Pistolenschütze und spielt als Amateur Klavier. Lebt in einem märchenhaften Cottage in Cornwall, England.
Justin Domingus — Systemadministrationsingenieur, der in einer DevOps-Umgebung mit Kubernetes und Cloud-Technologien arbeitet. Er verbringt gerne Zeit im Freien, trinkt Kaffee, fischt Krabben und sitzt am Computer. Lebt in Seattle, Washington, mit einer wundervollen Katze und einer noch wundervolleren Frau und besten Freundin, Adrienne.
» Weitere Details zum Buch finden Sie unter
»
»
Für Khabrozhiteley 25 % Rabatt mit Gutschein - Kubernetes
Nach Bezahlung der Papierversion des Buches wird ein elektronisches Buch per E-Mail verschickt.
Source: habr.com