Anwendungen auf Kubernetes bereitstellen

Einführung

In diesem Lab lernen Sie, wie Sie Anwendungen auf einem Kubernetes-Cluster bereitstellen. Wir beginnen mit der Einrichtung einer lokalen Kubernetes-Umgebung mithilfe von Minikube. Anschließend erkunden Sie essentielle kubectl-Befehle, um mit Ihrem Cluster zu interagieren und Kubernetes-Ressourcen zu verwalten. Danach erstellen Sie eine einfache YAML-Manifestdatei, wenden sie auf Ihren Cluster an und überprüfen den Status der Bereitstellung. Abschließend lernen Sie, wie Sie die bereitgestellte Anwendung über kubectl proxy zugreifen können.

Dieses Lab behandelt grundlegende Kubernetes-Fähigkeiten, einschließlich der Cluster-Einrichtung, der grundlegenden Ressourcenverwaltung und der Anwendungsbereitstellung. Am Ende dieses Labs werden Sie einen soliden Überblick darüber haben, wie Sie mit Kubernetes arbeiten und Ihre eigenen Anwendungen bereitstellen können.

Skills Graph

Starten des Kubernetes-Clusters

In diesem Schritt starten wir einen lokalen Kubernetes-Cluster mit Minikube. Minikube ist ein ausgezeichnetes Tool für die Entwicklung und das Lernen von Kubernetes, da es Ihnen ermöglicht, einen Ein-Knoten-Kubernetes-Cluster auf Ihrem lokalen Rechner auszuführen. Anschließend überprüfen wir, ob der Cluster korrekt läuft und einsatzbereit ist.

Öffnen Sie zunächst Ihr Terminal. Hier geben Sie die Befehle ein, um mit Ihrem Computer zu interagieren. Um den Minikube-Cluster zu starten, geben Sie den folgenden Befehl ein und drücken Sie die Eingabetaste:

minikube start

Dieser Befehl initiiert den Prozess der Erstellung und des Starts Ihres lokalen Kubernetes-Clusters. Minikube lädt die erforderlichen Komponenten herunter und konfiguriert Ihren Cluster. Sie werden im Terminal Ausgaben sehen, während Minikube startet. Hier ist ein Beispiel für die möglichen Ausgaben:

😄  minikube v1.29.0 on Ubuntu 22.04
✨  Automatically selected the docker driver
📌  Using Docker driver with root permissions
🔥  Creating kubernetes in kubernetes cluster
🔄  Restarting existing kubernetes cluster
🐳  Preparing Kubernetes v1.26.1 on Docker 20.10.23...
🚀  Launching Kubernetes...
🌟  Enabling addons: storage-provisioner, default-storageclass
🏄  Done! kubectl is now configured to use "minikube" cluster and "default" namespace

Sobald Minikube gestartet ist, überprüfen wir, ob es läuft und ob der Kubernetes-Cluster in Minikube einsatzbereit ist. Führen Sie die folgenden Befehle nacheinander aus und drücken Sie nach jedem Befehl die Eingabetaste:

minikube status
kubectl get nodes

Der Befehl minikube status gibt Ihnen den Status von Minikube selbst aus. Der Befehl kubectl get nodes kommuniziert mit Ihrem Kubernetes-Cluster und ruft Informationen über die Knoten (Computer) in Ihrem Cluster ab. Da Minikube ein Ein-Knoten-Cluster ist, sollten Sie einen Knoten in der Liste sehen.

Hier ist ein Beispiel für die möglichen Ausgaben:

minikube
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured

NAME       STATUS   ROLES           AGE   VERSION
minikube   Ready    control-plane   1m    v1.26.1

Lassen Sie uns analysieren, was diese Ausgabe uns mitteilt:

1. Der minikube-Status zeigt Running für host, kubelet und apiserver an. Dies zeigt an, dass die Kernkomponenten von Minikube korrekt laufen.
2. kubectl get nodes zeigt einen Knoten namens minikube mit einem STATUS von Ready an. Ready bedeutet, dass dieser Knoten Anwendungen ausführen kann. control-plane unter ROLES zeigt an, dass dieser Knoten als Steuerungsebene für den Kubernetes-Cluster fungiert und den Cluster verwaltet und orchestriert.

Diese Befehle bestätigen Folgendes:

1. Minikube läuft auf Ihrem Rechner.
2. Ein lokaler Kubernetes-Cluster wurde in Minikube erstellt.
3. Der Kubernetes-Cluster befindet sich im Zustand Ready und ist einsatzbereit.
4. Sie haben einen Ein-Knoten-Kubernetes-Cluster, bei dem der minikube-Knoten als Steuerungsebene fungiert.

Grundlegende kubectl-Befehle und Syntax lernen

In diesem Schritt werden Sie die grundlegenden kubectl-Befehle kennenlernen. kubectl ist das Befehlszeilentool, mit dem Sie mit Ihrem Kubernetes-Cluster interagieren können. Es ist unerlässlich für die Verwaltung von Kubernetes-Ressourcen. Wir werden zeigen, wie Sie kubectl verwenden, um Ressourcen anzuzeigen und die grundlegende Verwaltung von Kubernetes-Objekten zu verstehen.

Beginnen wir mit der Erkundung der Namespaces in Ihrem Kubernetes-Cluster. Namespaces sind eine Möglichkeit, Ihre Kubernetes-Ressourcen zu organisieren. Standardmäßig verfügen Kubernetes-Cluster über mehrere Namespaces für Systemkomponenten und Benutzerressourcen. Um eine Liste der Namespaces anzuzeigen, führen Sie den folgenden Befehl aus:

kubectl get namespaces

Dieser Befehl listet alle Namespaces auf, die in Ihrem Cluster verfügbar sind. Beispielausgabe:

NAME              STATUS   AGE
default           Active   10m
kube-node-lease   Active   10m
kube-public       Active   10m
kube-system       Active   10m

Normalerweise werden Sie mindestens diese Standard-Namespaces sehen:

• default: Der Standard-Namespace für benutzererstellte Ressourcen, wenn kein anderer Namespace angegeben wird.
• kube-node-lease: Wird für Knoten-Leases verwendet, die der Steuerungsebene helfen, die Gesundheit der Knoten zu verfolgen.
• kube-public: Vorgesehen für Ressourcen, die öffentlich zugänglich sein sollten (wird jedoch selten für sensible Informationen verwendet).
• kube-system: Enthält systemweite Ressourcen, wie z. B. Kern-Kubernetes-Komponenten.

Als nächstes lassen Sie uns die Systemkomponenten anzeigen, die im kube-system-Namespace laufen. Viele Kern-Kubernetes-Komponenten laufen als Pods in diesem Namespace. Um Pods in einem bestimmten Namespace anzuzeigen, verwenden Sie die Option -n oder --namespace gefolgt vom Namen des Namespaces. Führen Sie den folgenden Befehl aus, um die Pods im kube-system-Namespace anzuzeigen:

kubectl get pods -n kube-system

Dieser Befehl listet alle Pods auf, die im kube-system-Namespace laufen. Beispielausgabe:

NAME                               READY   STATUS    RESTARTS   AGE
coredns-787d4945fb-j8rhx           1/1     Running   0          15m
etcd-minikube                       1/1     Running   0          15m
kube-apiserver-minikube             1/1     Running   0          15m
kube-controller-manager-minikube    1/1     Running   0          15m
kube-proxy-xb9rz                    1/1     Running   0          15m
kube-scheduler-minikube             1/1     Running   0          15m
storage-provisioner                 1/1     Running   0          15m

Diese Ausgabe zeigt die Namen der Pods, ihren READY-Status (wie viele Container im Pod insgesamt bereit sind), ihren STATUS (z. B. Running), wie oft sie RESTARTED wurden und ihre AGE. Dies sind die wesentlichen Komponenten, die Kubernetes funktionieren lassen.

Jetzt lassen Sie uns einige grundlegende kubectl-Befehlsmuster erkunden. Die allgemeine Syntax für kubectl-Befehle lautet:

kubectl [command] [TYPE] [NAME] [flags]

Lassen Sie uns dies aufschlüsseln:

• kubectl: Das Befehlszeilentool selbst.
• [command]: Gibt an, welche Aktion Sie ausführen möchten. Häufige Befehle sind:
  • get: Zeigt eine oder mehrere Ressourcen an.
  • describe: Zeigt Details zu einer bestimmten Ressource an.
  • create: Erstellt eine neue Ressource.
  • delete: Löscht Ressourcen.
  • apply: Wendet eine Konfiguration auf eine Ressource an. Wir werden dies später häufig verwenden.
• [TYPE]: Gibt den Kubernetes-Ressourcentyp an, mit dem Sie interagieren möchten. Häufige Ressourcentypen sind:
  • pods: Die kleinsten deployierbaren Einheiten in Kubernetes.
  • deployments: Verwalten von Pod-Sets für Skalierung und Updates.
  • services: Stellen Anwendungen bereit, die in Pods laufen.
  • nodes: Die Worker-Maschinen in Ihrem Kubernetes-Cluster.
  • namespaces: Logische Gruppierungen von Ressourcen.
• [NAME]: Der Name einer bestimmten Ressource. Dies ist optional; wenn Sie den Namen weglassen, wird kubectl auf alle Ressourcen des angegebenen Typs angewendet.
• [flags]: Optionale Flags, um das Verhalten des Befehls zu ändern (z. B. -n <namespace>, -o wide).

Lassen Sie uns einige Beispiele betrachten:

## Alle Ressourcen im Standard-Namespace abrufen
kubectl get all

## Einen bestimmten Ressourcentyp beschreiben (den 'minikube'-Knoten)
kubectl describe nodes minikube

Der Befehl kubectl get all ruft Informationen über alle Ressourcentypen (Services, Deployments, Pods usw.) im default-Namespace ab. Eine Beispielausgabe könnte wie folgt aussehen:

NAME                 TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
service/kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP   20m

Dies zeigt, dass im default-Namespace ein service namens kubernetes vorhanden ist.

Der Befehl kubectl describe nodes minikube liefert viele detaillierte Informationen über den minikube-Knoten, einschließlich seines Status, seiner Kapazität, seiner Adressen und vieles mehr. Dies ist hilfreich, um den Zustand und die Konfiguration Ihrer Knoten zu verstehen.

Diese Befehle helfen Ihnen dabei:

1. Die Ressourcen in Ihrem Kubernetes-Cluster anzuzeigen.
2. Detaillierte Informationen über Clusterkomponenten und ihren aktuellen Status zu erhalten.
3. Die grundlegende Befehlsstruktur und Syntax von kubectl zu verstehen.

Erstellen eines einfachen YAML-Manifests

Bevor Sie Ihr erstes YAML-Manifest erstellen, ist es wichtig, die wichtigsten Kubernetes-Objekte zu verstehen, mit denen Sie arbeiten werden. Diese Objekte sind die Bausteine für die Verwaltung und Orchestrierung Ihrer Anwendungen in Kubernetes.

Grundlegendes zu Kubernetes-Objekten

• Pod: Die grundlegendste Einheit in Kubernetes. Ein Pod ist wie eine Box, die einen oder mehrere Container enthalten kann. Diese Container in einem Pod teilen sich dasselbe Netzwerk und den gleichen Speicher. Stellen Sie sich einen Pod als eine einzelne Instanz Ihrer Anwendung vor.
• Deployment: Deployments werden verwendet, um Pods zu verwalten. Sie stellen sicher, dass eine gewünschte Anzahl von Pod-Replikaten jederzeit ausgeführt wird. Wenn ein Pod fehlschlägt, ersetzt ein Deployment ihn automatisch. Deployments behandeln auch Updates Ihrer Anwendung auf kontrollierte Weise, wie z. B. Rolling Updates.
• Service: Services bieten eine stabile Möglichkeit, auf Ihre in Pods ausgeführte Anwendung zuzugreifen. Da Pods erstellt und zerstört werden können, können sich ihre IP-Adressen ändern. Ein Service bietet eine feste IP-Adresse und einen DNS-Namen, der immer auf die Gruppe von Pods zeigt, die er verwaltet. Dies ermöglicht es anderen Teilen Ihrer Anwendung oder externen Benutzern, zuverlässig auf Ihre Anwendung zuzugreifen, ohne die einzelnen Pod-IPs verfolgen zu müssen.

Hier ist ein Diagramm, das die Beziehungen zwischen diesen Objekten veranschaulicht:

Das Verständnis dieser Objekte ist von entscheidender Bedeutung, da Sie ihren gewünschten Zustand und ihre Konfiguration mithilfe von YAML-Manifesten definieren werden.

Überblick über YAML-Manifeste

Ein YAML-Manifest in Kubernetes ist eine Datei im YAML-Format, die die Kubernetes-Objekte beschreibt, die Sie erstellen oder verwalten möchten. YAML ist eine menschenlesbare Daten-Serialisierungssprache. Die Verwendung von YAML für Kubernetes-Manifeste bietet mehrere Vorteile:

1. Deklarative Verwaltung: Sie beschreiben den gewünschten Zustand Ihrer Ressourcen in der YAML-Datei (z. B. "Ich möchte, dass 3 Replikate meiner Anwendung ausgeführt werden"). Kubernetes arbeitet dann daran, den tatsächlichen Zustand mit Ihrem gewünschten Zustand übereinzustimmen. Dies wird als deklarative Verwaltung bezeichnet.
2. Versionskontrolle: YAML-Dateien sind textbasiert und können einfach in Versionskontrollsystemen wie Git gespeichert werden. Dies ermöglicht es Ihnen, Änderungen an Ihren Kubernetes-Konfigurationen im Laufe der Zeit zu verfolgen, auf frühere Konfigurationen zurückzukehren und mit anderen zu kollaborieren.
3. Wiederverwendbarkeit und Portabilität: Sie können YAML-Manifeste in verschiedenen Umgebungen (Entwicklung, Test, Produktion) mit minimalen Änderungen wiederverwenden. Dies macht Ihre Bereitstellungen konsistenter und reproduzierbarer.

Nachdem Sie nun die Grundlagen von Kubernetes-Objekten und YAML-Manifesten verstanden haben, sind Sie bereit, Ihr erstes Manifest zu erstellen.

Erstellen eines YAML-Manifests

Navigieren Sie zunächst in Ihr Projektverzeichnis. Es wird angenommen, dass Sie ein project-Verzeichnis in Ihrem Home-Verzeichnis (~) haben. Wenn Sie es nicht haben, erstellen Sie es jetzt mit mkdir project. Ändern Sie dann Ihr aktuelles Verzeichnis in project mit cd project:

cd ~/project

Erstellen Sie als Nächstes ein neues Verzeichnis, um Ihre Kubernetes-Manifeste zu speichern. Nennen wir es k8s-manifests. Verwenden Sie den mkdir-Befehl, um das Verzeichnis zu erstellen, und dann cd, um in es zu wechseln:

mkdir -p k8s-manifests
cd k8s-manifests

Nun werden Sie Ihre erste YAML-Manifestdatei erstellen. Beginnen wir mit einem einfachen Manifest für einen NGINX-Pod. NGINX ist ein beliebter Webserver. Wir werden einen Pod erstellen, der einen einzelnen NGINX-Container ausführt. Verwenden Sie den nano-Texteditor, um eine Datei namens nginx-pod.yaml zu erstellen:

nano nginx-pod.yaml

nano ist ein einfacher Texteditor, der in Ihrem Terminal läuft. Sobald nano geöffnet ist, fügen Sie den folgenden Inhalt in die Datei ein:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx
spec:
  containers:
    - name: nginx
      image: nginx:latest
      ports:
        - containerPort: 80

Lassen Sie uns jeden Teil dieses YAML-Manifests verstehen:

• apiVersion: v1: Gibt die Kubernetes-API-Version an, die für die Erstellung dieses Objekts verwendet werden soll. v1 ist die Kern-API-Gruppe und wird für grundlegende Objekte wie Pods, Services und Namespaces verwendet.
• kind: Pod: Gibt an, dass Sie eine Pod-Ressource definieren.
• metadata:: Enthält Daten über den Pod, wie z. B. seinen Namen und Labels.
  • name: nginx-pod: Setzt den Namen des Pods auf nginx-pod. So werden Sie sich innerhalb von Kubernetes auf diesen Pod beziehen.
  • labels:: Labels sind Schlüssel-Wert-Paare, die an Objekte angehängt werden. Sie werden verwendet, um Objekte zu organisieren und Teilmengen von Objekten auszuwählen. Hier fügen wir ein Label app: nginx diesem Pod hinzu.
• spec:: Beschreibt den gewünschten Zustand des Pods.
  • containers:: Eine Liste der Container, die innerhalb des Pods ausgeführt werden sollen. In diesem Fall haben wir nur einen Container.
    • - name: nginx: Setzt den Namen des Containers auf nginx.
    • image: nginx:latest: Gibt das Container-Image an, das verwendet werden soll. nginx:latest bezieht sich auf die neueste Version des NGINX-Docker-Images von Docker Hub.
    • ports:: Eine Liste der Ports, die dieser Container verfügbar machen wird.
      • - containerPort: 80: Gibt an, dass der Container Port 80 verfügbar machen wird. Port 80 ist der Standard-HTTP-Port.

Nachdem Sie den Inhalt eingefügt haben, speichern Sie die Datei und verlassen Sie nano. Um dies zu tun, drücken Sie Ctrl+X (verlassen), geben Sie dann Y ein (ja, um zu speichern) und drücken Sie schließlich Enter, um den Dateinamen zu bestätigen und zu speichern.

Nachdem Sie nun Ihre nginx-pod.yaml-Datei erstellt haben, müssen Sie sie auf Ihren Kubernetes-Cluster anwenden, um den Pod zu erstellen. Verwenden Sie den kubectl apply-Befehl mit der -f-Option, die die Datei mit dem Manifest angibt:

kubectl apply -f nginx-pod.yaml

Dieser Befehl sendet das Manifest an Ihren Kubernetes-Cluster, und Kubernetes wird den Pod wie definiert erstellen. Sie sollten eine Ausgabe ähnlich der folgenden sehen:

pod/nginx-pod created

Um zu überprüfen, ob der Pod erstellt und ausgeführt wurde, verwenden Sie den kubectl get pods-Befehl. Dies listet alle Pods im Standard-Namespace auf. Sie können auch kubectl describe pod nginx-pod verwenden, um detaillierte Informationen über den nginx-pod zu erhalten. Führen Sie diese Befehle aus:

kubectl get pods
kubectl describe pod nginx-pod

Beispielausgabe für kubectl get pods:

NAME        READY   STATUS    RESTARTS   AGE
nginx-pod   1/1     Running   0          1m

Diese Ausgabe zeigt, dass der nginx-pod READY ist (1 von 1 Container ist bereit) und sein STATUS Running ist. Dies bedeutet, dass Ihr NGINX-Pod erfolgreich erstellt und ausgeführt wird.

Nun erstellen wir ein Manifest für eine komplexere Ressource: ein Deployment. Ein Deployment verwaltet eine Gruppe von Pods und stellt sicher, dass die gewünschte Anzahl von Replikaten ausgeführt wird. Erstellen Sie eine neue Datei namens nginx-deployment.yaml mit nano:

nano nginx-deployment.yaml

Fügen Sie den folgenden Inhalt in nginx-deployment.yaml ein:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:latest
          ports:
            - containerPort: 80

Lassen Sie uns die wichtigsten Unterschiede und neuen Teile im Vergleich zum nginx-pod.yaml-Manifest hervorheben:

• apiVersion: apps/v1: Für Deployments verwenden Sie die apps/v1-API-Version, die Teil der apps-API-Gruppe ist und höhere Anwendungsverwaltungsressourcen behandelt.
• kind: Deployment: Gibt an, dass Sie eine Deployment-Ressource definieren.
• spec:: Der spec-Abschnitt für ein Deployment ist komplexer, da er definiert, wie das Deployment Pods verwalten soll.
  • replicas: 3: Dies ist neu. Es gibt an, dass Sie 3 Replikate (Kopien) Ihres Pods ausführen möchten. Das Deployment stellt sicher, dass es immer 3 Pods gibt, die den in der template definierten Kriterien entsprechen.
  • selector:: Ein Selektor wird vom Deployment verwendet, um zu identifizieren, welche Pods es verwalten soll.
    • matchLabels:: Definiert die Labels, die Pods haben müssen, um von diesem Deployment ausgewählt zu werden. Hier werden Pods mit dem Label app: nginx ausgewählt.
  • template:: Die template definiert die Pod-Spezifikation, die das Deployment verwendet, um neue Pods zu erstellen. Es ist im Wesentlichen dieselbe Pod-Definition wie in unserem nginx-pod.yaml-Beispiel, einschließlich metadata.labels und spec.containers. Wichtig: Die hier in template.metadata.labels definierten Labels müssen mit selector.matchLabels übereinstimmen, damit das Deployment diese Pods verwalten kann.

Speichern Sie und verlassen Sie nano (Ctrl+X, Y, Enter).

Wenden Sie nun dieses Deployment-Manifest auf Ihren Cluster an:

kubectl apply -f nginx-deployment.yaml

Sie sollten eine Ausgabe wie die folgende sehen:

deployment.apps/nginx-deployment created

Überprüfen Sie das Deployment und die von ihm erstellten Pods. Verwenden Sie kubectl get deployments, um den Status des Deployments zu überprüfen, und kubectl get pods, um die Pods anzuzeigen.

kubectl get deployments
kubectl get pods

Beispielausgabe:

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3/3     3            3           1m

NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-xxx-yyy            1/1     Running   0          1m
nginx-deployment-xxx-zzz            1/1     Running   0          1m
nginx-deployment-xxx-www            1/1     Running   0          1m

• kubectl get deployments zeigt, dass das nginx-deployment READY 3/3, UP-TO-DATE 3 und AVAILABLE 3 hat. Dies bedeutet, dass das Deployment erfolgreich 3 Pods erstellt und verwaltet, und alle sind bereit und verfügbar.
• kubectl get pods listet jetzt drei Pods auf, deren Namen mit nginx-deployment- beginnen. Dies sind die Pods, die von Ihrem nginx-deployment erstellt und verwaltet werden.

Anwenden des YAML-Manifests

In diesem Schritt werden Sie den kubectl apply-Befehl detaillierter untersuchen und verschiedene Methoden zum Anwenden von Kubernetes-Manifesten lernen. Basierend auf den YAML-Dateien aus dem vorherigen Schritt werden wir verschiedene Techniken zum Anwenden von Manifesten demonstrieren.

Stellen Sie zunächst sicher, dass Sie sich im richtigen Verzeichnis befinden:

cd ~/project/k8s-manifests

Erstellen wir ein neues Unterverzeichnis, um unsere Manifeste noch besser zu organisieren. Erstellen Sie ein Verzeichnis namens manifests und navigieren Sie hinein:

mkdir -p manifests
cd manifests

Nun erstellen wir ein Manifest für eine einfache Webanwendung, das sowohl ein Deployment als auch einen Service in einer einzigen Datei enthält. Erstellen Sie eine neue Datei namens web-app.yaml mit nano:

nano web-app.yaml

Fügen Sie den folgenden Inhalt zu web-app.yaml hinzu:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: nginx:alpine
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  selector:
    app: web
  type: ClusterIP
  ports:
    - port: 80
      targetPort: 80

Dieses Manifest definiert zwei Kubernetes-Ressourcen in einer einzigen Datei, getrennt durch ---. Dies ist eine übliche Methode, um verwandte Ressourcen zusammenzufassen. Lassen Sie uns die Neuerungen aufschlüsseln:

• Mehrere Ressourcen in einer Datei: Die Datei web-app.yaml enthält jetzt zwei separate Kubernetes-Ressourcendefinitionen: ein Deployment und einen Service. Das Trennzeichen --- wird verwendet, um sie voneinander zu unterscheiden.
• kind: Service: Dies definiert eine Service-Ressource.
  • spec.selector.app: web: Dieser Service wird auf Pods abzielen, die das Label app: web haben. Dies stimmt mit den Labels überein, die wir für die von der web-app-Deployment erstellten Pods festgelegt haben.
  • spec.type: ClusterIP: Gibt den Service-Typ als ClusterIP an. Dies bedeutet, dass der Service über eine interne IP-Adresse innerhalb des Clusters verfügbar gemacht wird und normalerweise für die Kommunikation zwischen Services innerhalb des Clusters verwendet wird.
  • spec.ports: Definiert, wie der Service Ports auf die Ziel-Pods abbildet.
    • port: 80: Der Port am Service selbst, auf den Sie zugreifen werden.
    • targetPort: 80: Der Port auf den Ziel-Pods, an den der Service den Datenverkehr weiterleiten wird.

Nun wenden wir dieses Manifest mit verschiedenen Methoden an.

Methode 1: Anwenden der gesamten Datei

Dies ist die häufigste Methode, um ein Manifest anzuwenden. Verwenden Sie kubectl apply -f gefolgt vom Dateinamen:

kubectl apply -f web-app.yaml

Dieser Befehl wird sowohl das Deployment als auch den Service erstellen, die in web-app.yaml definiert sind. Sie sollten eine Ausgabe wie die folgende sehen:

deployment.apps/web-app created
service/web-service created

Methode 2: Anwenden aus einem Verzeichnis

Sie können alle Manifeste in einem Verzeichnis auf einmal anwenden. Wenn Sie mehrere Manifestdateien im manifests-Verzeichnis haben, können Sie sie alle anwenden, indem Sie das Verzeichnis anstelle einer bestimmten Datei angeben:

kubectl apply -f.

Der Punkt . repräsentiert das aktuelle Verzeichnis. kubectl sucht nach YAML-Dateien in diesem Verzeichnis und wendet sie alle an. Dies ist nützlich, wenn Sie Ihre Manifeste in mehrere Dateien innerhalb eines Verzeichnisses organisiert haben.

Methode 3: Anwenden von einer URL (Optional)

kubectl apply kann auch Manifeste direkt von einer URL anwenden. Dies ist nützlich, um Beispielanwendungen oder Konfigurationen, die online gehostet werden, schnell bereitzustellen. Beispielsweise können Sie die Redis-Master-Deployment aus dem Kubernetes-Beispiel-Repository bereitstellen:

kubectl apply -f https://raw.githubusercontent.com/kubernetes/examples/master/guestbook/redis-master-deployment.yaml

Dies lädt das Manifest von der URL herunter und wendet es auf Ihren Cluster an. Hinweis: Seien Sie vorsichtig, wenn Sie Manifeste von nicht vertrauenswürdigen URLs anwenden, da sie möglicherweise Ihren Cluster ändern können.

Lassen Sie uns einige zusätzliche Optionen für kubectl apply untersuchen.

Dry Run

Sie können die Option --dry-run=client verwenden, um das Anwenden eines Manifests zu simulieren, ohne tatsächlich Änderungen am Cluster vorzunehmen. Dies ist nützlich, um zu überprüfen, ob Ihr Manifest gültig ist und um zu sehen, welche Ressourcen erstellt oder geändert würden:

kubectl apply -f web-app.yaml --dry-run=client

Dieser Befehl gibt aus, was erstellt oder geändert würde, aber er wendet die Änderungen nicht tatsächlich auf Ihren Cluster an.

Ausführliche Ausgabe

Für eine detailliertere Ausgabe von kubectl apply können Sie die Option -v gefolgt von einem Ausführlichkeitsgrad verwenden (z. B. -v=7). Höhere Ausführlichkeitsgrade liefern detailliertere Informationen, was für das Debugging hilfreich sein kann:

kubectl apply -f web-app.yaml -v=7

Dies gibt viel mehr Informationen über die API-Anforderungen aus, die gestellt werden, und die Verarbeitung des Manifests.

Überprüfen Sie die Ressourcen, die durch das Anwenden von web-app.yaml erstellt wurden. Verwenden Sie kubectl get deployments und kubectl get services, um die Deployments und Services in Ihrem Cluster aufzulisten:

## Auflisten der Deployments
kubectl get deployments

## Auflisten der Services
kubectl get services

## Beschreiben des Deployments, um mehr Details zu sehen
kubectl describe deployment web-app

Beispielausgabe für kubectl get deployments:

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3/3     3            3           3m33s
redis-master       0/1     1            0           23s
web-app            2/2     2            2           42s

Beispielausgabe für kubectl get services:

NAME          TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
kubernetes    ClusterIP   10.96.0.1       <none>        443/TCP   8m28s
web-service   ClusterIP   10.106.220.33   <none>        80/TCP    46s

Beachten Sie, dass Sie jetzt ein web-app-Deployment mit 2/2 READY-Replikaten und einen web-service vom Typ ClusterIP haben.

Lassen Sie uns kurz über den Unterschied zwischen deklarativer und imperativer Verwaltung in Kubernetes sprechen, insbesondere im Zusammenhang mit kubectl apply und kubectl create.

• kubectl apply: Verwendet einen deklarativen Ansatz. Sie definieren den gewünschten Zustand in Ihren Manifestdateien, und kubectl apply versucht, diesen Zustand zu erreichen. Wenn Sie kubectl apply mehrmals mit demselben Manifest ausführen, wird Kubernetes nur Änderungen vornehmen, wenn es Unterschiede zwischen dem gewünschten Zustand im Manifest und dem aktuellen Zustand im Cluster gibt. kubectl apply wird im Allgemeinen für die Verwaltung von Kubernetes-Ressourcen empfohlen, da es robuster und einfacher für die Verwaltung von Änderungen im Laufe der Zeit ist. Es verfolgt die Konfiguration Ihrer Ressourcen und ermöglicht inkrementelle Updates.
• kubectl create: Verwendet einen imperativen Ansatz. Sie geben Kubernetes direkt an, eine Ressource zu erstellen. Wenn Sie versuchen, kubectl create für eine Ressource auszuführen, die bereits existiert, führt dies normalerweise zu einem Fehler. kubectl create ist weniger flexibel für die Verwaltung von Updates und Änderungen im Vergleich zu kubectl apply.

In den meisten Fällen, insbesondere für die Verwaltung von Anwendungsbereitstellungen, ist kubectl apply die bevorzugte und empfohlene Methode aufgrund ihrer deklarativen Natur und der besseren Verwaltung von Updates und Konfigurationen.

Überprüfen des Deployment-Status

In diesem Schritt lernen Sie, wie Sie den Status von Kubernetes-Deployments und anderen Ressourcen mithilfe verschiedener kubectl-Befehle untersuchen und überprüfen können. Sie werden verschiedene Methoden kennenlernen, um Informationen über Ihre laufenden Anwendungen und deren Zustand innerhalb des Kubernetes-Clusters zu sammeln.

Stellen Sie zunächst sicher, dass Sie sich im manifests-Verzeichnis Ihres Projekts befinden:

cd ~/project/k8s-manifests/manifests

Beginnen wir damit, alle Deployments im aktuellen Namespace aufzulisten (dies ist standardmäßig default, es sei denn, Sie haben ihn geändert). Verwenden Sie kubectl get deployments:

kubectl get deployments

Dieser Befehl bietet einen knappen Überblick über Ihre Deployments. Beispielausgabe:

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3/3     3            3           4m44s
redis-master       1/1     1            1           94s
web-app            2/2     2            2           113s

Hier ist die Bedeutung jeder Spalte:

• NAME: Der Name des Deployments.
• READY: Zeigt die Anzahl der bereitgestellten Replikate im Vergleich zur gewünschten Anzahl der Replikate an (z. B. 3/3 bedeutet, dass 3 gewünschte Replikate bereit sind).
• UP-TO-DATE: Gibt an, wie viele Replikate auf den neuesten gewünschten Zustand aktualisiert wurden.
• AVAILABLE: Zeigt an, wie viele Replikate derzeit verfügbar sind, um Datenverkehr zu bedienen.
• AGE: Wie lange das Deployment bereits läuft.

Um detailliertere Informationen in einem erweiterten Format zu erhalten, können Sie die Option -o wide mit kubectl get deployments verwenden:

kubectl get deployments -o wide

Beispielausgabe:

NAME               READY   UP-TO-DATE   AVAILABLE   AGE     CONTAINERS   IMAGES                      SELECTOR
nginx-deployment   3/3     3            3           4m58s   nginx        nginx:latest                app=nginx
redis-master       1/1     1            1           108s    master       registry.k8s.io/redis:e2e   app=redis,role=master,tier=backend
web-app            2/2     2            2           2m7s    web          nginx:alpine                app=web

Die -o wide-Ausgabe enthält zusätzliche Spalten wie CONTAINERS, IMAGES und SELECTOR, die mehr Informationen über das Deployment liefern.

Um die Pods zu untersuchen, die Teil eines bestimmten Deployments sind, können Sie Labels verwenden. Denken Sie daran, dass wir in unserem web-app-Deployment-Manifest das Label app: web für die Pods festgelegt haben. Sie können dieses Label verwenden, um Pods mit kubectl get pods -l <label_selector> zu filtern. Um die Pods anzuzeigen, die mit dem web-app-Deployment verknüpft sind, führen Sie aus:

kubectl get pods -l app=web

Beispielausgabe:

NAME                      READY   STATUS    RESTARTS   AGE
web-app-xxx-yyy           1/1     Running   0          10m
web-app-xxx-zzz           1/1     Running   0          10m

Dies listet die Pods auf, die dem Label-Selektor app=web entsprechen, also die Pods, die vom web-app-Deployment verwaltet werden.

Für ausführliche Informationen über ein bestimmtes Deployment verwenden Sie kubectl describe deployment <deployment_name>. Beschreiben wir das web-app-Deployment:

kubectl describe deployment web-app

kubectl describe liefert eine Fülle von Informationen über das Deployment, darunter:

• Name, Namespace, CreationTimestamp, Labels, Annotations: Grundlegende Metadaten über das Deployment.
• Selector: Der Label-Selektor, der verwendet wird, um die vom Deployment verwalteten Pods zu identifizieren.
• Replicas: Anzahl der gewünschten, aktualisierten, gesamten, verfügbaren und nicht verfügbaren Replikate.
• StrategyType, RollingUpdateStrategy: Details zur Update-Strategie (z. B. RollingUpdate).
• Pod Template: Die Spezifikation, die verwendet wird, um Pods für dieses Deployment zu erstellen.
• Conditions: Bedingungen, die den Status des Deployments anzeigen (z. B. Available, Progressing).
• Events: Eine Liste von Ereignissen im Zusammenhang mit dem Deployment, die für die Fehlerbehebung hilfreich sein können.

Schauen Sie sich die Abschnitte Conditions und Events in der describe-Ausgabe an. Diese Abschnitte geben oft Hinweise, wenn es Probleme mit Ihrem Deployment gibt. Wenn beispielsweise ein Deployment nicht Available wird, können die Events Fehler im Zusammenhang mit dem Abrufen von Images, Fehlern bei der Pod-Erstellung usw. anzeigen.

Um den Status des Services zu überprüfen, können Sie ähnliche Befehle verwenden. Listen Sie zunächst alle Services auf:

kubectl get services

Beispielausgabe:

NAME          TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
kubernetes    ClusterIP   10.96.0.1       <none>        443/TCP   10m
web-service   ClusterIP   10.106.220.33   <none>        80/TCP    2m47s

Dies zeigt den web-service zusammen mit seinem TYPE (ClusterIP), seiner CLUSTER-IP und den verfügbaren PORT(S) an.

Für weitere Details zu einem Service verwenden Sie kubectl describe service <service_name>:

kubectl describe service web-service

Die describe service-Ausgabe enthält:

• Name, Namespace, Labels, Annotations: Grundlegende Metadaten.
• Selector: Der Label-Selektor, der verwendet wird, um die Ziel-Pods zu identifizieren.
• Type: Der Service-Typ (ClusterIP in diesem Fall).
• IP, IPs: Die Cluster-IP-Adresse, die dem Service zugewiesen wurde.
• Port, TargetPort: Port-Zuordnungen, die für den Service definiert sind.
• Endpoints: Zeigt die IP-Adressen und Ports der Pods an, die derzeit diesen Service unterstützen. Dies ist sehr wichtig. Wenn Sie keine Endpunkte sehen, bedeutet dies, dass der Service nicht korrekt mit einem Pod verbunden ist, wahrscheinlich aufgrund einer Fehlkonfiguration des Selektors.
• Session Affinity, Events: Andere Service-Konfigurationen und Ereignisse.

Beim Überprüfen des Deployment-Status sollten Sie auf folgende Schlüsselpunkte achten:

• Deployment READY-Status: Stellen Sie sicher, dass die gewünschte Anzahl von Replikaten angezeigt wird (z. B. 2/2 für web-app).
• Pod STATUS: Alle Pods sollten im Running-Status sein.
• Service Endpoints: Überprüfen Sie, dass der Service Endpunkte hat und dass diese den IP-Adressen Ihrer laufenden Pods entsprechen. Wenn es keine Endpunkte gibt, überprüfen Sie den Selektors des Services und die Pod-Labels.
• Nach Warnungen oder Fehlern suchen: Untersuchen Sie die Ausgabe von kubectl describe deployment <deployment_name> und kubectl describe service <service_name> auf ungewöhnliche Bedingungen oder Fehler in den Events-Abschnitten.

Durch die Verwendung dieser kubectl-Befehle können Sie effektiv den Status Ihrer Deployments und Services in Kubernetes überwachen und überprüfen und so sicherstellen, dass Ihre Anwendungen wie erwartet laufen.

Zugriff auf die Anwendung über kubectl proxy

In diesem Schritt lernen Sie, wie Sie auf Ihre Kubernetes-Anwendungen über kubectl proxy zugreifen können. kubectl proxy erstellt eine sichere Proxyverbindung zum Kubernetes-API-Server, sodass Sie Cluster-Services und Pods von Ihrem lokalen Rechner aus zugreifen können. Dies ist besonders nützlich für die Entwicklung und das Debugging, insbesondere wenn Sie auf Services zugreifen möchten, die nicht extern zugänglich sind.

Stellen Sie zunächst sicher, dass Sie sich im Projektverzeichnis befinden:

cd ~/project/k8s-manifests/manifests

Starten Sie den kubectl proxy im Hintergrund. Dieser Befehl führt den Proxy in einem separaten Prozess aus, sodass Sie weiterhin Ihr Terminal verwenden können.

kubectl proxy --port=8080 &

Das & am Ende des Befehls führt ihn im Hintergrund aus. Sie sollten eine Ausgabe wie die folgende sehen:

Starting to serve on 127.0.0.1:8080

Wenn Ihr Terminal nach Ausführung dieses Befehls "hängen" scheint, müssen Sie möglicherweise einmal Ctrl+C drücken, um zum Eingabeprompt zurückzukehren. Der Proxy sollte weiterhin im Hintergrund laufen.

Nun finden wir die Namen der Pods, die Teil Ihres web-app-Deployments sind. Sie können erneut kubectl get pods -l app=web verwenden:

## Get pod names for the 'web-app'
kubectl get pods -l app=web

Beispielausgabe:

NAME                      READY   STATUS    RESTARTS   AGE
web-app-xxx-yyy           1/1     Running   0          20m
web-app-xxx-zzz           1/1     Running   0          20m

Notieren Sie sich den Namen eines der Pods, beispielsweise web-app-xxx-yyy. Sie werden diesen Pod-Namen verwenden, um den API-Pfad zum Zugriff auf den NGINX-Webserver zu konstruieren, der in diesem Pod läuft.

Kubernetes-API-Ressourcen sind über bestimmte Pfade zugänglich. Um über den kubectl proxy auf einen Pod zuzugreifen, müssen Sie eine URL wie die folgende konstruieren:

http://localhost:8080/api/v1/namespaces/<namespace>/pods/<pod_name>/proxy/

Lassen Sie uns diese URL aufschlüsseln:

• http://localhost:8080: Die Adresse, auf der kubectl proxy läuft. Standardmäßig hört es auf Port 8080 auf Ihrem lokalen Rechner.
• /api/v1: Gibt die Kubernetes-API-Version (v1) an.
• /namespaces/<namespace>: Der Namespace, in dem Ihr Pod läuft. In unserem Fall ist es default.
• /pods/<pod_name>: Der Name des Pods, auf den Sie zugreifen möchten. Ersetzen Sie <pod_name> durch den tatsächlichen Namen Ihres Pods (z. B. web-app-xxx-yyy).
• /proxy/: Gibt an, dass Sie eine Verbindung zum Pod über den Proxy herstellen möchten.

Um es einfacher zu machen, den Pod-Namen in der URL zu verwenden, speichern wir den Namen des ersten Pods in einer Shell-Variablen. Führen Sie diesen Befehl aus, der kubectl get pods und jsonpath verwendet, um den Namen des ersten Pods mit dem Label app=web zu extrahieren:

## Get the name of the first pod with label 'app=web'
POD_NAME=$(kubectl get pods -l app=web -o jsonpath='{.items[0].metadata.name}')
echo $POD_NAME ## Optional: print the pod name to verify

Nun können Sie die $POD_NAME-Variable in Ihrem curl-Befehl verwenden, um auf die Standardseite von NGINX zuzugreifen, die von Ihrem Pod bereitgestellt wird. Verwenden Sie curl, um eine HTTP-Anfrage an die Proxy-URL zu senden. Ersetzen Sie ${POD_NAME} in der URL durch die Variable, die wir gerade festgelegt haben:

curl http://localhost:8080/api/v1/namespaces/default/pods/${POD_NAME}/proxy/

Wenn alles korrekt funktioniert, sollte dieser Befehl den HTML-Inhalt der Standard-Willkommensseite von NGINX zurückgeben. Eine Beispielausgabe wäre HTML-Inhalt, der mit folgendem beginnt:

<!doctype html>
<html>
  <head>
    <title>Welcome to nginx!</title>
    ...
  </head>
  <body>
    <h1>Welcome to nginx!</h1>
    ...
  </body>
</html>

Diese Ausgabe bestätigt, dass Sie erfolgreich über den kubectl proxy auf den NGINX-Webserver zugegriffen haben, der in Ihrem Pod läuft.

Lassen Sie uns einige weitere Dinge erkunden, die Sie mit kubectl proxy tun können.

Auflisten aller Pods im Standard-Namespace über den Proxy:

Sie können direkt über den Proxy auf die Kubernetes-API zugreifen. Beispielsweise können Sie diese URL verwenden, um alle Pods im default-Namespace aufzulisten:

curl http://localhost:8080/api/v1/namespaces/default/pods/

Dies gibt eine JSON-Antwort zurück, die Informationen über alle Pods im default-Namespace enthält.

Abrufen detaillierter Informationen zu einem bestimmten Pod über den Proxy:

Um detaillierte Informationen zu einem bestimmten Pod zu erhalten (ähnlich wie mit kubectl describe pod), können Sie direkt auf den API-Endpunkt des Pods zugreifen:

curl http://localhost:8080/api/v1/namespaces/default/pods/${POD_NAME}

Dies gibt eine JSON-Antwort mit detaillierten Informationen über den angegebenen Pod zurück.

Stoppen von kubectl proxy:

Wenn Sie mit der Verwendung von kubectl proxy fertig sind, sollten Sie ihn stoppen. Da wir ihn im Hintergrund gestartet haben, müssen Sie seine Prozess-ID (PID) finden und ihn beenden. Sie können den jobs-Befehl verwenden, um die Hintergrundprozesse aufzulisten:

jobs

Dies zeigt Ihnen die Hintergrundprozesse an, die aus Ihrer aktuellen Terminal-Sitzung ausgeführt werden. Sie sollten kubectl proxy aufgeführt sehen. Um ihn zu stoppen, können Sie den kill-Befehl gefolgt von der Prozess-ID verwenden. Wenn beispielsweise jobs [1] Running kubectl proxy --port=8080 & anzeigt, dann ist die Prozess-ID 1. Sie würden verwenden:

kill %1

Ersetzen Sie %1 durch die Job-ID, die der jobs-Befehl angezeigt hat. Alternativ können Sie die Prozess-ID mit ps aux | grep kubectl proxy finden und dann kill <PID> verwenden.

Wichtige Punkte zu kubectl proxy zu beachten:

• kubectl proxy erstellt eine sichere, authentifizierte Verbindung zum Kubernetes-API-Server.
• Es ermöglicht Ihnen, auf Cluster-Ressourcen (Pods, Services usw.) von Ihrem lokalen Rechner aus zuzugreifen, als wären Sie im Cluster-Netzwerk.
• Es ist sehr nützlich für das Debugging, die Entwicklung und die Erkundung der Kubernetes-API.
• Aus Sicherheitsgründen ist kubectl proxy nur auf localhost (127.0.0.1) zugänglich. Es ist nicht dafür vorgesehen, Services öffentlich zugänglich zu machen.

Zusammenfassung

In diesem Lab haben Sie erfolgreich gelernt, wie Sie Anwendungen auf einem Kubernetes-Cluster mithilfe von Minikube bereitstellen können. Sie haben begonnen, indem Sie einen lokalen Kubernetes-Cluster mit Minikube eingerichtet und seinen Status überprüft haben. Anschließend haben Sie essentielle kubectl-Befehle zur Interaktion mit Ihrem Cluster und zur Verwaltung von Ressourcen kennengelernt. Sie haben gelernt, Namespaces aufzulisten, Details über Knoten und Pods zu erhalten und die grundlegende Befehlsstruktur von kubectl zu verstehen. Diese Schritte haben Ihnen eine solide Grundlage für die Arbeit mit Kubernetes gegeben.

Sie haben dann einfache YAML-Manifeste für einen Pod und ein Deployment erstellt, sie mithilfe von kubectl apply auf Ihren Cluster angewendet und den Deployment-Status mithilfe verschiedener kubectl-Befehle wie get und describe überprüft. Diese praktische Erfahrung hat Ihnen geholfen, den deklarativen Ansatz zum Bereitstellen von Anwendungen auf Kubernetes zu verstehen und wie Sie effektiv mit dem Cluster interagieren können.

Schließlich haben Sie gelernt, wie Sie auf Ihre bereitgestellte Anwendung über kubectl proxy zugreifen können, das eine sichere Möglichkeit bietet, mit der API Ihres Clusters zu interagieren und auf Services und Pods von Ihrem lokalen Rechner aus zuzugreifen. Dies ist eine wertvolle Technik für die Entwicklung, das Debugging und die Erkundung Ihrer Kubernetes-Umgebung.

Durch die Absolvierung dieses Labs haben Sie praktische Erfahrung mit essentiellen Kubernetes-Konzepten und -Tools gesammelt und sich auf den Weg gebracht, komplexere Anwendungen auf Kubernetes bereitzustellen und zu verwalten.