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.

Registrierung vorhandener Cluster

Die Clusterregistrierungsfunktion ersetzt die Funktion zum Importieren von Clustern.

Die Kontrolle, die Rancher zur Verwaltung eines registrierten Clusters hat, hängt von der Art des Clusters ab. Für Details siehe Managementfähigkeiten für registrierte Cluster.

Voraussetzungen

Kubernetes-Knotenrollen

Registrierte RKE Kubernetes-Cluster müssen alle drei Knotenrollen - etcd, controlplane und worker - haben. Ein Cluster mit nur Controlplane-Komponenten kann nicht in Rancher registriert werden.

Für weitere Informationen zu RKE-Knotenrollen siehe die Best Practices.

Berechtigungen

Um einen Cluster in Rancher zu registrieren, müssen Sie cluster-admin Berechtigungen innerhalb dieses Clusters haben. Wenn nicht, gewähren Sie diese Berechtigungen Ihrem Benutzer, indem Sie Folgendes ausführen:

kubectl create clusterrolebinding cluster-admin-binding \
  --clusterrole cluster-admin \
  --user [USER_ACCOUNT]

Da Google Kubernetes Engine (GKE) standardmäßig die cluster-admin Rolle nicht gewährt, müssen Sie diese Befehle auf GKE-Clustern ausführen, bevor Sie sie registrieren können. Um mehr über rollenbasierte Zugriffskontrolle für GKE zu erfahren, siehe bitte die offizielle Google-Dokumentation.

Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), and Google Kubernetes Engine (GKE)

Um EKS, AKS und GKE-Cluster erfolgreich aus Rancher zu importieren oder bereitzustellen, muss der Cluster mindestens eine verwaltete Knoten-Gruppe haben.

AKS-Cluster können nur importiert werden, wenn lokale Konten aktiviert sind. Wenn ein Cluster so konfiguriert ist, dass Microsoft Entra ID für die Authentifizierung verwendet wird, kann Rancher ihn nicht importieren und meldet einen Fehler.

EKS Anywhere-Cluster können mit einer API-Adresse und Anmeldeinformationen in Rancher importiert/registriert werden, wie bei jedem Downstream-Cluster. EKS Anywhere-Cluster werden als importierte Cluster behandelt und haben keine vollständige Lebenszyklus-Unterstützung von Rancher.

GKE Autopilot-Cluster werden nicht unterstützt. Siehe GKE Autopilot und Standard vergleichen für weitere Informationen zu den Unterschieden zwischen GKE-Modi.

Einen Cluster registrieren

  1. Klicken Sie auf ☰ > Clusterverwaltung.

  2. Auf der Cluster Seite, Vorhandene importieren.

  3. Wählen Sie den Typ des Clusters aus.

  4. Verwenden Sie Mitgliederrollen, um die Benutzerautorisierung für den Cluster zu konfigurieren. Klicken Sie auf Mitglied hinzufügen, um Benutzer hinzuzufügen, die auf den Cluster zugreifen können. Verwenden Sie das Rolle-Dropdown, um die Berechtigungen für jeden Benutzer festzulegen.

  5. Wenn Sie einen generischen Kubernetes-Cluster in Rancher importieren, führen Sie die folgenden Schritte zur Einrichtung aus:

    1. Klicken Sie auf Agent-Umgebungsvariablen unter Cluster-Optionen, um Umgebungsvariablen für Rancher-Cluster-Agent festzulegen. Die Umgebungsvariablen können mit Schlüssel-Wert-Paaren festgelegt werden. Wenn der Rancher-Agent einen Proxy benötigt, um mit dem Rancher-Server zu kommunizieren, können die Umgebungsvariablen HTTP_PROXY, HTTPS_PROXY und NO_PROXY mit Agent-Umgebungsvariablen festgelegt werden.

    2. Aktivieren Sie die Projekt-Netzwerkisolierung, um sicherzustellen, dass der Cluster Kubernetes NetworkPolicy Ressourcen unterstützt. Benutzer können die Option Projekt-Netzwerkisolierung im Dropdown-Menü Erweiterte Optionen auswählen, um dies zu tun.

    3. Konfigurieren Sie die Versionsverwaltungsfunktion für importierte RKE2- und K3s-Cluster.

  6. Klicken Sie auf Erstellen.

  7. Die Voraussetzung für cluster-admin Berechtigungen wird angezeigt (siehe Voraussetzungen oben), einschließlich eines Beispielbefehls zur Erfüllung der Voraussetzung.

  8. Kopieren Sie den kubectl Befehl in Ihre Zwischenablage und führen Sie ihn auf einem Knoten aus, auf dem kubeconfig so konfiguriert ist, dass er auf den Cluster zeigt, den Sie importieren möchten. Wenn Sie sich nicht sicher sind, ob es korrekt konfiguriert ist, führen Sie kubectl get nodes aus, um dies zu überprüfen, bevor Sie den in Rancher angezeigten Befehl ausführen.

  9. Wenn Sie selbstsignierte Zertifikate verwenden, erhalten Sie die Nachricht certificate signed by unknown authority. Um diese Validierung zu umgehen, kopieren Sie den Befehl, der mit curl beginnt, der in Rancher angezeigt wird, in Ihre Zwischenablage. Führen Sie dann den Befehl auf einem Knoten aus, auf dem kubeconfig so konfiguriert ist, dass er auf den Cluster zeigt, den Sie importieren möchten.

  10. Wenn Sie das Ausführen des Befehls auf Ihrem Knoten abgeschlossen haben, klicken Sie auf Fertig.

Die NO_PROXY Umgebungsvariable ist nicht standardisiert, und das akzeptierte Format des Wertes kann zwischen Anwendungen variieren. Beim Konfigurieren der NO_PROXY Variablen für Rancher muss der Wert dem Format entsprechen, das von Golang erwartet wird.

Konkret sollte der Wert eine durch Kommas getrennte Zeichenfolge sein, die nur IP-Adressen, CIDR-Notation, Domainnamen oder spezielle DNS-Labels (z. B. *) enthält. Für eine vollständige Beschreibung des erwarteten Wertformats siehe die Upstream Golang-Dokumentation.

Ergebnis:

  • Ihr Cluster ist registriert und hat den Status Ausstehend. Rancher stellt Ressourcen bereit, um Ihr Cluster zu verwalten.

  • Sie können auf Ihren Cluster zugreifen, nachdem sein Status auf Aktiv aktualisiert wurde.

  • Aktive Cluster werden zwei Projekte zugewiesen: Default (mit dem Namespace default) und System (mit den Namespaces cattle-system, traefik, kube-public und kube-system, falls vorhanden).

Sie können ein Cluster, das derzeit in einem Rancher-Setup aktiv ist, nicht erneut registrieren.

Konfiguration eines importierten EKS-, AKS- oder GKE-Clusters mit Terraform

Sie sollten nur die minimalen Felder definieren, die Rancher beim Import eines EKS-, AKS- oder GKE-Clusters mit Terraform benötigt. Dies ist wichtig, da Rancher die Konfiguration des Clusters mit jeder Konfiguration überschreibt, die der Benutzer bereitgestellt hat.

Selbst ein kleiner Unterschied zwischen dem aktuellen Cluster und einer vom Benutzer bereitgestellten Konfiguration könnte unerwartete Ergebnisse haben.

Die von Rancher benötigten minimalen Konfigurationsfelder zum Importieren von EKS-Clustern mit Terraform unter Verwendung von eks_config_v2 sind wie folgt:

  • cloud_credential_id

  • name

  • region

  • importiert (dieses Feld sollte immer auf true für importierte Cluster gesetzt werden)

Beispiel-YAML-Konfiguration für importierte EKS-Cluster:

resource "rancher2_cluster" "my-eks-to-import" {
  name        = "my-eks-to-import"
  description = "Terraform EKS Cluster"
  eks_config_v2 {
    cloud_credential_id = rancher2_cloud_credential.aws.id
    name                = var.aws_eks_name
    region              = var.aws_region
    imported            = true
  }
}

Sie finden zusätzliche Beispiele für andere Cloud-Anbieter in der Rancher2 Terraform Provider-Dokumentation.

Verwaltungsmöglichkeiten für registrierte Cluster

Die Kontrolle, die Rancher zur Verwaltung eines registrierten Clusters hat, hängt von der Art des Clusters ab.

Funktionen für alle registrierten Cluster

Nach der Registrierung eines Clusters kann der Clusterbesitzer:

Zusätzliche Funktionen für registrierte SUSE® Rancher Prime: RKE2 und SUSE® Rancher Prime: K3s Cluster

K3s ist eine leichtgewichtige, vollständig konforme Kubernetes-Distribution für Edge-Installationen.

RKE2 ist Ranchers Kubernetes-Distribution der nächsten Generation für Rechenzentrum- und Cloud-Installationen.

Wenn ein RKE2- oder K3s-Cluster in Rancher registriert wird, erkennt Rancher es. Die Rancher-Benutzeroberfläche zeigt Funktionen an, die für alle registrierten Cluster verfügbar sind, zusammen mit den folgenden Optionen zum Bearbeiten und Aktualisieren des Clusters:

Zusätzliche Funktionen für registrierte EKS-, AKS- und GKE-Cluster

Rancher behandelt registrierte EKS-, AKS- oder GKE-Cluster ähnlich wie Cluster, die in Rancher erstellt wurden. Rancher zerstört jedoch keine registrierten Cluster, wenn Sie sie über die Rancher-Benutzeroberfläche löschen.

Wenn Sie einen EKS-, AKS- oder GKE-Cluster in Rancher erstellen und ihn dann löschen, zerstört Rancher den Cluster. Wenn Sie einen registrierten Cluster über Rancher löschen, trennt sich der Rancher-Server vom Cluster. Der Cluster bleibt aktiv, obwohl er nicht mehr in Rancher ist. Sie können weiterhin auf den abgemeldeten Cluster zugreifen, wie zuvor, bevor Sie ihn registriert haben.

Siehe Clusterverwaltungsfähigkeiten nach Cluster-Typ für weitere Informationen darüber, welche Funktionen für die Verwaltung registrierter Cluster verfügbar sind.

Konfigurieren der Versionsverwaltung für SUSE® Rancher Prime: RKE2 und SUSE® Rancher Prime: K3s Cluster

Wenn die Versionsverwaltung für einen importierten Cluster aktiviert ist, kann ein Upgrade außerhalb von Rancher unerwartete Folgen haben.

Die Funktion zur Versionsverwaltung für importierte RKE2- und K3s-Cluster kann mit einer der folgenden Optionen konfiguriert werden:

  • Globale Standardeinstellung (Standard): Erbt das Verhalten von der globalen imported-cluster-version-management Einstellung.

  • Wahr: Aktiviert die Versionsverwaltung, sodass Benutzer die Kubernetes-Version und die Upgrade-Strategie des Clusters über Rancher steuern können.

  • Falsch: Deaktiviert die Versionsverwaltung, sodass Benutzer die Kubernetes-Version des Clusters unabhängig, außerhalb von Rancher verwalten können.

Sie können das Standardverhalten für neu erstellte Cluster oder bestehende, die auf "globale Standardeinstellung" gesetzt sind, ändern, indem Sie die Versionsverwaltung für importierte Cluster Einstellung anpassen.

Änderungen an der globalen Versionsverwaltung für importierte Cluster Einstellung treten während des nächsten Abstimmungszyklus des Clusters in Kraft.

Wenn die Versionsverwaltung für einen Cluster aktiviert ist, wird Rancher die system-upgrade-controller App zusammen mit den zugehörigen Plänen und anderen erforderlichen Kubernetes-Ressourcen im Cluster bereitstellen. Wenn die Versionsverwaltung deaktiviert ist, entfernt Rancher diese Komponenten aus dem Cluster.

Konfigurieren von SUSE® Rancher Prime: RKE2 und SUSE® Rancher Prime: K3s Cluster-Upgrades

Es ist eine bewährte Praxis in Kubernetes, das Cluster vor dem Upgrade zu sichern. Beim Upgrade eines hochverfügbaren K3s-Clusters mit einer externen Datenbank sichern Sie die Datenbank auf die vom Anbieter der relationalen Datenbank empfohlene Weise.

Die concurrency ist die maximale Anzahl von Knoten, die während eines Upgrades nicht verfügbar sein dürfen. Wenn die Anzahl der nicht verfügbaren Knoten größer ist als die concurrency, schlägt das Upgrade fehl. Wenn ein Upgrade fehlschlägt, müssen Sie möglicherweise fehlgeschlagene Knoten reparieren oder entfernen, bevor das Upgrade erfolgreich sein kann.

  • Parallelität des Controlplanes: Die maximale Anzahl von Serverknoten, die gleichzeitig aktualisiert werden können; auch die maximalen nicht verfügbaren Serverknoten

  • Parallelität der Worker: Die maximale Anzahl von Worker-Knoten, die gleichzeitig aktualisiert werden können; auch die maximalen nicht verfügbaren Worker-Knoten

In der RKE2- und K3s-Dokumentation werden Controlplane-Knoten als Serverknoten bezeichnet. Diese Knoten führen den Kubernetes-Master aus, der den gewünschten Zustand des Clusters aufrechterhält. Standardmäßig haben diese Controlplane-Knoten die Fähigkeit, standardmäßig Workloads zugewiesen zu bekommen.

Auch in der RKE2- und K3s-Dokumentation werden Knoten mit der Worker-Rolle als Agentenknoten bezeichnet. Alle Workloads oder Pods, die im Cluster bereitgestellt werden, können standardmäßig auf diese Knoten geplant werden.

Debug-Protokollierung und Fehlersuche für registrierte SUSE® Rancher Prime: RKE2 und SUSE® Rancher Prime: K3s Cluster

Knoten werden vom System Upgrade Controller, der im Downstream-Cluster läuft, aktualisiert. Basierend auf der Clusterkonfiguration stellt Rancher zwei Pläne zum Upgrade von Knoten bereit: einen für Controlplane-Knoten und einen für Worker. Der System-Upgrade-Controller folgt den Plänen und aktualisiert die Knoten.

Um die Debug-Protokollierung für die Implementierung des System-Upgrade-Controllers zu aktivieren, bearbeiten Sie das ConfigMap, um die Debug-Umgebungsvariable auf true zu setzen. Starten Sie dann den system-upgrade-controller Pod neu.

Die Protokolle, die von dem system-upgrade-controller erstellt wurden, können durch Ausführen dieses Befehls angezeigt werden:

kubectl logs -n cattle-system system-upgrade-controller

Der aktuelle Status der Pläne kann mit diesem Befehl angezeigt werden:

kubectl get plans -A -o yaml

Wenn der Cluster beim Upgrade hängen bleibt, starten Sie den system-upgrade-controller neu.

Um Probleme beim Upgrade zu vermeiden, sollten die Kubernetes Upgrade Best Practices befolgt werden.

Autorisierter Cluster-Endpunkt-Support für SUSE® Rancher Prime: RKE2 und SUSE® Rancher Prime: K3s Cluster

Rancher unterstützt autorisierte Cluster-Endpunkte (ACE) für registrierte RKE2- und K3s-Cluster. Diese Unterstützung umfasst manuelle Schritte, die Sie im Downstream-Cluster ausführen, um den ACE zu aktivieren. Für weitere Informationen zum autorisierten Cluster-Endpunkt klicken Sie hier.

Hinweise:

  • Diese Schritte müssen nur auf den Steuerungsebene-Knoten des Downstream-Clusters ausgeführt werden. Sie müssen jeden Steuerungsebene-Knoten einzeln konfigurieren.

  • Die folgenden Schritte funktionieren sowohl bei RKE2- als auch bei K3s-Clustern, die in v2.6.x registriert sind, sowie bei denen, die aus einer vorherigen Version von Rancher mit einem Upgrade auf v2.6.x registriert (oder importiert) wurden.

  • Diese Schritte ändern die Konfiguration der Downstream RKE2- und K3s-Cluster und stellen den kube-api-authn-webhook bereit. Wenn eine zukünftige Implementierung des ACE ein Update für den kube-api-authn-webhook erfordert, müsste dies ebenfalls manuell erfolgen. Für weitere Informationen zu diesem Webhook klicken Sie hier.
Manuelle Schritte, die auf der Steuerungsebene jedes Downstream-Clusters zur Aktivierung von ACE durchgeführt werden müssen:

  1. Erstellen Sie eine Datei unter /var/lib/rancher/{rke2,k3s}/kube-api-authn-webhook.yaml mit folgendem Inhalt:

     apiVersion: v1
 kind: Config
 clusters:
 ** name: Default
cluster:
  insecure-skip-tls-verify: true
  server: http://127.0.0.1:6440/v1/authenticate
 users:
 ** name: Default
user:
  insecure-skip-tls-verify: true
 current-context: webhook
 contexts:
 ** name: webhook
context:
  user: Default
  cluster: Default

  2. Fügen Sie Folgendes zur Konfigurationsdatei hinzu (oder erstellen Sie eine, wenn sie nicht existiert); beachten Sie, dass der Standardstandort /etc/rancher/{rke2,k3s}/config.yaml ist:

     kube-apiserver-arg:
     - authentication-token-webhook-config-file=/var/lib/rancher/{rke2,k3s}/kube-api-authn-webhook.yaml

  3. Führen Sie folgende Befehle aus:

    sudo systemctl stop {rke2,k3s}-server
sudo systemctl start {rke2,k3s}-server

  4. Schließlich müssen Sie must zur Rancher-Benutzeroberfläche zurückkehren und den importierten Cluster dort bearbeiten, um die Aktivierung des ACE abzuschließen. Klicken Sie auf ⋮ > Konfiguration bearbeiten, und klicken Sie dann auf die Registerkarte Netzwerk unter Clusterkonfiguration. Klicken Sie schließlich auf die Schaltfläche Aktiviert für Autorisierter Endpunkt. Sobald der ACE aktiviert ist, haben Sie die Möglichkeit, einen vollständig qualifizierten Domänennamen (FQDN) und Zertifikatsinformationen einzugeben.

Das Feld FQDN ist optional, und wenn eines eingegeben wird, sollte es auf den Downstream-Cluster verweisen. Zertifikatsinformationen sind nur erforderlich, wenn sich ein Load-Balancer vor dem Downstream-Cluster befindet, der ein nicht vertrauenswürdiges Zertifikat verwendet. Wenn Sie ein gültiges Zertifikat haben, muss nichts in das Feld CA-Zertifikate hinzugefügt werden.

Annotieren von registrierten Clustern

Für alle Arten von registrierten Kubernetes-Clustern, mit Ausnahme von RKE2 und K3s Kubernetes-Clustern, hat Rancher keine Informationen darüber, wie der Cluster bereitgestellt oder konfiguriert ist.

Daher geht Rancher davon aus, dass mehrere Funktionen standardmäßig deaktiviert sind, wenn ein Cluster registriert wird. Rancher geht davon aus, um zu vermeiden, dass UI-Optionen dem Benutzer angezeigt werden, selbst wenn die Funktionen im registrierten Cluster nicht aktiviert sind.

Wenn der Cluster jedoch über eine bestimmte Funktion verfügt, möchte ein Benutzer dieses Clusters möglicherweise dennoch die Funktion für den Cluster in der Rancher-Benutzeroberfläche auswählen. Um dies zu tun, muss der Benutzer Rancher manuell angeben, dass bestimmte Funktionen für den Cluster aktiviert sind.

Durch das Annotieren eines registrierten Clusters ist es möglich, Rancher anzuzeigen, dass einem Cluster zusätzliche Funktionen außerhalb von Rancher zugewiesen wurden.

Die folgende Annotation zeigt Ingress-Funktionen an. Beachten Sie, dass die Werte nicht-primitiver Objekte im JSON-Format kodiert werden müssen, wobei die Anführungszeichen escaped sind.

"capabilities.cattle.io/ingressCapabilities": "[
  {
    "customDefaultBackend":true,
    "ingressProvider":"asdf"
  }
]"

Diese Funktionen können für den Cluster annotiert werden:

  • ingressCapabilities

  • loadBalancerCapabilities

  • nodePoolScalingSupported

  • nodePortRange

  • taintSupport

Alle Funktionen und deren Typdefinitionen können in der Rancher API-Ansicht unter [Rancher Server URL]/v3/schemas/capabilities eingesehen werden.

Um einen registrierten Cluster zu annotieren,

  1. Klicken Sie auf ☰ > Clusterverwaltung.

  2. Gehen Sie auf der Seite Cluster zu dem benutzerdefinierten Cluster, das Sie annotieren möchten, und klicken Sie auf ⋮ > Konfiguration bearbeiten.

  3. Erweitern Sie den Abschnitt Labels & Annotationen.

  4. Klicken Sie auf Annotation hinzufügen.

  5. Fügen Sie eine Annotation zum Cluster im Format capabilities/<capability>: <value> hinzu, wobei value die Clusterfähigkeit ist, die durch die Annotation überschrieben wird. In diesem Szenario ist Rancher sich keiner Fähigkeiten des Clusters bewusst, bis Sie die Annotation hinzufügen.

  6. Klicken Sie auf Speichern.

Ergebnis: Die Annotation verleiht dem Cluster keine Fähigkeiten, weist Rancher jedoch darauf hin, dass der Cluster über diese Fähigkeiten verfügt.

Fehlerbehebung

Dieser Abschnitt listet einige der häufigsten Fehler auf, die beim Importieren eines Clusters auftreten können, und bietet Schritte zur Fehlersuche.

AKS

Der folgende Fehler kann auftreten, wenn lokale Konten in Ihrem Cluster deaktiviert sind:

Error: Getting static credential is not allowed because this cluster is set to disable local accounts.

Um dieses Problem zu lösen, aktivieren Sie lokale Konten, bevor Sie erneut versuchen, den Cluster zu importieren:

az aks update --resource-group <resource-group> --name <cluster-name> --enable-local-accounts