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.

Netzwerkservices

Diese Seite erklärt, wie CoreDNS, der Traefik Ingress-Controller, der Network Policy-Controller und der ServiceLB-Load-Balancer-Controller innerhalb von K3s funktionieren.

Bitte beziehen Sie sich auf die Installationsnetzwerkoptionen-Seite für Details zu den Flannel-Konfigurationsoptionen und der Auswahl des Backends oder wie Sie Ihr eigenes CNI einrichten können.

Für Informationen darüber, welche Ports für K3s geöffnet werden müssen, beziehen Sie sich auf die Netzwerkanforderungen.

CoreDNS

CoreDNS wird automatisch beim Start des Servers bereitgestellt. Um es zu deaktivieren, konfigurieren Sie alle Server im Cluster mit der --disable=coredns-Option.

Wenn Sie CoreDNS nicht installieren, müssen Sie selbst einen Cluster-DNS-Anbieter installieren.

Traefik Ingress-Controller

Traefik ist ein moderner HTTP-Reverse-Proxy und Load-Balancer, der entwickelt wurde, um Microservices einfach bereitzustellen. Es vereinfacht die Netzwerkkomplexität beim Entwerfen, Bereitstellen und Ausführen von Anwendungen.

Der Traefik Ingress-Controller stellt einen LoadBalancer-Service bereit, der die Ports 80 und 443 verwendet und die externen IPs des LoadBalancer-Services im Status der verwalteten Ingress-Ressourcen anzeigt.

Standardmäßig verwendet ServiceLB alle Knoten im Cluster, um den Traefik LoadBalancer-Service zu hosten, was bedeutet, dass die Ports 80 und 443 nicht für andere HostPort- oder NodePort-Pods verwendet werden können und der Status der Ingress-Ressourcen die IPs aller Cluster-Mitglieder anzeigt.

Um die von Traefik verwendeten Knoten und damit die im Ingress-Status beworbenen Knoten-IPs einzuschränken, können Sie die Anweisungen im Abschnitt Steuerung der ServiceLB-Knotenauswahl unten befolgen, um zu begrenzen, auf welchen Knoten ServiceLB ausgeführt wird, oder indem Sie einige Knoten zu einem LoadBalancer-Pool hinzufügen und den Traefik-Service auf diesen Pool beschränken, indem Sie übereinstimmende Labels in der Traefik HelmChartConfig festlegen.

Traefik wird standardmäßig beim Starten des Servers bereitgestellt. Die Standardwerte des Charts finden Sie in /var/lib/rancher/k3s/server/manifests/traefik.yaml, aber diese Datei sollte nicht manuell bearbeitet werden, da K3s die Datei beim Start mit den Standardwerten ersetzt. Stattdessen sollten Sie Traefik anpassen, indem Sie ein zusätzliches HelmChartConfig-Manifest in /var/lib/rancher/k3s/server/manifests erstellen. Für weitere Details und ein Beispiel siehe Anpassen von verpackten Komponenten mit HelmChartConfig. Für weitere Informationen zu den möglichen Konfigurationswerten beziehen Sie sich auf values.yaml des Traefik Helm Charts, das mit Ihrer Version von K3s enthalten ist.

Um Traefik aus Ihrem Cluster zu entfernen, starten Sie alle Server mit dem --disable=traefik-Flag. Für weitere Informationen siehe Verwalten von verpackten Komponenten.

Für Details zur spezifischen Version von Traefik, die mit K3s enthalten ist, konsultieren Sie die Versionshinweise für Ihre Version.

K3s-Versionen, die mit 1.32 beginnen, enthalten Traefik v3. Bestehende Installationen von Traefik v2 werden automatisch auf v3 upgegradet, wenn K3s upgegradet wird. Traefik v3 sollte mit der Konfiguration von v2 kompatibel sein; konsultieren Sie die Upstream Dokumentation zur Migration von v2 auf v3 für weitere Informationen.
K3s-Versionen 1.21 bis 1.31 enthalten Traefik v2, es sei denn, eine bestehende Installation von Traefik v1 wird gefunden, in diesem Fall wurde Traefik nicht auf v2 aktualisiert.
K3s-Versionen 1.20 und frühere enthalten Traefik v1.

Netzwerk-Richtlinien-Controller

K3s enthält einen eingebetteten Netzwerk-Richtlinien-Controller. Die zugrunde liegende Implementierung ist die Netpol-Controller-Bibliothek von kube-router (keine andere Funktionalität von kube-router ist vorhanden) und kann hier gefunden werden.

Um ihn zu deaktivieren, starten Sie jeden Server mit dem --disable-network-policy-Flag.

Netzwerk-Richtlinien-Iptables-Regeln werden nicht entfernt, wenn die K3s-Konfiguration geändert wird, um den Netzwerk-Richtlinien-Controller zu deaktivieren. Um die konfigurierten kube-router-Netzwerk-Richtlinien-Regeln nach der Deaktivierung des Netzwerk-Richtlinien-Controllers zu bereinigen, verwenden Sie das k3s-killall.sh Skript oder bereinigen Sie sie mit iptables-save und iptables-restore. Diese Schritte müssen manuell auf allen Knoten im Cluster ausgeführt werden.

iptables-save | grep -v KUBE-ROUTER | iptables-restore
ip6tables-save | grep -v KUBE-ROUTER | ip6tables-restore

Service Load Balancer

Jeder LoadBalancer-Controller kann in Ihrem K3s-Cluster bereitgestellt werden. Standardmäßig bietet K3s einen Lastenausgleich, der als ServiceLB bekannt ist (ehemals Klipper LoadBalancer), der verfügbare Host-Ports verwendet.

Upstream Kubernetes erlaubt die Erstellung von Services vom Typ LoadBalancer, enthält jedoch keine Standardimplementierung eines Lastenausgleichs, sodass diese Services pending bleiben, bis einer installiert wird. Viele gehostete Dienste erfordern einen Cloud-Anbieter wie Amazon EC2 oder Microsoft Azure, um eine externe Lastenausgleichsimplementierung anzubieten. Im Gegensatz dazu ermöglicht der K3s ServiceLB die Verwendung von LoadBalancer-Services ohne einen Cloud-Anbieter oder zusätzliche Konfiguration.

Wie ServiceLB funktioniert

Der ServiceLB-Controller überwacht Kubernetes Services mit dem spec.type-Feld, das auf LoadBalancer gesetzt ist.

Für jeden LoadBalancer-Service wird ein DaemonSet im kube-system Namespace erstellt. Dieses DaemonSet erstellt wiederum ServiceLB-Pods mit einem svc- Präfix auf jedem Knoten. Diese Pods nutzen hostPort unter Verwendung des Service-Ports, daher werden sie nur auf Knoten bereitgestellt, die diesen Port verfügbar haben. Wenn es keine Knoten mit diesem Port gibt, bleibt der LB im Status "Pending". Es ist zu beachten, dass es möglich ist, mehrere Services auf demselben Knoten bereitzustellen, solange sie unterschiedliche Ports verwenden.

Wenn der ServiceLB-Pod auf einem Knoten läuft, der eine externe IP konfiguriert hat, wird die externe IP des Knotens in die Adressliste des Services status.loadBalancer.ingress mit ipMode: VIP eingetragen. Andernfalls wird die interne IP des Knotens verwendet.

Wenn der Verkehr zur externen IP dem Network Address Translation (NAT) unterliegt – zum Beispiel in der Public Cloud, wenn die öffentliche IP des Knotens als externe IP verwendet wird – wird der Verkehr über den hostPort in den ServiceLB-Pod geleitet. Der Pod verwendet dann iptables, um den Verkehr an die ClusterIP-Adresse und den Port des Services weiterzuleiten. Wenn der Verkehr nicht dem NAT unterliegt und stattdessen mit der Zieladresse übereinstimmt, die der LoadBalancer-Adresse entspricht, wird der Verkehr abgefangen (normalerweise durch kube-proxy iptables-Ketten oder ipvs) und an die ClusterIP-Adresse und den Port des Services weitergeleitet.

Verwendung

Erstellen Sie einen Service vom Typ LoadBalancer in K3s.

Bekanntes Problem

Wenn externer Verkehr den Knoten über ein NAT (z. B. in der Public Cloud) erreicht und Sie externalTrafficPolicy=local für Zwecke wie die Erhaltung der Quell-IP des Clients benötigen, definieren Sie bitte nicht die K3s-Konfiguration node-external-ip für einen der Knoten, da dies nicht korrekt funktioniert.

Steuerung der Auswahl von ServiceLB-Knoten.

Durch das Hinzufügen des svccontroller.k3s.cattle.io/enablelb=true Labels zu einem oder mehreren Knoten wechselt der ServiceLB-Controller in den Allow-List-Modus, in dem nur Knoten mit dem Label berechtigt sind, LoadBalancer-Pods zu hosten. Knoten, die unlabeled bleiben, werden von der Nutzung durch ServiceLB ausgeschlossen.

Standardmäßig sind Knoten nicht beschriftet. Solange alle Knoten unlabeled bleiben, werden alle Knoten mit verfügbaren Ports von ServiceLB verwendet.

Erstellen von ServiceLB-Knoten-Pools.

Um eine bestimmte Teilmenge von Knoten auszuwählen, die Pods für einen LoadBalancer hosten sollen, fügen Sie das enablelb Label zu den gewünschten Knoten hinzu und setzen Sie übereinstimmende lbpool Labelwerte auf den Knoten und Services. Beispiel:

Benennen Sie Knoten A und Knoten B mit svccontroller.k3s.cattle.io/lbpool=pool1 und svccontroller.k3s.cattle.io/enablelb=true.
Benennen Sie Knoten C und Knoten D mit svccontroller.k3s.cattle.io/lbpool=pool2 und svccontroller.k3s.cattle.io/enablelb=true.
Erstellen Sie einen LoadBalancer-Service auf Port 443 mit dem Label svccontroller.k3s.cattle.io/lbpool=pool1. Das DaemonSet für diesen Dienst stellt Pods nur auf Knoten A und Knoten B bereit.
Erstellen Sie einen weiteren LoadBalancer-Service auf Port 443 mit dem Label svccontroller.k3s.cattle.io/lbpool=pool2. Das DaemonSet wird Pods nur auf Knoten C und Knoten D bereitstellen.

Deaktivierung von ServiceLB.

Um ServiceLB zu deaktivieren, konfigurieren Sie alle Server im Cluster mit dem --disable=servicelb-Flag.

Dies ist notwendig, wenn Sie einen anderen LB, wie MetalLB, betreiben möchten.

Bereitstellung eines externen Cloud Controller Managers.

K3s bietet einen eingebetteten Cloud Controller Manager (CCM), der Folgendes tut:

Hostet den Service Load Balancer LoadBalancer-Controller.
Löscht die node.cloudprovider.kubernetes.io/uninitialized Taint.
Setzt die Knotenadressfelder basierend auf den --node-ip, --node-external-ip, --node-internal-dns und --node-external-dns Flags.

Bevor Sie einen externen CCM bereitstellen, müssen Sie alle K3s-Server mit dem --disable-cloud-controller Flag starten, um den integrierten CCM zu deaktivieren. Bei Verwendung eines externen CCM werden die Knotenadressen von den Metadaten-APIs der Cloud-Anbieterinstanzen bereitgestellt, anstatt von den K3s-Flagwerten.

Wenn Sie den integrierten CCM deaktivieren und keinen externen Ersatz bereitstellen und ordnungsgemäß konfigurieren, bleiben die Knoten tainted und nicht planbar.