Expose LoadBalanced Kubernetes Services with BGP (Cilium)

Expose LoadBalanced Kubernetes Services with BGP (Cilium)

Deze blog laat zien hoe jouw Kubernetes-service met behulp van Cilium en BGP aan de buitenwereld kan worden blootgesteld.

Cilium

Cilium is een open source-project om netwerken, beveiliging en observeerbaarheid te bieden voor cloud-native omgevingen zoals Kubernetes-clusters en andere containerorkestratieplatforms.

Hulp nodig met Cilium of Kubernetes?

Zorg ervoor dat jij onze whitepaper ontvangt of vraag een van de experts gewoon alles wat te maken heeft met Cilium, netwerken, Kubernetes, clustors of setups. We staan meer dan klaar om je te helpen!

Gratis white paper
Vraag onze experts

Bekijk zeker onze laatste evenementen over Cilium TIP
Sluit je aan bij SUE HQ of meld je aan voor onze livestreams. Leer alles wat er te weten valt en inzichten over Cilium en zijn mogelijkheden. Leer meer >

BGP

Border Gateway Protocol (BGP) is een gestandaardiseerd extern gateway-protocol dat is ontworpen om routerings- en bereikbaarheidsinformatie uit te wisselen tussen autonome systemen (AS) op internet. BGP is geclassificeerd als een pad-vectorrouteringsprotocol. Het neemt routeringsbeslissingen op basis van paden, netwerkbeleid of regelsets die zijn geconfigureerd door een netwerkbeheerder.

Cilium and BGP

In release 1.10 integreerde Cilium BGP-ondersteuning met MetalLB, waardoor het Kubernetes Service-ip-adressen van het type LoadBalancer kan aankondigen met behulp van BGP. Het resultaat is dat services van buiten het Kubernetes-netwerk bereikbaar zijn zonder extra componenten, zoals een Ingress Router. Vooral het ‘zonder extra componenten’ gedeelte is fantastisch nieuws, aangezien elk onderdeel latency toevoegt – dus zonder die minder latency.

Lab environment

Laat ons eerst uitleggen hoe het lab is opgezet en wat het eindresultaat zal zijn.

Het lab bestaat uit een clientnetwerk (192.168.10.0/24) en een Kubernetes-netwerk (192.168.1.1/24). Wanneer een Service een LoadBalancer ip-adres krijgt, wordt dat adres bediend vanuit de pool 172.16.10.0/24. In ons lab zijn de volgende knooppunten aanwezig:

Name IP addresses Description
bgp-router1 192.168.1.1/24 (k8s network), 192.168.10.1/24 (client network) The BGP router
k8s-control 192.168.1.5/24 (k8s network), 192.168.10.233/24 (client network) Management node
k8s-master1 192.168.1.10/24 (k8s network) k8s master
k8s-worker1 192.168.1.21/24 (k8s network) k8s worker
k8s-worker2 192.168.1.22/24 (k8s network) k8s worker
k8s-worker3 192.168.1.23/24 (k8s network) k8s worker
k8s-worker4 192.168.1.24/24 (k8s network) k8s worker
k8s-worker5 192.168.1.25/24 (k8s network) k8s worker

Nadat alle onderdelen zijn geconfigureerd, is het mogelijk om vanuit het clientnetwerk een Service in het Kubernetes-netwerk te bereiken met behulp van het aangekondigde LoadBalancer IP-adres. Zie afbeelding hieronder.

Lab configuration

BGP router

De router is een Red Hat 8-systeem met drie netwerkinterfaces (extern-, kubernetes- en clientnetwerk) met FRRouting (FRR) verantwoordelijk voor de afhandeling van het BGP-verkeer. FRR is een gratis en open source internetrouteringsprotocolsuite voor Linux- en Unix-platforms. Het implementeert veel routeringsprotocollen zoals BGP, OSPF en RIP. In ons lab is alleen BGP ingeschakeld.

dnf install frr
systemctl enable frr
firewall-cmd --permanent --add-port=179/tcp
echo 'net.ipv4.ip_forward=1' > /etc/sysctl.d/01-sysctl.conf
sysctl -w net.ipv4.ip_forward=1

Na het instaleren FRR, the BGP daemon is configured to start by changing bgpd=no to bgpd=yes in the configuration file /etc/frr/daemons, using the following BGP configuration in /etc/frr/bgpd.conf

log syslog notifications
frr defaults traditional
!
router bgp 64512
no bgp ebgp-requires-policy
bgp router-id 192.168.1.1
neighbor 192.168.1.10 remote-as 64512
neighbor 192.168.1.10 update-source enp7s0
neighbor 192.168.1.21 remote-as 64512
neighbor 192.168.1.21 update-source enp7s0
neighbor 192.168.1.22 remote-as 64512
neighbor 192.168.1.22 update-source enp7s0
neighbor 192.168.1.23 remote-as 64512
neighbor 192.168.1.23 update-source enp7s0
neighbor 192.168.1.24 remote-as 64512
neighbor 192.168.1.24 update-source enp7s0
neighbor 192.168.1.25 remote-as 64512
neighbor 192.168.1.25 update-source enp7s0
address-family ipv4 unicast
neighbor 192.168.1.10 next-hop-self
neighbor 192.168.1.21 next-hop-self
neighbor 192.168.1.22 next-hop-self
neighbor 192.168.1.23 next-hop-self
neighbor 192.168.1.24 next-hop-self
neighbor 192.168.1.25 next-hop-self
exit-address-family
!
address-family ipv6 unicast
exit-address-family
!
line vty

In the config file above the AS number 64512 is used, which is reserved for private use. The Kubernetes master node and worker nodes are configured as neighbor. The ip address of the router’s interface in the Kubernetes network (192.168.1.1) is used as router id.
After the configuration above is applied and the FRR daemon is started using the systemctl start frr command, the command vtysh -c ‘show bgp summary’ shows the following output.

IPv4 Unicast Summary:
BGP router identifier 192.168.1.1, local AS number 64512 vrf-id 0
BGP table version 0
RIB entries 0, using 0 bytes of memory
Peers 6, using 86 KiB of memory

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt
192.168.1.10 4 64512 0 0 0 0 0 never Active 0
192.168.1.21 4 64512 0 0 0 0 0 never Active 0
192.168.1.22 4 64512 0 0 0 0 0 never Active 0
192.168.1.23 4 64512 0 0 0 0 0 never Active 0
192.168.1.24 4 64512 0 0 0 0 0 never Active 0
192.168.1.25 4 64512 0 0 0 0 0 never Active 0

Total number of neighbors 6

Kubernetes and Cilium

It goes beyond the scope of this blog to explain how to install the Kubernetes nodes and the Kubernetes cluster. For your information: in this lab Red Hat 8 (minimal installation) is used as the operating system for all the nodes and Kubeadm was subsequ