Success breeds complacency. This state of satisfaction and inertia often comes after triumphs; especially in sports. It affects championship-winning teams and individuals. After a victorious season, Phil Jackson, the legendary NBA coach of the Chicago Bulls and Los Angeles Lakers basketball teams, would often notice a drop off in performance, focus and discipline in his teams.
Apathy doesn’t only affect successful sports teams or even artists – it is rampant in the world of technology. The Antitrust Law Journal’s United States vs IBM: A Monument To Arrogance article chronicles an extreme example of when monopoly and dominance leads to hubris.
Given the incredible momentum behind Cilium, the swift adoption of Tetragon and the success of Isovalent, it’s reasonable to wonder: will these eBPF-based projects now become stagnant?
Absolutely not.
In this post, I am going to look ahead to upcoming innovations and trends that explain why the eBPF revolution is just getting started.
eBPF Climbing Up The Stack
Cilium has historically been using the Envoy proxy for Layer 7 use cases, such as observability and security. A popular high performance and low overhead proxy, Envoy has been used by many service mesh implementations. Within Cilium, eBPF tends to be used for Layer 3/4 use cases and Envoy for Layer 7 use cases. However using Envoy comes with a trade-off – traffic has to be redirected to the proxy for processing, adding a marginal latency.
But eBPF is climbing up the stack. With Isovalent Enterprise for Tetragon, you can use eBPF to observe traffic at the application layer without the need for Envoy or Cilium, for that matter.
Being able to observe traffic down to the application layer without having to compromise on latency greatly reduces the latency overhead as the graph below highlights:
Expect to see more content around this use case in the coming weeks and months.
Network Performance Parity Between Containers and Hosts
For all the benefits that virtualization and containerization bring, there are compromises that come with adding multiple layers of abstractions. Observability, troubleshooting and performance are examples of concessions engineers have to make in virtualized environments. Networking performance in particular suffers from having to connect virtual machines and containers to the outside world.
Traditionally, containers have leveraged virtual network devices (often referred to as veth, as in “virtual Ethernet”) to communicate with the host. Communicating with a peer outside of the host requires going through the internal Linux networking stack multiple times (through the guest and through the host), causing a noticeable overhead.
netkit, a new device introduced in the Linux Kernel 6.7, eliminates most of the overhead by leveraging BPF programs on the virtual device. For example, if the BPF program determines that the traffic must be sent out of the node, the netkit can bypass the node directly instead of sending the traffic up the networking stack.
Performance tests showed throughput parity between container and host.
This model is already in production testing at Meta & Bytedance, with some spectacular results (double digits performance gains over veth).
Expect netkit to become available with the Cilium 1.16 release, later on this summer.
Multicast Networking for Low Latency and High Volume Trading Applications
Financial institutions engage in high-frequency trading (HFT) where split-second decisions can make or break profitability. Low latency ensures that traders can capitalize on fleeting market opportunities before competitors. In traditional data center networks, multicast networking was used to optimize packet delivery. Unlike alternative packet delivery mechanisms like unicast (one packet was sent per recipient) and broadcast (packets are sent to every recipient in the network), multicast consists in sending a single packet to the network and relying on the network to copy and deliver that traffic only to nodes who subscribed for this traffic.
This publisher/subscriber model is highly efficient and relevant for brokers, trading firms and financial information who need to distribute and receive market data efficiently.
But while multicast seems like an excellent packet distribution mechanism, it has not seen much adoption by Kubernetes users; with only the legacy and discontinued weavenet CNI offering multicast support. The other challenge – that most network engineers will be familiar with – is operating multicast networks as visualizing multicast traffic can be challenging.
The upcoming Isovalent Enterprise for Cilium release will introduce support for multicast, enabling organizations to optimize traffic delivery for applications based on a publisher/subscriber model.
Simply configure a CRD such as the following and multicast traffic sent to the groups below will be sent to the subscribers:
Combine it with Isovalent Enterprise for Tetragon to monitor multicast traffic. Tetragon will provide Prometheus metrics for UDP and Multicast streams, which you can visualize in Grafana dashboards.
Context-Driven Runtime Security
While I mentioned this briefly in my networking predictions, this time I will elaborate further.
Today, Kubernetes Network Policies and the more advanced and granular Cilium Network Policies enable users to enforce micro-segmentation in their cluster and to enforce traffic policies based on IP addresses, or even better, the identity of a Pod.
This remains one of the most popular reasons why users adopt Cilium – securing your clusters through a least-privileged approach to your network is a must-have for production workloads.
That being said, a flaw remains in the network policy logic. It implicitly assumes that the network policy applies equally to all containers in the pod.
But this assumption is incomplete. A pod is often made up of “application” containers and of many auxiliary containers (sidecar proxy, a logging engine, monitoring, caching, etc…) and init containers (to load configuration files, for health checks, security hardening, etc…).
When we apply a security policy to a pod, we end up with overly permissive rules to allow all containers to do what they need to. We need to better understand the intent of each application and apply security policies based on the context.
By leveraging Cilium and Tetragon together and leveraging Tetragon’s runtime context, we should be able to apply stringent security policies based on the binary or the process that each container needs to execute ; thus granting containers only the minimum access necessary to perform their tasks.
Interested in becoming a design partner in the first Cilium & Tetragon integration? Get in touch via the Cilium Slack.
Disrupting the Load Balancing Stagnation
When I mentioned inertia, complacency and stagnation at the top, I could have also referred to the Application Delivery Controller (ADC) market. Even though load balancers are crucial elements of any network and enable applications to scale and be resilient, it has seen very little significant change in the past decade.
Time to shake off the lethargy – the Cilium Load Balancer is coming.
Its origins go back to Cilium 1.10 when XDP and Maglev were introduced. The feedback from users was that the performance gains were so good that they thought they had made a mistake during the measurements.
The Czech technological company Seznam.cz had a networking infrastructure leveraging F5 hardware load balancers before pivoting to software load balancers based on IPVS (L4 Load Balancing) and Envoy proxy (L7 Load Balancing). After running into CPU issues, they eventually switched to Cilium’s XDP-based load balancing.
They noticed their CPU load came down from 36 CPUs to 0.5 CPU.
While this feature was initially introduced in Cilium 1.10, it was complex to operate and only geared towards power users like the engineers at Seznam.
This year, expect Cilium Load Balancer to become much more accessible. It’s about time a high performance eBPF-based and declarative load balancer built for cloud native applications enters the market.
The Power of a Community
As we were preparing the Cilium 1.15 release blog post, we came to realize how many new features and contributions were contributed by the broader Cilium community. While the project was created by Isovalent, it was donated to the CNCF in October 2021 and graduated two years later.
It remains a welcoming space where new contributions are welcome (this LinkedIn search link should take you to all the recent “New Cilium Contributor” announcements) and valuable.
Prior to joining Isovalent, Nico worked in many different roles—operations and support, design and architecture, and technical pre-sales—at companies such as HashiCorp, VMware, and Cisco.
In his current role, Nico focuses primarily on creating content to make networking a more approachable field and regularly speaks at events like KubeCon, VMworld, and Cisco Live.
