Ich habe 3 Master- und 6 Worker-Knoten mit demselben IP-Segment eingerichtet, 172.26.10.XX.
Für Load Balancer-Dienste verwende ich Kube-Vip mit den folgenden Namespace-Spezifikationen für die Konfiguration: -
Data
====
cidr-private-app:
----
172.26.10.XX/27
range-global:
----
172.26.16.XX-172.26.16.XX
range-public-app:
----
172.26.14.XX-172.26.14.XX
BinaryData
Wenn ich versuche, einen Dienst-LB mit der IP 172.26.10.XX verfügbar zu machen, kann ich problemlos auf den In/Out-Cluster zugreifen. Aber wenn ich einen Dienst mit den LB-IPs 172.26.16.XX und 172.26.14.XX verfügbar mache, kann ich nur in den Clusterknoten darauf zugreifen und nicht außerhalb des Clusters. Stimmt etwas nicht? Ich bin für jeden Rat dankbar.
Anmerkung:
K8S: v1.27.7+k3s2 KUBE-VIP: 0.6.4 Firewall-Regeln: Erlauben/Alle Kommunikation von Server zu Server mit IP-Segment 172.26.10.XX, 172.26.16.XX und 172.26.14.XX
Starten Sie alle Knoten neu und überprüfen Sie die Konfiguration der Firewall.
Ich gehe davon aus, dass die LB IP-Adressen mit unterschiedlichen IP-Segmenten durchsuchen kann.
Antwort1
Problem
172.26.16.0 ist ein anderes Subnetz als 172.26.10.0/27. Hosts innerhalb des Clusters verfügen über Routing-Informationen für das Subnetz 172.26.16.0, da kube-vip die richtigen Routen hinzufügt. Hosts außerhalb des Clusters wissen nicht, wo dieses Subnetz zu finden ist, sofern ihnen nicht ausdrücklich Bescheid gesagt wird (etwas aktualisiert ihre Routen). Hosts, denen eine Route fehlt, verwenden die Standardroute, die im Allgemeinen ein Router im Netzwerk ist. Wenn dieser Router nicht weiß, wo 172.26.16.0 zu finden ist, verwirft er die Pakete entweder oder leitet sie weiter.es istStandardroute.
Wenn Sie eine IP innerhalb des Subnetzes verwenden, mit dem die Hosts konfiguriert sind, erkennen andere Hosts, dass sie Informationen an einen Host im selben Netzwerk senden. Sie verwenden ARP, um die MAC-Adresse des Ziels zu ermitteln und Frames an diesen Host zu senden.
Sie können diese Routing-Tabellen auf Knoten innerhalb und außerhalb des Clusters untersuchen.
ip route show table all
tldr; Sie benötigen einen Router, um zwischen Netzwerken zu wechseln. Ihre Kubernetes-Knoten fungieren als Router, deshalb funktioniert die Kommunikation innerhalb des Clusters
Lösung
Am einfachsten ist es wahrscheinlich, IPs zu verwenden, die Teil des Hostsubnetzes sind, wenn Sie möchten, dass Hosts außerhalb des Clusters die IPs erreichen können. Wenn sich Ihre Hosts beispielsweise im Subnetz 172.26.10.0/27 befinden, verwenden Sie 172.26.10.24/29 (.24 - .31) für Ihre VIPs.
Eine weitere Option: Richten Sie statische Routen auf Hosts außerhalb von Kubernetes ein, die ihnen mitteilen, dass sie das VIP-Netzwerk mithilfe der Kubernetes-Knoten als Gateway finden können. Wenn Ihre Knoten 172.26.10.1, .2, .3 sind, dann hätten Hosts außerhalb von k8s eine Route wie172.26.16.0/24 via 172.26.10.1
Eine weitere Option: Richten Sie Routen auf dem Router ein, den externe Hosts von k8s verwenden, und lassen Sie den Router den Verkehr wieder an das VIP-Netzwerk senden (Ihr Router benötigt wahrscheinlich eine IP-Adresse für jedes Subnetz, das auf derselben Schnittstelle konfiguriert ist).
Eine weitere Option: Fügen Sie jedem Host außerhalb von k8s, der sich im selben Subnetz wie die VIPs des Load Balancers befindet, sekundäre IPs hinzu.
Eine weitere Option: Richten Sie ein Routing-Protokoll wie RIP oder OSPF ein, damit Hosts außerhalb von k8s Informationen über Netzwerke innerhalb des k8s-Clusters erhalten (einige CNIs tun dies, z. B. Calico mit BGP).