Knotenpools zum vertikalen Skalieren von Clustern hinzufügen

So skalieren Sie ein vorhandenes Cluster, indem Sie die Anzahl der Knotenpools im Cluster mit der Konsole erhöhen:

1. Wählen Sie auf der Listenseite Cluster den Namen des Clusters, das Sie ändern möchten. Wenn Sie Hilfe beim Suchen der Listenseite oder des Clusters benötigen, finden Sie weitere Informationen unter Cluster auflisten.
2. Wählen Sie unter Ressourcen die Option Knotenpools aus.
3. Wählen Sie die Schaltfläche Knotenpool hinzufügen, und skalieren Sie das Cluster, indem Sie Knotenpools hinzufügen.
4. Geben Sie Details für den neuen Knotenpool ein:
   • Name: Ein Name Ihrer Wahl für den neuen Knotenpool. Geben Sie keine vertraulichen Informationen ein.
   • Compartment: Das Compartment, in dem der neue Knotenpool erstellt werden soll.
   • Knotentyp: Wenn der Netzwerktyp des Clusters VCN-natives Podnetzwerk ist, geben Sie den Typ der Worker-Knoten in diesem Knotenpool an (siehe Virtuelle Knoten und verwaltete Knoten). Wählen Sie eine der folgenden Optionen aus:
     • Verwaltet: Wählen Sie diese Option aus, wenn Sie für die Verwaltung der Worker-Knoten im Knotenpool verantwortlich sein möchten. Verwaltete Knoten, die auf Compute-Instanzen (Bare Metal oder virtuelle Maschine) in Ihrem Mandanten ausgeführt werden. Da Sie für die Verwaltung verwalteter Knoten verantwortlich sind, können Sie diese flexibel konfigurieren, um Ihre spezifischen Anforderungen zu erfüllen. Sie sind für das Upgrade von Kubernetes auf verwalteten Knoten und für die Verwaltung der Clusterkapazität verantwortlich.
     • Virtuell: Wählen Sie diese Option aus, wenn Sie von einer "serverlosen" Kubernetes-Erfahrung profitieren möchten. Mit virtuellen Knoten können Sie Kubernetes-Pods in großem Maßstab ausführen, ohne dass der Betriebsaufwand für das Upgrade der Data-Plane-Infrastruktur und das Verwalten der Clusterkapazität entsteht.

     Weitere Informationen finden Sie unter Virtuelle Knoten mit verwalteten Knoten vergleichen.

   • Version: (Nur verwaltete Knotenpools) Die Version von Kubernetes, die auf jedem verwalteten Knoten in einem verwalteten Knotenpool ausgeführt werden soll. Standardmäßig ist die für die Control-Plane-Knoten angegebene Kubernetes-Version ausgewählt. Die Kubernetes-Version auf Worker-Knoten muss entweder dieselbe Version wie auf den Control-Plane-Knoten oder eine frühere Version sein, die noch kompatibel ist. 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.

5. Wenn der Clusternetzwerktyp natives VCN-Pod-Networking lautet und Sie Verwaltet als Knotentyp ausgewählt haben, oder wenn der Clusternetzwerktyp Flannel-Overlay lautet:

   1. Geben Sie Konfigurationsdetails für den verwalteten Knotenpool an:

      • 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, stellen Sie sicher, dass die Knotenausprägung, Availability-Domain und Faultdomain in der Platzierungskonfiguration des Knotenpools mit dem Instanztyp, der Availability-Domain und der Faultdomain der Kapazitätsreservierung übereinstimmen. 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: Die Ausprägung, die für Worker-Knoten im Knotenpool verwendet werden soll. 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: Das Image, das auf Worker-Knoten im Knotenpool verwendet werden muss. Ein Image ist eine Vorlage einer virtuellen Festplatte, die das Betriebssystem und andere Software für den Knoten bestimmt.

        Um das Standardbild 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.

      • Knotenanzahl: Die Anzahl der in dem Knotenpool zu erstellenden Worker-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.
      • 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: Konfigurieren Sie die Größe und die 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 Verschlüsselung während der Übertragung. 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, geben Sie an, 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.
        • 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.

        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 die Standardwerte für erweiterte Knotenpooloptionen, oder wählen Sie Erweiterte Einstellungen anzeigen, und geben Sie wie folgt Alternativen an:

      • Cordon und Drain: Geben Sie an, wann und wie Worker-Knoten Cordon und Drain verwendet werden sollen, bevor sie beendet werden.

        • 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 Skript, mit dem cloud-init auf jeder Instanz ausgeführt wird, die Worker-Knoten hostet, 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).
      • Knotenpooltags und Knotentags: (Optional) Mindestens ein Tag, das dem Knotenpool und Compute-Instanzen hinzugefügt werden soll, 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.
      • SSH-Public Key (optional): Der Public-Key-Teil des Schlüsselpaares, das Sie für den SSH-Zugriff auf die einzelnen 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).
6. Wenn Sie Virtuell als Knotentyp ausgewählt haben:
   1. Geben Sie Konfigurationsdetails für den virtuellen Knotenpool an:
      • 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 zusätzliche 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.

      • Knotenanzahl: Die Anzahl der virtuellen Knoten, die im virtuellen Knotenpool erstellt werden, 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.

      • Podausprägung: Die Ausprägung, die für Pods verwendet werden soll, die auf virtuellen Knoten im virtuellen Knotenpool ausgeführt werden. Die Ausprägung bestimmt den Prozessortyp, auf dem der Pod ausgeführt werden soll.

        Nur die in Ihrem Mandanten verfügbaren Ausprägungen, die von der Kubernetes-Engine unterstützt werden, werden angezeigt. Weitere Informationen finden Sie unter Unterstützte Images (einschließlich benutzerdefinierter Images) und Ausprägungen für Worker-Knoten.

        Beachten Sie, dass Sie die CPU- und Speicherressourcenanforderungen für virtuelle Knoten in der Podspezifikation explizit angeben (siehe Speicherressourcen Containern und Pods zuweisen und CPU-Ressourcen Containern und Pods zuweisen in der Kubernetes-Dokumentation).

      • Kommunikation mit virtuellen Knoten:
        • Subnetz: Ein regionales Subnetz (empfohlen) oder AD-spezifisches Subnetz, das zum HHost von virtuellen 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). Siehe 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: Pods, die auf virtuellen Knoten ausgeführt werden, verwenden VCN-natives Podnetzwerk. Geben Sie an, wie Pods im Knotenpool über ein Podsubnetz miteinander kommunizieren:
        • Subnetz: Ein 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). Siehe 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.

   2. Akzeptieren Sie die Standardwerte für erweiterte virtuelle Knotenpooloptionen, oder wählen Sie Erweiterte Einstellungen anzeigen, und geben Sie wie folgt Alternativen an:

      • Knotenpooltags: (Optional) Ein oder mehrere Tags, die dem virtuellen Knotenpool hinzugefügt werden sollen. 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.
      • 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. Dadurch wird sichergestellt, dass Pods nicht auf virtuellen Knoten in einem bestimmten virtuellen Knotenpool ausgeführt werden. Beachten Sie, dass Sie Taints nur auf virtuelle Knoten anwenden können.

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

7. Wählen Sie Hinzufügen aus, um den neuen Knotenpool zu erstellen.