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.

Verteiltes hybrides oder Multicloud-Cluster

Ein K3s-Cluster kann weiterhin auf Knoten bereitgestellt werden, die kein gemeinsames privates Netzwerk teilen und nicht direkt verbunden sind (z. B. Knoten in verschiedenen Public Clouds). Es gibt zwei Optionen, um dies zu erreichen: die integrierte k3s-Multicloud-Lösung und die Integration mit dem tailscale VPN-Anbieter.

Die Latenz zwischen den Knoten wird zunehmen, da die externe Konnektivität mehr Hops erfordert. Dies wird die Netzwerkleistung verringern und könnte auch die Gesundheit des Clusters beeinträchtigen, wenn die Latenz zu hoch ist.

Integriertes etcd wird in dieser Art von Bereitstellung nicht unterstützt. Wenn integriertes etcd verwendet wird, müssen alle Serverknoten über ihre privaten IPs erreichbar sein. Agenten können über mehrere Netzwerke verteilt sein, aber alle Server sollten sich am selben Standort befinden.

Integrierte k3s-Multicloud-Lösung

K3s verwendet WireGuard, um ein VPN-Mesh für den Clusterverkehr einzurichten. Jeder Knoten muss eine eindeutige IP haben, über die er erreichbar ist (normalerweise eine öffentliche IP). Der K3s-Überwachungsverkehr verwendet einen WebSocket-Tunnel, und der Cluster-(CNI)-Verkehr verwendet einen WireGuard-Tunnel.

Um diese Art der Bereitstellung zu ermöglichen, müssen Sie die folgenden Parameter auf den Servern hinzufügen:

--node-external-ip=<SERVER_EXTERNAL_IP> --flannel-backend=wireguard-native --flannel-external-ip

und auf den Agenten:

--node-external-ip=<AGENT_EXTERNAL_IP>

wobei SERVER_EXTERNAL_IP die IP ist, über die wir den Serverknoten erreichen können, und AGENT_EXTERNAL_IP die IP ist, über die wir den Agentenknoten erreichen können. Beachten Sie, dass der K3S_URL-Konfigurationsparameter im Agenten SERVER_EXTERNAL_IP verwenden sollte, um eine Verbindung herstellen zu können. Denken Sie daran, die Netzwerkanforderungen zu überprüfen und den Zugriff auf die aufgeführten Ports sowohl auf internen als auch auf externen Adressen zu ermöglichen.

Sowohl SERVER_EXTERNAL_IP als auch AGENT_EXTERNAL_IP müssen eine Verbindung zueinander haben und sind normalerweise öffentliche IPs.

Dynamische IPs

Wenn Knoten dynamische IPs zugewiesen bekommen und sich die IP ändert (z. B. in AWS), müssen Sie den --node-external-ip Parameter an die neue IP anpassen. Wenn K3s als Dienst ausgeführt wird, müssen Sie /etc/systemd/system/k3s.service ändern und dann ausführen:

systemctl daemon-reload
systemctl restart k3s

Integration mit dem Tailscale VPN-Anbieter (experimentell)

Verfügbar in v1.27.3, v1.26.6, v1.25.11 und neueren Versionen.

K3s kann mit Tailscale integriert werden, sodass Knoten den Tailscale VPN-Dienst nutzen, um ein Mesh zwischen Knoten aufzubauen.

Es gibt vier Schritte, die mit Tailscale durchgeführt werden müssen, bevor K3s bereitgestellt wird:

  1. Melden Sie sich bei Ihrem Tailscale-Konto an

  2. Generieren Sie in Settings > Keys einen Authentifizierungsschlüssel ($AUTH-KEY), der für alle Knoten in Ihrem Cluster wiederverwendbar sein kann.

  3. Entscheiden Sie sich für das podCIDR, das der Cluster verwenden wird (standardmäßig 10.42.0.0/16). Fügen Sie die CIDR (oder CIDRs für Dual-Stack) in der Zugriffskontrolle mit dem Abschnitt hinzu:

    "autoApprovers": {
     "routes": {
         "10.42.0.0/16":        ["your_account@xyz.com"],
         "2001:cafe:42::/56": ["your_account@xyz.com"],
     },
 },

  4. Installieren Sie Tailscale auf Ihren Knoten.

    curl -fsSL https://tailscale.com/install.sh | sh

Um K3s mit aktivierter Tailscale-Integration bereitzustellen, müssen Sie den folgenden Parameter auf jedem Ihrer Knoten hinzufügen:

--vpn-auth="name=tailscale,joinKey=$AUTH-KEY"

oder geben Sie diese Informationen in einer Datei an und verwenden Sie den Parameter:

--vpn-auth-file=$PATH_TO_FILE

Optional, wenn Sie Ihren eigenen Tailscale-Server (z. B. Headscale) haben, können Sie sich mit ihm verbinden, indem Sie ,controlServerURL=$URL zu den vpn-auth-Parametern hinzufügen.

Als Nächstes können Sie fortfahren, den Server mit dem folgenden Befehl zu erstellen.

k3s server --token <token> --vpn-auth="name=tailscale,joinKey=<joinKey>" --node-external-ip=<TailscaleIPOfServerNode>

Nach der Ausführung dieses Befehls greifen Sie auf die Tailscale-Admin-Konsole zu, um den Tailscale-Knoten und das Subnetz zu genehmigen (sofern nicht bereits über autoApprovers genehmigt).

Sobald der Server eingerichtet ist, verbinden Sie die Agenten mit:

k3s agent --token <token> --vpn-auth="name=tailscale,joinKey=<joinKey>" --server https://<TailscaleIPOfServerNode>:6443 --node-external-ip=<TailscaleIPOfAgentNode>

Genehmigen Sie erneut den Tailscale-Knoten und das Subnetz, wie Sie es für den Server getan haben.

Wenn Sie ACLs in Tailscale aktiviert haben, müssen Sie eine "accept"-Regel hinzufügen, um Pods die Kommunikation miteinander zu ermöglichen. Vorausgesetzt, der Authentifizierungsschlüssel, den Sie erstellt haben, kennzeichnet die Tailscale-Knoten automatisch mit dem Tag testing-k3s, sollte die Regel folgendermaßen aussehen:

"acls": [
    {
        "action": "accept",
        "src":    ["tag:testing-k3s", "10.42.0.0/16"],
        "dst":    ["tag:testing-k3s:*", "10.42.0.0/16:*"],
    },
],

Wenn Sie planen, mehrere K3s-Cluster im selben Tailscale-Netzwerk auszuführen, erstellen Sie bitte geeignete ACLs, um IP-Konflikte zu vermeiden, oder verwenden Sie unterschiedliche PodCIDR-Subnetze für jeden Cluster.