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: K3s Cluster-Konfigurationsreferenz

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

Übersicht

Sie können die Kubernetes-Optionen auf eine von 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 K3s-Konfigurationsdatei erstellen. Mit einer Konfigurationsdatei können Sie alle während einer K3s-Installation verfügbaren Optionen festlegen.

Cluster in der Rancher-Benutzeroberfläche bearbeiten

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

  1. Mit einem Formular.

  2. 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,

  1. Klicken Sie auf ☰ > Clusterverwaltung.

  2. 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 K3s-Cluster in YAML siehe die K3s-Dokumentation.

Um Ihren Cluster mit YAML zu bearbeiten:

  1. Klicken Sie auf ☰ > Clusterverwaltung.

  2. Gehen Sie zu dem Cluster, den Sie konfigurieren möchten, und klicken Sie auf ⋮ > Als YAML bearbeiten.

  3. 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.

Vorlage für die Pod-Sicherheitszulassungskonfiguration
Geheimnisse verschlüsseln

Option zum Aktivieren oder Deaktivieren der Verschlüsselung von Geheimnissen. Wenn aktiviert, werden Geheimnisse mit einem AES-CBC-Schlüssel verschlüsselt. Wenn deaktiviert, sind zuvor verschlüsselte Geheimnisse nicht lesbar, bis die Verschlüsselung erneut aktiviert wird. Siehe die K3s-Dokumentation für Einzelheiten.

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.

SELinux

Option zum Aktivieren oder Deaktivieren der SELinux-Unterstützung.

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 K3s-Dokumentation für Einzelheiten.

Klipper-Service LB

Option zum Aktivieren oder Deaktivieren des Klipper-Service-Lastenausgleichs. Siehe die K3s-Dokumentation für Einzelheiten.

Traefik Ingress

Option zum Aktivieren oder Deaktivieren des Traefik HTTP-Proxy und Lastenausgleichs. Für weitere Details und Konfigurationsoptionen siehe die K3s-Dokumentation.

Lokaler Speicher

Option zum Aktivieren oder Deaktivieren des lokalen Speichers auf dem/den Knoten.

Metrics Server

Option zum Aktivieren oder Deaktivieren des Metrics Servers. Wenn aktiviert, stellen Sie sicher, dass Port 10250 für eingehenden TCP-Verkehr geöffnet ist.

Add-On-Konfiguration

Zusätzliche Kubernetes-Manifestdateien, die als Add-on verwaltet werden, um beim Start in den Cluster angewendet zu werden. Siehe die K3s-Dokumentation für Einzelheiten.

Agent-Umgebungsvariablen

Option zum Setzen von Umgebungsvariablen für K3s-Agenten. Die Umgebungsvariablen können mit Schlüssel-Wert-Paaren festgelegt werden. Siehe die K3-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 K3s-Dokumentation.

Metriken

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

Netzwerke

Cluster CIDR

IPv4/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.

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.

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.

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 K3s-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, Konfigurationen festzulegen, die bereits in Konfigurationen in der Rancher UI aufgeführt sind, sowie Rancher-spezifische Parameter festzulegen.

Klicken Sie hier, um Beispiel-Cluster-Konfigurationsdatei-Ausschnitt aufzuklappen.

apiVersion: provisioning.cattle.io/v1 kind: Cluster
spec:
cloudCredentialSecretName: cattle-global-data:cc-fllv6
clusterAgentDeploymentCustomization: {}
fleetAgentDeploymentCustomization: {}
kubernetesVersion: v1.26.7+k3s1
localClusterAuthEndpoint: {}
rkeConfig:
additionalManifest: ""
chartValues: {}
etcd:
snapshotRetention: 5
snapshotScheduleCron: 0 */5 * * *
machineGlobalConfig:
disable-apiserver: false
disable-cloud-controller: false
disable-controller-manager: false
disable-etcd: false
disable-kube-proxy: false
disable-network-policy: false
disable-scheduler: false
etcd-expose-metrics: false
kube-apiserver-arg:
- audit-policy-file=/etc/rancher/k3s/user-audit-policy.yaml
- audit-log-path=/etc/rancher/k3s/user-audit.logs
profile: null
secrets-encryption: false
machinePools:
- controlPlaneRole: true
etcdRole: true
machineConfigRef:
kind: Amazonec2Config
name: nc-test-pool1-pwl5h
name: pool1
quantity: 1
unhealthyNodeTimeout: 0s
workerRole: true
machineSelectorConfig:
- config:
docker: false
protect-kernel-defaults: false
selinux: false
machineSelectorFiles:
- fileSources:
- configMap:
name: ''
secret:
name: audit-policy
items:
- key: audit-policy
path: /etc/rancher/k3s/user-audit-policy.yaml
machineLabelSelector:
matchLabels:
rke.cattle.io/control-plane-role: 'true'
registries: {}
upgradeStrategy:
controlPlaneConcurrency: '1' controlPlaneDrainOptions: deleteEmptyDirData: true disableEviction: false enabled: false force: false gracePeriod: -1 ignoreDaemonSets: true ignoreErrors: false postDrainHooks: null preDrainHooks: null skipWaitForDeleteTimeoutSeconds: 0 timeout: 120 workerConcurrency: '1' workerDrainOptions: deleteEmptyDirData: true disableEviction: false enabled: false force: false gracePeriod: -1 ignoreDaemonSets: true ignoreErrors: false postDrainHooks: null preDrainHooks: null skipWaitForDeleteTimeoutSeconds: 0 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/k3s/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 K3s installierten System-Charts an.

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

Beispiel:

chartValues:
    chart-name:
        key: value

machineGlobalConfig

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

Beispiel:

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

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 K3s erwartet, dass die Werte als Dateipfade eingegeben werden:

  • private-registry

  • flannel-conf

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

Beispiel:

apiVersion: provisioning.cattle.io/v1
kind: Cluster
spec:
  rkeConfig:
    machineGlobalConfig:
      private-registry: |
        mirrors:
          docker.io:
            endpoint:
              - "http://mycustomreg.com:5000"
        configs:
          "mycustomreg:5000":
            auth:
              username: xxxxxx # this is the registry username
              password: xxxxxx # this is the registry password

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 die Dateien vorhanden sind, bevor die K3s-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:

  1. Es muss im fleet-default Namespace sein, in dem das Cluster-Objekt existiert.

  2. 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