Ziele

• Erfahren Sie mehr über Anwendungsbereitstellungen.
• Stellen Sie Ihre erste App auf Kubernetes mit kubectl bereit.

Kubernetes-Bereitstellungen (Deployments)

Sobald Sie einen Kubernetes-Cluster ausgeführt haben, können Sie Ihre containerisierten Anwendungen darüber bereitstellen.                 Dazu erstellen Sie eine Kubernetes Deployment-Konfiguration. Das Deployment weist Kubernetes an, wie Instanzen Ihrer Anwendung erstellt und aktualisiert werden. Nachdem Sie ein Deployment erstellt haben, plant der Kubernetes-Master die genannten Anwendungsinstanzen für einzelne Nodes im Cluster.

Sobald die Anwendungsinstanzen erstellt wurden, überwacht ein Kubernetes Deployment Controller diese Instanzen kontinuierlich. Wenn der Node, der eine Instanz hostet, ausfällt oder gelöscht wird, ersetzt der Deployment Controller die Instanz durch eine Instanz auf einem anderen Node im Cluster. Dies bietet einen Selbstheilungsmechanismus, um Maschinenausfälle oder -wartungen zu vermeiden.

In einer Welt vor der Orchestrierung wurden häufig Installationsskripts zum Starten von Anwendungen verwendet, sie erlaubten jedoch keine Wiederherstellung nach einem Maschinenausfall. Kubernetes Deployments erstellen Ihre Anwendungsinstanzen und sorgen dafür, dass sie über mehrere Nodes hinweg ausgeführt werden. Dadurch bieten Kubernetes Deployments einen grundlegend anderen Ansatz für die Anwendungsverwaltung.

Erste App auf Kubernetes bereitstellen

Sie können eine Bereitstellung mithilfe der Kubernetes-Befehlszeilenschnittstelle Kubectl erstellen und verwalten. Kubectl verwendet die Kubernetes-API, um mit dem Cluster zu interagieren.                     In diesem Modul lernen Sie die gebräuchlichsten Kubectl-Befehle kennen, die zum Erstellen von Deployments zum Ausführen Ihrer Anwendungen in einem Kubernetes-Cluster erforderlich sind.

Wenn Sie ein Deployment erstellen, müssen Sie das Container-Image für Ihre Anwendung und die Anzahl der Replikate angeben, die Sie ausführen möchten. Sie können diese Informationen später ändern, indem Sie Ihr Deployment aktualisieren; In den Modulen 5 und 6 des Bootcamps wird diskutiert, wie Sie Ihre Deployments skalieren und aktualisieren können.

Für unser erstes Deployment verwenden wir eine Node.js-Anwendung, die in einem Docker-Container verpackt ist. Um die Node.js-Anwendung zu erstellen und den Docker-Container bereitzustellen, folgen Sie den Anweisungen im Hello Minikube tutorial.

Nun, da Sie wissen, was Deployments sind, gehen wir zum Online-Tutorial und stellen unsere erste App bereit!

Ziele:

• Erfahren Sie mehr über Kubernetes Pods.
• Erfahren Sie mehr über Kubernetes-Nodes.
• Beheben Sie Fehler in bereitgestellten Anwendungen.

Kubernetes Pods

Als Sie ein Deployment in Modul 2, hat Kubernetes einen Pod erstellt, der Ihre Anwendungsinstanz hostet. Ein Pod ist eine Kubernetes-Abstraktion, die eine Gruppe von einem oder mehreren Anwendungscontainern (z. B. Docker oder rkt) und einigen gemeinsam genutzten Ressourcen für diese Container darstellt. Diese Ressourcen umfassen:

• Gemeinsamer Speicher, als Volumes
• Networking, als eindeutige Cluster-IP-Adresse
• Informationen zur Ausführung der einzelnen Container, wie z.B. die Container-Image-Version oder bestimmte Ports, die verwendet werden sollen.

Ein Pod stellt einen anwendungsspezifischen "logischen Host" dar und kann verschiedene Anwendungscontainer enthalten, die relativ eng gekoppelt sind. Ein Pod kann beispielsweise sowohl den Container mit Ihrer Node.js-Applikation als auch einen anderen Container beinhalten, der die vom Webserver Node.js zu veröffentlichenden Daten einspeist. Die Container in einem Pod teilen sich eine IP-Adresse und einen Portbereich, sind immer kolokalisiert und gemeinsam geplant und laufen in einem gemeinsamen Kontext auf demselben Node.

Pods-Übersicht

Nodes

Ein Pod läuft immer auf einem Node. Ein Node ist eine Arbeitsmaschine in Kubernetes und kann je nach Cluster entweder eine virtuelle oder eine physische Maschine sein. Jeder Node wird vom Master verwaltet. Ein Node kann über mehrere Pods verfügen, und der Kubernetes-Master übernimmt automatisch die Planung der Pods für die Nodes im Cluster. Die automatische Zeitplanung des Masters berücksichtigt die verfügbaren Ressourcen auf jedem Node.

Auf jedem Kubernetes Node läuft mindestens:

• Kubelet, ein Prozess, der für die Kommunikation zwischen dem Kubernetes Master und dem Node verantwortlich ist; Er verwaltet die Pods und die auf einer Maschine laufenden Container.
• Eine Containerlaufzeit (wie Docker, rkt), die für das Abrufen des Containerabbilds aus einer Registry, das Entpacken des Containers und das Ausführen der Anwendung verantwortlich ist.

Node Überblick

Troubleshooting mit kubectl

In Modul 2 erstellt haben, haben Sie die Befehlszeilenschnittstelle von Kubectl verwendet. Sie verwenden sie weiterhin in Modul 3, um Informationen zu den bereitgestellten Anwendungen und ihren Umgebungen zu erhalten. Die häufigsten Operationen können mit den folgenden kubectl-Befehlen ausgeführt werden:

• kubectl get - Ressourcen auflisten
• kubectl describe - Detaillierte Informationen zu einer Ressource anzeigen
• kubectl logs - Die Logdateien von einem Container in einem Pod anzigen
• kubectl exec - Einen Befehl für einen Container in einem Pod ausführen

Mit diesen Befehlen können Sie sehen, wann Anwendungen bereitgestellt wurden, ihren aktuellen Status anzeigen, sehen wo sie ausgeführt werden und wie sie konfiguriert sind.

Nun, da wir mehr über unsere Clusterkomponenten und die Befehlszeile wissen, wollen wir unsere Anwendung untersuchen.

Ziele:

• Erfahren Sie mehr über einen Service in Kubernetes
• Verstehen, wie Labels und LabelSelector-Objekte sich auf einen Dienst beziehen
• Stellen Sie eine Anwendung außerhalb eines Kubernetes-Clusters mithilfe eines Services bereit

Überblick über Kubernetes Services

Kubernetes Pods sind sterblich. Pods haben tatsächlich einen Lebenszyklus. Wenn ein Worker-Node stirbt, gehen auch die auf dem Knoten laufenden Pods verloren. Ein ReplicaSet kann dann durch Erstellen neuer Pods dynamisch den Cluster in den gewünschten Status zurückversetzen, damit die Anwendung weiterhin ausgeführt werden kann. Als ein anderes Beispiel betrachten wir ein Bildverarbeitungs-Backend mit 3 Reproduktionen. Diese Repliken sind austauschbar; Das Front-End-System sollte sich nicht für Backend-Replikate interessieren, selbst wenn ein Pod verloren geht und neu erstellt wird. Allerdings hat jeder Pod in einem Kubernetes-Cluster eine eindeutige IP-Adresse, sogar Pods auf demselben Knoten. Daher müssen Änderungen automatisch zwischen den Pods abgeglichen werden, damit Ihre Anwendungen weiterhin funktionieren.

Ein Dienst in Kubernetes ist eine Abstraktion, die einen logischen Satz von Pods und eine Richtlinie für den Zugriff auf diese definiert. Services ermöglichen eine lose Kopplung zwischen abhängigen Pods. Ein Service ist in YAML (bevorzugt) oder JSON spezifiziert, wie alle Kubernetes-Objekte. Die Gruppe von Pods, auf die ein Service abzielt, wird normalerweise von einem LabelSelector bestimmt (Siehe unten, warum Sie möglicherweise wünschen, einen Service ohne selector in die Spezifikation aufzunehmen).

Obwohl jeder Pod über eine eindeutige IP-Adresse verfügt, werden diese IP-Adressen nicht außerhalb des Clusters ohne einen Service verfügbar gemacht. Services ermöglichen es Ihren Anwendungen, Datenverkehr zu empfangen. Services können auf unterschiedliche Weise verfügbar gemacht werden, indem Sie einen type in der ServiceSpec angeben:

• ClusterIP (Standardeinstellung) - Macht den Service auf einer internen IP im Cluster verfügbar. Durch diesen Typ ist der Service nur innerhalb des Clusters erreichbar.
• NodePort - Macht den Dienst auf demselben Port jedes ausgewählten Knotens im Cluster mithilfe von NAT verfügbar. Macht einen Dienst von außerhalb des Clusters mit <NodeIP>:<NodePort> zugänglich. Oberhalb von ClusterIP positioniert.
• LoadBalancer - Erstellt einen externen Load-Balancer in der aktuellen Cloud (sofern unterstützt) und weist dem Service eine feste externe IP zu. Oberhalb von NodePort positioniert.
• ExternalName - Macht den Dienst mit einem beliebigen Namen verfügbar (Spezifiziert durch externalName in der Konfiguration) indem Sie einen CNAME-Datensatz mit dem Namen zurückgeben. Kein Proxy wird verwendet. Für diesen Typ ist v1.7 von kube-dns oder höher erforderlich.

Weitere Informationen zu den verschiedenen Arten von Services finden Sie im Verwendung von Source IP Tutorial. Siehe auch Anwendungen mit Services verbinden.

Beachten Sie außerdem, dass es einige Anwendungsfälle mit Services gibt, bei denen keine selector Spezifikation in der Konfiguration nötig ist. Ein Service ohne selector erstellt auch nicht das entsprechende Endpunktobjekt. Auf diese Weise können Benutzer einen Service manuell bestimmten Endpunkten zuordnen. Eine andere Möglichkeit, warum es keinen Selektor gibt, ist die strikte Verwendung type: ExternalName.

Services und Labels

Ein Service leitet den Traffic über eine Reihe von Pods. Services sind die Abstraktion, die es Pods ermöglichen, in Kubernetes zu sterben und sich zu replizieren, ohne die Anwendung zu beeinträchtigen. Die Erkennung und das Routing zwischen abhängigen Pods (z. B. Frontend- und Backend-Komponenten in einer Anwendung) werden von Kubernetes Services ausgeführt.

Services passen zu einem Satz von Pods mit Labels und Selektoren, eine einfache Gruppierung, die logische Operationen an Objekten in Kubernetes ermöglicht. Labels sind Schlüssel/Wert-Paare, die an Objekte angehängt werden, und können auf verschiedene Arten verwendet werden:

• Festlegen von Objekten für Entwicklung, Test und Produktion
• Versions-Tags einbetten
• Klassifizieren von Objekten mithilfe von Tags

Labels können zum Zeitpunkt der Erstellung oder zu einem späteren Zeitpunkt an Objekte angehängt werden. Sie können jederzeit geändert werden. Lassen Sie uns jetzt unsere Anwendung mit einem Service verfügbar machen und einige Labels anbringen.

Ziele:

• Skalieren einer App mit kubectl.

Eine Anwendung skalieren

In den vorherigen Modulen haben wir ein Deployment erstellt, und es dann öffentlich mittels einem Service bereitgestellt. Das Deployment hat nur einen Pod für die Ausführung unserer Anwendung erstellt. Wenn der Anfragen zunehmen, müssen wir die Anwendung skalieren, um den Anforderungen der Benutzer gerecht zu werden.

Skalieren wird durch Ändern der Anzahl der Repliken in einer Bereitstellung erreichtt

Skalierung - Übersicht

Durch das Skalieren eines Deployments wird sichergestellt, dass neue Pods erstellt und auf Nodes mit verfügbaren Ressourcen geplant werden. Durch die Skalierung wird die Anzahl der Pods auf den neuen gewünschten Status erhöht. Kubernetes unterstützt auch die automatische Skalierung von Pods, dies ist jedoch außerhalb des Anwendungsbereichs dieses Lernprogramms. Die Skalierung auf Null ist ebenfalls möglich und beendet alle Pods der angegebenen Bereitstellung.

Das Ausführen mehrerer Instanzen einer Anwendung erfordert eine Möglichkeit, den Datenverkehr auf alle Anwendungen zu verteilen. Services verfügen über eine integrierte Lastverteilung, der den Netzwerkverkehr auf alle Pods eines bereitgestellten Deployments verteilt. Die Services überwachen kontinuierlich die laufenden Pods mithilfe von Endpunkten, um sicherzustellen, dass der Datenverkehr nur an die verfügbaren Pods gesendet wird.

Wenn Sie mehrere Instanzen einer Anwendung ausgeführt haben, können Sie Rolling-Updates ohne Ausfallzeiten durchführen. Wir werden das im nächsten Modul behandeln. Nun gehen wir zum Online-Terminal und skalieren unsere Anwendung.

Objectives

• Führen Sie ein Rolling-Update mit kubectl durch.

Anwendung aktualisieren

Anwender erwarten, dass Anwendungen jederzeit verfügbar sind, und Entwickler haben das Bedürfnis mehrmals täglich neue Versionen davon bereitstellen. In Kubernetes geschieht dies mit laufenden Aktualisierungen. Rolling Updates ermöglichen die Aktualisierung von Deployments ohne Ausfallzeit, indem Pod-Instanzen inkrementell mit neuen aktualisiert werden. Die neuen Pods werden auf Nodes mit verfügbaren Ressourcen geplant.

Im vorherigen Modul haben wir unsere Anwendung so skaliert, dass mehrere Instanzen ausgeführt werden können. Dies ist eine Voraussetzung, um Aktualisierungen durchzuführen, ohne die Anwendungsverfügbarkeit zu beeinträchtigen. Standardmäßig ist die maximale Anzahl von Pods, die während der Aktualisierung nicht verfügbar sein kann, und die maximale Anzahl neuer Pods, die erstellt werden können, 1. Beide Optionen können entweder nach Zahlen oder Prozentsätzen (von Pods) konfiguriert werden. In Kubernetes werden Updates versioniert und jedes Deployment-Update kann auf die vorherige (stabile) Version zurückgesetzt werden.

Rolling Updates - Übersicht

Ähnlich wie bei der Anwendungsskalierung wird der Datenverkehr, wenn ein Deployment öffentlich verfügbar gemacht wird, während der Aktualisierung auf die verfügbaren Pods lastverteilt. Ein verfügbarer Pod ist eine Instanz, die den Benutzern der Anwendung zur Verfügung steht.

Rolling Updates ermöglichen die folgenden Aktionen:

• Heraufstufen einer Anwendung von einer Umgebung in eine andere (über Aktualisierungen der Container-Images)
• Rollback auf frühere Versionen
• Kontinuierliche Integration und kontinuierliche Bereitstellung von Anwendungen ohne Ausfallzeiten

Im folgenden interaktiven Tutorial werden wir unsere Anwendung auf eine neue Version aktualisieren und auch einen Rollback durchführen.