Note to reader: Time stamps embedded in [ ] below are there to help you navigate to the related section of the full interview video included in this blog.
If applications are the vehicle for modern enterprise operations and services driving growth and competitiveness, containers, microservices, and the cloud are the engine propelling it. In a modern multi-cloud world with endless containers, microservices, and API connections, solutions like Kubernetes are great, but only take us part of the way.
True observability and security in these complex environments require solutions like Cilium and eBPF that are a mix of established tools and innovative software-defined approaches. This frees enterprises and their varied developer teams to create today and tomorrow’s application services efficiently and simply.
But what is Cilium and eBPF, and how do they accomplish these complex goals? Last week at the KubeCon conference in Valencia Spain, I sat down with Dan Wendlandt, Co-founder & CEO of Isovalent, to discuss how their development and use of the open-source Cilium brings game-changing advantages of eBPF to the Kubernetes ecosystem. He’ll help explain how Cilium and eBPF work to address the new scalability, security, and visibility requirements of the ubiquitous enterprise container workloads and microservices for cloud-native, multi-cloud environments.
The Cilium and eBPF origin and evolution story
According to Dan, eBPF is the most exciting thing to happen in Linux in the last 20 years [2:26]. He began by explaining how Isovalent started with the fundamental thesis that eBPF was going to change everything about networking, security, and observability.
The story begins with Berkeley Packet filters (BPF), which have existed in Linux forever to filter packets [4:53]. It really started when running tcpdump and the need to specify filters running in the kernel. They had to be very efficient as the first point in the kernel where you wanted to add extensibility.
Adding extensibility to BPF (eBPF) is basically the expansion of that framework to allow hooking these eBPF programs anywhere in the kernel, which expanded use cases. Dan explained how, in the old days, adding something new in your Linux kernel required writing it upstream, merging it in, and having the functionality three years later [6:00]. This made for a horrible iteration cycle.
eBPF made it possible to add intelligence safely and dynamically to any of the mainstream Linux distros. “The unlimited versatility of eBPF enables extending the behavior of the linked kernel to natively understand things like Kubernetes and API calls,” explained Dan. “That really makes it a natural fit for these modern workloads enterprises run.”
According to Dan, Cilium began with the relationship forged with Isovalent cofounder Thomas Graf in working on the open vswitch project. “He was one of the first people at Nicira who built open vswitch, and drove a lot of that software to find networking movement, which led to NVP becoming NSX when VMware bought Nicira.”
Dan and Thomas had the vision of how software-defined networking (SDN) would bring it much closer to the application. This would provide greater contextual understanding of which services are communicating and making the API call.
The two started focusing on eBPF as the key to unlock this future. “Thomas had discovered eBPF while starting the Cilium project, and my excitement about the possibilities of eBPF were spurred by the discovery of that project through the magic of open source and GitHub,” said Dan. This led me to the contributor’s tab where I found Thomas, reached out to him, and we started working on this together.”
Defining open source and community differences for genuine progress
The discussion with Dan then focused on the power of community, which eventually led them to starting Isovalent. According to Dan, the power of community was the driving force behind their pioneering Cilium-driven eBPF-based networking and service mesh software solutions.
Dan explained how open sourcing your code is necessary but isn’t sufficient to building a successful community [13:22]. Community was their focus with Cilium eBPF to ensure more people use and grow its possibilities together, and was the impetus for organizing the eBPF Summit. “Community and building open source requires wanting other people to be successful even if it doesn’t accrue to you as a company,” said Dan [15:05]. “There’s greater value in becoming the standard based on the notion that growing the community is going to benefit everyone.”
Getting to the core of Cilium and eBPF
According to Dan, understanding Cilium and its intended core purpose starts with comparing it to traditional iptables firewalls, which use the static functionality built into the Linux kernel in a way [16:58]. He explained the design of iptables firewalls requires humans to type a couple of firewall lines at a command line and apply them manually, which hasn’t changed in 20 years.
Dan acknowledged the obvious scale and performance benefits of doing this in eBPF but emphasized there was much more to it. He pointed out the real unique advantage of eBPF lies in its ability to pull in additional context and understand beyond the IP, port, and packet. This includes understanding:
- Service identity
- API call
- The process that made the API call
“That additional context makes eBPF precious from an observability and security enforcement perspective,” explained Dan. “So, I think what really makes Cilium jump out to people are things like our Hubble observability capability for observing who is talking to who, what’s working, and what’s not working.”
Dan explained how the Kubernetes cluster is just a black box where IP addresses are meaningless, and workloads are coming and going. It’s imperative to know why service A can’t talk to service B, which he feels is the missing piece of the overall Kubernetes ecosystem.
“Observability must come before security, so you know who’s talking to who,” explained Dan [20:52]. “This enables determining what connections require applying zero trust networking policies to limit communications between only those connections where it’s supposed to happen.”
While that’s always been the case, he sees it as imperative in a complicated world of application containerization, microservices, and API calls [21:54]. “Putting firewall policies in place based on what you think your app is doing leads to big trouble,” said Dan. “There’s always what the developer thinks their app does and then there is the reality of the connections.”
He further explained the core problem with security is the friction between locking down a communication path and possibly breaking the application or reducing reliability [24:00]. The efficient observability of eBPF eliminates the need for sidecars, and there’s no added latency or overhead. This provides the ability to activate “always on” security observability in a way that simplifies the process for application developers. “It’s a fundamental step in confirming a breach and the accessed data at the very least,” said Dan. “Then you can decide where to enforce policies based on observability in a more simple, efficient, and secure way.”
Although kernels with good eBPF support have now become ubiquitous, it requires literally writing kernel code. That makes the technology less accessible to someone running a business, which is where projects like Cilium come in.
According to Dan, “we don’t tell Cilium users where to write their eBPF code specifically.” We give them high level CRDs to define things like ‘how service A should be able to talk to service B, but nothing else,’ or, ‘give me the HTTP metrics between service A and service B.’” The translation between high level human understandable intent and extremely low level eBPF code needs the layer Cilium effectively provides.“
Fulfilling different enterprise and developer team needs
Today’s enterprises, and most Isovalent customers, have multi-cloud environments [31:00]. They’re not necessarily bridged and connected, but they’re leveraging infrastructure from multiple types of different underlying infrastructure. However, enterprises don’t want to secure their Kubernetes workloads or get observability data differently when they’re on Azure versus AWS. “Linux is that universal Cloud Native Runtime, and Cilium is injecting the additional intelligence to provide the observability, security, and connectivity abstractions they need,” explained Dan.
According to Dan, the conversation is now centered on the reality that apps and workloads will be in many places, based on data governance and costs [36:05]. Kubernetes shines by giving enterprises a sane way to think about how to expose many types of underlying infrastructure to their application teams. “Kubernetes does a great job of that in terms of application deployment and lifecycle,” said Dan. But the observability and security components also need to have the same cloud-independent property.”
Kubernetes and changing observability needs
While Isovalent brings a major part of the discovery-of-need fulfillment to Kubernetes environments, there are countless other things remaining to be done. “As long as there is complexity, there will be people trying to find better abstractions and ways to get observability into that complexity while balancing simplicity and control,” said Dan [38:18]. “Kubernetes is just the bottom 80 percent that is generic, so companies can really focus on the top 20 percent represented by the PaaS layer that their business needs.”
Dan concluded by explaining how different teams within an enterprise IT organization have very different needs [44:30]. Each one requires language that explains solutions and features for each specific need. “I think businesses should be able to decide how much of that sophistication they want to expose to their app, which is how we design our Isovalent solutions.”
We’d love to hear what you think. Ask a question or leave a comment below.
And stay connected with Cisco DevNet on social!
LinkedIn | Twitter @CiscoDevNet | Facebook | Developer Video Channel
CONNECT WITH US