Cilium BGP Lab with LoadBalancing and more!

 

At this point, we know how to install Cilium and create a BGP peering with our routers. Now we need to let the outside world reach our Kubernetes apps.

If you don’t have the KinD cluster with Cilium go to https://arielantigua.com/weblog/2024/07/cilium-bgp-lab-locally/

When using Cilium you can reach an application using the Pod IP address or using a LoadBalance IP assigned to a Service. In the previous article we only advertised the Pod Address to our BGP neighbors, lets add more stuff so we can be close to a real deployment.

If you already have cloned the repo, go and do a pull so you can get the new config files and other stuff in the Makefile, or better yet, go and do a new clone of the repo and start from scratch, that’s the idea of the repo!

New stuff in this LAB.

      • serviceSubnet in cluster.yaml (10.2.0.0/16)
      • serviceSelector in the CiliumBGPPeeringPolicy (service = public), this useful to identify what LoadBalancer will be announced by this peering policy.
      • public-pool.yaml with the configuration for the LoadBalancer IP Pool.
      • If you look at the topo.yaml file, will find a new Linux node (client0) for testing, this is based on alpine:latest, will test reachability to our LoadBalancer IP from this container that is connected to tor1 with IP address 10.0.100.2/24
      • Bookinfo application so we can have something to reach from client0.

Now let’s build the environment, just like before, running make will create a KinD cluster with 4 nodes (1 control-plane and 3 workers), a containerlab topology with 3 routers (FRR), and 1 client (Alpine). decide to let alone the Cilium install manually or with make cilium, in case there is a need to do something different with the same KinD cluster or add another option to Cilium at install time.

A black screen with white text Description automatically generated

This is the result of running make, as you can see in the image, now you can go and install Cilium in whatever way you like the most, in this case, I will use these options:

cilium install --version=1.15 \
--helm-set ipam.mode=kubernetes \
--helm-set tunnel-protocol=vxlan \
--helm-set ipv4NativeRoutingCIDR="10.0.0.0/8" \
--helm-set bgpControlPlane.enabled=true \
--helm-set k8s.requireIPv4PodCIDR=true

The fastest way is to do this: make cilium

A screen shot of a computer Description automatically generated

A screen shot of a computer screen Description automatically generated

The nodes are ready for workloads.

Now is the time to apply both, the CiliumBGPPeeringPolicy and the CiliumLoadBalancerIPPool.

You can do it with make or the official way with kubectl.

kubectl apply -f cilium-bgp-peering-policies.yaml 

kubectl apply -f public-pool.yaml

A screen shot of a computer screen Description automatically generated

You can validate the configurations with the following commands.

kubectl get -f cilium-bgp-peering-policies.yaml -oyaml

kubectl get -f public-pool.yaml -oyaml

Our lab environment is ready to assign IP to LoadBalancer services, lest check the existing ones first.

Is time to deploy our test application.

Now there is an app in the repo, you can deploy the bookinfo application, which is used by Istio to do some demos, I just cloned it and added a Service to pick up an Address from our IP Pool and advertised it to the Tor(0,1) routers.

https://github.com/aredan/ciliumlabs/tree/main/bookinfo/kustomize

kubectl apply -k kustomize

A screenshot of a computer program Description automatically generated

Let’s check the Services that we have now.

A screen shot of a computer Description automatically generated

There is our LoadBalancer IP address (10.0.10.1) and others ClusterIP, the LoadBalancer is the one that we will be testing from client0.

A screenshot of a computer program Description automatically generated

We can see there is an IP assigned to the Service, but is better if we can validate that this address is being announced to the Tor routers.

docker exec -it clab-bgp-cplane-router0 vtysh -c 'show bgp ipv4'

A computer screen shot of a computer Description automatically generated

Also, from Cilium itself we can validate that his address is being announced from the virtualRouters.

Within the Cilium CLI exists a subcommand called bgp (hard to pass!!) and with this, we can validate a few things.

A screenshot of a computer Description automatically generated

A screen shot of a computer Description automatically generated

cilium bgp routes advertised ipv4 unicast

A black screen with white text Description automatically generated

Our four nodes are announcing the same address to upstream routers, this is because of the trafficPolicy assigned to the service.

Is time to reach our App.

We need to get into client0 container, this is an alpine container so ash is the shell.

Installing curl and Lynx. In case you don’t know what Lynx is, is a console browser, this feels like traveling to the past when the one that stayed more in the console was the strongest.

A black screen with white text Description automatically generated

A screenshot of a computer program Description automatically generated

A computer screen shot of a black screen Description automatically generated

We can see that curl is reaching the app, this way is hard to interact we the application, now with Lynx!

lynx http://10.0.10.1

A screenshot of a computer Description automatically generated

 

Isovalent (Cilium creators) announced new support for ClusterIP in BGP !!

Cilium BGP Lab, locally!

Maybe you already know about Cilium, You don’t?
Go read https://docs.cilium.io/en/stable/overview/intro/ and come back !!

Hello again!
So now you want to learn about Cilium BGP functionality, for me this is one of the most exciting features of Cilium, maybe the reason is the addiction that I already have for BGP, who knows (AS207036). Back to the point, with Cilium you can establish a BGP session with your routers (Tor, border, or core, you decide.) and announce PodCIDR or LoadBalance for services.

For this learning exercise, we will use Kind and other tools to run a K8s cluster locally on any Linux (Windows or MacOS) machine. There is a lot of info on the internet on how to get Kind up and running and even how to install Cilium, I decided to build a collection of Cilium Labs (ciliumlabs) to speed up the process of getting a Cilium testing environment up and running.

First, go and clone the repo, all the information is on the README of each lab type, in this case, bgp/README.md is the one with the steps to get this ready, but we first need to install the prereqs. The prerequisites are listed in the main README file. In my environment, all this is met so I can proceed with the lab creation.

Continuar leyendo «Cilium BGP Lab, locally!»

Platform9 KubeVirt solution.

 

This is my opinion about this platform.

A few weeks ago, Platform9 announced a Hands-on-Lab for their KubeVirt implementation, and after using Harvester for running VMs mainly for deploying Rancher RKE clusters, I got my hands on this platform and the differences are huge.

First, Platform9 keeps its offering very close to the upstream project, what does this mean, it looks like you installed KubeVirt manually in your K8s cluster, this is good. The good thing about it is that you are more familiar with the solution and when the time to move to another KubeVirt offering comes, the changes will be minimal.

Continuar leyendo «Platform9 KubeVirt solution.»

Creating Linux VM with Harvester HCI.

In a previous article, we saw how to integrate Harvester in Rancher UI, and from there we were able to request a new K8s cluster with just a few clicks. Now is Virtual Machine time. How fast can we deploy a Linux VM.

Look at https://arielantigua.com/weblog/2023/12/harvester-hci-en-el-homelab/

For installing Harvester.

Linux VM.

This is easier than expected. You just need an img or qcow2 file imported into Harvester. Navigate to Images and click Create.

Continuar leyendo «Creating Linux VM with Harvester HCI.»

Ceph on Proxmox as Storage Provider.

For a few months, I’ve been reading about Ceph and how it works, I love distributed stuff, maybe the reason is that I can have multiple machines and the idea of clustering has always fascinated me. In Ceph, the more the better!

If you have multiple machines with lots of SSD/NVME the Ceph performance will be a lot different than having a 3-node cluster with only one OSD per node. This is my case, and the solution has been working well.

Installing Ceph on Proxmox is just a few clicks away, is already documented in https://pve.proxmox.com/wiki/Deploy_Hyper-Converged_Ceph_Cluster

At first, I have two nodes and the state of Ceph was faulty.

A screenshot of a computer Description automatically generated

The crush_map created by Proxmox is a 3-host configuration, that adds at least one OSD to the cluster, in this picture, there were only 2 hosts with 1 OSD each.

Continuar leyendo «Ceph on Proxmox as Storage Provider.»