47 Weg der Daten bei einem kubectl apply Befehl

47.1 Ausgangssituation

Wir haben ein Kubernetes Deployment, das mittels kubectl apply angewendet wird. Im folgenden Beispiel wird ein Deployment erstellt, das eine einfache Nginx-Anwendung betreibt.

Beispiel Deployment-Konfiguration:

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:1.14.2
        ports:
        - containerPort: 80

47.2 Ablauf des kubectl apply Befehls

1. Ausführung des kubectl apply Befehls:

   kubectl apply -f deployment.yaml

2. Kommunikation mit dem API-Server:

   • kubectl sendet eine HTTP-Anfrage an den Kubernetes API-Server. Diese Anfrage enthält die Definition des Deployments aus der deployment.yaml Datei.
   • Der API-Server empfängt die Anfrage und authentifiziert und autorisiert den Benutzer.

3. Verarbeitung durch den API-Server:

   • Der API-Server überprüft die bereitgestellte Deployment-Spezifikation auf syntaktische Korrektheit und Konformität mit den Kubernetes-Schemata.
   • Wenn die Validierung erfolgreich ist, schreibt der API-Server die Deployment-Spezifikation in die etcd-Datenbank. Dies geschieht durch einen PUT-Vorgang in etcd, der die Daten unter einem entsprechenden Schlüssel speichert (z.B. /registry/deployments/default/nginx-deployment).

4. Persistierung in etcd:

   • etcd speichert die Deployment-Daten und repliziert sie an andere etcd-Knoten, um Konsistenz und Hochverfügbarkeit sicherzustellen.

5. Benachrichtigung des Controller-Managers:

   • Der API-Server benachrichtigt den Controller-Manager über die Änderung, indem er das Deployment-Objekt im etcd aktualisiert. Der Controller-Manager überwacht kontinuierlich etcd auf Änderungen.
   • Der Deployment-Controller, eine Komponente des Controller-Managers, erkennt das neue Deployment-Objekt und erstellt entsprechende ReplicaSets.

6. Erstellung von ReplicaSets:

   • Der Deployment-Controller erstellt ein neues ReplicaSet-Objekt basierend auf den Spezifikationen des Deployments und speichert es in etcd.
   • Ein PUT-Vorgang in etcd speichert das ReplicaSet-Objekt unter einem entsprechenden Schlüssel (z.B. /registry/replicasets/default/nginx-deployment-xxxxx).

7. Benachrichtigung des Scheduler:

   • Der Scheduler wird vom API-Server über das neue ReplicaSet und die zu erstellenden Pods informiert.
   • Der Scheduler entscheidet, auf welchen Knoten (Nodes) die Pods platziert werden sollen und aktualisiert die Pod-Spezifikationen mit den Node-Informationen in etcd.

8. Pod-Erstellung durch Kubelet:

   • Die Kubelets auf den entsprechenden Nodes überwachen die etcd-Datenbank nach Änderungen, insbesondere nach neuen Pods, die ihnen zugewiesen wurden.
   • Jedes Kubelet entdeckt die neuen Pod-Spezifikationen, die für seine Node bestimmt sind, und startet die entsprechenden Container auf seiner Node.

9. Status-Updates:

   • Die Kubelets aktualisieren den Status der laufenden Pods kontinuierlich in etcd, indem sie Informationen über den aktuellen Zustand der Container bereitstellen.
   • Der API-Server stellt diese Statusinformationen anderen Komponenten, wie dem Controller-Manager und Scheduler, zur Verfügung.

47.3 Zusammenfassung des Datenflusses

1. kubectl -> API-Server: Übermittelt die Deployment-Spezifikation.
2. API-Server -> etcd: Persistiert die Deployment-Daten.
3. etcd -> Controller-Manager: Informiert über neue/aktualisierte Deployments.
4. Controller-Manager -> etcd: Erstellt und speichert ReplicaSet-Daten.
5. etcd -> Scheduler: Informiert über neue/aktualisierte ReplicaSets.
6. Scheduler -> etcd: Aktualisiert die Pod-Spezifikationen mit Node-Informationen.
7. etcd -> Kubelet: Informiert über neue Pods, die auf den Knoten erstellt werden sollen.
8. Kubelet -> etcd: Aktualisiert den Pod-Status.

Dieser Prozess stellt sicher, dass die Deployment-Spezifikation zuverlässig in Kubernetes angewendet wird und die Pods entsprechend der gewünschten Konfiguration erstellt und verwaltet werden.

47.4 High-Availability and Disaster Recovery

47.4.1 Einführung

Hohe Verfügbarkeit und Disaster Recovery sind entscheidende Aspekte für den Betrieb eines Kubernetes-Clusters in Produktionsumgebungen. Hohe Verfügbarkeit stellt sicher, dass der Cluster auch bei Ausfällen einzelner Komponenten oder Nodes weiter funktioniert, während Disaster Recovery Strategien und Verfahren umfasst, um den Cluster im Falle eines schwerwiegenden Ausfalls oder Datenverlusts wiederherzustellen.

47.4.2 Grundlagen der Hochverfügbarkeit

Hohe Verfügbarkeit in Kubernetes wird durch die Redundanz kritischer Komponenten und die Fähigkeit zur Selbstheilung erreicht. Die wichtigsten Komponenten für die Hochverfügbarkeit sind:

1. etcd-Cluster: Ein hochverfügbarer etcd-Cluster besteht aus mehreren etcd-Knoten (idealerweise mindestens drei), die Daten replizieren und den Konsens über den Cluster-Zustand sicherstellen.

2. Control Plane: Die Control Plane-Komponenten (API-Server, Scheduler, Controller-Manager) sollten ebenfalls redundant ausgelegt sein, um Ausfälle einzelner Komponenten abzufangen. Diese Komponenten können auf mehreren Nodes ausgeführt werden.

3. Worker Nodes: Die Anwendungen sollten auf mehrere Worker Nodes verteilt werden, um sicherzustellen, dass der Ausfall eines einzelnen Nodes nicht zu einem Ausfall der Anwendung führt.

47.4.3 Hochverfügbarkeitsarchitektur

47.4.3.1 Multi-Master-Setup

Ein Multi-Master-Setup erhöht die Verfügbarkeit der Control Plane. In diesem Setup gibt es mehrere Master-Nodes, die API-Server, Scheduler und Controller-Manager ausführen. Diese Master-Nodes sind hinter einem Load Balancer verborgen, der den Traffic an die aktiven Master-Nodes weiterleitet.

Beispielarchitektur:

[ Load Balancer ]
      /       \
[ Master 1 ] [ Master 2 ] [ Master 3 ]
     |          |          |
[ etcd 1 ]   [ etcd 2 ]  [ etcd 3 ]
     |          |          |
[ Worker Nodes ]

47.4.3.2 Implementierung eines Multi-Master-Setups

API-Server hinter einem Load Balancer:

apiVersion: v1
kind: Service
metadata:
  name: kube-apiserver-lb
  namespace: kube-system
spec:
  type: LoadBalancer
  selector:
    component: kube-apiserver
  ports:
  - protocol: TCP
    port: 443
    targetPort: 6443

etcd-Cluster Konfiguration:

apiVersion: v1
kind: Pod
metadata:
  name: etcd
  namespace: kube-system
spec:
  containers:
  - name: etcd
    image: quay.io/coreos/etcd:v3.4.13
    command:
    - /usr/local/bin/etcd
    - --data-dir=/var/lib/etcd
    - --name=etcd-0
    - --initial-advertise-peer-urls=http://etcd-0:2380
    - --listen-peer-urls=http://0.0.0.0:2380
    - --listen-client-urls=http://0.0.0.0:2379
    - --advertise-client-urls=http://etcd-0:2379
    - --initial-cluster=etcd-0=http://etcd-0:2380,etcd-1=http://etcd-1:2380,etcd-2=http://etcd-2:2380
    - --initial-cluster-state=new
    ports:
    - containerPort: 2379
    - containerPort: 2380
    volumeMounts:
    - name: etcd-data
      mountPath: /var/lib/etcd
  volumes:
  - name: etcd-data
    hostPath:
      path: /var/lib/etcd

47.4.4 Disaster Recovery

Disaster Recovery umfasst Strategien und Verfahren zur Wiederherstellung des Clusters nach einem schwerwiegenden Ausfall. Wichtige Aspekte sind:

1. Backup und Wiederherstellung von etcd: Regelmäßige Sicherungen des etcd-Datenbestands sind entscheidend. Diese Sicherungen sollten außerhalb des Clusters gespeichert werden.

Backup von etcd:

ETCDCTL_API=3 etcdctl snapshot save snapshot.db --endpoints=<etcd-endpoint> --cacert=<path-to-cafile> --cert=<path-to-certfile> --key=<path-to-keyfile>

Wiederherstellung von etcd:

ETCDCTL_API=3 etcdctl snapshot restore snapshot.db --data-dir=<new-etcd-data-dir>

2. Wiederherstellungsplan: Ein detaillierter Wiederherstellungsplan sollte vorhanden sein, der die Schritte zur Wiederherstellung des Clusters nach einem Ausfall beschreibt.

Beispiel Wiederherstellungsplan:

• Prüfen Sie den Zustand der etcd-Knoten.
• Wiederherstellen der etcd-Datenbank aus einer Sicherung.
• Starten der Control Plane-Komponenten.
• Überprüfen des Zustands der Worker Nodes und der Anwendungen.

47.4.5 Überwachung und Tests

Regelmäßige Überwachung und Tests der Hochverfügbarkeits- und Disaster Recovery-Strategien sind entscheidend, um sicherzustellen, dass sie im Ernstfall effektiv sind.

Überwachung von etcd:

ETCDCTL_API=3 etcdctl endpoint status --endpoints=<etcd-endpoint> --write-out=table

Testen von Backup und Wiederherstellung:

• Führen Sie regelmäßige Backups durch und stellen Sie sicher, dass die Backups vollständig und zugänglich sind.
• Simulieren Sie Ausfälle und üben Sie die Wiederherstellung aus den Sicherungen.

Hohe Verfügbarkeit und Disaster Recovery sind wesentliche Bestandteile eines robusten Kubernetes-Clusters. Durch die Implementierung redundanter Architekturen, regelmäßiger Backups und detaillierter Wiederherstellungspläne können Administratoren sicherstellen, dass ihr Cluster auch bei Ausfällen und Katastrophen betriebsbereit bleibt. Ein kontinuierliches Überwachungs- und Testprogramm stellt sicher, dass diese Strategien im Ernstfall wirksam sind.