Using Cilium for Kubernetes networking and observability

Table of contents

Introduction to Cilium and its use in Kubernetes

Cilium is a networking solution for Kubernetes that provides advanced networking and security features. It uses eBPF to perform high-performance networking, security and observability tasks within Kubernetes.

In this article, we’ll explore how to use Cilium for Kubernetes networking. We will cover the basics of setting up Cilium in a cluster, configuring network policies and using Hubble for observability. We’ll also discuss best practices for using Cilium in production environments and troubleshooting common issues. Let’s get started by installing Cilium to our Kubernetes cluster!

Note: We recommend using kind to try this out on your local machine. K3d (which uses k3s under the hood) does not ship bash in its node images, causing the cilium installation to fail.

Installing Cilium

First of all, we need to install the Cilium CLI as described in the documentation.

Once the CLI installation is finished, we can install Cilium to our cluster by running:

This will install Cilium to the cluster pointed to by our current kubectl context. To verify a working installation, we use:

The output should look something like this:

```

If everything looks good, we can verify proper network connectivity by running

This will create a dedicated namespace and run some tests on predefined workloads in order to test the cluster network connection.

The successful output looks like this:

If all the tests ran successfully, congratulations! We have successfully installed Cilium to our Kubernetes cluster!

Configuring network policies with Cilium

Network policies in Kubernetes are used to control and filter traffic. By default, any pod running in a cluster can communicate with any other pod, which might be insecure depending on the setup. Using network policies, we can implement rules that only allow traffic that we explicitly want to allow. Cilium allows us to set rules on the HTTP level, which decouples network rules from our application code.

Now that Cilium runs in our cluster, let’s put it to the test by applying some network policies to specify what traffic is allowed inside the cluster as well as ingressing/egressing.

The commonly used “default-deny-ingress” policy can be implemented with Cilium like this:

Since the matchLabels key is empty, this will be applied to every endpoint, effectively locking down any ingress traffic within the cluster.

We need our services to communicate with one another, therefore we add a policy that specifically allows ingress traffic between two services.

A simple “ingress-allow” policy could look something like this:

This network policy will allow all ingress traffic from endpoints with the label ```role: client``` and that connect to endpoints with the label ```role: backend-api```.

Moving up the OSI model layers, we can also lock down HTTP methods and paths like this:

This will allow incoming HTTP traffic from endpoints labeled with ```app: client``` to endpoints labeled with ```app: api```, as long as the HTTP method is GET, and the path is “/public”. Requests to ports other than 80 will be dropped, while other HTTP verbs and other paths will be rejected.

Using Cilium for observability

Cilium Hubble is a powerful observability tool that provides deep insights into the network traffic and security of a Kubernetes cluster. In this section, we will explore how to set up and use Hubble for observability.

Setting up Hubble

To use Hubble, we need to deploy it in our Kubernetes cluster as follows:

If we run “cilium status” again, we’ll see that Hubble is enabled and running.

To make use of the data that’s being collected, we install the Hubble CLI as described in the documentation. Once the installation is complete, we can verify Hubble API access by first creating a port forward for hubble and then using the Hubble CLI to inspect Hubble status and to query the API, like this:

If you like graphical user interfaces, you can also deploy Hubble UI to your cluster. Hubble UI gives you access to a graphical service map that can be used to visually inspect traffic within the cluster. For our example setup, Hubble UI looks like this:

Conclusion

In conclusion, Cilium offers a robust networking solution for Kubernetes, allowing users to enforce precise network policies and keep track of network activity in real-time. Its cloud native design and eBPF-based architecture make Cilium a top pick for users seeking advanced networking functionalities in their Kubernetes setups.

Going further

Cilium offers way more features than we can cover in this post, so here’s a short writeup of what else Cilium is capable of.

Cluster Mesh

With cluster mesh, we can extend networking paths across multiple Kubernetes clusters, allowing endpoints in connected clusters to communicate with each other while also enforcing network policies.

Service Mesh

Cilium service mesh aims to replace more traditional service mesh solutions like Linkerd. It has one key difference, though: While Linkerd relies on sidecar proxies to manage traffic between pods, Cilium service mesh uses eBPF on the node level to manage traffic, improving performance, reducing load and further decoupling the service mesh from the actual workloads.

Some of our other articles that you may like:

• Docker Desktop and Kubernetes
• Minikube vs. k3d vs. kind vs. Getdeck Beiboot
• Docker vs. Podman
• Kubernetes Logging with Promtail, Loki and Grafana
• An alternative to Telepresence 2: Gefyra