Hinweis:
- Dieses Tutorial erfordert Zugriff auf Oracle Cloud. Informationen zur Registrierung für einen kostenlosen Account finden Sie unter Erste Schritte mit Oracle Cloud Infrastructure Free Tier.
- Es verwendet Beispielwerte für Oracle Cloud Infrastructure-Zugangsdaten, -Mandanten und -Compartments. In der Übung ersetzen Sie diese Werte durch die Werte, die für Ihre Cloud-Umgebung spezifisch sind.
Oracle Cloud Infrastructure Container Engine for Kubernetes mit drei Worker-Knoten einrichten
Einführung
In diesem Tutorial wird erläutert, wie Sie mit Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE) ein Kubernetes-Cluster einrichten, das aus der Kubernetes-Control Plane und der Data Plane (Knotenpool) besteht. Außerdem werden wir zwei Beispielanwendungen auf der Kubernetes-Plattform bereitstellen und löschen, um zu beweisen, dass dies funktioniert. In diesem Tutorial werden die Voraussetzungen für zukünftige Tutorials geschaffen, die sich mit Netzwerkdiensten befassen, die in Kubernetes für von Containern gehostete Anwendungen angeboten werden.


Beispiele für OKE-Deployment-Modelle:
-
Beispiel 1: Cluster mit Flannel-CNI-Plug-in, öffentlichem Kubernetes-API-Endpunkt, privaten Worker-Knoten und öffentlichen Load Balancern
-
Beispiel 2: Cluster mit privatem Kubernetes-API-Endpunkt, privatem Worker-Knoten und öffentlichen Load Balancern.
-
Beispiel 3: Cluster mit privatem Kubernetes-API-Endpunkt, privatem Worker-Knoten und öffentlichen Load Balancern.
-
Beispiel 4: Cluster mit privatem Kubernetes-API-Endpunkt, privatem Worker-Knoten und öffentlichen Load Balancern.
Weitere Informationen über die verschiedenen OKE-Deployment-Modelle, die Sie auswählen können, finden Sie unter Beispielkonfigurationen für Netzwerkressourcen.
In diesem Tutorial implementieren wir das Deployment-Modell Beispiel 3.
Ziele
- Wir stellen ein Kubernetes-Kontrollcluster und Worker-Knoten bereit, die vollständig in Oracle Cloud Infrastructure (OCI) bereitgestellt und konfiguriert sind. Das nennen wir Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE). Wir stellen zwei Beispielanwendungen in zwei verschiedenen Namespaces bereit, in denen eine Anwendung mit einem Helm-Diagramm in einem neuen Namespace bereitgestellt wird. Am Ende werden wir die Anwendungen oder Pods bereinigen. Wir werden keine Netzwerkservices für von Kubernetes betriebene Anwendungen oder Pods bereitstellen.
Aufgabe 1: Neues Kubernetes-Cluster erstellen und Komponenten prüfen
-
Klicken Sie auf das Hamburger-Menü.

- Klicken Sie auf Entwicklerservices.
- Klicken Sie auf Kubernetes-Cluster (OKE).

-
Klicken Sie auf Cluster erstellen.

- Wählen Sie Schnellerstellung.
- Klicken Sie auf Weiterleiten.

-
Geben Sie auf der Seite Cluster erstellen (schnell) die folgenden Informationen ein.
- Geben Sie einen Clusternamen ein.
- Wählen Sie ein Compartment aus.
- Wählen Sie die Kubernetes-Version.
- Wählen Sie den Kubernetes-API-Endpunkt aus, der ein öffentlicher Endpunkt sein soll.
- Wählen Sie den Knotentyp aus, der verwaltet werden soll.
- Bildlauf nach unten.

- Wählen Sie die Kubernetes-Worker-Knoten aus, die private Worker sein sollen.
- Bildlauf nach unten.

- Behalten Sie die Knotenanzahl (Worker-Knoten) als Standard 3 bei.
- Klicken Sie anschließend auf Weiter.

- Prüfen Sie die Clusterparameter.
- Bildlauf nach unten.

- Prüfen Sie die Parameter der Knotenpools.
- Bildlauf nach unten.

- Aktivieren Sie nicht das Kontrollkästchen Einfaches Cluster erstellen.
- Klicken Sie auf Cluster erstellen.

-
Prüfen Sie den Status der verschiedenen erstellten Komponenten.

- Stellen Sie sicher, dass alles einen grünen Scheck hat.
- Klicken Sie auf Schließen.

- Prüfen Sie, ob der Status CREATING lautet.
- Bildlauf nach unten.

-
Prüfen Sie den Status der Cluster- und Knotenpoolerstellung. Das Kubernetes-Kontrollcluster wird erstellt, und der Worker-Knotenpool wird später erstellt.

-
Nach einigen Minuten wird das Kubernetes-Kontrollcluster erfolgreich erstellt.

-
Der Worker-Knotenpool wird jetzt erstellt.

-
Nach einigen Minuten wird der Worker-Knotenpool erfolgreich erstellt.

- Klicken Sie auf Knotenpools.
- Beachten Sie, dass die Worker-Knoten im Pool noch erstellt werden.
- Klicken Sie auf 3 der Worker-Knoten.

-
Beachten Sie, dass alle Knoten den Status Nicht bereit haben.

-
Nach einigen Minuten sind sie bereit.

Das Kubernetes-Kontrollcluster und die Worker-Knoten werden vollständig in Oracle Cloud Infrastructure (OCI) bereitgestellt und konfiguriert. Das nennen wir Oracle Cloud Infrastructure Container Engine for Kubernetes.
Aufgabe 2: Bereitgestellte Kubernetes-Clusterkomponenten in der OCI-Konsole prüfen
Wenn wir mit OKE ein Kubernetes-Cluster erstellen, werden einige Ressourcen in OCI erstellt, um dieses Deployment zu unterstützen.
Die erste und wichtigste Ressource ist das virtuelle Cloud-Netzwerk (VCN). Da wir die Option Schnellerstellung gewählt haben, wurde ein neues VCN für OKE erstellt.
-
Melden Sie sich bei der OCI-Konsole an, und navigieren Sie zu Networking, Virtuelle Cloud-Netzwerke (VCN). Das neue VCN wird angezeigt, das erstellt wurde. Klicken Sie auf das VCN.

Im VCN werden drei Subnetze angezeigt, ein privates und zwei öffentliche Subnetze zur Unterstützung des OKE-Deployments.

-
Prüfen Sie die Ressourcen.
- Klicken Sie auf CIDR-Blöcke/Präfixe, um das CIDR des VCN zu prüfen.
- Beachten Sie, dass
10.0.0.0/16von OCI zugewiesen wurde.

- Klicken Sie auf Routentabellen, um die Routingtabellen zu prüfen.
- Beachten Sie, dass zwei Routing-Tabellen erstellt wurden: Route zu privaten Subnetzen und Route zu öffentlichen Subnetzen.

- Klicken Sie auf Internetgateways, um das Internetgateway zu prüfen, das die Internetkonnektivität über die öffentlichen Subnetze zum und vom Internet bereitstellt.
- Beachten Sie, dass es nur ein Internetgateway gibt.

- Klicken Sie auf Sicherheitslisten, um die Sicherheitslisten zu prüfen, bei denen es sich um Ingress- oder Egress-Regeln handeln kann, um die Konnektivität zwischen den Subnetzen zu schützen.
- Beachten Sie, dass drei Sicherheitslisten vorhanden sind: eine für den Schutz der Kubernetes-Worker-Knotenkonnektivität, die zweite für den Schutz der Kubernetes-API-Endpunkte und die dritte für den Schutz der Kubernetes-Services.

- Klicken Sie auf NAT-Gateways, um das NAT-Gateway zu prüfen, das die Internetverbindung über die privaten Subnetze zum Internet bereitstellt.
- Beachten Sie, dass nur ein NAT-Gateway vorhanden ist.

- Klicken Sie auf Servicegateways, um das Servicegateway zu prüfen, das privaten Zugriff auf bestimmte Oracle-Services bietet, ohne die Daten einem Internetgateway oder NAT-Gateway zugänglich zu machen.
- Beachten Sie, dass nur ein Servicegateway vorhanden ist.

- Öffnen Sie die OCI-Konsole, klicken Sie auf das Hamburger-Menü, und navigieren Sie zu Compute, Instanzen.
- Beachten Sie, dass drei erstellte Instanzen als die drei Kubernetes-Worker-Knoten verwendet werden, die wir während des Deployments angegeben haben.

- Öffnen Sie die OCI-Konsole, klicken Sie auf das Hamburger-Menü, und navigieren Sie zu IP-Management, Reservierte öffentliche IPs.
- Beachten Sie, dass eine öffentliche IP-Adresse mit
.166endet, die für den öffentlichen Kubernetes-API-Endpunkt reserviert ist.

Wenn wir alle Informationen, die wir gerade gesammelt haben, platzieren und diese in einem Diagramm platzieren, sieht das Diagramm wie im folgenden Bild dargestellt aus.

-
Tabellen mit Konfigurationsdetails zum Bereitstellen von OKE
-
VCN:
Ressource Name VCN • Name: OKE-vcn-quick-IH-OKE-CLUSTER-af593850a
• CIDR-Block: 10.0.0.0/16
• DNS-Auflösung: AusgewähltInternetgateway • Name: OKE-igw-quick-IH-OKE-CLUSTER-af593850a NAT-Gateway • Name: OKE-ngw-quick-IH-OKE-CLUSTER-af593850a Servicegateway • Name: OKE-sgw-quick-IH-OKE-CLUSTER-af593850a
• Services: Alle Regionsservices in Oracle Services NetworkDHCP-Optionen • DNS-Typ auf Internet- und VCN-Resolver gesetzt -
Subnetze:
Ressource Beispiel Öffentliches Subnetz für Kubernetes-API-Endpunkt Zweck: Kubernetes-API-Endpunkt mit den folgenden Eigenschaften:
• Typ: Regional
• CIDR-Block: 10.0.0.0/28
• Routentabelle: OKE-public-routetable-IH-OKE-CLUSTER-af593850a
• Subnetzzugriff: Öffentlich
• DNS-Auflösung: Ausgewählt
• DHCP-Optionen: Standard
• Sicherheitsliste: OKE-k8sApiEndpoint-quick-IH-OKE-CLUSTER-af593850aPrivates Subnetz für Worker-Knoten Zweck: Workernodes mit den folgenden Eigenschaften:
• Typ: Regional
• CIDR-Block: 10.0.10.0/24
• Routentabelle: N/V
• Subnetzzugriff: Privat
• DNS-Auflösung: Ausgewählt
• DHCP-Optionen: Standard
• Sicherheitsliste: OKE-nodeseclist-quick-IH-OKE-CLUSTER-af593850aPrivates Subnetz für Pods Zweck: Pods mit den folgenden Eigenschaften:
• Typ: Regional
• CIDR-Block: 10.96.0.0/16
• Routentabelle: OKE-private-routetable-IH-OKE-CLUSTER-af593850a
• Subnetzzugriff: Privat
• DNS-Auflösung: Ausgewählt
• DHCP-Optionen: Standard
• Sicherheitsliste: Nicht anwendbarÖffentliches Subnetz für Service-Load-Balancer Zweck: Load Balancer mit den folgenden Eigenschaften:
• Typ: Regional
• CIDR-Block: 10.0.20.0/24
• Routentabelle: OKE-private-routetable-IH-OKE-CLUSTER-af593850a
• Subnetzzugriff: Öffentlich
• DNS-Auflösung: Ausgewählt
• DHCP-Optionen: Standard
• Sicherheitsliste: OKE-svclbseclist-quick-IH-OKE-CLUSTER-af593850a -
Routentabellen:
Ressource Beispiel Routentabelle für öffentliches Kubernetes-API-Endpunktsubnetz Zweck: routetable-Kubernetes-API-Endpunkt, wobei eine Routingregel wie folgt definiert ist:
• Ziel-CIDR-Block: 0.0.0.0/0
• Zieltyp: Internetgateway
• Ziel: OKE-igw-quick-IH-OKE-CLUSTER-af593850aRoutentabelle für privates Pods-Subnetz Zweck: routetable-pods, mit zwei Routingregeln, die wie folgt definiert sind:
• Regel für Traffic zum Internet:
◦ Ziel-CIDR-Block: 0.0.0.0/0
◦ Zieltyp: NAT-Gateway
◦ Ziel: OKE-ngw-quick-IH-OKE-CLUSTER-af593850a
• Regel für Traffic zu OCI-Services:
◦ Ziel: Alle Regionsservices in Oracle Services Network
◦ Zieltyp: Servicegateway
◦ Ziel: OKE-sgw-quick-IH-OKE-CLUSTER-af593850aRoutentabelle für öffentliches Load-Balancer-Subnetz Zweck: routetable-serviceloadbalancers, wobei eine Routingregel wie folgt definiert ist:
• Ziel-CIDR-Block: 0.0.0.0/0
• Zieltyp: Internetgateway
• Ziel: OKE-igw-quick-IH-OKE-CLUSTER-af593850a
-
-
Sicherheitslistenregeln für öffentliche Kubernetes-API-Endpunktsubnetze
Die
oke-k8sApiEndpoint-quick-IH-OKE-CLUSTER-af593850a-Sicherheitsliste enthält die Ingress- und Egress-Regeln, wie in den folgenden Tabellen gezeigt.-
Ingress-Regeln:
Zustandslos Quelle IP-Protokoll Quellportbereich Zielportbereich Typ und Code Lässt Folgendes zu Beschreibung Nr. 0.0.0.0/0 TCP Alle 6.443 TCP-Traffic für folgende Ports: 6443 Externer Zugriff auf Kubernetes-API-Endpunkt Nr. 10.0.10.0/24 TCP Alle 6.443 TCP-Traffic für folgende Ports: 6443 Kubernetes-Worker-zu-Kubernetes-API-Endpunktkommunikation Nr. 10.0.10.0/24 TCP Alle 12.250 TCP-Traffic für folgende Ports: 12250 Kubernetes-Worker zur Steuerung der Flugzeugkommunikation Nr. 10.0.10.0/24 ICMP 3, 4 ICMP-Traffic für: 3, 4 (Ziel nicht erreichbar: Fragmentierung erforderlich, aber "Don't Fragment" gesetzt) Pfad-Discovery -
Egress-Regeln:
Zustandslos Ziel IP-Protokoll Quellportbereich Zielportbereich Typ und Code Lässt Folgendes zu Beschreibung Nr. Alle AMS-Services im Oracle Services Network TCP Alle 443 TCP-Traffic für folgende Ports: 443 HTTPS Kommunikation von Kubernetes-Control-Plane mit OKE zulassen Nr. 10.0.10.0/24 TCP Alle Alle TCP-Traffic für folgende Ports: alle Gesamter Traffic zu Worker-Knoten Nr. 10.0.10.0/24 ICMP 3, 4 ICMP-Traffic für: 3, 4 (Ziel nicht erreichbar: Fragmentierung erforderlich, aber "Don't Fragment" gesetzt) Pfad-Discovery
-
-
Sicherheitslistenregeln für private Worker-Knotensubnetze
Die
oke-nodeseclist-quick-IH-OKE-CLUSTER-af593850a-Sicherheitsliste enthält die Ingress- und Egress-Regeln, wie in den folgenden Tabellen gezeigt.Ingress-Regeln:
Zustandslos Quelle IP-Protokoll Quellportbereich Zielportbereich Typ und Code Lässt Folgendes zu Beschreibung Nr. 10.0.10.0/24 Alle Protokolle Gesamter Traffic für alle Ports Kommunikation zwischen Pods auf einem Worker-Knoten und Pods auf anderen Worker-Knoten zulassen Nr. 10.0.0.0/28 ICMP 3, 4 ICMP-Traffic für: 3, 4 (Ziel nicht erreichbar: Fragmentierung erforderlich, aber "Don't Fragment" gesetzt) Pfad-Discovery Nr. 10.0.0.0/28 TCP Alle Alle TCP-Traffic für folgende Ports: alle TCP-Zugriff von Kubernetes Control Plane Nr. 0.0.0.0/0 TCP Alle 22 TCP-Traffic für folgende Ports: 22 (SSH-Remoteanmeldungsprotokoll) Eingehender SSH-Traffic für Worker-Knoten Nr. 10.0.20.0/24 TCP Alle 32.291 TCP-Traffic für folgende Ports: 32291 Nr. 10.0.20.0/24 TCP Alle 10.256 TCP-Traffic für folgende Ports: 10256 Nr. 10.0.20.0/24 TCP Alle 31.265 TCP-Traffic für folgende Ports: 31265 Egress-Regeln:
Zustandslos Ziel IP-Protokoll Quellportbereich Zielportbereich Typ und Code Lässt Folgendes zu Beschreibung Nr. 10.0.10.0/24 Alle Protokolle Gesamter Traffic für alle Ports Kommunikation zwischen Pods auf einem Worker-Knoten und Pods auf anderen Worker-Knoten zulassen Nr. 10.0.0.0/28 TCP Alle 6.443 TCP-Traffic für folgende Ports: 6443 Zugriff auf Kubernetes-API-Endpunkt Nr. 10.0.0.0/28 TCP Alle 12.250 TCP-Traffic für folgende Ports: 12250 Kubernetes-Worker zur Steuerung der Flugzeugkommunikation Nr. 10.0.0.0/28 ICMP 3, 4 ICMP-Traffic für: 3, 4 (Ziel nicht erreichbar: Fragmentierung erforderlich, aber "Don't Fragment" gesetzt) Pfad-Discovery Nr. Alle AMS-Services im Oracle Services Network TCP Alle 443 TCP-Traffic für folgende Ports: 443 HTTPS Kommunikation der Knoten mit OKE zulassen, um den ordnungsgemäßen Start und die Fortsetzung des Betriebs sicherzustellen Nr. 0.0.0.0/0 ICMP 3, 4 ICMP-Traffic für: 3, 4 (Ziel nicht erreichbar: Fragmentierung erforderlich, aber "Don't Fragment" gesetzt) ICMP-Zugriff über Kubernetes-Control-Plane Nr. 0.0.0.0/0 Alle Protokolle Gesamter Traffic für alle Ports Worker-Knotenzugriff auf Internet -
Sicherheitslistenregeln für öffentliche Load-Balancer-Subnetze
Die
oke-svclbseclist-quick-IH-OKE-CLUSTER-af593850a-Sicherheitsliste enthält die Ingress- und Egress-Regeln, wie in den folgenden Tabellen gezeigt.-
Ingress-Regeln:
Zustandslos Quelle IP-Protokoll Quellportbereich Zielportbereich Typ und Code Lässt Folgendes zu Beschreibung Nr. 0.0.0.0/0 TCP Alle 80 TCP-Traffic für folgende Ports: 80 -
Egress-Regeln:
Zustandslos Ziel IP-Protokoll Quellportbereich Zielportbereich Typ und Code Lässt Folgendes zu Beschreibung Nr. 10.0.10.0/24 TCP Alle 32.291 TCP-Traffic für folgende Ports: 32291 Nr. 10.0.10.0/24 TCP Alle 10.256 TCP-Traffic für folgende Ports: 10256 Nr. 10.0.10.0/24 TCP Alle 31.265 TCP-Traffic für folgende Ports: 31265
-
Aufgabe 3: Prüfen, ob das Kubernetes-Cluster mit der CLI ausgeführt wird
-
Öffnen Sie die OCI-Konsole, klicken Sie auf das Hamburger-Menü, und navigieren Sie zu Entwicklerservices, Kubernetes-Cluster (OKE). Klicken Sie auf das in Aufgabe 1 erstellte Kubernetes-Cluster.

- Bildlauf nach unten.
- Klicken Sie auf Schnellstart.

-
Klicken Sie auf Auf Cluster zugreifen.

- Wählen Sie Cloud Shell-Zugriff aus.
- Klicken Sie auf Kopieren, um den Befehl zu kopieren und den Zugriff auf das Kubernetes-Cluster zuzulassen.
- Klicken Sie auf Cloud Shell starten.

Das folgende Diagramm zeigt, wie die Verbindung hergestellt wird, um das Management im OKE-Cluster mit OCI Cloud Shell auszuführen.

-
Die OCI Cloud Shell wird gestartet.

Es werden einige Informationsmeldungen darüber angezeigt, was im Hintergrund passiert.

In diesem Fall kann OCI Cloud Shell auf verschiedenen CPU-Architekturen ausgeführt werden.
-
Klicken Sie auf Schließen, um diese Informationsmeldung zu schließen.

-
Wir können die OCI Cloud Shell für den Zugriff auf das Kubernetes-Cluster verwenden.

-
Fügen Sie den oben kopierten Befehl in diese Aufgabe ein.

-
Führen Sie den folgenden Befehl aus, um Informationen zum Kubernetes-Cluster abzurufen.
kubectl cluster-info
-
Führen Sie den folgenden Befehl aus, um Informationen zu den Worker-Knoten abzurufen.
kubectl get nodes
-
Führen Sie den folgenden Befehl aus, um weitere Informationen zu den Worker-Knoten abzurufen.
kubectl get nodes -o wide
-
Führen Sie den folgenden Befehl aus, um den Bildschirm zu leeren und mit einem neuen Bildschirm zu beginnen.
clear
- Beachten Sie, dass die vorherige Ausgabe gelöscht wurde, aber weiterhin verfügbar ist, wenn Sie nach oben scrollen.
- Klicken Sie auf das Symbol "Minimieren", um das OCI Cloud Shell-Fenster zu minimieren.

-
Klicken Sie auf Schließen, um das Fenster Auf Cluster zugreifen zu schließen.

Die Verbindung wird hergestellt, um das Management im OKE-Cluster mit OCI Cloud Shell auszuführen.

Aufgabe 4: Nginx-Beispielanwendung mit kubectl bereitstellen
-
Führen Sie die folgenden Befehle aus.
- Notieren Sie sich den Befehl, um die Kubernetes-Version abzurufen.
- Notieren Sie sich den Befehl, um eine Beispielanwendung bereitzustellen.
- Klicken Sie auf Wiederherstellen, um das Fenster "OCI Cloud Shell" wiederherzustellen.

-
Führen Sie den folgenden Befehl zum Abrufen der Kubernetes-Version aus.
kubectl version
-
Führen Sie den folgenden Befehl aus, um die aktuell bereitgestellten Pods oder Anwendungen zu prüfen.
kubectl get podsBeachten Sie, dass keine Ressourcen gefunden werden.

-
Führen Sie den folgenden Befehl aus, um eine neue Beispielanwendung bereitzustellen.
kubectl create -f https://k8s.io/examples/application/deployment.yaml
-
Führen Sie den folgenden Befehl aus, um die aktuell bereitgestellten Pods oder Anwendungen zu prüfen.
kubectl get pods -
Beachten Sie, dass sich Pods im Status RUNNING befinden. Das bedeutet, dass die gerade bereitgestellte Anwendung ausgeführt wird.

-
Führen Sie den folgenden Befehl aus, um die IP-Adressen für den Zugriff auf die Anwendung abzurufen.
kubectl get deploy,svc -
Beachten Sie, dass der neu bereitgestellten Anwendung keine IP-Adressen zugewiesen sind und dass nur dem Kubernetes-Cluster ein Cluster-IP-Service mit einer internen IP-Adresse zugeordnet ist.

-
Führen Sie den folgenden Befehl aus, um die angehängten (Netzwerk-)Services speziell für die neu bereitgestellte Anwendung zu prüfen.
kubectl get svc ngnix -
Beachten Sie, dass keine (Netzwerk-)Services für die bereitgestellte Nginx-Anwendung bereitgestellt oder angehängt sind. Aus diesem Grund können wir nicht von einer anderen Anwendung aus auf die Anwendung zugreifen oder den Webbrowser verwenden, um auf die Webseite im Nginx-Webserver zuzugreifen. Wir werden dies in einem anderen Tutorial besprechen.

Aufgabe 5: Beispielanwendung MySQL mit Helm-Diagramm bereitstellen
-
Ein Helm-Diagramm ist ein Package, das alle erforderlichen Ressourcen enthält, um eine Anwendung in einem Kubernetes-Cluster bereitzustellen. Führen Sie folgende Befehle aus, um:
-
Fügen Sie das Bitnami-Repository für die Datenbank MySQL hinzu.
helm repo add bitnami https://charts.bitnami.com/bitnami -
Stellen Sie eine MySQL-Datenbank auf den Kubernetes-Worker-Knoten bereit, und erstellen Sie außerdem einen neuen Namespace "mysql".
helm install mysql bitnami/mysql -–namespace mysql --create-namespace

-
-
Um die bereitgestellten Anwendungen abzurufen, führen Sie den folgenden Befehl aus. Mit diesem Befehl werden nur die bereitgestellten Anwendungen im aktuellen (Standard-)Namespace angezeigt.
kubectl get pods -
Beachten Sie, dass nur die Nginx-Anwendung im aktuellen (Standard-)Namespace angezeigt wird. Mit diesem Befehl werden jetzt die bereitgestellten Anwendungen clusterweit angezeigt (alle Namespaces).
kubectl get pods -A -w- Beachten Sie, dass die Nginx-Anwendung im Standard-Namespace ausgeführt wird.
- Beachten Sie, dass die Anwendung MySQL im neuen mysql-Namespace ausgeführt wird.

Aufgabe 6: Pods und Namespaces leeren
Wir haben eine Anwendung im Standard-Namespace (Nginx) und eine andere Anwendung in einem neuen Namespace (MySQL) bereitgestellt. Lassen Sie uns mithilfe von Helm-Charts die Umgebung bereinigen, damit wir neu anfangen können, wann immer wir es brauchen.
-
Mit dem folgenden Befehl können Sie alle Worker-Knoten abrufen (clusterweit).
kubectl get nodes -o wide -
Mit dem folgenden Befehl können Sie alle ausgeführten Pods im aktuellen (Standard-)Namespace abrufen.
kubectl get pods -o wide -
Führen Sie den folgenden Befehl aus, um alle Namespaces abzurufen.
kubectl get namespaces -
Führen Sie den folgenden Befehl aus, um alle ausgeführten Pods speziell im aktuellen (Standard-)Namespace abzurufen.
kubectl get pods --namespace=default -
Führen Sie den folgenden Befehl aus, um alle ausgeführten Pods speziell im MySQL-Namespace abzurufen.
kubectl get pods --namespace=mysql



-
Führen Sie den folgenden Befehl aus, um alle Deployments oder Pods im Standard-Namespace zu löschen.
kubectl delete --all deployments --namespace=default -
Mit dem folgenden Befehl können Sie prüfen, ob die Deployments oder Pods gelöscht werden.
kubectl get pods --namespace=default -
Mit dem folgenden Befehl können Sie alle ausgeführten Pods speziell im MySQL-Namespace abrufen. Prüfen Sie einfach, ob dies noch vorhanden ist.
kubectl get pods --namespace=mysql

-
Führen Sie den folgenden Befehl aus, um alle Deployments oder Pods und den vollständigen MySQL-Namespace zu löschen.
kubectl delete namespace mysql -
Mit diesem Befehl können Sie alle Namespaces erfassen und prüfen, ob der MySQL-Namespace gelöscht wurde.
kubectl get namespaces

Bestätigungen
- Autor - Iwan Hoogendoorn (OCI Network Specialist)
Weitere Lernressourcen
Sehen Sie sich weitere Übungen zu docs.oracle.com/learn an, oder greifen Sie auf weitere kostenlose Lerninhalte im Oracle Learning YouTube-Kanal zu. Besuchen Sie außerdem education.oracle.com/learning-explorer, um ein Oracle Learning Explorer zu werden.
Die Produktdokumentation finden Sie im Oracle Help Center.
Set up Oracle Cloud Infrastructure Container Engine for Kubernetes with Three Worker Nodes
F95670-02