Why Cilium Is the Coolest Kubernetes CNI Plugin and How to Deploy It

Cilium Introduction

Calico, the most widely used K8s CNI, recently announced eBPF support, while Cilium was the first to implement all kube‑proxy functions with eBPF. Could Cilium become the new leading CNI? This article walks through the coolest Kubernetes networking solution, Cilium.

Based on the official Cilium documentation.

Current Trend

Modern data‑center applications are shifting to micro‑service architectures, where many small independent services communicate via lightweight protocols such as HTTP, gRPC, or Kafka. The dynamic nature of micro‑services combined with containerized deployment leads to frequent large‑scale container start‑ups and restarts, posing both challenges and opportunities for secure, reachable networking.

Existing Problems

Traditional Linux network security mechanisms like iptables rely on static IP and port configurations. In micro‑service environments, IPs constantly change and ports are no longer fixed, making it difficult to maintain thousands of load‑balancing and access‑control rules. This results in performance bottlenecks for kube‑proxy, and troubleshooting or security auditing becomes extremely hard.

Solution

Cilium is a Kubernetes CNI plugin designed for large‑scale, highly dynamic container environments. It uses eBPF to identify services, pods, and containers by their identities instead of IP addresses, enabling API‑level network security policies. Cilium decouples security control from addressing, providing layer‑3/4 isolation as well as HTTP‑level controls, while also offering traditional L3/L4 isolation.

Because eBPF can be dynamically inserted into the Linux kernel, Cilium provides powerful security visualization without requiring application code changes or service restarts.

These features give Cilium high scalability, observability, and security in massive container deployments.

Deploy Cilium

Deploying Cilium is straightforward: you can apply a single YAML file that installs all components (the author used version 1.7.1) or use a Helm chart for one‑click deployment. Key points are the deployment environment and timing:

Official recommendation: all nodes should run the latest stable Linux kernel to enable all features.

Cilium should be installed after the core Kubernetes components. The author experienced a pending coredns status until Cilium was deployed, after which coredns became running.

The diagram below shows the overall Cilium deployment architecture.

Test Installation Effect

The official connectivity‑check tool verifies that a deployed Cilium works correctly. The author made minor adjustments for restricted networks; at least two nodes are required for the deployments to succeed.

kubectl apply -f connectivity-check.yaml

NAME                                 READY   UP-TO-DATE   AVAILABLE   AGE
echo-a                               1/1     1            1           16d
echo-b                               1/1     1            1           16d
host-to-b-multi-node-clusterip        1/1     1            1           16d
host-to-b-multi-node-headless         1/1     1            1           16d
pod-a                                 1/1     1            1           16d
pod-a-allowed-cnp                     1/1     1            1           16d
pod-a-external-1111                   1/1     1            1           16d
pod-a-l3-denied-cnp                   1/1     1            1           16d
pod-to-b-intra-node                   1/1     1            1           16d
pod-to-b-multi-node-clusterip          1/1     1            1           16d
pod-to-b-multi-node-headless           1/1     1            1           16d
pod-to-external-fqdn-allow-google-cnp  1/1     1            1           16d

If all deployments run successfully, Cilium is correctly installed and operational.

Network Visualization Tool Hubble

Cilium’s Hubble component provides simple, efficient network visualization by leveraging eBPF data paths. Hubble exposes deep visibility of Kubernetes traffic, integrates with a CLI, UI, and can be connected to Prometheus and Grafana for extended monitoring.

Deploy Hubble and Hubble UI

The official Helm chart allows flexible variable control. The author deployed Hubble UI and connected it to Grafana as follows:

helm template hubble \
    --namespace kube-system \
    --set metrics.enabled="{dns:query;ignoreAAAA;destinationContext=pod-short,drop:sourceContext=pod;destinationContext=pod,tcp,flow,port-distribution,icmp,http}" \
    --set ui.enabled=true \
    > hubble.yaml
kubectl apply -f hubble.yaml
# Includes two components: daemonset hubble and deployment hubble UI
kubectl get pod -n kube-system | grep hubble
hubble-67ldp               1/1   Running   0   21h
hubble-f287p               1/1   Running   0   21h
hubble-fxzms               1/1   Running   0   21h
hubble-tlq64               1/1   Running   1   21h
hubble-ui-5f9fc85849-hkzkr 1/1   Running   0   15h
hubble-vpxcb               1/1   Running   0   21h

Running Effect

The default Hubble UI service is a ClusterIP, which cannot be accessed externally. Create a NodePort service to expose it:

# hubble-ui-nodeport-svc.yaml
kind: Service
apiVersion: v1
metadata:
  namespace: kube-system
  name: hubble-ui-np
spec:
  selector:
    k8s-app: hubble-ui
  ports:
    - name: http
      port: 12000
      nodePort: 32321
  type: NodePort

Run kubectl apply -f hubble-ui-nodeport-svc.yaml and access the UI via any node IP and port 32321.

The top part shows the Service Map generated by the connectivity‑check component, automatically discovering L3/L4 dependencies. Clicking a service reveals a detailed relationship graph.

The lower half displays a data‑flow diagram for the kube-system namespace, showing gRPC communication between Hubble and Hubble‑UI. Core Kubernetes components are not shown, which raises curiosity.

The bottom section lists detailed flow information such as source pod, destination service, IP, port, L7 protocol, status, and last seen time.

Clicking a flow shows even more details.

The lower half can switch to network‑policy mode, listing all policies in the current namespace.

Enabling 7‑layer visualization requires adding annotations to target pods (details omitted).

Such network visualization is a dream tool for troubleshooting request‑call issues.

Integrate Grafana + Prometheus

For Grafana + Prometheus fans, enable Hubble metrics with the following Helm setting:

--set metrics.enabled="{dns:query;ignoreAAAA;destinationContext=pod-short,drop:sourceContext=pod;destinationContext=pod,tcp,flow,port-distribution,icmp,http}"

You can connect to existing Grafana/Prometheus or deploy a simple stack:

# Deploy Grafana and Prometheus in namespace cilium-monitoring
kubectl apply -f https://raw.githubusercontent.com/cilium/cilium/v1.6/examples/kubernetes/addons/prometheus/monitoring-example.yaml
# Expose them via NodePort for external access
kubectl expose deployment/grafana --type=NodePort --port=3000 --name=gnp -n cilium-monitoring
kubectl expose deployment/prometheus --type=NodePort --port=9090 --name=pnp -n cilium-monitoring

After deployment, import the official dashboard into Grafana; after a short wait, metrics appear.

Cilium combined with Hubble is indeed very useful!

Replace kube‑proxy Component

Cilium claims to fully implement kube‑proxy functionality, including ClusterIP, NodePort, ExternalIPs, and LoadBalancer, offering better performance, reliability, and debuggability thanks to eBPF.

If Cilium is installed after kube‑proxy, they coexist; Cilium decides based on kernel version whether kube‑proxy is still needed. Verify replacement status with:

# Check Cilium's kube‑proxy replacement status
kubectl exec -it -n kube-system [cilium-agent-pod] -- cilium status | grep KubeProxyReplacement
# Default is Probe state
# When Cilium agent starts, it probes kernel version and BPF feature availability.
# If not satisfied, it falls back to kube‑proxy for remaining Kubernetes features.
KubeProxyReplacement:   Probe   [NodePort (SNAT, 30000-32767), ExternalIPs, HostReachableServices (TCP, UDP)]
# List services managed by Cilium
kubectl exec -it -n kube-system [cilium-agent-pod] -- cilium service list
# Example output omitted for brevity
# Check if iptables still contain kube‑proxy rules
iptables-save | grep KUBE-SVC
# No output means kube‑proxy can be stopped.

Summary

Cilium is currently the coolest Kubernetes CNI plugin, offering advanced network policies, layer‑7 traffic control, and a simple, efficient, and user‑friendly network management experience built on BPF/eBPF. Give it a try!

Article reposted from DevOps技术栈 (copyright belongs to the original author).