Webinar-Reihe: Ein genauerer Blick auf Kubernetes

Einführung

Kubernetes ist ein Open-Source-Container-Orchestrierungs-Tool zum Verwalten von containerisierten Anwendungen. Im vorheriges Tutorial in dieser Reihe haben Sie Kubernetes auf DigitalOcean konfiguriert. Nachdem der Cluster nun betriebsbereit ist, können Sie Containeranwendungen darauf bereitstellen.

In diesem Lernprogramm erfahren Sie, wie diese Grundelemente zusammenarbeiten, wenn Sie einen Pod in Kubernetes bereitstellen, als Dienst verfügbar machen und ihn über einen Replikationscontroller skalieren.

Voraussetzungen

Um dieses Lernprogramm abzuschließen, müssen Sie zuerst das vorherige Lernprogramm in dieser Reihe abschließen: Getting Started with Kubernetes.

Schritt 1 - Grundlegendes zu Kubernetes

Kubernetes stellt eine API zur Verfügung, mit der Clients Anwendungen erstellen, skalieren und beenden. Jede Operation zielt auf eines oder mehrere Objekte ab, die Kubernetes verwaltet. Diese Objekte bilden die Grundbausteine von Kubernetes. Sie sind die Grundelemente, über die Sie containerisierte Anwendungen verwalten.

Das Folgende ist eine Zusammenfassung der wichtigsten API-Objekte von Kubernetes:

* Cluster *: Pool von Rechen-, Speicher- und Netzwerkressourcen.
* Nodes *: Hostcomputer, die im Cluster ausgeführt werden.
* Namespaces *: Logische Partitionen eines Clusters.
* Pods *: Einheiten der Bereitstellung.
* Labels * und * Selectors *: Schlüssel-Wert-Paare zur Identifizierung und Serviceerkennung.
* Services *: Sammlung von Pods, die zur selben Anwendung gehören.
* Replica Set *: Gewährleistet Verfügbarkeit und Skalierbarkeit.
* Bereitstellung *: Verwaltet den Anwendungslebenszyklus.

Schauen wir uns diese genauer an.

Die Nodes, die einen Kubernetes-Cluster ausführen, werden ebenfalls als Objekte behandelt. Sie können wie alle anderen API-Objekte von Kubernetes verwaltet werden. Um die logische Trennung von Anwendungen zu ermöglichen, unterstützt Kubernetes die Erstellung von Namespaces. Beispielsweise kann eine Organisation einen Kubernetes-Cluster logisch partitionieren, um eine Entwicklungs-, Test-, Staging- und Produktionsumgebung auszuführen. Jede Umgebung kann in einen dedizierten Namespace gestellt werden, der unabhängig verwaltet wird. Kubernetes stellt seine API über den Master Node zur Verfügung.

Obwohl Kubernetes Docker-Container ausführt, können diese Container nicht direkt bereitgestellt werden. Stattdessen müssen die Anwendungen in einem Format gepackt werden, das Kubernetes versteht. Mit diesem Format kann Kubernetes containerisierte Anwendungen effizient verwalten. Diese Anwendungen können einen oder mehrere Container enthalten, die zusammenarbeiten müssen.

Die grundlegende Einheit für das Packen und Bereitstellen in Kubernetes heißt Pod. Jeder Pod kann einen oder mehrere Container enthalten, die zusammen verwaltet werden müssen. Beispielsweise können ein Webserver (Nginx) -Container und ein Cache (Redis) -Container zusammen als Pod gepackt werden. Kubernetes behandelt alle Container, die zu einem Pod gehören, als logische Einheit. Jedes Mal, wenn ein neuer Pod erstellt wird, werden alle in der Pod-Definition deklarierten Container erstellt. Alle Container in einem Pod haben denselben Kontext wie die IP-Adresse, den Hostnamen und den Speicher. Sie kommunizieren miteinander über IPC (Interprozesskommunikation) und nicht über Remoteaufrufe oder REST-APIs.

Sobald die Container in Kubernetes gepackt und bereitgestellt wurden, müssen sie für den internen und externen Zugriff verfügbar gemacht werden. Bestimmte Container wie Datenbanken und Caches müssen nicht der Außenwelt ausgesetzt werden. Da auf APIs und Web-Frontends direkt von anderen Verbrauchern und Endbenutzern zugegriffen werden kann, müssen sie der Öffentlichkeit zugänglich gemacht werden. In Kubernetes werden Container basierend auf einer Richtlinie intern oder extern verfügbar gemacht. Durch diesen Mechanismus wird das Risiko verringert, dass sensible Arbeitslasten wie Datenbanken der Öffentlichkeit zugänglich gemacht werden.

Pods in Kubernetes werden durch Services angezeigt. Jeder Service wird zusammen mit den Port- und Protokollinformationen als interner oder externer Endpunkt deklariert. Interne Konsumenten einschließlich anderer Pods und externe Konsumenten wie API-Clients verlassen sich auf Kubernetes Services für die grundlegende Interaktion. Dienste unterstützen TCP- und UDP-Protokolle.

Jedes Objekt in Kubernetes, z. B. ein Pod oder ein Service, ist mit zusätzlichen Metadaten verknüpft, die als Labels und Selectors bezeichnet werden. Labels sind Schlüssel / Wert-Paare, die an ein Kubernetes-Objekt angehängt sind. Diese Bezeichnungen identifizieren ein oder mehrere API-Objekte eindeutig. Selektoren verknüpfen ein Kubernetes-Objekt mit einem anderen. Zum Beispiel hilft ein in einem Service definierter Selektor Kubernetes dabei, alle Pods mit einer Beschriftung zu finden, die dem Wert des Selektors entsprechen. Diese Zuordnung ermöglicht die dynamische Erkennung von Objekten. Neue Objekte, die zur Laufzeit mit denselben Labels erstellt werden, werden sofort erkannt und den entsprechenden Selektoren zugeordnet. Dieser Service Discovery-Mechanismus ermöglicht eine effiziente dynamische Konfiguration, z. B. Scale-In- und Scale-Out-Vorgänge.

Einer der Vorteile des Wechsels zu Containern ist die schnelle Skalierung. Da Container im Vergleich zu virtuellen Maschinen leichtgewichtig sind, können Sie sie in wenigen Sekunden skalieren. Für ein hochverfügbares und skalierbares Setup müssen Sie mehrere Instanzen Ihrer Anwendungen bereitstellen und sicherstellen, dass immer eine Mindestanzahl von Instanzen dieser Anwendungen ausgeführt wird. Um diese Konfiguration von containerisierten Anwendungen zu adressieren, führte Kubernetes das Konzept von Replica Sets ein, mit denen ein oder mehrere Pods die ganze Zeit ausgeführt werden können. Wenn mehrere Instanzen von Pods in einem Cluster ausgeführt werden müssen, werden sie als Replikatsätze gepackt. Kubernetes stellt sicher, dass die Anzahl der im Replikatsatz definierten Pods immer im aktiven Modus ist. Wenn ein Pod aufgrund eines Hardware- oder Konfigurationsproblems beendet wird, startet die Kubernetes-Steuerebene sofort einen weiteren Pod.

Ein Deployment-Objekt ist eine Kombination aus Pods und Replikatsätzen. Dieses Grundelement erweitert Kubernetes-Anwendungen um PaaS-ähnliche Funktionen. Damit können Sie ein laufendes Upgrade einer vorhandenen Bereitstellung mit minimaler Ausfallzeit durchführen. Bereitstellungen ermöglichen auch Muster wie kanarische Bereitstellungen und blaugrüne Bereitstellungen. Sie übernehmen die wesentlichen Teile des Application Lifecycle Management (ALM) von Container-Anwendungen.

Schritt 2 - Auflisten der Kubernetes-Knoten und -Namensräume

Angenommen, Sie haben die Schritte unter den Kubernetes-Cluster in DigitalOcean einrichten ausgeführt, führen Sie die folgenden Befehle aus, um alle aufzulisten Knoten und verfügbare Namespaces:

kubectl get nodes

OutputNAME                  STATUS    ROLES     AGE       VERSION
spc3c97hei-master-1   Ready     master    10m       v1.8.7
spc3c97hei-worker-1   Ready     <none>    4m        v1.8.7
spc3c97hei-worker-2   Ready     <none>    4m        v1.8.7

kubectl get namespaces

OutputNAME                STATUS    AGE
default             Active    11m
kube-public         Active    11m
kube-system         Active    11m
stackpoint-system   Active    4m

Wenn kein Namespace angegeben ist, zielt "+ kubectl +" auf den Standard-Namespace.

Jetzt starten wir eine Anwendung.

[[step-3–-creating-and-deploying-a-pod]] === Schritt 3 - Erstellen und Bereitstellen eines Pods

Kubernetes-Objekte werden in YAML-Dateien deklariert und über die CLI + kubectl + an Kubernetes gesendet. Definieren wir einen Pod und stellen ihn bereit.

Erstellen Sie eine neue YAML-Datei mit dem Namen "+ Simple-Pod.yaml +":

nano Simple-Pod.yaml

Fügen Sie den folgenden Code hinzu, der einen Pod mit einem Container basierend auf dem Nginx-Webserver definiert. Es wird über das TCP-Protokoll auf dem Port "+ 80 " angezeigt. Beachten Sie, dass die Definition die Bezeichnungen " name " und " env +" enthält. Wir verwenden diese Bezeichnungen, um bestimmte Pods zu identifizieren und zu konfigurieren.

Simple-Pod.yaml

apiVersion: "v1"
kind: Pod
metadata:
 name: web-pod
 labels:
   name: web
   env: dev
spec:
 containers:
   - name: myweb
     image: nginx
     ports:
       - containerPort: 80
         name: http
         protocol: TCP

Führen Sie den folgenden Befehl aus, um einen Pod zu erstellen.

kubectl create -f Simple-Pod.yaml

Outputpod "web-pod" created

Lassen Sie uns die Erstellung des Pods überprüfen.

kubectl get pods

OutputNAME      READY     STATUS    RESTARTS   AGE
web-pod   1/1       Running   0          2m

Im nächsten Schritt werden wir diesen Pod für das öffentliche Internet zugänglich machen.

Schritt 4 - Pods über einen Dienst freigeben

Dienste machen eine Reihe von Pods entweder intern oder extern verfügbar. Definieren wir einen Service, der den Nginx-Pod öffentlich verfügbar macht. Wir werden Nginx über einen NodePort verfügbar machen, ein Schema, das den Pod über einen beliebigen Port zugänglich macht, der auf jedem Knoten des Clusters geöffnet ist.

Erstellen Sie eine neue Datei mit dem Namen "+ Simple-Service.yaml +", die diesen Code enthält, der den Dienst für Nginx definiert:

Simple-Service.yaml

apiVersion: v1
kind: Service
metadata:
 name: web-svc
 labels:
   name: web
   env: dev
spec:
 selector:
   name: web
 type: NodePort
 ports:
   - port: 80
     name: http
     targetPort: 80
     protocol: TCP

Der Service erkennt alle Pods im selben Namespace, die mit dem Label mit dem Buchstaben "+ name: web +" übereinstimmen. Der Selektorabschnitt der YAML-Datei definiert diese Zuordnung explizit.

Wir geben an, dass der Service vom Typ NodePort ist, und zwar durch die Deklaration NodePort.

Verwenden Sie dann, um es an den Cluster zu senden.

kubectl create -f Simple-Service.yml

Diese Ausgabe zeigt an, dass der Service erfolgreich erstellt wurde:

Outputservice "web-svc" created

Lassen Sie uns den Port ermitteln, an dem der Pod verfügbar ist.

kubectl get services

OutputNAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)        AGE
kubernetes   ClusterIP   10.3.0.1     <none>        443/TCP        28m
     NodePort    10.3.0.143   <none>        80:32097/TCP   38s

Anhand dieser Ausgabe sehen wir, dass der Service auf Port + 32097 + verfügbar ist. Versuchen wir, eine Verbindung zu einem der Arbeitsknoten herzustellen.

Verwenden Sie die DigitalOcean-Konsole, um die IP-Adresse eines der Arbeitsknoten abzurufen.

image: https://assets.digitalocean.com/articles/webinar_4_kubernetes_closer_look/kB9HmSK.png [Die Tröpfchen in der DigitalOcean-Konsole, die Ihrem Kubernetes-Cluster zugeordnet sind.]

Verwenden Sie den Befehl "+ curl ", um eine HTTP-Anforderung an einen der Knoten an Port " 31930 +" zu senden.

curl http://:32097

Die Antwort mit der Nginx-Standardhomepage wird angezeigt:

Output<!DOCTYPE html>
<html>
 <head>
   <title>Welcome to nginx!</title>
...
    Commercial support is available at
    <a href="http://nginx.com/">nginx.com</a>.</p>
   <p><em>Thank you for using nginx.</em></p>
 </body>
</html>

Sie haben einen Pod und einen Service definiert. Betrachten wir nun die Skalierung mit Replikatsätzen.

Schritt 5 - Skalieren von Pods durch das Replikatset

Ein Replikatsatz stellt sicher, dass mindestens eine Mindestanzahl von Pods im Cluster ausgeführt wird. Löschen Sie den aktuellen Pod und erstellen Sie drei Pods über das Replikatset neu.

Löschen Sie zunächst den vorhandenen Pod.

kubectl delete pod web-pod

Outputpod "web-pod" deleted

Erstellen Sie nun eine neue Replikatsatzdeklaration. Die Definition des Replikatsatzes ist identisch mit einem Pod. Der Hauptunterschied besteht darin, dass es das Replikatelement enthält, das die Anzahl der auszuführenden Pods definiert. Wie ein Pod enthält er auch Labels als Metadaten, die bei der Serviceerkennung hilfreich sind.

Erstellen Sie die Datei "+ Simple-RS.yml +" und fügen Sie den folgenden Code zur Datei hinzu:

Simple-RS.yml

apiVersion: apps/v1beta2
kind: ReplicaSet
metadata:
 name: web-rs
 labels:
   name: web
   env: dev
spec:
 replicas: 3
 selector:
   matchLabels:
     name: web
 template:
   metadata:
     labels:
       name: web
       env: dev
   spec:
     containers:
     - name: myweb
       image: nginx
         ports:
           - containerPort: 80
             name: http
             protocol: TCP

Speichern und schließen Sie die Datei.

Erstellen Sie nun das Replikatset:

kubectl create -f Simple-RS.yml

Outputreplicaset "web-rs" created

Dann überprüfen Sie die Anzahl der Pods:

kubectl get pods

OutputNAME           READY     STATUS    RESTARTS   AGE
web-rs-htb58   1/1       Running   0          38s
web-rs-khtld   1/1       Running   0          38s
web-rs-p5lzg   1/1       Running   0          38s

Wenn wir über den NodePort auf den Service zugreifen, wird die Anfrage an einen der vom Replikatsatz verwalteten Pods gesendet.

Testen Sie die Funktionalität eines Replikatsets, indem Sie einen der Pods löschen und sehen, was passiert:

kubectl delete pod web-rs-p5lzg

Outputpod "web-rs-p5lzg" deleted

Schauen Sie sich die Schoten noch einmal an:

kubectl get pods

OutputNAME           READY     STATUS              RESTARTS   AGE
web-rs-htb58   1/1       Running             0          2m
web-rs-khtld   1/1       Running             0          2m

web-rs-p5lzg   1/1       Running             0          2m
web-rs-p5lzg   0/1       Terminating         0          2m

Sobald der Pod gelöscht wird, hat Kubernetes einen neuen erstellt, um sicherzustellen, dass die gewünschte Anzahl beibehalten wird.

Schauen wir uns nun Bereitstellungen an.

Schritt 6 - Umgang mit Bereitstellungen

Obwohl Sie Container als Pods und Replikatsätze bereitstellen können, erleichtern Bereitstellungen das Aktualisieren und Patchen Ihrer Anwendung. Sie können einen Pod mithilfe einer Bereitstellung direkt aktualisieren, was mit einem Replikatsatz nicht möglich ist. Dadurch ist es möglich, eine neue Version einer Anwendung mit minimalen Ausfallzeiten bereitzustellen. Sie bieten PaaS-ähnliche Funktionen für das Anwendungsmanagement.

Löschen Sie den vorhandenen Replikatsatz, bevor Sie eine Bereitstellung erstellen. Dadurch werden auch die zugehörigen Pods gelöscht:

kubectl delete rs web-rs

Outputreplicaset "web-rs" deleted

Definieren Sie nun eine neue Bereitstellung. Erstellen Sie die Datei "+ Simple-Deployment.yaml +" und fügen Sie den folgenden Code hinzu:

Simple-Deployment.yaml

apiVersion: apps/v1beta2
kind: Deployment
metadata:
 name: web-dep
 labels:
   name: web
   env: dev
spec:
 replicas: 3
 selector:
   matchLabels:
     name: web
 template:
   metadata:
     labels:
       name: web
   spec:
     containers:
     - name: myweb
       image: nginx
       ports:
       - containerPort: 80

Erstellen Sie eine Bereitstellung und überprüfen Sie die Erstellung.

kubectl create -f Simple-Deployment.yml

Outputdeployment "web-dep" created

Anzeigen der Bereitstellungen:

kubectl get deployments

OutputNAME      DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
web-dep   3         3         3            3           1m

Da die Bereitstellung zur Erstellung von Pods führt, werden gemäß der Replikatdeklaration in der YAML-Datei drei Pods ausgeführt.

kubectl get pods

OutputNAME                       READY     STATUS    RESTARTS   AGE
web-dep-8594f5c765-5wmrb   1/1       Running   0          2m
web-dep-8594f5c765-6cbsr   1/1       Running   0          2m
web-dep-8594f5c765-sczf8   1/1       Running   0          2m

Der zuvor erstellte Service leitet die Anforderungen weiterhin an die vom Deployment erstellten Pods weiter. Dies liegt an den Beschriftungen, die dieselben Werte wie die ursprüngliche Pod-Definition enthalten.

Bereinigen Sie die Ressourcen, indem Sie Deployment and Service löschen.

kubectl delete deployment web-dep

Outputdeployment "web-dep" deleted

kubectl delete service web-svc

Outputservice "web-svc" deleted

Weitere Informationen zu Bereitstellungen finden Sie in der Kubernetes documentation.

Fazit

In diesem Lernprogramm haben Sie die Grundbausteine von Kubernetes beim Bereitstellen eines Nginx-Webservers mit einem Pod, einem Service, einem Replikatsatz und einer Bereitstellung erläutert.

Im nächsten Teil dieser Serie erfahren Sie, wie Sie eine Multi-Container-Anwendung packen, bereitstellen, skalieren und verwalten.

TOC