Work in Progress
In einer verteilten Architektur, wie sie Kubernetes vorliegt, treten ab einer gewissen Größe auch Fragen zum IP-Routing in Erscheinung. Bei großen Kubernetes Installationen wird man kaum auf Nodes treffen, die alle im gleichen IP-Netz sind. Mit statischen Routen kommt man nicht sehr weit. Bei sehr großen, geographisch verteilten Installationen sind auch Überlegungen zu Anycast Netzen sinnvoll. Einige Routing Lösungen von Kubernetes bieten dazu das Protokoll BGP4 an, so kann man z.B. mit Calico Peers zu Routern erstellen, so dass die Router erfahren, welche Netze in Kubernetes genutzt werden.
Die vorhandene Netzwerktopologie spielt bereits eine Rolle bei der Auswahl des Kubernetes Netzwerkproviders. Während Weave ein eigenes Protokoll für das Overlay Netzwerk verwendet (6783/tcp und 6783-6784/udp), nutzt Calico dafür VxLAN oder IP-IP. Calico kann auch im Non-Overlay Mode betrieben werden, so dass eine vorhandene Netzinfrastruktur mitbenutzt wird. In dieser Betriebsart ist es sinnvoll, auf den Layer-3 Switches eine VRF Instanz zu konfigurieren und dort einen eigenen Routing Prozess (BGP4) laufen zu lassen. Der Zugang von und nach Kubernetes Pods und Nodes sollte auch hier nur über eine Firewall erfolgen. Außer Weave und Calico gibt es noch jede Menge anderer Network Provider, auf der Kubernetes Seite gibt es Liste der relevanten Lösungen.
Wie groß sollte das Pod Netzwerk gewählt werden? Am besten so groß wie möglich! Sinnvoll ist eine IPv6 only Lösung, so spart man sich die Schmerzen mit Dual-Stack in Kubernetes und man hat ein riesiges Netz zur Verfügung. Die Firewall bzw. ein Load-Balancer (z.B. haproxy) stellt via Dual-Stack die Verbindung zwischen alter Welt und dem Ingress her.
ToDo: Beispiel Config für IPv6 Setup
BGP4 ist ein Routing Protokoll, auf dem praktisch das ganze Internet basiert und praktisch alle Internetprovider ihre Routing Informationen austauschen. In den Beispielen für Calico und MetalLB sowie OPNsense wird ebenfalls BGP4 verwendet. Es gibt praktisch keinen ernstzunehmenden Router, Firewall oder Layer-3 Switch, der nicht BGP4 unterstützt. Im Linux und BSD Umfeld hat sich der FRR Routing Daemon weitgehend durchgesetzt. Neben den beteiligten IP-Netzen muss auch ein Autonomous System festgelegt werden, für private Anbindungen (also nicht Internet) sind die Nummern 64512-65534 eine gute Wahl. Sofern alle beteiligten Komponenten 4Byte AS unterstützen, dann können als private AS Bereiche auch 4200000000 - 4294967294 genutzt werden.
Aus Sicherheitsgründen sollte zur Absicherung der BGP4 Peerings auch ein BGP Passwort gesetzt werden.
Mit dieser FRR Konfiguration wurde eine Kubernetes Installation mit einem Linux Testserver verbunden:
$ sudo vtysh [sudo] Passwort für demo: Hello, this is FRRouting (version 7.4). Copyright 1996-2005 Kunihiro Ishiguro, et al. emc2# sh run Building configuration... Current configuration: ! frr version 7.4 frr defaults traditional hostname emc2 service password-encryption no ipv6 forwarding service password-encryption service password-encryption ! password 8 *** ! router bgp 64500 no bgp ebgp-requires-policy neighbor 192.168.48.2 remote-as 64512
neighbor 192.168.48.2 password *** neighbor 192.168.48.2 update-source br1 ! address-family ipv4 unicast network 192.168.48.0/24 neighbor 192.168.48.2 next-hop-self neighbor 192.168.48.2 soft-reconfiguration inbound exit-address-family ! line vty ! end
In diesem Beispiel wurde ein Passwort für Peer 192.168.48.2 gesetzt, was in Produktivumgebungen zu empfehlen ist.