Cilium, eBPF, and Modern Kubernetes Networking with Bill Mulligan

Modern cloud-native systems are built on highly dynamic, distributed infrastructure where containers spin up and down constantly, services communicate across clusters, and traditional networking assumptions break down. Linux networking was designed decades ago around static IPs and linear rule processing, which makes it increasingly difficult to achieve scale in Kubernetes environments. At the same time, modifying the Linux kernel to keep up with these demands is slow, risky, and impractical for most organizations. The Extended Berkeley Packet Filter, or eBPF, is a Linux kernel technology that allows sandboxed programs to run safely inside the kernel without modifying kernel source code or loading kernel modules. Cilium is an open-source, cloud-native networking platform that’s built on eBPF, and provides, secures, and observes connectivity between workloads in Kubernetes and other distributed environments. Bill Mulligan https://www.linkedin.com/in/bamulligan/ is a maintainer in the Cilium ecosystem and a member of the team at Isovalent https://isovalent.com/, the company behind Cilium. He joins the show with Gregor Vand to discuss how eBPF works under the hood, why Cilium has become one of the most widely adopted Kubernetes networking projects, and how the future of cloud-native infrastructure is being reshaped by programmable kernels. https://i0.wp.com/softwareengineeringdaily.com/wp-content/uploads/2023/11/Gregor-Vand.jpegGregor Vand is a security-focused technologist, having previously been a CTO across cybersecurity, cyber insurance and general software engineering companies. He is based in Singapore and can be found via his profile at vand.hk or on LinkedIn. Please click here to see the transcript of this episode. http://softwareengineeringdaily.com/wp-content/uploads/2026/03/SED1902-Cilium-and-eBPF.txt Sponsorship inquiries: [email protected] https://cms.megaphone.fm/organizations/619b680e-d813-11ea-9750-e7ecac406436/podcasts/e60108fe-e328-11ea-b2b6-1348249f900a/episodes/3913370a-bc44-11ed-ace6-8b1f96d82bba/[email protected] The post Cilium, eBPF, and Modern Kubernetes Networking with Bill Mulligan https://softwareengineeringdaily.com/podcasts/cilium-ebpf-and-modern-kubernetes-networking-with-bill-mulligan/ appeared first on Software Engineering Daily https://softwareengineeringdaily.com.

• 0:00Speaker 00

  Modern cloud native systems are built on highly dynamic distributed infrastructure where containers spin up and down constantly, services communicate across clusters, and traditional networking assumptions break down. Linux networking was designed decades ago around static IPs and linear rule processing, which makes it increasingly difficult to achieve scale in Kubernetes environments. At the same time, modifying the Linux kernel to keep up with these demands is slow, risky, and impractical for most organizations. The Extended Berkeley Packet Filter, or EBPF, is a Linux kernel technology that allows sandboxed programs to run safely inside the kernel without modifying kernel source code or loading kernel modules.

• 0:45Speaker 00

  Cilium is an open source cloud native networking platform that's built on EBPF and provides, secures, and observes connectivity between workloads in Kubernetes and other distributed environments. Bill Mulligan is a maintainer in the Cilium ecosystem and a member of the team at Isovalent, the company behind Cilium. He joins the show with Gregor Van to discuss how EBPF works under the hood, why Cilium has become one of the most widely adopted Kubernetes networking projects, and how the future of cloud native infrastructure is being reshaped by programmable kernels. Gregor Van is a security-focused technologist, having previously been a CTO across cybersecurity, cyber insurance,

• 1:29Speaker 00

  and general software engineering companies. He is based in Singapore and can be found via his profile at van.hk or on LinkedIn.

• 1:50Speaker 01

  Hello and welcome to Software Engineering Daily. My guest today is Bill Mulligan.

• 1:55Speaker 02

  Hey, thanks for having me.

• 1:57Speaker 01

  Yeah, great to have you here today, Bill. We're going to be talking all about Cilium and the technology EPBF. Before we get there, as we like to do, it would be great just to hear a bit about you and what was your journey to joining Cilium? And I believe the company you work for is sort of a wrapper around Cilium, for example. So maybe just walk us through all of that.

• 2:20Speaker 02

  Yeah, definitely. So I like to say it's a little bit of an accident how I've ended up here. Just a series of circumstances kind of going on. So actually, originally got my undergrad in biochemistry. So very, very far away from technology. Got my masters in social science and then ended up at the first startup that I was working at. And they were doing, back in 2018, an AI platform on top of Kubernetes. And at the time, nobody was doing AI, nobody was doing Kubernetes. So obviously, it went out of business pretty quickly, moved on to the next startup. Then I worked for the CNCF, the Cloud Native Computing Foundation, kind of looking at the global cloud native community before ending up at Isovalent as kind of like this promising startup in the cloud native space.

• 3:05Speaker 02

  And I was excited about going to Isovalent because Cilium at that time was like really starting to emerge onto the scene as kind of a new and exciting way to do networking in the Kubernetes and cloud native world. So like this company seems pretty interesting. They just emerged from stealth. And I was like, let's see where this rocket ship goes. And it's been kind of a wild ride since then.

• 3:27Speaker 01

  Awesome. For those that are not totally familiar, like what exactly is CNCF? And could you just sort of then describe like what Isovalent and Cilium? What is the relationship between the technology and the company and that kind of thing?

• 3:40Speaker 02

  Yeah, definitely. So CNCF is, or the Cloud Native Computing Foundation, is a sub-foundation of the Linux Foundation. So Linux hosts, obviously, Linux kernel, but I think it's 900 other projects. And CNCF is the largest sub-foundation under that. And CNCF itself hosts just over 200 projects now, Cilium being one of the projects. And really kind of the CNCF was created with Kubernetes as the core project. And then kind of all of the cloud native projects have been brought in around that. And Cilium being one of those. And what Cilium does in the cloud native world is, so Kubernetes is a way to orchestrate containers and other types of workloads now too. But it actually doesn't come with any networking, right? And in the world of Kubernetes, it's all distributed systems.

• 4:25Speaker 02

  And the most important part of a distributed system is the network, right? Because everything's got to be Talk to each other. So Cilium is the CNI or the Container Networking Interface that plugs into Kubernetes and basically says this packet needs to go here. This is how traffic is getting into our cluster. This is how we egress traffic out of it and a lot of other things. So essentially you can think about Cilium at a very high level as networking for the cloud native world at the very beginning. It's expanded a lot beyond that, which I guess we'll dive into a lot more after this. And then Isavialant is a company that originated Cilium. Then they gave it to the CNCF, so it's a neutral governance under there. And we have a lot of contributors from different companies around the ecosystem.

• 5:09Speaker 02

  And Isavialant is the company that's creating commercial products around the different projects that are in the Cilium ecosystem.

• 5:16Speaker 01

  Yeah, I saw the annual report came out just a few hours ago, actually.

• 5:21Speaker 02

  Yeah.

• 5:21Speaker 01

  For Cilium effectively, and it was said on December 16th, 2015, Thomas Kraft pushed the first commit for Cilium. So we're literally almost to the day 10 years on from that first commit.

• 5:34Speaker 02

  Yeah, exactly. So it's a decade in the making, right? A decade in the making overnight success, as people like to say. And it's kind of wild. I think different than a lot of open source projects. It actually is open source from the first commit. If you go look at the first commit, it's, I think, like 200 lines of code, the license and like dot Git ignore file. Like that's it.

• 5:56Speaker 01

  Awesome. Full of wins there is proper over.

• 5:58Speaker 02

  Yeah.

• 5:59Speaker 01

  Yeah.

• 5:59Speaker 02

  Yeah.

• 5:59Speaker 01

  Awesome. So I think we maybe should sort of get sort of super base level and just understand what is, so Cilium is what could be described as E BPF. And what is that? I think that's kind of where we need to start. I imagine some of our audience know this already and it's great that you're here. Equally, I think a lot of our audience have maybe no clue what this is.

• 6:23Speaker 02

  Yeah, so EBPF is also a technology that's not 10 years old. Birthday's a little bit earlier, it's about 11 years old now. And it's a Linux kernel technology. And Cilium was founded from the ground up based on EBPF as a technology. And what EBPF allows you to do is to reprogram the Linux kernel. And the comparison a lot of people like to make is like EBPF is to the kernel what JavaScript is to the browser. And so if you think back, like when we before we had JavaScript, you kind of had like static webpages, right? You could kind of consume information off of it, but you couldn't actually kind of do anything with the web page. JavaScript comes along and suddenly you could add interactive elements. As you start to interact at the web page, it changes what it's doing.

• 7:07Speaker 02

  And that's exactly what EBPF is doing for the Linux kernel. And if you're not familiar with how like Linux kernel development cycle works and how the Linux kernel kind of works as a whole, I'll kind of jump into that. And so the way Linux kernel works is not just, you know, you get this distribution and you download it and you're like using it. The way it works is you need to upstream things into the kernel. And Linux is the largest open source project in the world. And kind of the development cycles are a little bit longer because it's deployed on literally billions of devices. Every single Android phone is running some portion of Linux. So they need to be very careful about what actually goes into the upstream kernel. So the development cycles, and if you know anything about like Linux kernel mailing list, there's a lot of technical discussions that go on on the mailing list.

• 7:52Speaker 02

  So to be able to get something upstream is a long process, it can take years or maybe even for some more controversial things, a couple of years. So not just like, okay, like we need this new feature in Linux kernel, like let's just ship it. It's like, okay, well, you need to, you know, have the discussions, work with the people upstream, decide on the right path forwards, and then it gets into the kernel. And then you have it in the kernel, right? So that's like the latest one that like Linus just goes out and produces. But that's not actually what you're running in production. If you look at most people, what kernel they're running, it's actually two years old, three years old, five years old. I mean, people don't run the latest kernel. They wait for it to actually kind of like bake, they wait for like an LTS, like A long-term stable release, or they get something from their vendor.

• 8:36Speaker 02

  So if you look at the actual kernel version you're running, it's most likely a couple of years out of date. Right, so if you one-year development cycle, a couple of years till it actually gets into you, maybe it's five years from like, okay, I have this idea to when I can actually receive this future, right? So for most people, all intents and purposes, like the Linux kernel is pretty static, right? Like, you're not going to change it. EBPF came along and completely changed this programming model. What it allows you to do is you're saying you want a new feature. And the way that applications usually interact with the kernel is they interact by making like system calls into the kernel or other ways to interact with it. And you, the application says like, okay, can you read this file? Can you open this networking socket? Can you do these different things?

• 9:21Speaker 02

  And it makes a call into the kernel. The kernel does that thing and sends things back to user space. But what EBPF allows you to do is to modify how the kernel is actually running. So you take a program that you write, you insert it into the kernel, and now when the application makes a call into, from user space into kernel space, instead of working how the kernel normally does, your program now runs when that specific hook is called. So if somebody's like, say malicious process is trying to read a file, you can be like, we don't want this process to read this file, so it's blocked. If you want to, in the case of Sylium, be like, we want to do networking faster or more programmatic. We can be like, okay, this packet is coming here. We want to actually just reroute it directly without it going through the whole networking stack.

• 10:06Speaker 02

  And so what EBPF is allowing you to do is to actually add functionality on the fly into the Linux kernel. And if you've gotten to this point, you're kind of like, okay, well, Linux kernel, pretty important. I know if I like crash it, that's really bad. All the systems are over. And so that's kind of what makes EBPF really powerful is because it's not just extending the Linux kernel, but it's doing it in a safe way. Because if you just like throw random code into the kernel, you're very likely to crash it. If you're familiar with like the CrowdStrike incident where they took out half the world's IT, right? That was because there was a bug in the kernel and they crashed all the. Kernels around the world. It's obviously something you want to avoid.

• 10:46Speaker 02

  And so what EBPF allows you to do is it lets you insert programs into the kernel in a safe way. And the way that it does that is for each of the programs that you're adding to your kernel, it goes through a verification step. And what this verification step is basically checks that the program's safe to run in the kernel. So it's not going to crash the kernel. It's not going to like call memory out of bounds. It's not going to do these things that will essentially harm the kernel. And so these programs are safe to run in the kernel. They won't crash the system and they're a very efficient way to reprogram what's happening. And so that's kind of like the foundational technology, right? EBPF got merged into the kernel about 11 years ago. The Cilium team was like, okay, this way of programming the kernel

• 11:28Speaker 02

  is going to let us rebuild everything in the kernel better. Like, what can we rebuild first? And the team at the time was working on, they came out of like the Open vSwitch team. They were doing a lot of networking stuff and they're like, okay, we're going to start rebuilding networking in Linux kernel better, faster. I'm ready for the cloud native world. And so that's the birth of Sillium.

• 11:50Speaker 01

  Got it. And I think it's actually helpful. What does EBPF stand for? It's Extended Berkeley Packet Filter. I guess packet filter on the end there is kind of the thing. I mean, I believe there was, there was in theory a retro actively named classic Berkeley Packet Filter and EPPF is the sort of advanced version of that. Is that correct?

• 12:12Speaker 02

  Yeah. So BPF or Berkeley Packet Filter was kind of like the original thing from like decades ago. It's like, okay, can we put like a packet filter into the kernel? And that was the thing. And originally kind of like this story was Alexi, who was one of the co-creators of EBPF, came to Linux kernel and says like, I want to be able to insert bytecode into this. And they're like this huge path check coming into the kernel. They're like, no, no, we don't want to do that. And so Alexi went back to work with like Daniel and a couple of other people. And they're like, okay, like, how can we actually get to this into the kernel? And they're like, well, there's actually this like packet filter already in the kernel. What if we just improve that to be able to get what we wanted into it? And so piece by piece, they started improving the original BPF, like the

• 12:53Speaker 02

  Packet filter and then also extending it. And so what they're able to do was to improve the existing subsystem and then change it into a more generalized version. So like the CBPF, like the classic BPF is like the original kind of like Berkeley Packet Filter. And now EBPF is the extended version. We don't really call it extended Berkeley Packet Filter because it does so much more than just networking now and saying that it's a packet filter isn't really true. It does things across observability, security, profiling, scheduling, interacting with devices. It's basically like a generalized way to reprogram the Linux kernel. So we just kind of use it as like the standalone EBPF term, but that's kind of history and why if you hear somebody. It's a little bit confusing because there's BPF, there's CBPF and EBPF.

• 13:38Speaker 02

  And if you talk with some of the kernel people, they use EBPF and BPF kind of interchangeably. Just because of that history, but technically now it's called EBPF.

• 13:49Speaker 01

  Gotcha. Okay. So I think you've set the stage pretty well in terms of what does EBPF allow within Linux and like Linux kernel? So it's kind of become this framework for enabling things that can run in the kernel, almost like a sort of set of, I guess, rules that mean that if you want to build things that touch that, they're not going to break some of the big things. And I think, yeah, the CrowdStrike example was a good one. Like that's, that's what happens when this isn't done properly. That's obviously Windows, so it's not Linux, but yes, that was a problem. So where did then Cilium come from in that sense? And I guess Cilium is handling the networking side of what can be done with this capability.

• 14:33Speaker 01

  There must be other products, companies that then deal with other bits that are now possible with EBF being there. But yeah, what does Cilium enable and Kubernetes is obviously a big part of that. So let's kind of go there.

• 14:47Speaker 02

  So if you rewind back again about 10 years ago, we had like the whole containerization movement that was like really exploding at the time. And Kubernetes had also just been released as, you know, open source, not from first commit, but as like this actual standalone project. And so we kind of have this new cloud native world. And if you think about like the transition into the cloud native world, like what you're kind of seeing is a lot more ephemeral, dynamic environments. Containers are coming and going and kind of like the traditional world of how Linux was built. Right? Linux is not a 10-year-old technology. It's next year, a 35-year-old technology. And so like, kind of like the programming model for Linux kernel is very different from what you need in the cloud native world.

• 15:27Speaker 02

  Right? A lot of Linux networking is built based on IPs, based on IP tables. Think of like, okay, we have this list of IPs that we trust, a list of IPs that we don't trust. But if you think about the cloud native world, you're spinning up containers up and down all the time. And so how can we have this decades-old technology and bring it into the cloud native world? And that's really the challenge that Cilium was set out to do is how can we do cloud-native, identity-based networking? And so some of the original challenges that Cilium was looking at, like one is like IP tables is the way that we do a lot of networking. So as you're being like, okay, we need to send packet from this IP to this next IP.

• 16:11Speaker 02

  And the way that you do that is you have like a list of IP tables and you go through them linearly. But if you're having, I don't know, thousands, tens of thousands, a million containers in a cluster, going through a linear list of rules is not very efficient. So one of the first things that do and like, one of the reasons that a lot of people like Cilium is because it replaced IP tables and like Q proxy, which is the proxy that routes most of the traffic in Kubernetes, we replaced that with like what we call Q proxy replacement. And that's all written in BPF. And so it replaces IP tables with EBPf. And rather going through things linearly and having to do things kind of like in an ON order.

• 16:52Speaker 02

  What EBPf allows us to do is have everything in a hash map and it's able to look things up in O1. So a lot faster and a lot more scalable. So right, if you look at the difference when you have like 10 services in the cluster, it's not that big, right? Because you can run through a list of 10 services pretty quickly. But if you have 10,000, the difference between like reading through the rules linearly and being able to just look them up in the hash map is very significant. So that's one of the things like being able to write things in a modern way for the modern technology and the modern way of doing things is how making networking a lot more efficient. And there's a lot of stories now about like being able to replace Q proxy, like Trendall, like a e-commerce company in Turkey by replacing Q proxy.

• 17:34Speaker 02

  They increased cluster throughput by 40%. So big performance gains there. Then the next thing about Cilium is right. So you have a lot of containers, you have these IPs, but the IPs aren't fixed because they're coming and going all the time. And a big thing in networking is not just, yes, one is like connecting things, but it's also making sure that things that aren't supposed to be connected, don't stay connected. This whole like network security part. And if you're doing that based on IPs, you're going to have to be updating all these rules a lot and being like, okay, like this IP is like no longer being used. So we shouldn't be able to route traffic to it. And so being able to understand like network routing and like network security. If you're doing that with like fixed IPs as containers are coming and going, you're going to have to be updating these rules a lot.

• 18:18Speaker 02

  So it's going to cause a lot of churn in the cluster, a lot of overhead. And Cilium was like, okay, as we're moving from a world of IPs towards identity, like, you know, the classic DevOps analogy from pets to the cattle. We're not looking at like individuals anymore. We're looking at like groups or sets of people or things with like labels. And so Cilium switched the whole networking model from like this IP based model to this identity based model. And so rather than saying like IP X can talk to IP Y, we can say front end talks to back end. So then as we kind of rotate the containers behind these labels, it doesn't actually matter. And as you spin up a new container, you can be like, okay, this is a backend label. And so it can now automatically talk to all the front end labels.

• 19:00Speaker 02

  And so if you think about the cloud native world, it's like, how can we switch to this identity based model and being by being able to give things? Identity, it makes things a lot easier because you can swap things out on the backend and the identity is still the exact same. And it reduces a lot of the churn in the cluster too. So what Celine was trying to do at the beginning is like, you know, we have this new, modern cloud native world. Things are a lot more dynamic, ephemeral. The current networking technology that we have isn't going to be able to keep pace with what we need to do in this world. So how can we rethink networking for the modern world with EBPf? And the way EBPf allows this to do that, we can take out IP tables, we can route things like very efficiently, we can move from IP towards identity for both our like networking

• 19:44Speaker 02

  and both our and our security model and allows us to bring networking into the modern cloud native world.

• 19:50Speaker 01

  Yeah, it's a really good way to explain it. I guess there are some analogies with just like cloud, I am like identity management, like how the cloud providers effectively added this, what is unfortunately now an incredibly complex thing. And like you've got layers on I am now to try and make it easier to administer because people will end up creating the wrong identity profiles and all sorts of things. But yeah, so like, is that kind of a good analogy?

• 20:14Speaker 02

  Yeah, exactly. So if you like, you think about it, when you join a new company, they give you like an example would be like, or in my personal life, I log into Google and it gives me access to a lot of different services based on the identity that I have. I'm like, I say I'm Bill Mulligan, I give this like identity to Google and Google goes out and says like, this is Bill Mulligan to all these different services. You could do the same thing in Kubernetes, you can be like, okay, this new pod is now frontend, it's frontend to all these other services or it's it's the backend that all the frontend just want to talk to essentially. And like, if you think about like, when you're spinning, like adding a new like developer to your team, you don't want to give them kind of like access to GitHub and your cloud resources and your developer environment and to all the other services that they need.

• 20:59Speaker 02

  The way that you probably do it is you probably give them one identity to something like Okta and then Okta provides the identity out to all the other services that they need access to.

• 21:08Speaker 01

  Yeah, that makes sense. So maybe if we just look at what are the features, feature set, if you like, of Cilium, you know, we've got things like, we've touched on it there, but like network policies, I think that'd be interesting to kind of dive into a little bit more. Service mesh as well. And I think that'd be also helpful, maybe when we get there to just touch on like, what it even is a service mesh, because I think some listeners may not be familiar with that. And then we could maybe just sort of get on to some of the more advanced features as well. But yeah, so let's maybe just start with like, network policies, that seems to be kind of the core of Cilium, like, maybe if you just dive into that a little bit more.

• 21:46Speaker 02

  I talked to a lot of users out in the Cilium community, and like, the main three reasons that they choose Cilium, because there's a lot of different networking solutions in Kubernetes, is one is network policy, another one is queue proxy replacement, getting the performance and scalability benefits, encryption of network traffic, and observability with Hubble. But starting with network policy, so this is going back, distributed system, we want to make sure things cannot talk to each other, but we also want to make sure things can't talk to each other. And so in Kubernetes, there's Kubernetes network policies, and these are layer three, layer four network policies. So you're looking at things like IPs, like this IP can or can't talk to that other IP. So Cilium implements Kubernetes

• 22:31Speaker 02

  network policies for layer three and layer four. But the additional thing that a lot of people look at is also, it's not just, you know, these low level, we also want to look at like, layer seven network policies. So Cilium has layer seven network policies too, and we call them like, Cilium network policies. So things like, allow traffic from star.google.com, or don't allow traffic from this domain, right? So being able to look at the actual domain with layer seven network policies is super helpful for a lot of people. You can also do things like cluster-wide network policies, looking at which namespaces cannot talk to each other, or can talk to each other. So one interesting one, that

• 23:14Speaker 02

  use case that we had was like Bloomberg, obviously, a lot of financial data. And they were coming out with a new product that was a essentially like data sandbox studio. So customer logs in, they're able to access the financial data, they're able to do different types of work with it. So they're, they had a Jupiter notebook and they could, you know, write different programs against the, uh, get what they wanted to. And then you like to see the data, but I mean, the important thing is Bloomberg's financial data. They want to make sure like data is not being exfiltrated out of this data sandbox studio. They want to make sure they had multiple tenants and so each of the tenants can't talk to the other tenants. So, you know, one person can't see what the other person is doing with the data.

• 23:58Speaker 02

  And a lot of that you can do with network policy. So you basically namespace each of the tenants within the namespace and make sure that they can, with network policy, talk across the different namespaces in the cluster. And you can also write network policies, basically saying that data can't egress out of the Kubernetes cluster at all too. And so with that, they're able to create a new product for their customers while still keeping their sensitive financial data secure. So network policy is a really important thing to be able to secure your Kubernetes clusters.

• 24:30Speaker 01

  That's a great, really good example. Funny enough, I'm working on something similar, so I'm going to just ask a question on that basis. So why does Cilium make that easier than if not using Cilium?

• 24:39Speaker 02

  If you're just using Kubernetes, so there's different like CNIs that you could use in Kubernetes. And some of them, like it's not a requirement that they implement network policies. So some CNIs don't have any network policies, then you can't write any Kubernetes. Or you can write Kubernetes network policies, but they won't be enforced. It's really not effective. Some of them just do the Kubernetes network policies. Then you only get the layer three, layer four. So you can't write more complex or advanced use cases around network policy. And then the other one is like, other things like if you're doing like multi cluster network policy. So if you're running multiple Kubernetes clusters, this is another thing a lot of people turn towards Cilium for, because it simplifies.

• 25:18Speaker 02

  That Cilium allows you to look at network policy, not in just one Kubernetes clusters, but across multiple Kubernetes clusters. Kubernetes gives you basic network policy and Cilium allows you to do much more advanced use cases around network policy.

• 25:31Speaker 01

  Yeah, makes sense. So how about, is there anything more around network policies or do you want to go to the service mesh?

• 25:38Speaker 02

  We go to service mesh.

• 25:40Speaker 01

  So yeah, talk to us about service mesh. Again, I think what is a service mesh first and foremost? And then how is Cilium helping to that end?

• 25:47Speaker 02

  Yeah, so anybody that knows me might know that I'm trying to kill the word service mesh and the category service mesh. If you go look at it, there's an article that I wrote that I think explains a lot of my opinion that it's called like the future of service meshes networking. And so service mesh is a little bit newer than Kubernetes. And it's once again, like, okay, new cloud native world. Like, there's kind of a lot of things that we need to rethink. And a lot of this is like service routing. So service mesh is a term that tried to mean a lot of different things. So like, if we have like microservices, we have a lot of new challenges of how do we do the networking between them? How do we do the observability? How do we do the security between all of them? Like microservices running all over the place.

• 26:30Speaker 02

  And the service mesh tried to solve this with a lot of like layer seven networking stuff. So, right, it's like networking, observability and security, a lot around like layer seven stuff. And this is why I kind of have a problem with like the category like service mesh is like, if you look at all those, like, those are all like fundamentally like networking things. And if you're trying to do it at just one specific layer, you might be missing a lot of the context from all the other layers. So I think we had a big arc where service mesh was very hot and a lot of people were trying to implement it. But I think we're kind of getting into a phase where people are understanding that you can't separate out the different layers of the networking stack. Can't be like, oh, I'm just gonna look at only layer three.

• 27:15Speaker 02

  You actually, if you want to have the full context for your application, you need to look at all the layers and you need to look them like holistically, right? Because like an example that I've heard is people are running Cilium as a CNI. And then Cilium has a service mesh, which I'll get to in a second. But you can also run a different service mesh on top, right? So they're running Cilium and they're running a different service mesh. And they're like, okay, well, Cilium does a lot of smart things in EDPF. It doesn't use IP tables. It just reroutes traffic and do things like just route packets from socket to socket within the same Linux host. You do a lot of things. That will make it much more efficient, scalable, performance, save you CPU cycles. But it doesn't mean all the other parts of the networking stack know what's happening.

• 27:57Speaker 02

  So an example would be like, Cilium can route things directly from one socket to the next. And it doesn't go through the whole Linux kernel networking stack. So the service mesh is looking at the end of the Linux kernel networking stack. And it's like, okay, I'll do this like layer seven processing. Once it comes out of that, what like actually never goes through the networking stack. So you never see the packet. And so you're like, okay, like all this traffic is disappearing or we don't route it or we don't see it. And it's because it doesn't go through the traditional networking stack as the service mesh was expecting. And so service mesh, I think, can't be its own standalone category. You need to think of it in the context of your whole networking stack. And so this is why Cilium came along.

• 28:37Speaker 02

  It was originally just a CNI doing a lot of this layer three, layer four like routing. But then we're like, okay, well, networking is not just like a couple layer standalone category. It's actually like, you need to have the context of the full stack. So what we did is we came out with Cilium Service Mesh. And this is where some of like the layer seven network policies started to come in. And also doing other things like traffic routing in layer seven, some of the observability stuff. But integrated within the rest of the CNI and the rest of the kind of like networking story. And I think I also have a problem with the term service mesh because it's kind of like nebulous. It's like, where does service mesh live? Where does networking start? Where do they overlap? Where they're all just kind of like overlapping concerns.

• 29:20Speaker 02

  Like what I think of today as Cilium Service Mesh is Cilium's like gateway API implementation in Kubernetes. And some gamma, I think.

• 29:33Speaker 02

  I have a lot of problems with service.

• 29:35Speaker 01

  I get it. There's a lot of emotion pent up with service mesh.

• 29:37Speaker 02

  Yeah.

• 29:40Speaker 02

  But I think it's also really funny. So I look at the analytics for the website and like, one of the top, I think, three pages is the Cilium Service Mesh page. So it's what people are interested in. But I'm like, so what are you actually interested in? Is it, is it like the routing? Is it like the observability? Is it like the security? It's like, like people aren't trying to solve like service mesh isn't a problem. Trying to solve is like, okay, we need to do like layer seven routing and like host pass or something, or we need to do layer seven network security, like that's the actual problem you're trying to solve, like service meshes is like this kind of like nebulous term that somebody told me I needed it.

• 30:14Speaker 01

  Yeah, I mean, I think I can probably give then my perspective on that because yeah, working on a specific problem. You know, I'm not an engineer by day anymore, but working pretty sort of hand in hand with pretty advanced engineers. And when I was looking at what we're needing to achieve and did a sort of bit of running around sort of understanding, okay, what are the bits to the network stack that we need to think about here, service mesh just kept popping up. So I'm like, okay, guys, do we have a service mesh? It was kind of my first question, just to kind of maybe get a sense of, do we have a concept of this thing or not? And then, you know, I got my answer and then we move on from there. So I guess it is, it's just a sort of a catchall term

• 30:57Speaker 01

  to help to that end. And maybe that's why people are looking up so much on the website because it's sort of like, yeah, but that's just an anecdote, I guess, but yeah.

• 31:06Speaker 02

  Yeah, I think you're exactly right. I think it's kind of like, as we saw this transition to the cloud world, there is kind of like a lot of like quote unquote, new problems that were like, as we have a bunch of microservices, like there's like new networking problems, new like network security problems and like service mesh was the label to solve a lot of those problems. It's like, okay, we want a service mesh to solve the specific problems that we have, but kind of how the Cilium service mesh came around is like, we also were like, people started asking us about service mesh and we like looked into it and we're like, okay, what does the service mesh actually look like? And we're like, okay, with what we have so far, we actually have like 80% of the service mesh, because it's a lot of like networking, network security, network observability parts. The only part we're missing is like a bit of like the layer seven stuff. And so

• 31:51Speaker 02

  we're not actually building like a whole service mesh from scratch. We're actually just adding like that last 20% is what people are looking for. And so that's how we originally came out with like, what was the Cilium service mesh?

• 32:02Speaker 01

  Got it. So let's maybe move on from service mesh. That's been, I think, super helpful. And I'm sure there's a lot of people that I will sort of look at the term service mesh differently now.

• 32:14Speaker 02

  Sorry if I'm destroying people's hopes and dreams. One thing to solve it all.

• 32:18Speaker 01

  Yeah, exactly. That's that's all we're looking for, right? We're always looking for a term that just solves all our problems.

• 32:23Speaker 02

  Yeah.

• 32:24Speaker 01

  Cilium also does observability, to my understanding, through, I guess, a sort of arm of the product called Hubble. Could you maybe talk to us a bit about about Hubble?

• 32:34Speaker 02

  Yeah, definitely. So this is like everything else and kind of the Cilium ecosystem is based on EPPF. And so what Hubble does is like, okay, since our EPPF programs are in the kernel routing all the traffic and we can see all of that. What if we just like took that information and surfaced it to the user? And to be honest with you, I think Hubble is the favorite feature of basically like every user I talk to. Like the quote from the ESNET Energy Science Network, which is all like the national laboratories in the US. They're doing crazy stuff like IPv6 only Kubernetes cluster and it's like Hubble's a godsend. It lets me, what used to take multiple days of engineering time, I can now solve it in 30 seconds.

• 33:18Speaker 02

  And so going back, if we think about it, distributed computing packets are flying everywhere. We need to be able to understand it. It's not just like, okay, let me like debug my one application. I can follow it through the whole program. It's like, okay, applications are making calls out to different programs. It's going over the network. We don't know where the packets are going. We don't know where the information is going, where are things being dropped? And so this is where Hubble came along. It's like, okay, so if we're actually routing all the packets already with EPPF, why don't we actually observe them? And so Hubble kind of just like kind of piggybacks on top of the Cilium CNI and basically takes the information from the CNI and like surfaces it to the user in a couple of different ways. So there's, one is like network flow logs. So it's basically saying like, here are all the packets going through. This is like where they're going.

• 34:01Speaker 02

  And then the other one is the Hubble UI. And this allows you to create a service map of everything that's going on in your cluster. And you can see where things are being routed, where different things are connecting. And also, I think more importantly, where traffic is being dropped. Because to be honest, that's, you know, when most people run into networking, like everybody likes to not have to think about networking. The only time they do is when things are. Going wrong. And with Hubble, they're able to very easily visualize either through the UI or through the flow logs. They're able to see, okay, where is our traffic being dropped, right? Because that's probably like most people are concerned. The security team is concerned about like, okay, where's our, where are things going that they shouldn't be? But like, most developers on a day-to-day basis, they're saying, why isn't my traffic reaching the destination?

• 34:46Speaker 02

  And Hubble is a great way to understand that. So it can give you the reasons for like the policy drops. You can be like, okay, our security team wrote all these new network policies and deployed them into the cluster. And now all of my traffic's being blocked because they didn't want this type of traffic going in the cluster anymore. And then you can go have that conversation. Or you deploy a new service, why isn't any traffic reaching it? Well, okay, like it's in a new namespace and we don't have the network policy. We have a default deny all network policy in our cluster and we forgot to write one. Okay, we should allow traffic to this new namespace. So people love Hubble because it allows you to have insight into where all the network packets are going in your cluster in a very easy way.

• 35:28Speaker 01

  How would this be done, I guess, without Hubble? You just have to kind of roll your own or?

• 35:34Speaker 02

  So Linux, right, like decades old technology, there's a lot of networking tools to be able to understand where things are going, like TCP dump. But that's right, if you're using the networking stack. And the problem with BPF is like, there's kind of like this, uh, sometimes people say EBP F magic that people sprinkle on. It's like this black magic happening in the kernel and the packet just disappears because it's routed from one socket to the other and it doesn't go through all the traditional tooling, right? So as you're switching how you're doing things, you also need to come up with new tools. So yeah, Hubble is one of them. And there's also another project under Cilium called Peru, like Packet, Where Are You? And that's another great debugging tool that allows you to essentially pull more information out of the kernel.

• 36:17Speaker 02

  Like, one of the reasons that like people love EBP F is because you can hook anywhere in the kernel. You can pull any system information that you want. You can modify any system information. You can essentially pull out this fire hose of data. Like, the limitations of some of the previous tooling is like, it's either Like one, it doesn't like pull out the information you need, or it's like it's designed in a certain way. It's like, this is what it does, but EDPF allows you to look for anything that you want to. You want to pull out new type of information from the kernel. Well, you can write a program to be able to do that. And so what Peru and Hubble allow you to do is to surface exactly the information that you want, rather than relying on tooling that may not even work.

• 36:55Speaker 01

  Yeah, I think that's a helpful call out, given, as you say, BPPF could be seen as a bit of magic. Then for you with the magic, often, yeah, I mean, my sort of long ago version of that was like, when you start using the Ruby on Rails, for example. And then it's like, yeah, but we need like tools to actually then understand what's going on. Cause it's just a whole layer of magic passing data between the backend and the frontend. And I need to sort of understand what's going on there, for example.

• 37:20Speaker 02

  Exactly. So you can think about it, new tooling for the new world.

• 37:23Speaker 01

  So we've kind of looked at what Cilium does and why developers might want to look at it, or why they're using it already. Let's maybe just spend a little time going a bit deeper on how Cilium actually works sort of under the hood. So we've got the idea of like, what is a Cilium data path? For example, and then we can maybe sort of jump into just the actual component architecture after that. So I believe this sort of a concept of BPF hooks. Maybe we could kind of start there and just sort of, how does like Cilium actually work, I guess?

• 37:57Speaker 02

  So kind of like the basic architecture for Cilium is there is a Cilium operator running into your cluster. And this runs kind of like the lifecycle for all of the Cilium agents. And the way the Cilium agents work, it's like Damon said, so it's one Cilium agent running on each of the nodes in your Kubernetes clusters. And what the Cilium agent does is it installs all of the EDPF programs onto that specific node. And so what the agent does is it gets information and basically writes all the BPF programs and installs them actually into the the cluster. And the interesting thing about this architecture is it in some ways like simplifies a lot of the networking and upgrade lifecycle.

• 38:43Speaker 02

  Because the data plane, which is the BPF programs running in the kernel, is actually separated from the actual lifecycle of like the control plane, which is the agent and the operator running in the cluster. And so one thing I didn't touch in before with E B P F programs is that you install them into the cluster and they they start running and you can deinstall them. And so what that allows you to do, and there's there doesn't have to be any communication between like kernel space and user space between like the control plane and data plane. So the agent is installed on the node. It installs all the B P F programs. The B P F programs start routing all the networking packets or they're with Hubble and they're like observing all the networking packets. And with that, you're able to essentially,

• 39:29Speaker 02

  if the agent goes down, it doesn't matter because all the programs are pre-installed and they're still going to be routing the packets. The only thing that won't happen is you're not able to update any of the data path because the agent's not there anymore. And so what you can do is like you can update the agent. New agent is there and it can then modify the E B P F programs. It's a little bit different with Envoy. So that's with all the B P F stuff. Some of the layer seven stuff, which I guess I didn't touch on yet, is done with Envoy, which is a very popular service proxy. It's what a lot of the other service meshes are based on. And Envoy is also run as a daemon set. So one envoy on every single node in the cluster.

• 40:11Speaker 02

  And that works with the Cilium agent and the B P F programs to do some of the layer seven based routing. And so the B P F programs and the Envoy together kind of create the whole networking story and they work in concert with each other. And then layer seven is a little bit different because this is something that they're working on right now. It's like some layer seven connections are like more long-lived. So if you restart the Envoy on the node, then it like resets some of the connections. But now they're working on like hot restart of Envoy. So that starts changing a little bit different. But I guess what's different about like the Cilium architecture is like the agent is separate from the B P F programs that are running in the kernel. So the data path can keep on running even as things are changing on the control plane, too.

• 40:52Speaker 01

  So then we've got like the Cilium agent. I guess there's also the Cilium operator as well.

• 40:58Speaker 02

  Yeah, the operator manages the lifecycle of all the agents in the cluster.

• 41:02Speaker 01

  Gotcha. And then the CNI plugin, and then identity management, which we've obviously touched on a little bit as well. So in terms of getting up and running with Cilium, maybe we could take sort of two brief examples. One is like total greenfield, which is obviously, hopefully, the easier one. And then one is you've already got like a Kubernetes cluster kind of running something medium advanced. So maybe we take those kind of two cases, like, what are we talking in terms of getting up and running?

• 41:31Speaker 02

  So I have a brand new Kubernetes cluster. There's a couple of different ways to install Cilium. So the first and the easiest one is you're on a cloud provider, doing something like GKE or AKS. And Silliums are the default on that clusters. The cloud provider sets up your cluster, you get Cilium off and running to the races, it's already in there. I think that's one of the cool things is like, Cilium's already the default CNI for a lot of managed Kubernetes clusters. The next one is you're setting up your own Kubernetes cluster, and this is like super common use case for like on-prem or other things. Cilium has like a couple of different tools. I think most often people install Cilium with a Helm chart. So install that with Helm into your cluster. You can also install it with the

• 42:12Speaker 02

  Cilium CLI, but this is, I guess, maybe not as recommended, because then it's what things you pass into the CLI and trying to remember that versus like a Helm chart. So you're going to probably see most people install Cilium with a Cilium Helm chart. And then the migration story is something that we see commonly, because when I look at the way, like, people usually set up the Kubernetes cluster, it's like what I was saying before, nobody wants to care about the network until they have to care about it. And they don't usually turn to Cilium, or they might not always use Cilium until they come across one of the problems that they're having with, like, that Cilium helps solve, like I was saying before. So something like performance and scalability, the network policy or encryption,

• 42:57Speaker 02

  the observability aspect, or like multi-cluster networking. Because like, if you're running on something like OpenShift, OpenShift has their own CNI that they install into their Kubernetes clusters, or AWS, you have the AWS VPC CNI. So there's already one Installed in there, or maybe for instance, a lot of tutorials start with like flannel. And so you already have Kubernetes cluster running with a different networking CNI in there. And you run into one of these challenges that you're like, okay, well, I need to have better performance and scalability in my cluster. And our security team says we need to have these layer seven network policies. And our application developers are having a hard time debugging the cluster because they don't have any insight into where the traffic's actually going.

• 43:43Speaker 02

  And we're thinking about spinning up some more Kubernetes clusters. And you're like, okay, well, Cilium solves a lot of these problems. So I think we should migrate to Cilium as our CNI. And the question becomes, okay, like, how do we do that? And so the migration path that we see most commonly that people do is the cool thing about Cilium is it's not like, kind of like a big bang where you're like, okay, like we need to like switch this over. It actually allows a lot of incremental things. And so one common path is I see people doing is like, okay, we need better observability in our cluster. And so what you're able to do is to do CNI chaining. So you essentially have like your first CNI say like flannel and you're like, okay, I need better observability because it doesn't have any observability. And so you're able to essentially install Cilium on top of final.

• 44:28Speaker 02

  Final still does all the network routing, but Cilium is able to see all of that networking. And being able to surface that information through Hubble. So you now have the network observability without having to change any of your data plane. And you also now have the added benefit of having Cilium as a CNI in there. Or people also install Cilium for network policy. And so we don't want to change our data plane. Actually, there's a lot of companies that actually wrote their own in-house data plane. So for example, Alibaba wrote their own CNI, but they wanted to add network policy. So they installed Cilium on top to do the network policy part. And so now you have two CNIs in there, one's doing the networking, one's doing the network observability or network policy.

• 45:11Speaker 02

  And what you're able to do is Cilium has this flag called Cilium node config. And you're able to specify on each node in your cluster, which CNI you want to do the network routing. And so at the time, you're able to essentially say, okay, I want all of my original CNI to do the network routing. But what you then can then do is you're able to drain traffic off of a node. And say like, okay, we want this new node to be, as you're adding new nodes to the cluster, we want this new node to be using Cilium as the CNI for traffic routing. And so you can basically roll over your whole cluster node by node. And each node that's coming online now is able to have Cilium as the CNI. Until eventually, you're basically switching over all your traffic to the new CNI.

• 45:56Speaker 02

  Cilium's your CNI, and at that point, you can uninstall the old CNI.

• 46:00Speaker 01

  Well, yeah, that's really cool. Yeah, like the CNI chaining, that's, that's super cool in terms of.

• 46:05Speaker 02

  Yeah.

• 46:05Speaker 01

  Yeah, because my, as you say, like migration is, well, it's probably the more likely case for a lot of people maybe listening today that aren't using already. But unfortunately, that's also often the reason it doesn't get adopted as quickly because it's often challenging.

• 46:19Speaker 02

  Yeah, nobody likes to mess around with the network.

• 46:22Speaker 01

  Yes, quite, yeah.

• 46:24Speaker 02

  If it's working, just like leave it, right? But yeah, if you start to run into some of these problems, you're looking at a migration story and a lot of people want to do live migrations. So if you go on the Cilium website, there's actually quite a few stories, like the most recent one was from D B Shanker, which is like the German National Rail like logistics thing. And they needed to migrate over to Cilium and they did the Cilium node config and were able to do like a live migration of Cilium.

• 46:48Speaker 01

  Exactly, that's infrastructure sort of at some of the most important levels. So that's pretty cool. So kind of looking at, as we touched on right at the beginning, Cilium is a very open source project. And again, looking at the, so just some of the stats from the report that you guys just put out. There's a number, yeah, a hundred, a thousand individual contributors. You cross that line basically on the project in October 2025. So that's a, that's a huge number, that's a huge number of contributors. So like, this, this is surely one of like the, I guess, largest open source projects out there.

• 47:21Speaker 02

  Yeah, I think this is like kind of interesting for me. Cause it's also if you're looking at like other like vanity metrics like GitHub Stars and things like that. It's like, okay, how do you measure like the size, success of the, the project? And right, a lot of the people that I'm talking to, like Cilium is run by like the platform team. And it's like four engineers supporting 200 developers. And so if you look like at a lot of other projects, they're going to be a lot bigger. But it's just because like the number of people actually interacting with that is a lot bigger. You know, like a front end framework or something like that. It's going to have, you know, 200 developers for one SRE supporting those 200 people. And so it's, it's kind of wild to me that Cilium is kind of going into like such a large project, right?

• 48:02Speaker 02

  If you're looking at, there's a lot more developers that can write like HTML than, than can write EDP code. Right? So like a thousand contributors is actually quite a lot in some ways. In terms of like stats, so depending on how you look at it, Cilium is in the top three projects in the cloud native computing foundation. So 200 some projects are the largest ones in the cloud native space. Kubernetes, obviously number one, because it's also the second largest open source project in the world. Number two and number three is, is Cilium. So yeah, one of the fastest moving projects in the whole C N C F ecosystem.

• 48:37Speaker 01

  Yeah, I think I said in the report, now, now the second largest, Cilium is now the second largest. That's pretty, pretty awesome. So yeah, I mean, I guess sort of on that note, sort of in terms of community and contributions, like, is it usually someone who's kind of, I guess, using already through their company, I guess, that sort of ends up then jumping in and making a pull request for something that they've seen? Or do you also just have kind of diehard Cilium fans that just work on this?

• 49:04Speaker 02

  Yeah, I would say the most common thing, it's kind of like what I was saying before, like the number of people that can write EDP code in the world is, is not that large. The Cilium agent is written in Go, so it's a little bit different there. I think it's a bit more approachable, but yeah, Cilium is like a pretty deep networking technology or like technology as a whole. And so, yeah, the most common use case is, is we're running Cilium in our production cluster. We're running into this issue or bug. It's open source, so we're contributing this fix because nobody else in the community is working on it and we really need this. So that's actually how some of our like the earliest like maintainers of the project came along. So some of the earliest ones were actually from Palantir and Datadog because they were running Cilium in production.

• 49:47Speaker 02

  They needed things solved. Easiest way to do that is to upstream the changes into the project. They got more and more involved and became maintainers of the project. And then in the exact same way, two of the other big companies like, like I said, Google and Microsoft use Cilium as the data plane in their managed Kubernetes clusters, so they need to get involved to be able to upstream their changes. So it's people running Cilium in production that are trying to solve the issues that they have and that's really how they get involved.

• 50:15Speaker 01

  Looking ahead, when it's sort of this open source like roadmap, it can be a bit of an ephemeral term, but like, what are you? You know, twenty twenty five looks like it was a pretty big year. Like, what do you think is kind of on the horizon through twenty twenty six?

• 50:29Speaker 02

  I think there's a couple of different things. So one, like in the Kubernetes world, is really starting to see this transition to IPv6. I was just at SilliumCon in Atlanta, right next to a QubCon, and there is actually two talks from ESNet and also from TikTok talking about using IPv6-only Kubernetes clusters. I think maybe this is finally the year of IPv6, but I think we're really starting to get there. And a lot of the work done this year by the project was around how can we basically bring IPv6 feature parity up to IPv4? So I think there's a lot of work being done around there because we're actually starting to really see IPv6-only clusters going to production.

• 51:10Speaker 02

  And only that, like, going into production at scale. Like, if you look at the scale of the national labs, like, infrastructure in the US, like, it's, it's pretty big. Also TikTok also, like, like, quite big, very different use cases. So that's one is like in Kubernetes itself. The next one that I didn't touch on that much is around, I guess, everybody's kind of aware of like the whole VMware thing. And so people are looking to migrate off of that. I think that plays into like Cilium, like, a couple of different ways, like. One is like, how can we bring VMs into Kubernetes? And another part is how can we connect Kubernetes or like the cloud native world with the rest of our IT estate?

• 51:50Speaker 02

  Like sitting in virtual machines outside of that if we're migrating and modernizing, like, how do we still connect it to what we already have? So there's kind of like two pieces there. So one is how do we run like VMs in Kubernetes? And Cubert, I think a lot is what a lot of people are using. And one thing that I'm really excited about that Cilium's coming up with is this thing called NetKit. And this was originally developed to solve the container networking overhead. So the problem with containers is right, it's a process running on the host in its own network namespace. And by traversing into the network namespace, it creates essentially some overhead. And what NetKit allows you to do is to basically take something off of the NIC and put it into the container with essentially no overhead.

• 52:35Speaker 02

  So eliminating the networking overhead of containers, right? Since Cubert is kind of like a VM running in the container in Kubernetes. What we're doing now is like, can we use NetKit to get the packet into the VM directly from the NIC? So eliminating the overhead of not just the container, but of the VM running inside the container, running inside of the host. So it's, once again, how can we reprogram the networking stack to make it faster, more efficient, more scalable? As we add more layers of abstraction, how can we still kind of make those abstractions things that we can still get the performance that we need to out of our clusters? So that's on running VMs inside of it. And then the second part is connecting to the outside world.

• 53:16Speaker 02

  So we're actually doing a lot of work at Isolvion, like getting Cilium to connect to like the outside world. So VMs running outside of your cluster or VMs that you're trying to migrate into your Kubernetes cluster in a seamless way. You know, it's, once again, how do we make that transition, that migration story as easy as possible and doing that in a very smart way with EBP F?

• 53:39Speaker 01

  Awesome. Very cool. So NetKit is that they'll be available in 2026?

• 53:45Speaker 02

  No, so that's that's actually out now on the part of Cilium. So this is another thing. It was made by Daniel Borkman, who's also one of the co-creators at VVPF. That was kind of like the next project he was working on was NetKit. And that was a Linux kernel feature. So it's actually part of Linux kernel. Cilium uses NetKit to be able to eliminate that container networking overhead. And then we're also implementing it to work with Kubevert 2. So the whole part with four containers is already, it's in the kernel and it's in Cilium. If you're running like the right versions and then like the part with VMs is kind of for next year.

• 54:22Speaker 01

  Awesome. So just as we wrap up, where's best for a developer? Or just someone who's kind of interested in Cilium and maybe thinking about, I don't want to say throwing over the fence to the developers, but throwing it into the mix, like where was the best to go and just sort of get acquainted with Cilium?

• 54:38Speaker 02

  Yeah, so I'm extremely biased because I'm a maintainer of the website. So I would say go to cilium.io first. And I think there's a lot of like helpful resources for the different things that I've talked about. So if you're interested in like, okay, like I'm interested in like this Q proxy replacement or other things like that. We have pages for all the different features. So like, I want to learn more about Cilium as a CNI, about Q proxy replacement, about BGP or cluster mesh or host firewall. I want to learn more about Hubble. We can do that. We also have like created different pages for different industries, kind of talking to the challenges that a cloud provider or consulting company or financial services company. So it's not just like, here are the features, it's here are these features and how do they apply to your actual industry?

• 55:22Speaker 02

  And then the last part that we have is like these outcome pages, because once again, it's like you have these features, but like companies aren't buying a service mesh, they're buying a specific outcome. Like how do we do layer seven routing? Or how do we do zero trust networking? Or how do we do network automation? How do we consolidate our networking tools? And so like actually looking at those outcomes. And so it's kind of like moving up the stack from here's the feature to here's like the business value that we're getting and how do we do? For the industries. But if you actually want to get hands on, what I recommend is going to like the getting started and going to the labs. And there's a lot of hands on labs around Cilium. And so what these will actually allow you to do is to you don't even have to set up your own Kubernetes cluster. It's set up for you. Cilium is installed and it'll walk you through the different features. So

• 56:07Speaker 02

  basic one is like, okay, how do we install Cilium? And it'll walk you through that. The next one is okay, like I, I need to do network policy. How does Cilium network policy work? And there's a really famous Star Wars demo. It's like, how do we blow up the Death Star? Or how do we protect the Death Star? So it's like a fun lab. And it's different, like hands on labs, you're actually in Kubernetes cluster and walking you through these different features, how they work and how do you actually apply them to your cluster? Yeah. So those are all great sources. Obviously, there's always GitHub. We have a Slack channel if you want to jump in there too. But I would recommend if you want to like get hands on with Cilium, go to the labs. I know I like to actually be in a cluster and be able to do things or you know, just like read through some of the stuff. And then there's also the documentation pages there too.

• 56:49Speaker 01

  Awesome. Sounds pretty fully featured on that front. So yeah, cool. Well, Bill, awesome to have you on today. Thanks a lot for coming on. As we were talking about before recording, you've been doing a lot of traveling, so you've managed to find a slot on that schedule for this. So that's really appreciated. And no doubt we'll be following along and maybe catch up again in a couple of years or something.

• 57:12Speaker 02

  Yeah, that'd be great.

• 57:13Speaker 01

  All right. Thanks a lot.

• 57:14Speaker 02

  Yeah, thanks for having me.