Wer beginnt, sich mit Kubernetes zu beschäftigen, stößt schnell auf die Frage nach dem richtigen Overlay-Netz. War bei Docker Network Address Translation (NAT) das Standard-Netzinterface die Regel, so gilt nun bei Kubernetes die Prämisse: Jeder Pod muss jeden anderen Pod desselben Services über IP ohne NAT erreichen können. Eine Lösung ist natürlich, jedem Pod eine Adresse aus dem Subnetz zuzuweisen, zu dem auch der Node gehört, auf dem er ausgeführt wird. Das ist jedoch oft nicht gewollt. So stellt sich die Frage nach dem passenden Overlay-Netz.
Anders als bei anderen virtualisierten Umgebungen gibt es weder einen Zwang, ein bestimmtes Overlay zu nutzen, noch einen Platzhirsch. Vielmehr ist die Netzschnittstelle so offengehalten, dass viele Lösungen existieren. Allein auf der Webseite von Kubernetes stehen aktuell 28 verschiedene Varianten: angefangen bei A wie ACI von Cisco bis W wie Weave Net von Weaveworks. Diese sind unterschiedlich komplex zu betreiben und bieten voneinander abweichende Funktionen: einige sind einfache IP-over-IP-Tunnel, andere bilden ein mandantenfähiges, regelbasiertes Overlay, in dem sämtliche Kommunikation verschlüsselt wird. Ein weiterer Faktor bei der Auswahl des richtigen Overlays ist die Frage, ob, und wenn ja, welche Cloud mit angebunden werden soll. Diese nutzen oft Open Source Overlays, die sie jedoch an ihre Bedürfnisse angepasst haben.
Bevor man bei der Einführung von Kubernetes von der Test- in die Produktionsphase überwechselt, sollte man sich genau überlegen, welches Overlay man wählt und dabei zwischen Funktion und Komplexität abwägen.
