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!
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 subsequently used to set up the cluster.
The Cilium Helm chart version v1.1