Entdecken Sie den Kubernetes-Cluster

Einführung

In diesem Lab werden Sie einen lokalen Kubernetes-Cluster mit Minikube erkunden. Sie werden den Cluster starten, seine Einrichtung überprüfen und grundlegende Cluster-Ressourcen wie Pods und Deployments untersuchen. Diese praktische Erfahrung wird Ihnen helfen, die grundlegenden Komponenten und Befehle einer Kubernetes-Umgebung zu verstehen und bildet die Grundlage für weitere Erkundungen und Entwicklungen.

Sie beginnen damit, einen Minikube-Cluster auf Ihrem lokalen Rechner einzurichten und sicherzustellen, dass der Cluster läuft und einsatzbereit ist. Anschließend werden Sie die Konfiguration und den Gesundheitszustand des Clusters mit wichtigen kubectl-Befehlen wie kubectl cluster-info und kubectl get nodes überprüfen. Abschließend werden Sie die grundlegenden Cluster-Ressourcen, einschließlich Pods und Deployments, untersuchen, um sich mit dem Kubernetes-Objektmodell und dem Gesamtzustand des Clusters vertraut zu machen.

Lokalen Kubernetes-Cluster starten

In diesem Schritt werden Sie einen lokalen Kubernetes-Cluster mit Minikube starten und überprüfen. Minikube bietet eine einfache Möglichkeit, eine einheitliche Kubernetes-Umgebung für Lern- und Entwicklungszwecke einzurichten.

Zunächst navigieren Sie in das Projektverzeichnis:

cd ~/project

Starten Sie den Minikube-Cluster:

Hinweis: Gratisnutzer können nicht mit dem Internet verbinden. Daher wird Minikube bereits vorab gestartet, wenn Sie das Lab starten. Sie können direkt zum folgenden Codeabschnitt springen, um den Clusterstatus zu überprüfen. Upgrade auf einen Pro-Nutzer, um das Starten des Clusters selbst zu üben.

minikube start

😄  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

Überprüfen Sie den Clusterstatus mit mehreren Befehlen:

minikube status

Beispielausgabe:

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

Überprüfen Sie die Clusterknoten:

kubectl get nodes

Beispielausgabe:

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

Diese Befehle bestätigen, dass:

1. Minikube erfolgreich gestartet wurde
2. Der lokale Kubernetes-Cluster läuft
3. Der Cluster einsatzbereit ist
4. Sie einen Ein-Knoten-Cluster mit Control-Plane-Funktionalität haben

Der Minikube-Cluster bietet eine vollständige Kubernetes-Umgebung auf Ihrem lokalen Rechner, sodass Sie Anwendungen entwickeln und testen können, ohne einen vollständigen Mehr-Knoten-Cluster benötigen.

Übersicht über die Kubernetes-Architektur

Kubernetes basiert auf einem Client-Server-Modell, bei dem eine zentrale Control Plane (Steuerungsebene) den Zustand des Clusters regelt und eine Reihe von Worker Nodes (Arbeitsknoten) die Workloads ausführt. Auf hoher Ebene interagiert ein Benutzer (häufig ein Entwickler) mit dem Kubernetes-Cluster über Befehlszeilentools oder APIs. Die Control Plane trifft Entscheidungen darüber, was wo laufen soll, überwacht die Gesundheit des Clusters und stellt sicher, dass der gewünschte Zustand erreicht wird. Die Worker Nodes hosten Ihre Anwendungen in Pods – Gruppen aus einem oder mehreren Containern – und bieten die erforderlichen Rechen- und Speicherressourcen, um sie auszuführen.

Control Plane

Dies ist das “Gehirn” des Clusters und besteht aus mehreren Komponenten, die zusammenarbeiten, um das gesamte System zu verwalten:

• kube-apiserver (API): Dient als Eingangstor des Clusters. Alle administrativen Befehle und Ressourcenanforderungen werden über ihn geleitet.
• etcd (Key Value Store): Speichert alle Konfigurationsdaten und den aktuellen Zustand des Clusters. Wenn Sie die etcd-Daten verlieren, verlieren Sie auch den Zustand des Clusters.
• kube-scheduler (SCH): Weist Pods auf der Grundlage von Ressourcenanforderungen, Einschränkungen und Richtlinien an Nodes zu.
• kube-controller-manager (CTLM): Führt eine Vielzahl von Controllern aus, die kontinuierlich den Zustand des Clusters anpassen, um sicherzustellen, dass der tatsächliche Zustand mit dem gewünschten Zustand übereinstimmt, der durch Ihre Deployments und Konfigurationen definiert ist.

Nodes (Arbeitsknoten)

Auf Nodes werden die Workloads ausgeführt. Jeder Node hat:

• kubelet (KLT): Ein Agent auf Knotenebene, der mit der Control Plane kommuniziert. Er stellt sicher, dass Pods laufen und meldet ihren Status an die Control Plane zurück.
• Container Runtime (CR): Software, die Container ausführt und verwaltet (z. B. Docker oder containerd). Sie erstellt und verwaltet containerisierte Anwendungen innerhalb von Pods.

Pods

Ein Pod ist die kleinste deployierbare Einheit in Kubernetes und repräsentiert typischerweise eine einzelne Instanz einer laufenden Anwendung. Pods können einen oder mehrere Container enthalten, die denselben Netzwerknamespace und die gleichen Speichervolumes teilen.

Services

Ein Service ist eine Abstraktion, die eine logische Gruppe von Pods und eine Richtlinie für den Zugriff auf sie definiert. Services bieten stabile IP-Adressen, DNS-Namen und Lastverteilung, um sicherzustellen, dass externe Benutzer und andere Clusterkomponenten zuverlässig auf Ihre Anwendungen zugreifen können – auch wenn Pods zwischen Nodes verschoben oder während der Skalierung oder Rolling Updates ersetzt werden.

Interaktion mit dem Cluster

• Entwickler und Administratoren interagieren mit dem Cluster über den kube-apiserver, oft unter Verwendung von kubectl oder anderen Kubernetes-Clients.
• Wenn eine neue Anwendung deployed wird, arbeiten die Komponenten der Control Plane (Scheduler, Controller) zusammen, um die Pods auf die entsprechenden Nodes zu verteilen.
• Das kubelet auf jedem Node stellt sicher, dass die Pods gesund und wie angefordert laufen.
• Services leiten den Datenverkehr an die richtigen Pods weiter, sodass Clients auf Anwendungen zugreifen können, ohne die Positionsänderungen der Pods verfolgen zu müssen.

flowchart TB

    %% User interacting with the cluster
    User((Developer))
    User -->|kubectl CLI| API[kube-apiserver]

    %% Control Plane Components
    subgraph ControlPlane[Control Plane]
        API
        ETCD[etcd - Key Value Store]
        SCH[kube-scheduler]
        CTLM[kube-controller-manager]

        API --> ETCD
        API --> SCH
        API --> CTLM
    end

    %% Worker Node 1
    subgraph Node1[Worker Node]
        KLT1[kubelet]
        CR1[Container Runtime]
        subgraph Pods1[Pods]
            P1[Pod]
            P2[Pod]
        end

        KLT1 --> CR1
        CR1 --> P1
        CR1 --> P2
    end

    %% Worker Node 2
    subgraph Node2[Worker Node]
        KLT2[kubelet]
        CR2[Container Runtime]
        subgraph Pods2[Pods]
            P3[Pod]
            P4[Pod]
        end

        KLT2 --> CR2
        CR2 --> P3
        CR2 --> P4
    end

    %% Connections between Control Plane and Nodes
    API --> KLT1
    API --> KLT2

    %% Service connecting to Pods across different Nodes
    Service[Service]
    Service --> P1
    Service --> P2
    Service --> P3
    Service --> P4

In der Grafik:

• Der Entwickler interagiert mit dem kube-apiserver (API) über ein CLI-Tool wie kubectl.
• Die Komponenten der Control Plane (API, etcd, Scheduler, Controller Manager) verwalten den Clusterzustand und orchestrieren die Workloads.
• Jeder Worker Node führt ein kubelet und einen Container Runtime aus und hostet mehrere Pods.
• Ein Service leitet externen oder internen Datenverkehr an die richtigen Pods weiter und bietet einen stabilen Endpunkt, der die Komplexität des Pod-Lebenszyklus und von IP-Änderungen abstrahiert.

Dieses mentale Modell hilft Ihnen zu verstehen, was Sie sehen, wenn Sie den Zustand des Clusters untersuchen, die Gesundheit der Nodes überprüfen, Pods auflisten und Services abfragen – Konzepte, die Sie anwenden werden, wenn Sie mit kubectl-Befehlen weiterhin Kubernetes erkunden.

Cluster-Einrichtung überprüfen

In diesem Schritt erfahren Sie, wie Sie die Konfiguration und den Gesundheitszustand Ihres Kubernetes-Clusters mit wichtigen kubectl-Befehlen überprüfen können. Diese Befehle helfen Ihnen, den aktuellen Zustand und die Konnektivität des Clusters zu verstehen.

Zunächst überprüfen Sie die Cluster-Informationen:

kubectl cluster-info

Beispielausgabe:

Kubernetes control plane is running at https://192.168.49.2:8443
CoreDNS is running at https://192.168.49.2:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'

Dieser Befehl liefert Details über die Kubernetes-Control Plane und Kernservices wie CoreDNS.

Als Nächstes erhalten Sie eine detaillierte Ansicht der Cluster-Knoten:

kubectl get nodes -o wide

Beispielausgabe:

NAME       STATUS   ROLES           AGE    VERSION   INTERNAL-IP    EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION
minikube   Ready    control-plane   15m    v1.26.1   192.168.49.2   <none>        Ubuntu 22.04 LTS    5.15.0-72-generic

Lassen Sie uns die Knoten-Details noch umfassender untersuchen:

kubectl describe node minikube

Beispielausgabe (teilweise):

Name:               minikube
Roles:              control-plane
Labels:             beta.kubernetes.io/arch=amd64
                    beta.kubernetes.io/os=linux
                    kubernetes.io/arch=amd64
                    kubernetes.io/hostname=minikube
                    kubernetes.io/os=linux
                    minikube.k8s.io/commit=86a3b7e45a9a35cdcf8f4c80a4c6a46d20dda00f
Annotations:        node.alpha.kubernetes.io/ttl: 0
                    volumes.kubernetes.io/controller-managed-attach-detach: true
CreationTimestamp:  [Current Timestamp]
Capacity:
  cpu:                2
  ephemeral-storage:  17784212Ki
  memory:             1947748Ki
  pods:               110
Allocatable:
  cpu:                2
  ephemeral-storage:  16388876Ki
  memory:             1845348Ki
  pods:               110

Wichtige Erkenntnisse aus diesen Befehlen:

1. Überprüfen Sie, ob die Cluster-Control Plane läuft.
2. Prüfen Sie den Knotenstatus (Bereit/Nicht bereit).
3. Verstehen Sie die Knoten-Ressourcen und -Konfiguration.
4. Bestätigen Sie die Kubernetes-Version und die Knoten-Details.

Grundlegende Cluster-Ressourcen untersuchen

In diesem Schritt werden Sie grundlegende Kubernetes-Ressourcen wie Pods, Deployments und Services in allen Namespaces untersuchen. Mit der Option -A (oder --all-namespaces) können Sie sehen, wie die Ressourcen im gesamten Cluster organisiert sind. Dies ist eine ausgezeichnete Gelegenheit, das Konzept der Namespaces in Kubernetes kennen zu lernen und zu verstehen.

Namespaces: Ressourcen-Isolation

Namespaces sind logische Partitionen innerhalb eines Kubernetes-Clusters, die bei der Organisation und Verwaltung von Ressourcen helfen. Sie bieten eine Möglichkeit, verwandte Objekte zu gruppieren und Richtlinien, Zugangskontrollen und Ressourcenkontingente auf granularer Ebene anzuwenden. Durch die Aufteilung von Ressourcen in verschiedene Namespaces können Sie:

• Die Organisation verbessern: Verwandte Workloads gruppieren (z. B. nach Projekt, Team oder Umgebung wie Entwicklung, Test und Produktion).
• Sicherheit und Zugangskontrolle verbessern: Beschränken, welche Benutzer oder Service Accounts Ressourcen in einem bestimmten Namespace anzeigen oder ändern können.
• Die Ressourcenverwaltung vereinfachen: Ressourcenlimits, Netzwerkrichtlinien und andere clusterweite Konfigurationen effektiver anwenden.

Wenn Sie Ressourcen mit der Option -A (oder --all-namespaces) auflisten, werden Sie feststellen, dass Komponenten des Kubernetes-Systems im kube-system-Namespace liegen, der für die Cluster-Infrastruktur reserviert ist. Benutzererstellte Anwendungen befinden sich normalerweise im default-Namespace oder in anderen benutzerdefinierten Namespaces, die Sie definieren.

Namespaces und Ressourcen

flowchart LR

    %% User interacts with the cluster via kube-apiserver
    User((Developer))
    User -->|kubectl get pods -A| API[kube-apiserver]

    %% Control Plane Subgraph
    subgraph ControlPlane[Control Plane]
        API
        ETCD[etcd]
        SCH[kube-scheduler]
        CTLM[kube-controller-manager]
    end

    API --> ETCD
    API --> SCH
    API --> CTLM

    %% kube-system namespace
    subgraph kube-system[Namespace: kube-system]
        SysDeployment[Deployment: coredns]
        SysPod1[Pod: coredns-xxx]
        SysService[Service: kube-dns]

        SysDeployment --> SysPod1
        SysService --> SysPod1
    end

    %% default namespace (renamed to avoid parse issues)
    subgraph defaultNs[Namespace: default]
        DefDeployment[Deployment: my-app]
        DefPod1[Pod: my-app-pod1]
        DefPod2[Pod: my-app-pod2]
        DefService[Service: my-app-service]

        DefDeployment --> DefPod1
        DefDeployment --> DefPod2
        DefService --> DefPod1
        DefService --> DefPod2
    end

    %% dev namespace
    subgraph dev[Namespace: dev]
        DevDeployment[Deployment: dev-app]
        DevPod[Pod: dev-app-pod]
        DevService[Service: dev-app-service]

        DevDeployment --> DevPod
        DevService --> DevPod
    end

    %% Demonstration of communication
    API --> kube-system
    API --> defaultNs
    API --> dev

In der Grafik:

• Die Control Plane verwaltet den gesamten Cluster, kommuniziert mit den Knoten und steuert die Workloads.
• Namespaces (wie kube-system, default und dev) trennen die Ressourcen im Cluster logisch voneinander.
  • kube-system enthält systemrelevante Komponenten wie CoreDNS und kube-dns.
  • default wird üblicherweise für allgemeine Workloads verwendet, hier dargestellt durch ein my-app-Deployment.
  • dev könnte eine Entwicklungsumgebung repräsentieren, die von Produktions-Workloads isoliert ist.

Durch die Ansicht der Ressourcen in allen Namespaces erhalten Sie ein umfassendes Verständnis, wie diese logischen Partitionen dazu beitragen, einen organisierten und sicheren Cluster aufrechtzuerhalten.

Beispiele:

Liste aller Pods in allen Namespaces:

kubectl get pods -A

Beispielausgabe:

NAMESPACE     NAME                               READY   STATUS    RESTARTS      AGE
kube-system   coredns-787d4945fb-j8rhx           1/1     Running   0             20m
kube-system   etcd-minikube                      1/1     Running   0             20m
kube-system   kube-apiserver-minikube            1/1     Running   0             20m
kube-system   kube-controller-manager-minikube   1/1     Running   0             20m
kube-system   kube-proxy-xb9rz                   1/1     Running   0             20m
kube-system   kube-scheduler-minikube            1/1     Running   0             20m
kube-system   storage-provisioner                1/1     Running   1 (20m ago)   20m

Hier sehen Sie alle systemrelevanten Pods, die im kube-system-Namespace laufen. Wenn Sie andere Deployments oder Services in verschiedenen Namespaces hätten, würden sie ebenfalls in dieser Liste erscheinen, jeweils eindeutig durch ihren Namespace gekennzeichnet.

Liste aller Deployments in allen Namespaces:

kubectl get deployments -A

Beispielausgabe:

NAMESPACE     NAME      READY   UP-TO-DATE   AVAILABLE   AGE
kube-system   coredns   1/1     1            1           20m

Das coredns-Deployment befindet sich im kube-system-Namespace.

Umfassende Ansicht aller Ressourcen in allen Namespaces:

kubectl get all -A

Dieser Befehl zeigt eine Übersicht über Pods, Services und Deployments in verschiedenen Namespaces an und hilft Ihnen zu verstehen, wie diese Ressourcen im gesamten Cluster verteilt sind.

Wichtige Erkenntnisse:

• Namespaces bieten logische Isolation und Organisation innerhalb eines Kubernetes-Clusters.
• Verschiedene Kubernetes-Komponenten und -Ressourcen sind in bestimmte Namespaces organisiert (z. B. kube-system für Kernservices, default für allgemeine Workloads und zusätzliche Namespaces, die Sie erstellen).
• Durch die Verwendung von -A zur Ansicht der Ressourcen in allen Namespaces erhalten Sie Einblicke in die Struktur Ihres Clusters und wie Namespaces als Grenzen für die Ressourcenorganisation und Zugangskontrolle dienen.

Wenn Sie verstehen, wie Namespaces als logische Umgebungen funktionieren, können Sie Ihre Workloads und die zugehörigen Cluster-Ressourcen besser navigieren, isolieren und verwalten, insbesondere wenn Sie Ihre Deployments skalieren und Ihre Kubernetes-Umgebung komplexer gestalten.

Zusammenfassung

In diesem Lab haben Sie einen lokalen Kubernetes-Cluster mit Minikube gestartet und überprüft. Minikube bietet eine einfache Möglichkeit, eine einheitliche Kubernetes-Umgebung für Lern- und Entwicklungszwecke einzurichten. Sie haben bestätigt, dass der Minikube-Cluster erfolgreich gestartet wurde, der lokale Kubernetes-Cluster läuft, der Cluster einsatzbereit ist und Sie einen Ein-Knoten-Cluster mit Control-Plane-Funktionalität haben. Sie haben auch gelernt, wie Sie die Konfiguration und den Gesundheitszustand Ihres Kubernetes-Clusters mit wichtigen kubectl-Befehlen wie kubectl cluster-info und kubectl get nodes überprüfen können. Diese Befehle haben Ihnen geholfen, den aktuellen Zustand und die Konnektivität des Clusters zu verstehen.