Verwalteten Knotenpool aktualisieren

So ändern Sie die Eigenschaften von Knotenpools und Worker-Knoten vorhandener Kubernetes-Cluster:

1. Öffnen Sie das Navigationsmenü , und wählen Sie Entwicklerservices aus. Wählen Sie unter Container und Artefakte die Option Kubernetes-Cluster (OKE) aus.
2. Wählen Sie das Compartment aus, das das Cluster enthält.
3. Wählen Sie auf der Seite Clusterliste den Namen des Clusters, das Sie ändern möchten.
4. Wählen Sie auf der Seite Clusterdetails unter Ressourcen die Option Knotenpools aus.
5. Wählen Sie den Namen des Knotenpools aus, den Sie ändern möchten.

6. Verwenden Sie die Registerkarte Knotenpooldetails, um Informationen zum Knotenpool anzuzeigen, darunter:

   • Status des Knotenpools.
   • OCID des Knotenpools.
   • Der Typ der Worker-Knoten im Knotenpool (verwaltet oder virtuell).
   • Die Konfiguration, die derzeit beim Starten neuer Worker-Knoten im Knotenpool verwendet wird, einschließlich:
     • Die Kubernetes-Version, die auf Worker-Knoten ausgeführt werden soll
     • Die Ausprägung, die für Worker-Knoten verwendet werden soll
     • Das Image, das auf Worker-Knoten verwendet werden soll
   • Die Availability-Domains, Faultdomains und verschiedene regionale Subnetze (empfohlen) oder AD-spezifische Subnetze, die Worker-Knoten hosten

   Der Typ der Worker-Knoten im Knotenpool (verwaltet oder virtuell) bestimmt, welche Knotenpool- und Worker-Knoteneigenschaften Sie ändern können.

7. (Optional) Ändern Sie bei einem verwalteten Knotenpool und verwalteten Knoten die Eigenschaften wie folgt:

   1. Wählen Sie Bearbeiten aus, und geben Sie Folgendes an:
      • Name: Ein anderer Name für den Knotenpool. Geben Sie keine vertraulichen Informationen ein.

      • Version: Eine andere Version von Kubernetes, die auf neuen Worker-Knoten im Knotenpool ausgeführt werden soll, wenn ein In-Place-Upgrade durchgeführt wird. Die Kubernetes-Version auf Worker-Knoten muss entweder dieselbe Version wie auf den Control-Plane-Knoten oder eine frühere Version, die noch kompatibel ist, sein (siehe Kubernetes-Versionen und Kubernetes Engine (OKE)).

        Wenn Sie ein OKE-Image für Worker-Knoten angeben, muss die hier ausgewählte Kubernetes-Version mit der Kubernetes-Version im OKE-Image identisch sein.

        Wenn Sie neue Worker-Knoten starten möchten, auf denen die angegebene Kubernetes-Version ausgeführt wird, müssen Sie vorhandene Worker-Knoten im Knotenpool per drain-Befehl "leeren" (um zu verhindern, dass neue Pods gestartet und vorhandene Pods gelöscht werden) und dann jeden vorhandenen Worker-Knoten der Reihe nach beenden.

        Sie können auch eine andere Version von Kubernetes angeben, die auf neuen Worker-Knoten ausgeführt werden soll, indem Sie ein Out-of-Place-Upgrade durchführen. Weitere Informationen zum Upgrade von Worker-Knoten finden Sie unter Verwaltete Knoten auf eine neuere Kubernetes-Version upgraden.

      • Knotenanzahl: Eine andere Anzahl von Knoten im Knotenpool. Siehe Knotenpools skalieren.
      • Knotenplatzierungskonfiguration:
        • Availability-Domain: Die Availability-Domain, in der Worker-Knoten abgelegt werden.
        • Worker-Knotensubnetz: Ein regionales Subnetz (empfohlen) oder ein AD-spezifisches Subnetz, das zum Hoster von Worker-Knoten konfiguriert ist. Wenn Sie Load-Balancer-Subnetze angegeben haben, müssen die Worker-Knotensubnetze unterschiedlich sein. Die von Ihnen angegebenen Subnetze können privat (empfohlen) oder öffentlich sein. Siehe Subnetzkonfiguration.
        • Faultdomains: (Optional) Eine oder mehrere Faultdomains in der Availability-Domain, in der Worker-Knoten platziert werden sollen.

        Wählen Sie optional Erweiterte Optionen anzeigen aus, um einen zu verwendenden Kapazitätstyp anzugeben (siehe Worker-Knotenkapazitätstypen verwalten). Wenn Sie eine Kapazitätsreservierung angeben, beachten Sie, dass die Knotenausprägung, Availability-Domain und Faultdomain in der Platzierungskonfiguration des verwalteten Knotenpools mit dem Instanztyp, der Availability-Domain und der Faultdomain der Kapazitätsreservierung übereinstimmen müssen. Siehe Kapazitätsreservierungen für das Provisioning von verwalteten Knoten verwenden.

        Wählen Sie optional Weitere Zeile aus, um zusätzliche Domains und Subnetze auszuwählen, in denen Worker-Knoten abgelegt werden sollen.

        Wenn die Worker-Knoten erstellt werden, werden sie so gleichmäßig wie möglich auf die ausgewählten Availability-Domains und Faultdomains verteilt. Wenn Sie keine Faultdomains für eine bestimmte Availability-Domain auswählen, werden die Worker-Knoten so gleichmäßig wie möglich auf alle Faultdomains in dieser Availability-Domain verteilt.

      • Knotenausprägung: Eine andere Ausprägung für Worker-Knoten im Knotenpool. Die Ausprägung bestimmt die Anzahl von CPUs und den Speicherplatz, der jedem Knoten zugewiesen wird.

        Nur die in Ihrem Mandanten verfügbaren Ausprägungen, die von der Kubernetes-Engine unterstützt werden, werden angezeigt.

        Wenn Sie eine flexible Ausprägung auswählen, können Sie explizit die CPU-Anzahl und die Arbeitsspeichermenge angeben.

        Weitere Informationen finden Sie unter Unterstützte Images (einschließlich benutzerdefinierter Images) und Ausprägungen für Worker-Knoten.

      • Image: Ein anderes Image, das auf Worker-Knoten im Knotenpool verwendet werden kann. Ein Image ist eine Vorlage einer virtuellen Festplatte, die das Betriebssystem und andere Software für den Knoten bestimmt.

        Um das Bild zu ändern, wählen Sie Image ändern aus. Wählen Sie im Fenster Alle Images durchsuchen eine Imagequelle aus, und wählen Sie ein Bild wie folgt aus:

        • OKE-Worker-Knotenimages: Empfohlen. Wird von Oracle bereitgestellt und basiert auf Plattformimages. OKE-Images sind so optimiert, dass sie als Basisimages für Worker-Knoten mit allen erforderlichen Konfigurationen und der erforderlichen Software dienen. Wählen Sie ein OKE-Image aus, wenn Sie die Zeit für das Provisioning von Worker-Knoten zur Laufzeit im Vergleich zu Plattformimages und benutzerdefinierten Images minimieren möchten.

          OKE-Imagenamen enthalten die Versionsnummer der darin enthaltenen Kubernetes-Version. Wenn Sie eine Kubernetes-Version für den Knotenpool angeben, muss das hier ausgewählte OKE-Image dieselbe Versionsnummer wie die Kubernetes-Version des Knotenpools aufweisen.

        • Plattformimages: Von Oracle bereitgestellt und enthalten nur ein Oracle Linux-Betriebssystem. Wählen Sie ein Plattformimage aus, wenn die Kubernetes Engine die erforderliche Software herunterladen, installieren und konfigurieren soll, wenn die Compute-Instanz, die einen Worker-Knoten hostet, zum ersten Mal hochgefahren wird.

        Weitere Informationen finden Sie unter Unterstützte Images (einschließlich benutzerdefinierter Images) und Ausprägungen für Worker-Knoten.

      • Sicherheitsregeln in Netzwerksicherheitsgruppe (NSG) verwenden: Kontrollieren Sie den Zugriff auf den Knotenpool anhand von Sicherheitsregeln, die für eine oder mehrere von Ihnen angegebene Netzwerksicherheitsgruppen (NSGs) definiert sind (maximal fünf). Sie können Sicherheitsregeln verwenden, die für NSGs definiert sind, anstatt oder aber auch für Sicherheitslisten (NSGs werden empfohlen). Weitere Informationen zu den für die NSG anzugebenden Sicherheitsregeln finden Sie unter Sicherheitsregeln für Worker-Knoten.

      • Boot-Volume: Ändern Sie die Größe und Verschlüsselungsoptionen für das Boot-Volume des Worker-Knotens:

        • Um eine benutzerdefinierte Größe für das Boot-Volume anzugeben, aktivieren Sie das Kontrollkästchen Benutzerdefinierte Boot-Volume-Größe angeben. Geben Sie dann eine benutzerdefinierte Größe zwischen 50 GB und 32 TB an. Die angegebene Größe muss größer als die Standardgröße des Boot-Volumes für das ausgewählte Image sein. Weitere Informationen finden Sie unter Benutzerdefinierte Boot-Volume-Größen.

          Wenn Sie die Boot-Volume-Größe erhöhen, müssen Sie auch die Partition für das Boot-Volume (die Root-Partition) erweitern, um die größere Größe zu nutzen. Siehe Die Partition für ein Boot-Volume erweitern. Oracle Linux-Plattformimages enthalten das Package oci-utils. Sie können den Befehl oci-growfs aus diesem Package in einem benutzerdefinierten cloud-init-Skript verwenden, um die Root-Partition zu erweitern und das Dateisystem dann zu vergrößern. Weitere Informationen finden Sie unter Erweitern der Root-Partition von Worker-Knoten.

        • Für VM-Instanzen können Sie optional das Kontrollkästchen Verschlüsselung während der Übertragung verwenden aktivieren. Für Bare-Metal-Instanzen, die Verschlüsselung während der Übertragung unterstützen, ist diese Option standardmäßig aktiviert und kann nicht konfiguriert werden. Weitere Informationen zur Verschlüsselung während der Übertragung finden Sie unter Block-Volume-Verschlüsselung. Wenn Sie Ihren eigenen Vault-Verschlüsselungsschlüssel für das Boot-Volume verwenden, wird dieser Schlüssel auch für den Verschlüsselungsvorgang während der Übertragung verwendet. Andernfalls wird der von Oracle bereitgestellte Verschlüsselungsschlüssel verwendet.
        • Boot-Volumes werden standardmäßig verschlüsselt. Sie können jedoch optional Ihren eigenen Vault-Verschlüsselungsschlüssel verwenden, um die Daten in diesem Volume zu verschlüsseln. Um den Vault-Service für Ihre Verschlüsselungsanforderungen zu verwenden, aktivieren Sie das Kontrollkästchen Dieses Volume mit einem von Ihnen verwalteten Schlüssel verschlüsseln. Wählen Sie das Vault Compartment und den Vault mit dem zu verwendenden Masterverschlüsselungsschlüssel aus, und wählen Sie dann das Masterverschlüsselungsschlüssel-Compartment und den Masterverschlüsselungsschlüssel aus. Wenn Sie diese Option aktivieren, wird dieser Schlüssel sowohl für die Data-at-Rest-Verschlüsselung als auch für die Verschlüsselung während der Übertragung verwendet.
          Wichtig
          
          Der Block Volume-Service unterstützt keine Verschlüsselung von Volumes mit Schlüsseln, die mit dem Rivest-Shamir-Adleman-(RSA-)Algorithmus verschlüsselt wurden. Wenn Sie Ihre eigenen Schlüssel verwenden, müssen Sie Schlüssel verwenden, die mit dem Advanced Encryption Standard-(AES-)Algorithmus verschlüsselt wurden. Dies gilt für Block-Volumes und Boot-Volumes.

        Beachten Sie, dass eine IAM-Policy Zugriff auf den Serviceverschlüsselungsschlüssel erteilen muss, um Ihren eigenen Vault-Serviceverschlüsselungsschlüssel zur Verschlüsselung von Daten zu verwenden. Siehe Policy für den Zugriff auf vom Benutzer verwaltete Verschlüsselungsschlüssel zum Verschlüsseln von Boot-Volumes, Block-Volumes und/oder Dateisystemen erstellen.

      • Podkommunikation: Wenn der Netzwerktyp des Clusters natives VCN-Pod-Networking ist, ändern Sie, wie Pods im Knotenpool über ein Podsubnetz miteinander kommunizieren:
        • Subnetz: Ein regionales Subnetz, das zum Hosten von Pods konfiguriert ist. Das angegebene Podsubnetz muss privat sein. In einigen Situationen können das Worker-Knotensubnetz und das Podsubnetz dasselbe Subnetz sein. (In diesem Fall empfiehlt Oracle, Sicherheitsregeln in Netzwerksicherheitsgruppen und nicht in Sicherheitslisten zu definieren.) Siehe Subnetzkonfiguration.
        • Netzwerksicherheitsgruppe: Kontrollieren Sie den Zugriff auf das Podsubnetz mit Sicherheitsregeln, die für eine oder mehrere Netzwerksicherheitsgruppen (NSGs) definiert sind, die Sie angeben (maximal fünf). Sie können Sicherheitsregeln verwenden, die für NSGs definiert sind, anstatt oder aber auch für Sicherheitslisten (NSGs werden empfohlen). Weitere Informationen zu den Sicherheitsregeln, die für die NSG angegeben werden sollen, finden Sie unter Sicherheitsregeln für Worker-Knoten und -Pods.

        Wählen Sie optional Erweiterte Optionen anzeigen aus, um die maximale Anzahl von Pods anzugeben, die Sie auf einem einzelnen Worker-Knoten in einem Knotenpool ausführen möchten, bis zu einem Grenzwert von 110. Das Limit von 110 wird von Kubernetes festgelegt. Wenn Sie mehr als 31 Pods auf einem einzelnen Worker-Knoten möchten, muss die für den Knotenpool angegebene Ausprägung drei oder mehr VNICs unterstützen (eine VNIC, um eine Verbindung zum Worker-Knotensubnetz herzustellen, und mindestens zwei VNICs, um eine Verbindung zum Podsubnetz herzustellen). Siehe Maximale Anzahl von VNICs und Pods, die von verschiedenen Ausprägungen unterstützt werden.

        Weitere Informationen zur Podkommunikation finden Sie unter Pod Networking.

   2. Akzeptieren Sie entweder die vorhandenen Werte für erweiterte Knotenpooloptionen, oder wählen Sie Erweiterte Optionen anzeigen aus, und geben Sie Alternativen wie folgt an:

      • Cordon und Drain: Ändern Sie, wann und wie Worker-Knoten abgesperrt und abgelassen werden sollen, bevor Sie sie beenden.

        • Ausweichfrist (Minuten): Die Dauer, die es erlaubt, Worker-Knoten vor dem Beenden abzuschnüren und abzulassen. Akzeptieren Sie die Standardvorgabe (60 Minuten), oder geben Sie eine Alternative an. Beispiel: Wenn Sie einen Knotenpool horizontal skalieren oder seine Platzierungskonfiguration ändern, möchten Sie möglicherweise 30 Minuten für das Cordonieren von Worker-Knoten und das Drainieren ihrer Workloads zulassen. Um Worker-Knoten sofort zu beenden, ohne sie zu verbinden und zu entleeren, geben Sie 0 Minuten an.
        • Beenden nach Kulanzfrist erzwingen: Geben Sie beim Ersetzen oder Löschen von Knoten im Knotenpool an, ob Worker-Knoten am Ende der Kulanzfrist für die Räumung beendet werden sollen, selbst wenn sie nicht erfolgreich gesperrt und entladen wurden. Standardmäßig ist diese Option nicht ausgewählt.
        • Aktion nach Kulanzfrist erzwingen: Wenn Sie Wartungsaufgaben auf Worker-Knoten ausführen (z.B. einen Knoten neu starten und das Boot-Volume eines Knotens ersetzen), geben Sie an, ob die Aktion am Ende der Kulanzfrist für die Räumung ausgeführt werden soll, selbst wenn der Worker-Knoten nicht erfolgreich gesperrt und entladen wurde. Standardmäßig ist diese Option nicht ausgewählt.

        Knotenpools, die Worker-Knoten enthalten, die innerhalb der Ausschlussfrist nicht heruntergefahren oder beendet werden können, haben den Status Aktion erforderlich. Der Status der Arbeitsanforderung, die den Austrittsvorgang initiiert hat, wird auf Nicht erfolgreich gesetzt, und der Austrittsvorgang wird abgebrochen. Weitere Informationen finden Sie unter Cluster überwachen.

        Weitere Informationen finden Sie unter Verwaltete Knoten vor dem Herunterfahren oder Beenden cordoning and draining.

      • Initialisierungsskript: (Optional) Ein anderes Skript für die Ausführung von cloud-init auf Instanzen, die Worker-Knoten hosten, wenn die Instanz zum ersten Mal hochgefahren wird. Das angegebene Skript muss in einem der von cloud-init unterstützten Formate (z.B. cloud-config) geschrieben werden und ein unterstützter Dateityp (z.B. .yaml) sein. Geben Sie das Skript wie folgt an:
        • Cloud-Init-Skript auswählen: Wählen Sie eine Datei mit dem cloud-init-Skript aus, oder ziehen Sie die Datei per Drag-and-Drop in das Feld.
        • Cloud-Init-Skript einfügen: Kopieren Sie den Inhalt eines Cloud-Init-Skripts, und fügen Sie ihn in das Feld ein.

        Wenn Sie noch keine Cloud-Init-Skripte zum Initialisieren von Worker-Knoten in Clustern geschrieben haben, die von der Kubernetes Engine erstellt wurden, ist es möglicherweise hilfreich, die Option Benutzerdefinierte Cloud-Init-Skriptvorlage herunterladen auszuwählen. Die heruntergeladene Datei enthält die Standardlogik, die von Kubernetes Engine bereitgestellt wird. Sie können Ihre eigene benutzerdefinierte Logik entweder vor oder nach der Standardlogik hinzufügen, aber die Standardlogik nicht ändern. Beispiele finden Sie unter Beispielanwendungsfälle für benutzerdefinierte Cloud-init-Skripte.

      • Kubernetes-Labels: (Optional) Mindestens ein Label (zusätzlich zu einem Standardlabel), das Worker-Knoten im Knotenpool hinzugefügt werden soll, um die Zielfestlegung von Workloads in bestimmten Knotenpools zu ermöglichen. Beispiel: Um alle Knoten in einem Knotenpool aus der Liste der Backend-Server in einem Load-Balancer-Backend-Set auszuschließen, geben Sie node.kubernetes.io/exclude-from-external-load-balancers=true an (siehe node.kubernetes.io/exclude-from-external-load-balancers).
      • SSH-Public Key (optional): Ein anderer Public-Key-Teil des Schlüsselpaares, das Sie für den SSH-Zugriff auf die Knoten im Knotenpool verwenden möchten. Der Public Key wird auf allen Worker-Knoten im Cluster installiert. Wenn Sie keinen öffentlichen SSH-Schlüssel angeben, stellt Kubernetes Engine einen bereit. Da Sie jedoch nicht über den entsprechenden Private Key verfügen, haben Sie keinen SSH-Zugriff auf die Worker-Knoten. Beachten Sie, dass Sie nicht direkt mit SSH auf alle Worker-Knoten in Privaten Subnetzen zugreifen kann (siehe Verbindungen zu verwalteten Knoten in Privaten Subnetzen mit SSH herstellen).
   3. Wählen Sie Änderungen speichern aus, um die aktualisierten Eigenschaften zu speichern.

8. (Optional) Bei einem virtuellen Knotenpool und virtuellen Knoten ändern Sie die Eigenschaften wie folgt:

   1. Wählen Sie Bearbeiten aus, und geben Sie Folgendes an:
      • Name: Ein anderer Name für den Knotenpool. Geben Sie keine vertraulichen Informationen ein.
      • Knotenanzahl: Eine andere Anzahl von im Knotenpool zu erstellenden virtuellen Knoten, die in den ausgewählten Availability-Domains und im regionalen Subnetz (empfohlen) oder AD-spezifischen Subnet abgelegt werden, das Sie für jede Availability-Domain angeben. Siehe Knotenpools skalieren.
      • Knotenplatzierungskonfiguration:
        • Availability-Domain: Die Availability-Domain, in der virtuelle Knoten abgelegt werden.
        • Faultdomains: (Optional) Eine oder mehrere Faultdomains in der Availability-Domain, in der virtuelle Knoten platziert werden sollen.

        Wählen Sie optional Weitere Zeile aus, um weitere Domains und Subnetze auszuwählen, in denen virtuelle Knoten platziert werden sollen.

        Wenn die virtuellen Knoten erstellt werden, werden sie so gleichmäßig wie möglich auf die ausgewählten Availability-Domains und Faultdomains verteilt. Wenn Sie keine Faultdomains für eine bestimmte Availability-Domain auswählen, werden die virtuellen Knoten so gleichmäßig wie möglich auf alle Faultdomains in dieser Availability-Domain verteilt.

      • Kommunikation mit virtuellen Knoten:
        • Subnetz: Ein anderes regionales Subnetz (empfohlen) oder ein AD-spezifisches Subnetz, das zum Hosten virtueller Knoten konfiguriert ist. Wenn Sie Load-Balancer-Subnetze angegeben haben, müssen die virtuellen Knoten-Subnetze unterschiedlich sein. Die von Ihnen angegebenen Subnetze können privat (empfohlen) oder öffentlich sein und regional (empfohlen) oder AD-spezifisch sind. Es wird empfohlen, dass das Podsubnetz und das Subnetz des virtuellen Knotens dasselbe Subnetz sind (in diesem Fall muss das Subnetz des virtuellen Knotens privat sein). Weitere Informationen finden Sie unter Subnetzkonfiguration.
        • Sicherheitsregeln in Netzwerksicherheitsgruppe (NSG) verwenden: Kontrollieren Sie den Zugriff auf das Subnetz des virtuellen Knotens mit Sicherheitsregeln, die für eine oder mehrere von Ihnen angegebene Netzwerksicherheitsgruppen (NSGs) definiert sind (maximal fünf). Sie können Sicherheitsregeln verwenden, die für NSGs definiert sind, anstatt oder aber auch für Sicherheitslisten (NSGs werden empfohlen). Weitere Informationen zu den Sicherheitsregeln, die für die NSG angegeben werden sollen, finden Sie unter Sicherheitsregeln für Worker-Knoten und -Pods.
      • Podkommunikation:
        • Subnetz: Ein anderes regionales Subnetz, das zum Hosten von Pods konfiguriert ist. Das Podsubnetz, das Sie für virtuelle Knoten angeben, muss privat sein. Es wird empfohlen, dass das Podsubnetz und das Subnetz des virtuellen Knotens dasselbe Subnetz sind (in diesem Fall empfiehlt Oracle, Sicherheitsregeln in Netzwerksicherheitsgruppen und nicht in Sicherheitslisten zu definieren). Weitere Informationen finden Sie unter Subnetzkonfiguration.
        • Sicherheitsregeln in Netzwerksicherheitsgruppe (NSG) verwenden: Kontrollieren Sie den Zugriff auf das Podsubnetz mit Sicherheitsregeln, die für eine oder mehrere von Ihnen angegebene Netzwerksicherheitsgruppen (NSGs) definiert sind (maximal fünf). Sie können Sicherheitsregeln verwenden, die für NSGs definiert sind, anstatt oder aber auch für Sicherheitslisten (NSGs werden empfohlen). Weitere Informationen zu den Sicherheitsregeln, die für die NSG angegeben werden sollen, finden Sie unter Sicherheitsregeln für Worker-Knoten und -Pods.

        Weitere Informationen zur Podkommunikation finden Sie unter Pod Networking.

      • Kubernetes-Labels und -Taints: (Optional) Aktivieren Sie das Targeting von Workloads in bestimmten Knotenpools, indem Sie virtuellen Knoten Labels und Taints hinzufügen:
        • Labels: Mindestens ein Label (zusätzlich zu einem Standardlabel), das VM-Knoten im virtuellen Knotenpool hinzugefügt werden soll, um die Zielfestlegung von Workloads an bestimmten Knotenpools zu ermöglichen.
        • Taints: Mindestens ein Taints, das virtuellen Knoten im virtuellen Knotenpool hinzugefügt werden soll. Taints ermöglichen es virtuellen Knoten, Pods abzulehnen. Stellen Sie daher sicher, dass Pods nicht auf virtuellen Knoten in einem bestimmten virtuellen Knotenpool ausgeführt werden. Sie können Taints nur auf virtuelle Knoten anwenden.

        Weitere Informationen finden Sie in der Kubernetes-Dokumentation unter Pods zu Knoten zuweisen.

   2. Wählen Sie Änderungen speichern aus, um die aktualisierten Eigenschaften zu speichern.
9. Verwenden Sie die Registerkarte Knotenpooltags und die Registerkarte Knotentags, um Tags hinzuzufügen oder zu ändern, die auf den Knotenpool angewendet werden, sowie Tags, die auf Compute-Instanzen angewendet werden, die Worker-Knoten im Knotenpool hosten. Mit Tagging können Sie verschiedene Ressourcen über Compartments hinweg gruppieren. Außerdem können Sie Ressourcen mit Ihren eigenen Metadaten annotieren. Siehe Clusterbezogene Kubernetes-Ressourcen taggen.
10. Unter Ressourcen:
    • Wählen Sie Knoten aus, um Informationen zu bestimmten Worker-Knoten in einem verwalteten Knotenpool anzuzeigen. Bearbeiten Sie optional die Konfigurationsdetails eines bestimmten Worker-Knots, indem Sie den Namen des Worker-Knots auswählen.
    • Wählen Sie Virtuelle Knoten aus, um Informationen zu bestimmten Worker-Knoten in einem virtuellen Knotenpool anzuzeigen.
    • Wählen Sie Metriken aus, um den Zustand, die Kapazität und die Performance eines verwalteten Knotenpools zu überwachen. Weitere Informationen finden Sie unter OKE-Metriken (Kubernetes Engine).
    • Wählen Sie Arbeitsanforderungen aus, um:
      • Rufen Sie die Details einer bestimmten Arbeitsanforderung für die Knotenpoolressource ab.
      • Listen Sie die Arbeitsanforderungen für die Knotenpoolressource auf.

      Weitere Informationen finden Sie unter Arbeitsanforderungen anzeigen.