Erweiterte Optionen und Konfiguration

Standardmäßig laufen die Zertifikate in RKE2 nach 12 Monaten ab.

Wenn die Zertifikate abgelaufen sind oder weniger als 90 Tage verbleiben, bevor sie ablaufen, werden die Zertifikate beim Neustart von RKE2 rotiert.

Zertifikate können auch manuell rotiert werden. Um dies zu tun, ist es am besten, den rke2-server-Prozess zu beenden, die Zertifikate zu rotieren und dann den Prozess wieder zu starten:

Um die Agentenzertifikate zu erneuern, starten Sie rke2-agent auf den Agentenknoten neu. Agentenzertifikate werden jedes Mal erneuert, wenn der Agent startet.

Es ist auch möglich, einen einzelnen Dienst zu rotieren, indem Sie das --service Flag übergeben, zum Beispiel: rke2 certificate rotate --service api-server. Siehe Zertifikatsverwaltung für weitere Details.

Jede Datei, die in /var/lib/rancher/rke2/server/manifests gefunden wird, wird automatisch in Kubernetes bereitgestellt, ähnlich wie kubectl apply.

Für Informationen über das Bereitstellen von Helm-Charts mit dem Manifests-Verzeichnis, siehe den Abschnitt über Helm.

RKE2 wird eine Konfigurationsdatei für containerd unter /var/lib/rancher/rke2/agent/etc/containerd/config.toml generieren, die spezifische Werte für die aktuelle Cluster- und Knotenkonfiguration verwendet.

Für erweiterte Anpassungen können Sie eine containerd-Konfigurationsvorlage im selben Verzeichnis erstellen:

Containerd 2.0 ist rückwärtskompatibel mit früheren Konfigurationsversionen, und RKE2 wird weiterhin die veraltete Konfiguration der Version 2 aus config.toml.tmpl rendern, wenn config-v3.toml.tmpl nicht gefunden wird.

Die Vorlagendatei wird mit der text/template Bibliothek in die containerd-Konfiguration gerendert. Siehe ContainerdConfigTemplateV3 und ContainerdConfigTemplate in templates.go für den Standardinhalt der Vorlage. Die Vorlage wird mit einer ContainerdConfig Struktur als Dot-Wert (Datenargument) ausgeführt.

Wenn Sie RKE2 in einer Umgebung ausführen, die nur über einen HTTP-Proxy externe Konnektivität hat, können Sie Ihre Proxy-Einstellungen im RKE2 systemd-Dienst konfigurieren. Diese Proxy-Einstellungen werden dann in RKE2 verwendet und an den eingebetteten containerd und kubelet sowie an die Control-Plane, etcd und kube-proxy statischen Pods weitergegeben.

Fügen Sie die erforderlichen HTTP_PROXY, HTTPS_PROXY und NO_PROXY Variablen zur Umgebungsdatei Ihres systemd-Dienstes hinzu, normalerweise:

RKE2 wird automatisch die internen Pod- und Service-IP-Bereiche des Clusters sowie die DNS-Domain des Clusters zur Liste der NO_PROXY Einträge hinzufügen. Sie sollten sicherstellen, dass die von den Kubernetes-Knoten selbst verwendeten IP-Adressbereiche (d.h. die öffentlichen und privaten IPs der Knoten) in der NO_PROXY Liste enthalten sind oder dass die Knoten über den Proxy erreichbar sind.

Wenn Sie die Proxy-Einstellungen für containerd konfigurieren möchten, ohne RKE2 und Kubelet zu beeinflussen, können Sie die Variablen mit CONTAINERD_ voranstellen:

RKE2-Agenten können mit den Optionen node-label und node-taint konfiguriert werden, die ein Label und einen Taint zu Kubelet hinzufügen. Die beiden Optionen fügen nur bei der Registrierung Labels und/oder Taints hinzu und können nur einmal hinzugefügt und danach nicht mehr über rke2-Befehle entfernt werden.

Wenn Sie die Knoten-Labels und Taints nach der Knotenregistrierung ändern möchten, sollten Sie kubectl verwenden. Bitte beachten Sie die offizielle Kubernetes-Dokumentation für Details, wie man Taints und Labels hinzufügt.

Agentenknoten werden über eine Websocket-Verbindung registriert, die vom rke2 agent-Prozess initiiert wird, und die Verbindung wird von einem clientseitigen Lastenausgleichsmechanismus aufrechterhalten, der als Teil des Agentenprozesses läuft.

Agenten registrieren sich beim Server mit dem geheimen Teil des Cluster-Join-Tokens sowie einem zufällig generierten, knotenspezifischen Passwort, das auf dem Agenten unter /etc/rancher/node/password gespeichert ist. Der Server speichert die Passwörter für einzelne Knoten als Kubernetes-Geheimnisse, und alle nachfolgenden Versuche müssen dasselbe Passwort verwenden. Die Knotenpasswortgeheimnisse werden im kube-system Namespace mit Namen gespeichert, die das Template <host>.node-password.rke2 verwenden. Diese Geheimnisse werden gelöscht, wenn der entsprechende Kubernetes-Knoten gelöscht wird.

Wenn das /etc/rancher/node Verzeichnis eines Agenten entfernt wird, sollte die Passwortdatei vor dem Start des Agenten neu erstellt werden, oder der Eintrag sollte vom Server oder Kubernetes-Cluster entfernt werden (je nach RKE2-Version).

Das Installationsskript stellt Einheiten für systemd bereit, aktiviert oder startet den Dienst jedoch standardmäßig nicht.

Beim Ausführen mit systemd werden Protokolle in /var/log/syslog erstellt und mit journalctl -u rke2-server oder journalctl -u rke2-agent angezeigt.

Ein Beispiel für die Installation mit dem Installationsskript:

Die mit rke2 gebündelten Serverdiagramme, die während des Cluster-Bootstrappings bereitgestellt werden, können deaktiviert und durch Alternativen ersetzt werden. Ein häufiger Anwendungsfall ist das Ersetzen des gebündelten rke2-ingress-nginx-Diagramms durch eine Alternative.

Um eines der gebündelten Systemdiagramme zu deaktivieren, setzen Sie den disable-Parameter in der Konfigurationsdatei vor dem Bootstrapping. Ein Beispiel für die Deaktivierung aller verfügbaren Systemdiagramme ist:

In öffentlichen AWS-Regionen, um sicherzustellen, dass RKE2 cloud-fähig ist und in der Lage ist, bestimmte Cloud-Ressourcen automatisch bereitzustellen, konfigurieren Sie RKE2 mit:

Bei der Installation von RKE2 in klassifizierten Regionen (wie SC2S oder C2S) gibt es einige zusätzliche Voraussetzungen, die zu beachten sind, um sicherzustellen, dass RKE2 weiß, wie und wo es sicher mit den entsprechenden AWS-Endpunkten kommunizieren kann:

Die folgenden Optionen stehen unter dem server Unterbefehl für RKE2 zur Verfügung. Die Optionen ermöglichen die Angabe von CPU-Anforderungen und -limits für die Komponenten der Steuerungsebene innerhalb von RKE2.

Werte sind eine durch Kommas getrennte Liste von [controlplane-component]-(cpu|memory)=[desired-value]. Die möglichen Werte für controlplane-component sind:

Ein Beispiel für eine Konfiguration könnte wie folgt aussehen:

Die Einheitwerte für CPU/Speicher sind identisch mit den Kubernetes-Ressourceneinheiten (Siehe: Ressourcengrenzen in Kubernetes).

Die folgenden Optionen stehen unter dem server Unterbefehl für RKE2 zur Verfügung. Diese Optionen spezifizieren das Mounten von Verzeichnissen aus dem Node-Dateisystem in die statische Pod-Komponente, die dem vorangestellten Namen entspricht.

Die folgenden Konfigurationsoptionen stehen dem server Unterbefehl für RKE2 zur Verfügung. Diese Optionen geben zusätzliche Umgebungsvariablen im Standardformat an, d.h., KEY=VALUE für die statische Pod-Komponente, die dem vorangestellten Namen entspricht.

Für dieselbe Komponente können mehrere Umgebungsvariablen angegeben werden, indem die Flag-Werte als Array in der Konfigurationsdatei übergeben werden.