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. Ö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 ein Compartment aus, für das Sie eine Berechtigung besitzen.
3. Wählen Sie auf der Seite Clusterliste den Namen des Clusters, das Sie ändern möchten.
4. Wählen Sie unter Ressourcen die Option Knotenpools aus.
5. Wählen Sie die Schaltfläche Knotenpool hinzufügen, und skalieren Sie das Cluster, indem Sie Knotenpools hinzufügen.
6. 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, wenn Sie die Zuständigkeit für die Verwaltung der Worker-Knoten im Knotenpool haben möchten. Verwaltete Knoten, die auf Compute-Instanzen (entweder Bare Metal oder Virtual Machine) 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 das Verwalten der Clusterkapazität verantwortlich.
     • Virtuell: Wählen Sie diese Option, wenn Sie von einem "serverlosen" Kubernetes-Erlebnis profitieren möchten. Mit virtuellen Knoten können Sie Kubernetes-Pods in großem Maßstab ausführen, ohne den Betriebsaufwand für das Upgrade der Data-Plane-Infrastruktur und die Verwaltung der Clusterkapazität.

     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.

7. Wenn der Netzwerktyp des Clusters VCN-natives Podnetzwerk ist und Sie Verwaltet als Knotentyp ausgewählt haben oder wenn der Netzwerktyp des Clusters Flannel-Overlay lautet:

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

      • Knotenplatzierungskonfiguration:
        • Availability-Domain: Eine Availability-Domain, in der Worker-Knoten abgelegt werden.
        • Worker-Knotensubnetz: Ein regionales Subnetz (empfohlen) oder ein AD-spezifisches Subnetz, das zum Hosten von Worker-Knoten konfiguriert ist. Wenn Sie Load-Balancer-Subnetze angegeben haben, müssen die Worker-Knotensubnetze unterschiedlich sein. Die 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.

      • Bild: Das Image, das auf Worker-Knoten im Knotenpool verwendet werden soll. 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-Mitarbeiterknotenimages: Empfohlen. Wird von Oracle bereitgestellt und basiert auf Plattformimages. OKE-Images sind für die Verwendung als Basisimages für Worker-Knoten mit allen erforderlichen Konfigurationen und der erforderlichen Software optimiert. 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: Wird von Oracle bereitgestellt und enthält nur ein Oracle Linux-Betriebssystem. Wählen Sie ein Plattformimage aus, wenn Kubernetes Engine die erforderliche Software herunterladen, installieren und konfigurieren soll, wenn die Compute-Instanz, die einen Worker-Knoten hostet, zum ersten Mal hochfährt.

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

      • Knotenanzahl: Die Anzahl der im Knotenpool zu erstellenden Worker-Knoten, die in den von Ihnen ausgewählten Availability-Domains und im regionalen Subnetz (empfohlen) oder AD-spezifischen Subnetz abgelegt werden, das Sie für jede Availability-Domain angeben.
      • Sicherheitsregeln in Network Security Group (NSG) verwenden: Kontrollieren Sie den Zugriff auf den Knotenpool mit Sicherheitsregeln, die für mindestens eine von Ihnen angegebene Netzwerksicherheitsgruppe (NSGs) definiert sind (maximal fünf). Sie können Sicherheitsregeln verwenden, die für NSGs definiert sind, anstelle von oder sowie für Sicherheitslisten definierte Sicherheitsregeln (NSGs werden empfohlen). Weitere Informationen zu den Sicherheitsregeln, die Sie für die NSG angeben können, finden Sie unter Sicherheitsregeln für Worker-Knoten.

      • Boot-Volume: Konfigurieren Sie die Größen- 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 von 50 GB bis 32 TB ein. 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 einen eigenen Vault-Verschlüsselungsschlüssel für das Boot-Volume verwenden, wird dieser Schlüssel auch für die Verschlüsselung 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 verwaltenden Schlüssel verschlüsseln. Wählen Sie das Vault Compartment und den Vault aus, die den zu verwendenden Master-Verschlüsselungsschlüssel enthalten, und wählen Sie dann das Master-Verschlüsselungsschlüssel-Compartment und den Master-Verschlü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-Podnetzwerk lautet, 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 Fällen 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 (bis zu maximal fünf) definiert sind. Sie können Sicherheitsregeln verwenden, die für NSGs definiert sind, anstelle von oder sowie für Sicherheitslisten definierte Sicherheitsregeln (NSGs werden empfohlen). Weitere Informationen zu den Sicherheitsregeln, die Sie für die NSG angeben können, 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 Optionen anzeigen aus, und geben Sie wie folgt Alternativen an:

      • Cordon und Drain: Geben Sie an, wann und wie Worker-Knoten vor dem Beenden Cordon und Drain werden sollen.

        • Nachfrist für Entscheidungsfindung (Minuten): Die Dauer, die das Cordon und Drain von Worker-Knoten vor dem Beenden zulässt. Übernehmen Sie den Standardwert (60 Minuten), oder geben Sie eine Alternative an. Beispiel: Wenn Sie einen Knotenpool herunterskalieren oder seine Platzierungskonfiguration ändern, möchten Sie möglicherweise 30 Minuten Zeit für das Cordon von Worker-Knoten und das Drain ihrer Workloads. Geben Sie 0 Minuten an, um Worker-Knoten sofort zu beenden, ohne sie zu verbinden und zu entfernen.
        • 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 für die Ausführung von cloud-init auf jeder Instanz, 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 geschrieben werden (z.B. cloud-config) und muss ein unterstützter Dateityp sein (z.B. .yaml). Geben Sie das Skript folgendermaßen an:
        • Cloud-Init-Skript auswählen: Wählen Sie eine Datei mit dem cloud-init-Skript aus, oder verschieben 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 hinzugefügt werden soll, und Compute-Instanzen, 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 SSH-Public Key angeben, stellt die 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 mit SSH nicht direkt auf alle Worker-Knoten in privaten Subnetzen zugreifen können (siehe Verbindung zu verwalteten Knoten in privaten Subnetzen mit SSH herstellen).
8. Wenn Sie Virtuell als Knotentyp gewählt haben:
   1. Geben Sie Konfigurationsdetails für den virtuellen Knotenpool an:
      • Knotenplatzierungskonfiguration:
        • Availability-Domain: Eine 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 im virtuellen Knotenpool zu erstellenden virtuellen Knoten, die in den von Ihnen ausgewählten Availability-Domains und im regionalen Subnetz (empfohlen) oder AD-spezifischen Subnetz 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 ein AD-spezifisches Subnetz, das zum Hosten virtueller Knoten konfiguriert ist. Wenn Sie Load-Balancer-Subnetze angegeben haben, müssen die virtuellen Knotensubnetze unterschiedlich sein. Die angegebenen Subnetze können privat (empfohlen) oder öffentlich und regional (empfohlen) oder AD-spezifisch sein. Es wird empfohlen, dass das Podsubnetz und das virtuelle Knotensubnetz dasselbe Subnetz sind (in diesem Fall muss das virtuelle Knotensubnetz 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 Netzwerksicherheitsgruppen (NSGs) definiert sind, die Sie angeben (maximal fünf). Sie können für NSGs definierte Sicherheitsregeln anstelle der für Sicherheitslisten definierten Sicherheitsregeln verwenden (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 (bis zu maximal fünf) definiert sind. Sie können Sicherheitsregeln verwenden, die für NSGs definiert sind, anstelle von oder sowie für Sicherheitslisten definierte Sicherheitsregeln (NSGs werden empfohlen). Weitere Informationen zu den Sicherheitsregeln, die Sie für die NSG angeben können, 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) Mindestens ein Tag, das dem virtuellen Knotenpool hinzugefügt werden soll. 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 die Zielgruppenselektion von Workloads in bestimmten Knotenpools, indem Sie virtuellen Knoten Labels und Taints hinzufügen:
        • Labels: Mindestens ein Label (zusätzlich zu einem Standardlabel), das virtuellen Knoten im virtuellen Knotenpool hinzugefügt werden soll, um die Zielfestlegung von Workloads in bestimmten Knotenpools zu ermöglichen.
        • Taints: Eine oder mehrere Taints, die virtuellen Knoten im virtuellen Knotenpool hinzugefügt werden sollen. Taints ermöglichen virtuellen Knoten, Pods abzuwehren, wodurch sichergestellt wird, 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.

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