Traditionelle App-Architektur mit VMs

Das folgende Diagramm zeigt ein Beispiel für eine traditionelle App-Architektur, die auf virtuellen Maschinen (VMs) basiert.

1. Der Benutzer sendet eine Anforderung an den öffentlichen Endpunkt der App. Der öffentliche Endpunkt wird durch einen Lastausgleichsservice dargestellt, der den eingehenden Netzverkehr zwischen den verfügbaren App-Serverinstanzen verteilt.
2. Die Lastausgleichsfunktion wählt eine der einwandfreien App-Serverinstanzen aus, die auf einer VM ausgeführt werden, und leitet die Anforderung weiter. App-Dateien, wie der App-Code, Konfigurationsdateien und Abhängigkeiten, werden auf der VM des App-Servers gespeichert.
3. Der App-Server speichert App-Daten in MySQL, die auf einer Datenbank-VM läuft.

Containerisierte Architektur

Das folgende Diagramm zeigt ein Beispiel für eine moderne Containerarchitektur, die in einem Kubernetes-Cluster ausgeführt wird.

1. Der Benutzer sendet eine Anforderung an den öffentlichen Endpunkt der App. Der öffentliche Endpunkt wird durch eine Ingress-Lastausgleichsfunktion für Anwendungen (ALB) dargestellt, die eingehenden Netzverkehr auf die App-Pods im Cluster verteilt. Die ALB enthält eine Sammlung von Regeln, die eingehenden Netzverkehr an eine öffentlich zugänglich gemachte App zulassen.
2. Die ALB leitet die Anforderung an einen der verfügbaren App-Pods im Cluster weiter. App-Pods werden auf Workerknoten ausgeführt, bei denen es sich um eine virtuelle oder eine physische Maschine handeln kann.
3. App-Pods speichern Daten auf persistenten Datenträgern. Persistente Datenträger können verwendet werden, um Daten zwischen App-Instanzen oder Workerknoten gemeinsam zu nutzen.
4. App-Pods speichern Daten in einem IBM Cloud-Datenbankservice. Sie können eine eigene Datenbank im Kubernetes-Cluster ausführen, jedoch ist die Verwendung einer verwalteten Database as a Service-Datenbank (DBaaS) in der Regel einfacher zu konfigurieren und stellt integrierte Backup- und Skalierungsfunktionen bereit. Im IBM Cloud-Katalog finden Sie viele Datenbanktypen.

VMs, Container und Kubernetes

Kubernetes Service bietet die Funktionalität zur Ausführung von containerisierten Apps in Kubernetes-Clustern und stellt die folgenden Tools und Funktionen zur Verfügung:

• Intuitive Benutzererfahrung und leistungsstarke Tools.
• Integrierte Sicherheit und Isolierung für eine schnelle Bereitstellung sicherer Anwendungen.
• Cloud-Dienste, die kognitive Fähigkeiten von Watson™ beinhalten.
• Fähigkeit, dedizierte Cluster-Ressourcen sowohl für zustandslose Anwendungen als auch für zustandsbehaftete Arbeitslasten zu verwalten.

Was IBM für Sie tut

Die Verwendung von Kubernetes-Clustern mit IBM Cloud Kubernetes Service bietet Ihnen die folgenden Vorteile:

• Mehrere Rechenzentren, in denen Sie Ihre Cluster bereitstellen können
• Unterstützung von Optionen für Netze mit Ingress- und Lastausgleichsfunktionen
• Unterstützung für dynamische persistente Datenträger
• Hoch verfügbare, von IBM verwaltete Kubernetes-Master

Nicht persistenter Datenspeicher

Container und Pods sind per Definition Komponenten mit kurzer Lebensdauer, die kurzfristig und unerwartet ausfallen können. Sie können Daten im lokalen Dateisystem eines Containers speichern. Daten in einem Container können nicht mit anderen Containern oder Pods gemeinsam genutzt werden und gehen verloren, wenn der Container ausfällt oder entfernt wird.

Erstellung des persistenten Datenspeichers für Apps kennenlernen

Sie können App-Daten und Container-Daten auf NFS oder Blockspeichern persistieren, indem Sie native persistente Kubernetes Volumes verwenden.

Zur Bereitstellung von NFS-Dateispeicher oder Blockspeicher müssen Sie Speicher für Ihren Pod anfordern, indem Sie einen Persistent Volume Claim (PVC, Anforderung für persistenten Datenträger) erstellen. In Ihrem PVC können Sie aus vordefinierten Speicherklassen auswählen, die die Art des Speichers, die Speicherkapazität in Gigabyte, IOPS, die Datenaufbewahrungsrichtlinie und die Lese- und Schreibberechtigungen für Ihren Speicher definieren. Ein PVC stellt einen persistenten Datenträger (PV - Persistent Volume) dynamisch bereit, der eine reale Speichereinheit in IBM Cloud darstellt. Sie können den PVC an Ihren Pod anhängen, um Lese- und Schreiboperationen auf dem PV auszuführen. Daten, die in PVs gespeichert werden, sind verfügbar, auch wenn der Container ausfällt oder der Pod neu geplant wird. NFS und der Blockspeicher, der die PV unterstützt, werden von IBM geclustert, um eine hohe Verfügbarkeit Ihrer Daten zu gewährleisten.

Informationen zur Erstellung eines PVC finden Sie in den Schritten, die in der Dokumentation zu Kubernetes Service-Speicher beschrieben werden.

Verschiebung vorhandener Daten in persistenten Speicher kennenlernen

Zum Kopieren von Daten von Ihrer lokalen Maschine auf Ihren persistenten Speicher müssen Sie den PVC an einen Pod anhängen. Anschließend können Sie Daten von Ihrer lokalen Maschine auf den persistenten Datenträger in Ihrem Pod kopieren.

1. Zum Kopieren von Daten müssen Sie zunächst eine Konfiguration erstellen, die etwa wie folgt aussieht:

   kind: Pod
   apiVersion: v1
   metadata:
     name: task-pv-pod
   spec:
     volumes:
       - name: task-pv-storage
         persistentVolumeClaim:
          claimName: mypvc
     containers:
       - name: task-pv-container
         image: nginx
         ports:
           - containerPort: 80
             name: "http-server"
         volumeMounts:
           - mountPath: "/mnt/data"
             name: task-pv-storage
   

2. Anschließend würden Sie einen Befehl wie den folgenden verwenden, um Daten von Ihrer lokalen Maschine in den Pod zu kopieren:

    kubectl cp <local_filepath>/<filename> <namespace>/<pod>:<pod_filepath>
   

3. Kopieren Sie Daten von einem Pod in Ihrem Cluster auf Ihre lokale Maschine:

   kubectl cp <namespace>/<pod>:<pod_filepath>/<filename> <local_filepath>/<filename>
   

Backups für persistenten Speicher einrichten

Gemeinsam genutzte Dateiressourcen und Blockspeicher werden an derselben Position wie Ihr Cluster bereitgestellt. Der Speicher selbst wird von IBM auf Cluster-Servern gehostet, um hohe Verfügbarkeit bereitzustellen. Allerdings werden gemeinsam genutzte Dateiressourcen und Blockspeicher nicht automatisch durch Backups gesichert und können nicht mehr erreichbar sein, wenn ein gesamter Standort ausfällt. Wenn Sie Ihre Daten gegen Verlust oder Beschädigung schützen wollen, können Sie regelmäßige Backups einrichten, durch die Sie Ihre Daten bei Bedarf wiederherstellen können.

Weitere Informationen finden Sie unter "Planung von Speicheroptionen für NFS und Blockspeicher".

12-Faktor-Prinzipien anwenden

Die Zwölf-Faktor-App ist eine Methodik zur Erstellung von Cloud-nativen Apps. Wenn Sie eine App containerisieren, diese App in die Cloud verschieben und sie mit Kubernetes orchestrieren wollen, ist es wichtig, einige dieser Prinzipien zu verstehen und anzuwenden. Einige dieser Prinzipien sind in IBM Cloud erforderlich.

Die folgenden Schlüsselprinzipien sind erforderlich:

• Codebasis - Sämtliche Quellcode- und Konfigurationsdateien werden in einem Versionssteuerungssystem verfolgt (z. B. in einem Git-Repository). Dies ist erforderlich, wenn eine DevOps-Pipeline für die Entwicklung genutzt wird.
• Build, Veröffentlichung, Ausführung - Die 12-Faktor-App verwendet eine strikte Trennung der Build-, Veröffentlichungs- und Ausführungsphase. Dies kann durch eine integrierte DevOps-Delivery Pipeline automatisiert werden, sodass die App erstellt (Build) und getestet wird, bevor sie im Cluster bereitgestellt wird. Lesen Sie das Lernprogramm App in Kubernetes, um zu erfahren, wie Sie eine Pipeline für kontinuierliche Integration und Bereitstellung einrichten. Es behandelt die Einrichtung von Phasen der Quellcodeverwaltung, Erstellung, Prüfung und Bereitstellung und zeigt Ihnen, wie Sie Integrationen wie Sicherheitsscanner, Benachrichtigungen und Analysen hinzufügen können.
• Konfiguration - Sämtliche Konfigurationsinformationen werden in Umgebungsvariablen gespeichert. Im App-Code werden keine Serviceberechtigungsnachweis fest codiert. Zum Speichern von Berechtigungsnachweisen können Sie geheime Kubernetes-Schlüssel verwenden. Weitere Informationen zu Berechtigungsnachweisen später.

Berechtigungsnachweise in geheimen Kubernetes-Schlüsseln speichern

Es ist in keinem Fall eine gute Idee, Berechtigungsnachweise im App-Code zu speichern. Stattdessen stellt Kubernetes sogenannte "Geheimnisse" bereit, die sensible Informationen wie Passwörter, OAuth-Token oder SSH-Schlüssel enthalten. Geheime Kubernetes-Schlüssel werden standardmäßig verschlüsselt, was geheime Schlüssel zu einer sichereren und flexibleren Option zum Speichern sensibler Daten macht, als solche Daten buchstäblich in einer pod oder einem Container-Image zu speichern.

Eine Möglichkeit zur Verwendung von geheimen Schlüsseln in Kubernetes ist zum Beispiel die folgende:

1. Erstellen Sie die Datei cloud-secrets.txt und speichern Sie darin die Serviceberechtigungsnachweise der Cloud-Services.

   {
       "url": "<SERVICE_URL>",
       "api_key": <API_Key>
   }
   

2. Erstellen Sie dann Kubernetes, indem Sie den folgenden Befehl ausführen, und überprüfen Sie, ob das Geheimnis erstellt wurde, indem Sie kubectl get secrets verwenden, nachdem Sie den folgenden Befehl ausgeführt haben:

   kubectl create secret generic cloud-service-secret --from-file=cloud-secrets.txt=./cloud-secrets.txt
   

Erstellung einer Kubernetes-Bereitstellungsdatei 'deployment.yaml'

Zum Erstellen von Kubernetes-Dateien 'deployment.yaml' müssen Sie wie folgt vorgehen:

1. Erstellen Sie deployment.yaml. Hier ist ein Beispiel für eine deployment YAML-Datei.

2. In Ihrer deployment.yaml können Sie Ressourcenquoten für Ihre Container definieren, um festzulegen, wie viel CPU und Speicher jeder Container benötigt, um ordnungsgemäß zu starten. Wenn für Container Ressourcenquoten angegeben wurden, kann der Kubernetes-Scheduler bessere Entscheidungen darüber treffen, auf welchen Workerknoten Ihre Pods platziert werden sollen.

3. Als Nächstes können Sie die folgenden Befehle verwenden, um die erstellte Bereitstellung und die erstellten Dienste zu erstellen und anzuzeigen:

   kubectl create -f <filepath/deployment.yaml>
   kubectl get deployments
   kubectl get services
   kubectl get pods