Het is al weer ruim 5 jaar geleden dat ik mijn CKA certificering haalde. In die tijd was MetalLB de GOTO oplossing om services van het type LoadBalancer een IP-adres te geven dat via BGP routeerbaar en bereikbaar gemaakt kon worden van buiten het cluster. Een ideale manier om bijvoorbeeld direct een publiek ip adres aan je ingress controller te koppelen. Tegenwoordig zit de BGP functionaliteit ook in Cilium. Het voordeel is dat je MetalLB kan doorstrepen. Een softwarepakket minder om je druk om te maken dus. In dit artikel neem ik jullie mee in een basisconfiguratie van Cilium waarin ik services van het type LoadBalancer voorzie van een IPadres dat van buiten kubernetes bereikbaar is.
Benodigdheden
- Helm
- Cilium-cli van versie 1.18.2
- standaard kubernetes cluster zonder fancy opties
- Een router met BGP of in plaats daarvan het Bird package die de BGP functionaliteit op je computer mogelijk maakt.
Situatieschets
In de onderstaande tekening is de setup te zien waarmee deze setup gebouwd is. te zien is hoe het homelab een apart segment is in het netwerk. Via statische routes worden zowel de iprange waarin de k8s nodes zitten (192.168.88.0/24) en de ip range (172.30.0.0/24) doorgestuurd naar de homelab router. De laatstgenoemde ip range wordt niet in zijn geheel doorgerouteerd vanaf de homelab router. hoe dat wel gaat, wordt later in dit verhaal duidelijk. Voor nu is het belangrijk om te weten dat services in Kubernetes met een IP in die range, bereikbaar zijn geworden. In dit geval is het een prive iprange maar in het echt zou het maar zo een publiek routeerbaar IP kunnen zijn.
BGP
Het Border Gateway Protocol ofwel BGP is vooral bekend in situaties waarbij meerdere autonome systemen (bijvoorbeeld internet service providers) aan andere autonome systemen vertellen welke ip ranges bij hen te vinden zijn. Deze ip ranges worden vervolgens in de routetabel gezet en iedereen kan vervolgens ip adressen uit die range vinden.
Elk autonoom systeem heeft zijn eigen nummer: Het ASnummer. In dit geval krijgen alle kubernetes workers het zelfde ASnummer (65001). De homelab router heeft ook zijn eigen Asnummer (65002). Omdat het verschillende Asnummers zijn, spreken we hier van “eBGP”. Cilium en de homelab router worden zo geconfigureerd dat ze elkaar BGP peer zijn. De Cilium configuratie om dit te realiseren komt verderop aan bod. De configuratie van BGP op de router zal per merk wat verschillen. Belangrijk is dat de BGP connecties zo ingesteld worden dat ze wel luisteren (listen) maar niet actief verbinden (connect). Cilium heeft standaard namelijk geen listener op BGP poort 179. Dat klinkt gek, mar het verkleint de attack surface van cilium natuurlijk wel.
Configuratie van BGP op de homelab router
Als homelab router gebruik ik in mijn setup een Mikrotik Hex refresh. Een kleine, gunstig geprijsde router die alle benodigde open standaarden zoals ook BGP ondersteunt. screenshots van de CLI geven goed weer hoe ik de router geconfigureerd heb. Uiteraard is via een grafische web interface ook veel mogelijk.
Om te beginnen is hier het bgp template waar de te maken connecties gebruik van maken:
De configuratie van de connecties ziet er zo uit:
Het belangrijk dat connect=no en listen=yes, local.address en as=65001 correct zijn ingesteld. Verderop in dit artikel moet het in overeenstemming zijn met de ciliumkant van de BGP configuratie.
Het is nog niet mogelijk om al “advertisements” of “established sessions” te zien. Verderop wordt Cilium geconfigureerd en komt BGP tot leven.
Configuratie van BGP in Cilium
Binnen Cilium moeten er best wat schakeltjes goed staan om BGP te laten werken. Onderlinge verwijzingen tussen labels en selectors moeten goed staan, de BGP gerelateerde CRD’s moeten geconfigureerd worden. Alles moet in Harmonie zijn met hoe Kubernetes (voordat Cilium geïnstalleerd is) is opgetuigd en ook veel opties in de configuratie van Cilium zelf hebben invloed op de werking. Cilium kan enorm veel. Voor dit artikel beperk ik me tot de basis van de Cilium configuratie en is Kubernetes zonder specifieke opties op de default manier op gezet. (Ik heb Kubeadm gebruikt. De default bij Talos, k3s of andere distributies kan uiteraard verschillen.)
Eerst wordt Cilium via helm geïnstalleerd. In de standaard values.yaml moet eigenlijk maar 1 ding aangepast worden om BGP functionaliteit aan te zetten en de Custom Resource Defenitions (CRD’s ) te installeren:
bgpControlPlane:
enabled: trueDe installatie van Cilium is vervolgens zo gedaan:
helm repo add https://helm.cilium.io/
helm repo update
helm upgrade --install cilium cilium/cilium --version 1.18.2 --namespace cilium-cni --create-namespace -f values.yaml
Het bovenstaande helm installatie/upgrade commando is idempotent. Dit maakt het makkelijk te automatiseren. Het is belangrijk dat ook de versie mee gegeven wordt. Dit is voor de duidelijkheid de chart versie en niet specifiek de cilium versie. In de values.yaml zal je dus ook de image tags moeten gebruiken die overeenkomen met de versie van van Cilium die je wil installeren. Vergeet je de image tags dan kom je voor verrassingen te staan en kan het gedrag afwijkend zijn. In mijn geval vergat ik het eerst en werkte BGP op alle fronten maar niet specifiek voor service type Loadbalancer (Het hele doel van dit artikel).
Na de installatie komt Cilium tot leven en zijn ook de benodigde Custom Resource Definitions aangemaakt. Controleer dat met het commando:
kubectl api-resources|grep bgpHet configureren van de CRD’s is niet zo zeer ingewikkeld maar alles moet wel goed staan. De Cilium website bevat gelukkig een heleboel goede documentatie. Als je die BGP gerelateerde documentatie van Cilium vervolgens ook nog in https://notebooklm.google.com inlaadt als “source of truth” dan heb je er een leuke debug hulp bij die zelfs kan controleren of je verschillende yaml files wel een matchend label hebben. NotebookLM lijkt daarbij wel in positieve zin de uitzondering op dit moment. Copilot en ChatGPT raken de weg volledig kwijt met yaml voorbeelden vol verkeerde apiVersions. Uiteraard moet je er niet blindelings op vertrouwen maar het was een goede hulp in mijn geval. Cilium heeft hier een heel fijn schema waarin de onderliggende relaties tussen de CRD’s perfect uitgelegd wordt.
De volledige installatie instructies, gebruikte CRD’s en values.yaml zijn te vinden op mijn GitHub pagina in het project cloudnativeblog.nl in de folder “Cilium-project-1”.
Let op: Een ip van een service met type LoadBalancer wordt pas via BGP gerouteerd als de service het juiste label heeft: bgp: jazeker. Ook wordt er gebruik gemaakt van een label dat nodes moeten hebben om de bgp peer te activeren.
Kijken of het werkt
Zorg er voor dat je een service hebt van het type LoadBalancer met het juiste label. De service krijgt dan een loadbalancer IP:
Gebruik ook de Cilium-cli om te kijken of het werkt:
Ook aan de kant van de homelab router kan het gecontroleerd worden.
conclusie
Er moet veel goed staan om het een succes te laten zijn. Als dat eenmaal goed staat draait het goed en stabiel. Als het eenmaal werkt is het een superfijne oplossing. Ik moedig jullie aan om Cilium ook een kans te geven. Het kan zijn dat het gaat duizelen van alle opties maar als je er je weg in weet te vinden wil je in de meeste scenario’s geen andere CNI meer.
0 reacties