Kubernetes schrijft niet voor hoe je netwerkconfiguratie er uit moet zien maar besteedt dit uit aan plug-ins waaruit je kan kiezen. Hierdoor is er veel keuzevrijheid. Zoals vaker in de open source wereld heeft vrijheid soms net zoveel voor- als nadelen. Ik neem ik je mee in een zoektocht door het woud van keuzes en laat zien waarom ik in een specifieke situatie bij Calico uitkom.
Onderzoek
Er zijn veel netwerkplug-ins. Het is lastig om een goede keuze te maken. Verschillende aspecten spelen mee. Er zijn veel mogelijkheden! Aan de hand van een aantal vragen die ik mezelf stelde heb ik de lijst van plug-ins verkleind.
- Is support voor “network policies” nodig?
- Welke versie van Kubernetes wil ik gebruiken?
- Hoe actief / groot is de community achter de netwerkplugin?
- Met welke appliances moet het integreren?
- wil ik de plugin met de Kubernetes client kunnen beheren?
- Mogen een paar kubernetes basiscomponenten vervangen worden door een alternatief in een plug-in?
- Is de “performance penalty”van netwerk overlay technieken acceptabel?
- gaat eenvoud boven functionaliteit of andersom?
- wil ik de standaard MTU aanpassen?
Veel vragen zorgen voor wedervragen. Voor het onderzoek is dat misschien lastig. Achteraf merk je de voordelen meteen. Je weet dan in ieder geval wel goed wat er mogelijk is op netwerkgebied. Waar de gebruiker dit infra gerelateerde vraagstuk graag links laat liggen, is het voor de beheerder erg belangrijk!
De lijst van beschikbare netwerkplug-ins wordt snel kleiner als je antwoorden hebt gevonden op bovenstaande vragen.
Performance
De performance van de plug-in is vervolgens belangrijk. Zo is er bijvoorbeeld al verschil meetbaar tussen verschillende netwerkplug-ins. Als je bijvoorbeeld gebruik maakt van Flannel met de onderliggende VXLAN technologie, zit daar al een “performance penalty” in. Als je geen VXLAN offloading ondersteuning in de netwerkkaarten van de servers hebt is dit meetbaar. Daarnaast is er ten opzichte van de traditionele wereld een toename in netwerkverkeer. Als veel microservices requests op elkaar afvuren is er onderling communicatie nodig.
Bij kleine testclusters heb je niet snel het besef dat dit later als het gebruik toeneem belangrijk wordt. Om in jouw situatie de verschillen zichtbaar te maken kan je een klein cluster optuigen met Flannel. Maak vervolgens een pod /service die bijvoorbeeld een simpele webpagina serveert en installeer de Telegraf agent.
Configureer een “inputs.http_response” check zodat Telegraf de verkregen metrics door kan sturen naar Influxdb. Via Grafana visualiseer je vervolgens de verzamelde metrics. Herhaal de test met Calico. In onze test is Calico de winnaar. Probeer het eens!
Functionaliteit
Naast performance is functionaliteit belangrijk. Hierdoor kan het zijn dat de overhead van VXLAN bijvoorbeeld een noodzakelijk kwaad is omdat het cluster moet integreren met de buitenwereld. Kijk daarnaast kritisch naar de verhouding tussen functionaliteit en eenvoud. Eenvoud is soms al complex genoeg. Calico kan bijvoorbeeld op 2 manieren geïnstalleerd worden. Als je alle functionaliteiten wil, zal Calico geen gebruik kunnen maken van de Kubernetes API als datastore maar moet er een aparte ETCD service opgezet worden. Daarnaast kan je voor bepaalde configuraties geen gebruik meer maken van kubectl. Calicoctl neemt dan deels het werk over. Dat hoeft geen probleem te zijn maar hou er in ieder geval rekening mee. Gelukkig lijkt het er op dat de support van de Kubernetes API in de toekomstige releases van Calicio steeds beter wordt ondersteund.
Qua functionaliteit is het voor mij doorslaggevend dat Calico ondersteuning biedt voor Kubernetes netwerkpolicies en het routeren van service/pod IP’s via BGP.
Beveiliging
Niet alle plug-ins bieden je de mogelijkheid om “Kubernetes network policies” via de Kubernetes API te beheren. Dit is een mooie toevoeging aan een plug-in en je hoeft hem niet perse te gebruiken. Mocht je het in het begin niet nodig vinden en later wel, dan zit je met Calico in ieder geval goed. Qua encryptie van het container netwerk heb ik nog niet de juiste use case gevonden om dat te willen. In die gevallen kan je beter de individuele services versleutelen maar dat staat uiteraard los van de netwerkplug-in.
Tot slot
Om tot een voor jouw situatie geschikte netwerkplug-in te komen moet je onderzoek doen. Zijn de servers virtueel of fysiek? is het “underlay” netwerk toevallig ook al stiekem “overlay”? Wat voor applicatie/protocol is er actief in het cluster? Het beïnvloedt allemaal je netwerkperformance. Neem het niet voor lief maak er een serieus onderzoek van. De totale mix van functionaliteit en performance levert in mijn specifieke situatie Calico op als beste plug-in maar of dat ook voor jou geldt is nog maar de vraag.
Auteur: Geurt Hakfoort – Cloud Specialist Denit
