Dieses Dokument wurde mithilfe automatisierter maschineller Übersetzungstechnologie übersetzt. Wir bemühen uns um korrekte Übersetzungen, übernehmen jedoch keine Gewähr für die Vollständigkeit, Richtigkeit oder Zuverlässigkeit der übersetzten Inhalte. Im Falle von Abweichungen ist die englische Originalversion maßgebend und stellt den verbindlichen Text dar.

SUSE® Rancher Prime: RKE2 Cluster-Konfigurationsreferenz

Dieser Abschnitt behandelt die Konfigurationsoptionen, die in Rancher für einen neuen oder bestehenden RKE2 Kubernetes-Cluster verfügbar sind.

Übersicht

Sie können die Kubernetes-Optionen auf eine der folgenden zwei Arten konfigurieren:

Rancher UI: Verwenden Sie die Rancher UI, um Optionen auszuwählen, die häufig angepasst werden, wenn ein Kubernetes-Cluster eingerichtet wird.
Cluster-Konfigurationsdatei: Anstatt die Rancher-Benutzeroberfläche zu verwenden, um Kubernetes-Optionen für den Cluster auszuwählen, können fortgeschrittene Benutzer eine RKE2-Konfigurationsdatei erstellen. Die Verwendung einer Konfigurationsdatei ermöglicht es Ihnen, viele zusätzliche Optionen für eine RKE2-Installation festzulegen.

Cluster in der Rancher-Benutzeroberfläche bearbeiten

Die Rancher-Benutzeroberfläche bietet zwei Möglichkeiten, einen Cluster zu bearbeiten:

Mit einem Formular.
Mit YAML.

Cluster mit einem Formular bearbeiten

Das Formular deckt die am häufigsten benötigten Optionen für Cluster ab.

Um Ihren Cluster zu bearbeiten,

Klicken Sie auf ☰ > Clusterverwaltung.
Gehen Sie zu dem Cluster, den Sie konfigurieren möchten, und klicken Sie auf ⋮ > Konfiguration bearbeiten.

Cluster in YAML bearbeiten

Für eine vollständige Referenz der konfigurierbaren Optionen für RKE2-Cluster in YAML siehe die RKE2-Dokumentation.

Um Ihren Cluster in YAML zu bearbeiten:

Klicken Sie auf ☰ > Clusterverwaltung.
Gehen Sie zu dem Cluster, den Sie konfigurieren möchten, und klicken Sie auf ⋮ > Als YAML bearbeiten.
Bearbeiten Sie die RKE-Optionen unter der rkeConfig-Direktive.

Konfigurationsoptionen in der Rancher-Benutzeroberfläche

Maschinenpool-Konfiguration

Dieser Abschnitt behandelt generische Maschinenpool-Konfigurationen. Für spezifische Konfigurationen von Infrastruktur-Anbietern siehe Folgendes:

Pool-Name

Der Name des Maschinenpools.

Maschinenanzahl

Die Anzahl der Maschinen im Pool.

Rollen

Option zur Zuweisung von etcd-, Steuerungs- und Arbeitsrollen zu Knoten.

Speziell

Automatische Ersetzung

Die Zeitspanne, in der Knoten unerreichbar sein können, bevor sie automatisch gelöscht und ersetzt werden.

Entleeren vor dem Löschen

Ermöglicht das Entleeren von Knoten, indem alle Pods vor dem Löschen des Knotens entfernt werden.

Kubernetes-Knoten-Labels

Fügen Sie Labels zu Knoten hinzu, um die Organisation und Objektauswahl zu unterstützen.

Für Details zu den Anforderungen an die Labelsyntax siehe die Kubernetes-Dokumentation.

Taints

Fügen Sie Taints zu Knoten hinzu, um zu verhindern, dass Pods auf den Knoten geplant oder ausgeführt werden, es sei denn, die Pods haben passende Toleranzen.

Clusterkonfiguration

Allgemeine Grundlagen

Kubernetes Version

Die Version von Kubernetes, die auf Ihren Clusterknoten installiert ist.

Für Details zum Upgrade oder Zurücksetzen von Kubernetes siehe Kubernetes upgraden.

Container-Netzwerkanbieter

Der Netzwerkanbieter, den der Cluster verwendet.

Nachdem Sie den Cluster gestartet haben, können Sie Ihren Netzwerkanbieter nicht mehr ändern. Wählen Sie daher sorgfältig aus, welchen Netzwerkanbieter Sie verwenden möchten, da Kubernetes keinen Wechsel zwischen Netzwerkanbietern zulässt. Sobald ein Cluster mit einem Netzwerkanbieter erstellt wurde, würde ein Wechsel des Netzwerkanbieters erfordern, dass Sie den gesamten Cluster und alle seine Anwendungen herunterfahren.

Standardmäßig ist Rancher mit den folgenden Netzwerkanbietern kompatibel:

Canal
Cilium*
Calico
Flannel
Multus
Wenn Sie Projekt-Netzwerkisolierung im Cilium CNI verwenden, ist es möglich, das Routing von eingehendem Datenverkehr zwischen Knoten zu aktivieren. Klicken Sie auf die CNI-Anbieterdokumentation, um mehr zu erfahren.

Für weitere Details zu den verschiedenen Netzwerkanbietern und wie man sie konfiguriert, bitte unsere RKE2-Dokumentation einsehen.

Wenn Sie cilium oder multus,cilium als Ihren Anbieter für Container-Netzwerkschnittstellen verwenden, stellen Sie sicher, dass die Option IPv6-Unterstützung aktivieren ebenfalls aktiviert ist.

Cloud-Anbieter

Sie können einen Kubernetes-Cloud-Anbieter konfigurieren. Wenn Sie dynamisch bereitgestellte Volumes und Speicher in Kubernetes verwenden möchten, müssen Sie in der Regel den spezifischen Cloud-Anbieter auswählen, um ihn zu nutzen. Wenn Sie beispielsweise Amazon EBS verwenden möchten, müssen Sie den aws Cloud-Anbieter auswählen.

Wenn der Cloud-Anbieter, den Sie verwenden möchten, nicht als Option aufgeführt ist, müssen Sie die Konfigurationsdatei-Option verwenden, um den Cloud-Anbieter zu konfigurieren. Bitte beziehen Sie sich auf dieses Dokument, wie Sie den Cloud-Anbieter konfigurieren.

Vorlage für die Pod-Sicherheitszulassungskonfiguration

Die Standard-Vorlage für die Pod-Sicherheitszulassungskonfiguration für den Cluster.

Compliance-Profil für Worker

Wählen Sie einen Compliance-Benchmark aus, um die Systemkonfiguration zu überprüfen.

Projekt-Netzwerkisolierung

Wenn Ihr Netzwerkanbieter die Projekt-Netzwerkisolierung zulässt, können Sie wählen, ob Sie die interprojektliche Kommunikation aktivieren oder deaktivieren möchten.

Die Projekt-Netzwerkisolierung ist verfügbar, wenn Sie ein RKE2-Netzwerk-Plugin verwenden, das die Durchsetzung von Kubernetes-Netzwerkrichtlinien unterstützt, wie z.B. Canal.

CoreDNS

Standardmäßig wird CoreDNS als der Standard-DNS-Anbieter installiert. Wenn CoreDNS nicht installiert ist, muss ein alternativer DNS-Anbieter selbst installiert werden. Siehe die RKE2-Dokumentation für zusätzliche CoreDNS-Konfigurationen.

Ingress

Ingress-NGINX
Traefik

Ingress-NGINX EOL: Der Community-ingress-nginx Controller erreichte im März 2026 das Ende seines Lebenszyklus (EOL) und läuft in RKE2 v1.36 aus. Die von SUSE Rancher Prime bereitgestellten RKE2-Versionen werden weiterhin ingress-nginx Unterstützung und CVE-Fehlerbehebungen (8+) für den gesamten Lebenszyklus von RKE2 v1.32, v1.33, v1.34, v1.35 und v1.36 erhalten. Traefik ist der empfohlene Migrationspfad für SUSE Rancher RKE2-Umgebungen, es wird empfohlen, so schnell wie möglich zu migrieren. Siehe Migrating from Ingress NGINX to Traefik in a Rancher provisioned RKE2 Cluster für weitere Details.

Dies ist die veraltete Ingress-Option, um Ingress-NGINX innerhalb des Clusters zu aktivieren. Bitte beziehen Sie sich auf die RKE2-Dokumentation für zusätzliche Konfigurationsoptionen.

Wenn Sie Ihre Anwendungen in einer Hochverfügbarkeitskonfiguration bereitstellen möchten und Ihre Knoten bei einem Cloud-Anbieter hosten, der über keine native Lastenausgleichsfunktion verfügt, aktivieren Sie diese Option, um Traefik Ingress innerhalb des Clusters zu verwenden. Bitte beziehen Sie sich auf die RKE2-Dokumentation für zusätzliche Konfigurationsoptionen.

Metrics Server

Option zum Aktivieren oder Deaktivieren des Metrics Servers.

Jeder Cloud-Anbieter, der in der Lage ist, einen Cluster mit RKE2 zu starten, kann Metriken sammeln und Ihre Clusterknoten überwachen. Aktivieren Sie diese Option, um Ihre Knotenmetriken im Portal Ihres Cloud-Anbieters anzuzeigen.

Add-On-Konfiguration

Zusätzliche Kubernetes-Manifestdateien, die als Add-on verwaltet werden, um beim Start in den Cluster angewendet zu werden. Einzelheiten hierzu erfahren Sie in der RKE2-Dokumentation.

Agent-Umgebungsvariablen

Option zum Setzen von Umgebungsvariablen für Rancher-Agenten. Die Umgebungsvariablen können mit Schlüssel-Wert-Paaren festgelegt werden. Siehe die RKE2-Dokumentation für weitere Details.

etcd

Automatische Snapshots

Option zum Aktivieren oder Deaktivieren von wiederkehrenden etcd-Snapshots. Wenn aktiviert, haben Benutzer die Möglichkeit, die Häufigkeit der Snapshots zu konfigurieren. Für Details siehe die RKE2-Dokumentation. Beachten Sie, dass bei RKE2 Snapshots auf jedem etcd-Knoten gespeichert werden. Dies unterscheidet sich von RKE1, das nur einen Snapshot pro Cluster speichert.

Metriken

Option zu wählen, ob etcd-Metriken öffentlich oder nur innerhalb des Clusters bereitgestellt werden sollen.

Netzwerke

Cluster CIDR

IPv4- und/oder IPv6-Netzwerk-CIDRs, die für Pod-IPs verwendet werden sollen (Standard: 10.42.0.0/16).

Beispielwerte:

Nur IPv4: 10.42.0.0/16
Nur IPv6: 2001:cafe:42::/56
Dual-Stack: 10.42.0.0/16,2001:cafe:42::/56

Für zusätzliche Anforderungen und Einschränkungen im Zusammenhang mit Dual-Stack oder nur IPv6-Netzwerken siehe die folgenden Ressourcen:

Sie müssen die Service CIDR konfigurieren, wenn Sie den Cluster zum ersten Mal erstellen. Sie können die Service CIDR in einem bestehenden Cluster nach dem Start nicht aktivieren.
Wenn Sie cilium oder multus,cilium als Ihren Anbieter für Container-Netzwerkschnittstellen verwenden, stellen Sie sicher, dass die Option IPv6-Unterstützung aktivieren ebenfalls aktiviert ist.

Service CIDR

IPv4/IPv6-Netzwerk-CIDRs, die für Service-IPs verwendet werden sollen (Standard: 10.43.0.0/16).

Beispielwerte:

Nur IPv4: 10.43.0.0/16
Nur IPv6: 2001:cafe:43::/112
Dual-Stack: 10.43.0.0/16,2001:cafe:43::/112

Für zusätzliche Anforderungen und Einschränkungen im Zusammenhang mit Dual-Stack oder nur IPv6-Netzwerken siehe die folgenden Ressourcen:

Sie müssen die Service CIDR konfigurieren, wenn Sie den Cluster zum ersten Mal erstellen. Sie können die Service CIDR in einem bestehenden Cluster nach dem Start nicht aktivieren.
Wenn Sie cilium oder multus,cilium als Ihren Anbieter für Container-Netzwerkschnittstellen verwenden, stellen Sie sicher, dass die Option IPv6-Unterstützung aktivieren ebenfalls aktiviert ist.

Cluster DNS

IPv4-Cluster-IP für den coredns-Dienst. Sollte sich im Bereich Ihrer Service-CIDR befinden (Standard: 10.43.0.10).

Cluster-Domain

Wählen Sie die Domain für den Cluster aus. Der Standardwert ist cluster.local.

NodePort Service Portbereich

Option zum Ändern des Portbereichs, der für NodePort-Dienste verwendet werden kann. Der Standardwert ist 30000-32767.

Hostnamen kürzen

Option, Hostnamen auf 15 Zeichen oder weniger zu kürzen. Sie können dieses Feld nur während der initialen Erstellung des Clusters festlegen. Sie können das 15-Zeichen-Limit nach der Clustererstellung nicht aktivieren oder deaktivieren.

Diese Einstellung betrifft nur maschinenprovisionierte Cluster. Da benutzerdefinierte Cluster Hostnamen während ihres eigenen Node-Erstellungsprozesses festlegen, der außerhalb von Rancher erfolgt, schränkt dieses Feld die Länge von Hostnamen in benutzerdefinierten Clustern nicht ein.

Das Kürzen von Hostnamen in einem Cluster verbessert die Kompatibilität mit Windows-basierten Systemen. Obwohl Kubernetes Hostnamen mit einer Länge von bis zu 63 Zeichen zulässt, beschränken Systeme, die NetBIOS verwenden, Hostnamen auf 15 Zeichen oder weniger.

TLS Alternative Namen

Fügen Sie Hostnamen oder IPv4/IPv6-Adressen als Subject Alternative Names im TLS-Zertifikat des Servers hinzu.

Stapelpräferenz

Wählen Sie den Netzwerk-Stack für den Cluster. Diese Option beeinflusst:

Die Adresse, die für Gesundheits- und Bereitschaftsprüfungen von Komponenten wie Calico, etcd, kube-apiserver, kube-scheduler, kube-controller-manager und kubelet verwendet wird.
Die Server-URL im authentication-token-webhook-config-file für den autorisierten Cluster-Endpunkt.
Die advertise-client-urls-Einstellung für etcd während der Snapshot-Wiederherstellung.

Die Optionen sind ipv4, ipv6, dual:

Wenn auf ipv4 gesetzt, verwendet der Cluster 127.0.0.1.
Wenn auf ipv6 gesetzt, verwendet der Cluster [::1].
Wenn auf dual gesetzt, verwendet der Cluster localhost.

Die Stapelpräferenz muss mit der Netzwerkkonfiguration des Clusters übereinstimmen:

Auf ipv4 für ausschließlich IPv4-Cluster setzen.
Auf ipv6 für ausschließlich IPv6-Cluster setzen.
Auf dual für Dual-Stack-Cluster setzen.

Die Sicherstellung, dass die Konfiguration der Loopback-Adresse korrekt ist, ist entscheidend für eine erfolgreiche Cluster-Bereitstellung. Für weitere Informationen siehe die Seite zu den Knotenanforderungen.

Autorisierter Cluster-Endpunkt

Der autorisierte Cluster-Endpunkt kann verwendet werden, um direkt auf den Kubernetes-API-Server zuzugreifen, ohne dass eine Kommunikation über Rancher erforderlich ist.

Dies ist standardmäßig in von Rancher gestarteten Kubernetes-Clustern aktiviert, wobei die IP des Knotens mit der controlplane-Rolle und den standardmäßigen selbstsignierten Kubernetes-Zertifikaten verwendet wird.

Für weitere Details, wie ein autorisierter Cluster-Endpunkt funktioniert und warum er verwendet wird, siehe den Architekturabschnitt.

Wir empfehlen die Verwendung eines Lastenausgleichers mit dem autorisierten Cluster-Endpunkt. Für Details siehe den empfohlenen Architekturabschnitt.

Registries

Wählen Sie das Image-Repository aus, von dem Rancher-Images abgerufen werden sollen. Für weitere Details und Konfigurationsoptionen siehe die RKE2-Dokumentation.

Upgrade-Strategie

Parallelität der Steuerungsebene

Wählen Sie aus, wie viele Knoten gleichzeitig aktualisiert werden können. Kann eine feste Zahl oder ein Prozentsatz sein.

Parallelität der Worker

Wählen Sie aus, wie viele Knoten gleichzeitig aktualisiert werden können. Kann eine feste Zahl oder ein Prozentsatz sein.

Knoten entleeren (Steuerungsebene)

Option, alle Pods vom Knoten vor dem Upgrade zu entfernen.

Knoten entleeren (Worker-Knoten)

Option, alle Pods vom Knoten vor dem Upgrade zu entfernen.

Speziell

Option, um Kubelet-Optionen für verschiedene Knoten festzulegen. Für verfügbare Optionen siehe die Kubernetes-Dokumentation.

Referenz zur Cluster-Konfiguration

Das Bearbeiten von Clustern in YAML ermöglicht es Ihnen, die verfügbaren Optionen in einer RKE2-Installation festzulegen, einschließlich der bereits in Konfigurationsoptionen in der Rancher UI aufgeführten, sowie Rancher-spezifische Parameter festzulegen.

Beispiel-Cluster-Konfigurationsdatei-Ausschnitt

yaml apiVersion: provisioning.cattle.io/v1 kind: Cluster-Spezifikation: cloudCredentialSecretName: cattle-global-data:cc-s879v kubernetesVersion: v1.25.12+rke2r1 localClusterAuthEndpoint: {} rkeConfig: additionalManifest: "" chartValues: rke2-calico: {} etcd: snapshotRetention: 5 snapshotScheduleCron: 0 */5 * * * machineGlobalConfig: cni: calico disable-kube-proxy: false etcd-expose-metrics: false profile: null kube-apiserver-arg: - audit-policy-file=/etc/rancher/rke2/user-audit-policy.yaml - audit-log-path=/etc/rancher/rke2/user-audit.logs machinePools: - controlPlaneRole: true etcdRole: true machineConfigRef: kind: Amazonec2Config name: nc-test-pool1-pwl5h name: pool1 quantity: 1 unhealthyNodeTimeout: 0s workerRole: true machineSelectorConfig: - config: protect-kernel-defaults: false machineSelectorFiles: - fileSources: - configMap: name: '' secret: name: audit-policy items: - key: audit-policy path: /etc/rancher/rke2/user-audit-policy.yaml machineLabelSelector: matchLabels: rke.cattle.io/control-plane-role: 'true' registries: {} upgradeStrategy: controlPlaneConcurrency: "1" controlPlaneDrainOptions: deleteEmptyDirData: true enabled: true gracePeriod: -1 ignoreDaemonSets: true timeout: 120 workerConcurrency: "1" workerDrainOptions: deleteEmptyDirData: true enabled: true gracePeriod: -1 ignoreDaemonSets: true timeout: 120

additionalManifest

Geben Sie zusätzliche Manifeste an, die an die Knoten der Steuerungsebene geliefert werden sollen.

Der Wert ist ein String und wird am Pfad /var/lib/rancher/rke2/server/manifests/rancher/addons.yaml auf den Zielknoten platziert.

Beispiel:

additionalManifest: |-
  apiVersion: v1
  kind: Namespace
  metadata:
    name: name-xxxx

Wenn Sie System-Charts anpassen möchten, sollten Sie das Feld chartValues wie unten beschrieben verwenden.

Alternativen, wie die Verwendung eines HelmChartConfig zur Anpassung der System-Charts über additionalManifest, können unerwartetes Verhalten verursachen, da mehrere HelmChartConfig für denselben Chart vorhanden sind.

chartValues

Geben Sie die Werte für die von RKE2 installierten System-Charts an.

Für weitere Informationen darüber, wie RKE2 verpackte Komponenten verwaltet, siehe RKE2-Dokumentation.

Beispiel:

chartValues:
    chart-name:
        key: value

machineGlobalConfig

Geben Sie die RKE2-Konfigurationen an. Änderungen an der Konfiguration, die hier vorgenommen werden, gelten für jeden Knoten. Die Konfigurationsoptionen, die in der Standalone-Version von RKE2 verfügbar sind, können hier angewendet werden.

Beispiel:

machineGlobalConfig:
    etcd-arg:
        - key1=value1
        - key2=value2

Es gibt einige Konfigurationsoptionen, die beim Bereitstellen über Rancher nicht geändert werden können:

data-dir (Ordner zur Speicherung des Status), der standardmäßig auf /var/lib/rancher/rke2 gesetzt ist.

Um es einfacher zu machen, Dateien im Voraus auf Knoten zu platzieren, erwartet Rancher, dass die folgenden Werte in die Konfiguration aufgenommen werden, während RKE2 erwartet, dass die Werte als Dateipfade eingegeben werden:

audit-policy-file
cloud-provider-config
private-registry

Rancher liefert die Dateien an den Pfad /var/lib/rancher/rke2/etc/config-files/<option> in den Zielknoten und setzt die richtigen Optionen im RKE2-Server.

Beispiel:

apiVersion: provisioning.cattle.io/v1
kind: Cluster
spec:
  rkeConfig:
    machineGlobalConfig:
      audit-policy-file:
        apiVersion: audit.k8s.io/v1
        kind: Policy
        rules:
        - level: RequestResponse
          resources:
          - group: ""
            resources:
            - pods

machineSelectorConfig

machineSelectorConfig ist dasselbe wie machineGlobalConfig, mit der Ausnahme, dass ein Label-Selector mit der Konfiguration angegeben werden kann. Die Konfiguration wird nur auf Knoten angewendet, die dem angegebenen Label-Selector entsprechen.

Mehrere config Einträge sind erlaubt, wobei jeder seine eigene machineLabelSelector angibt. Ein Benutzer kann matchExpressions, matchLabels, beides oder keines angeben. Das Weglassen des machineLabelSelector Abschnitts dieses Feldes hat denselben Effekt wie das Einfügen der Konfiguration in den machineGlobalConfig Abschnitt.

Beispiel:

machineSelectorConfig
  - config:
      config-key: config-value
    machineLabelSelector:
      matchExpressions:
        - key: example-key
          operator: string # Valid operators are In, NotIn, Exists and DoesNotExist.
          values:
            - example-value1
            - example-value2
      matchLabels:
        key1: value1
        key2: value2

machineSelectorFiles

Dieses Feature ist in Rancher v2.7.2 und später verfügbar.

Dateien an Knoten liefern, damit sie vorhanden sind, bevor die RKE2-Server- oder Agent-Prozesse gestartet werden. Der Inhalt der Datei wird entweder aus einem Secret oder einem ConfigMap abgerufen. Die Zielknoten werden durch das machineLabelSelector gefiltert.

Beispiel:

machineSelectorFiles:
  - fileSources:
      - secret:
          items:
            - key: example-key
              path: path-to-put-the-file-on-nodes
              permissions: 644 (optional)
              hash: base64-encoded-hash-of-the-content (optional)
          name: example-secret-name
    machineLabelSelector:
      matchExpressions:
        - key: example-key
          operator: string # Valid operators are In, NotIn, Exists and DoesNotExist.
          values:
            - example-value1
            - example-value2
      matchLabels:
        key1: value1
        key2: value2
  - fileSources:
      - configMap:
          items:
            - key: example-key
              path: path-to-put-the-file-on-nodes
              permissions: 644 (optional)
              hash: base64-encoded-hash-of-the-content (optional)
          name: example-configmap-name
    machineLabelSelector:
      matchExpressions:
        - key: example-key
          operator: string # Valid operators are In, NotIn, Exists and DoesNotExist.
          values:
            - example-value1
            - example-value2
      matchLabels:
        key1: value1
        key2: value2

Das Secret oder die ConfigMap muss die folgenden Anforderungen erfüllen:

Es muss im fleet-default Namespace sein, in dem das Cluster-Objekt existiert.
Es muss die Annotation rke.cattle.io/object-authorized-for-clusters: cluster-name1,cluster-name2 haben, die es den Ziel-Clustern erlaubt, es zu verwenden.

Das Rancher Dashboard bietet ein benutzerfreundliches Formular zum Erstellen des Secrets oder der ConfigMap.

Beispiel:

apiVersion: v1
data:
  audit-policy: >-
    IyBMb2cgYWxsIHJlcXVlc3RzIGF0IHRoZSBNZXRhZGF0YSBsZXZlbC4KYXBpVmVyc2lvbjogYXVkaXQuazhzLmlvL3YxCmtpbmQ6IFBvbGljeQpydWxlczoKLSBsZXZlbDogTWV0YWRhdGE=
kind: Secret
metadata:
  annotations:
    rke.cattle.io/object-authorized-for-clusters: cluster1
  name: name1
  namespace: fleet-default