kube-proxy ist die Kubernetes-Komponente, die ich auf jeder Worker Node meines Clusters betreibe und die für mich das Routing zu Kubernetes-Services technisch umsetzt. Der Prozess sorgt dafür, dass meine Pods über stabile virtuelle Service-IPs erreichbar sind, auch wenn sich Pod-Adressen ständig ändern.
Für mich bildet kube-proxy damit die Grundlage meines Cluster-Netzwerks, zusammen mit meinem CNI-Plugin und kubelet.
Wo ich kube-proxy betreibe
kube-proxy läuft für mich ausschließlich auf Node-Ebene. In selbst installierten Clustern installiere ich ihn als Teil meiner Worker-Maschinen, meist automatisch über DaemonSets oder Systemcontainer. In Cloud-Clustern wie AKS oder EKS wird kube-proxy ebenfalls auf meinen Worker Nodes betrieben, dort aber für mich vom Provider verwaltet.
- Ich benötige kube-proxy auf jedem Node
- Er spricht für mich nur mit dem kube-apiserver
- Er schreibt selbst nichts in etcd, sondern setzt API-Objekte lokal um
Was kube-proxy für mich macht
Ich nutze in Kubernetes virtuelle Service-IPs. Wenn ich einen Service anlege, weist Kubernetes diesem eine ClusterIP zu. Für mich erzeugt kube-proxy danach lokale Netzwerkregeln, damit Anfragen an diese IP automatisch zu meinen passenden Pods weitergeleitet werden.
Teilaufgaben
- Umsetzung meiner Services in Routing-Regeln
- Lastverteilung zu meinen Pod-IPs
- Berücksichtigung meiner Endpoints
- Unterstützung mehrerer Modi
Wie kube-proxy funktioniert
Der Prozess arbeitet für mich eventbasiert:
- Ich lege einen Service in der API an
- Endpoints-Controller pflegt meine Pod-IPs
- kube-proxy beobachtet diese Änderungen über Watch
- Erzeugt für mich lokale Regeln
Netzwerk-Modi, die ich verwende
Für mich unterstützt kube-proxy vor allem zwei technische Implementierungen:
- iptables-Modus: kube-proxy erstellt für mich iptables-Regeln für Service-IP → Pod-IP-Weiterleitung.
- IPVS-Modus: Ich nutze IPVS, wenn ich für mich performantes und skalierbares Service-Routing benötige.
Ich kann den aktiven Modus für mich in meiner Node-Konfiguration festlegen.
Beispiele meiner Nutzung mit Services
Beispiel 1 – Ich erstelle ClusterIP
apiVersion: v1
kind: Service
spec:
selector: app=web
Für mich erzeugt kube-proxy danach Regeln, damit meine Anfragen an den Service zu allen Pods mit Label app=web verteilt werden.
Beispiel 2 – Ich lösche einen Pod
Wenn ich kubectl delete pod ausführe, ändert Endpoints-Controller die Liste meiner IPs, kube-proxy aktualisiert für mich sofort die lokalen Routing-Regeln – mein Service bleibt erreichbar.
Was kube-proxy nicht macht
- Ich plane Nodes mit kube-scheduler
- Monitoring meiner Container erledigt kubelet
- Ingress-Routing ist für mich ein Add-on
- kube-proxy ist nur mein Service-Routing
Fazit
kube-proxy ist für mich die Netzwerk-Komponente, die ich auf jeder Kubernetes-Worker-Node betreibe und die meine virtuellen Services in echte lokale Routing-Regeln umsetzt. Der Prozess funktioniert rein über Watch-Events des kube-apiserver und hält das Routing zu meinen Pods auch bei Änderungen und Skalierungen stabil.