 Hello, hello, and welcome, everyone. Welcome to Cloud Native Live, where we dive into the code behind Cloud Native. I'm Taylor D'Olazal, head of ecosystem at the CNCF, where I work closely with teams as they navigate their Cloud Native journeys. Every week, we bring a new set of presenters to showcase how to work with Cloud Native technologies. They'll build things, they will break things, and they will answer your questions. In today's session, Alara Ozturk has joined us to talk about using Calico, EBPF, Linux, Windows, on Azure and AKS. This is an official live stream of the CNCF, and as such is subject to the CNCF Code of Conduct. Please don't add anything to the chat or voice any questions that would be in violation of that Code of Conduct. Basically, please be respectful to one another, and let's have a fantastic session today. With that, I'd like to turn it over to Alara to kick off today's presentation. Alara, please take it away. Welcome. Thank you, thank you. I think there was a small confusion. So Alara is our, I'm Geary, rather Christian, by the way. I thought she was gonna join the meeting. She works for, she's in a different team and she manages all these meetings. Sorry about the confusion. So yeah, my name is Geary Radha Krishnan. I'm a Product Marketing Manager at Tigera, and I'll be presenting today. Let me start sharing my screen first. Let me know. All right, you can see my screen. What's going on? So I'm excited to present this today. So I'll talk about Calico, CNI for Azure AKS and also a little bit about Calico's eBPF data plane. And Microsoft recently announced, bring your own CNI program. And we jumped on this opportunity to have Calico be supported on AKS clusters. So I'll go through the benefits and use cases why someone would want to use Calico CNI on Azure. Just talk about some of the use cases that we've noticed and we've seen and also some of the benefits. Before I start, just wanted to talk about Project Calico a little bit. So it's an active community for cloud networking and security. If you're not familiar with Calico, it's an open source CNI that's available to use on communities and other cloud-native platforms. So there are links to different projects here, Project Calico and then the GitHub link and links for the Slack channel. So there are about 6,000 active members in our Slack channel and we have an active community of around 150 contributors. And in the next slide, I'll show you the depth and distribution of Calico. So feel free to join this community. So we would be excited to have you on our Slack channels where you can discuss with other members about just troubleshooting or any Q&A that you have. So as you can see, it's one of the most widely adopted CNI and security solutions for communities. We are powering more than two million nodes across 166 countries and we've noticed that there's been a billion plus talker pools for Calico and it powers about 500,000 clusters across these, across 50,000 enterprises. So Calico also gives you a choice of data planes. We've designed it in a way that it's a pluggable data plane model and Calico supports standard Linux, it supports EBPF and also the Windows host network services or HNS. We support both on-prem or public clouds. It could be on a single node, it could be across a thousand node cluster. So whether you want to scale to thousands of microservices with EBPF or if you want to add Windows workloads to your communities deployment, Calico has you covered. The core design principles of Calico, we leverage best practices of cloud native design patterns and combined with standards-based network protocols which is trusted by the largest internet carriers. So what you get is exceptional scalability and running at scale in some of the largest communities deployment enterprises. So Calico works across all major communities distributions whether it's OpenShift, Rancher, Mirantis on-prem or some of the managed community services like Azure or Amazon's EKS or GKE. It also works on hybrid platforms. We've noticed some of our people that we talked to they've used AWS Outposts or even Anthos for their hybrid deployments. And as I mentioned, it works in a plug-able data plane model. We support EBPF, Linux and Windows and two types of containers at the moment, Linux and Windows. Let me start by talking a little bit about Calico's EBPF data plane. So today Calico offers four data plane models which is data plane types, standard Linux with IP tables, Windows HNS, EBPF and VPP. I'm assuming most of you would know the advantages of EBPF or what EBPF can do. So to put it really simple words, it's just like a in kernel virtual machine that gives superpowers to your Linux programs. So what it does is you can attach mini programs to low level hooks in the kernel and this gives you the ability to do advanced networking and security functions within your software. So some of the key benefits that I want to show you of using EBPF is performance. That's the highest possible benefit that you will get. And the second is native Kubernetes service handling. And the third benefit is source IP preservation and direct server return or DSR. So each benefit here will be significant and it's worth discussing further. So let's do that now. When you talk about performance, so we did a performance throughput measurement using CUBEF and used a pair of pods running on different nodes. I want to just give you a few details on how this test was performed. So on the left, you see that it was, the MTU was 1440 and on the right, you see the MTU is 8940. And basically MTU is the maximum packet size and 1500 is the realistic number for internet traffic and 9K is typically called a jumbo frame and used within some data centers. What we've done is reduced it by 60 to be conservative just in case you're running it on top of some overlay network. And we measured both CPU usage and throughput. I'll just talk about throughput now. And you can see that with 8940 MTU, both options come close to saturating the 14 gig link. So one more thing I forgot to mention was we used a 40 gig link to test this throughput. So at the smaller packet size, we see a gap in throughput up here. So Kubehp generally limits itself to a single core, which makes it a really good tool for seeing how much traffic can be pushed by any application with a limited amount of CPU. But a caveat here is that not to misinterpret this data as the throughput limit for the node rather than for a single instance of Kubehp. So if you had more CPU multi-threaded application and ran more pod instances, you could saturate the 40 gig link theory to you. And if you've not noticed yet, the red is with EBBF and the blue is with standard and max networking. And you can see that the throughput is definitely higher with the EBBF. The second benefit is native Kubernetes service handling. So originally Calico's EBBF data plane wasn't planned to replace Kubehp proxy, but ultimately it did and we'll see why. So as a general philosophy, maintaining compatibility with upstream Kubernetes components when possible is usually beneficial. But as we started developing Calico, we found that the optimum EBBF design for Calico's feature wouldn't work with existing Kubehp proxy without increasing the complexity and reduction in performance. So once we started getting close to replacing Kubehp proxy, we decided how we could improve on the upstream implementation by natively handling Kubernetes services within Calico data plane. So in the next slide, you can see that we've achieved reduced latency. So Kubehp proxy's implementation, it uses a list of rules that grows with the number of services. So latency gets worse as the number of services increase. Both IPvS mode and our implementation, it uses an efficient map lookup instead, resulting in a flat performance. You can see that EBBF is way below compared to IP tables and IPvS. That means it's faster with a TCP connect time test. The next benefit, the last benefit I'm gonna talk about is source IP preservation and direct server return. The data path through a cluster with the EBBF data plane enabled is much more simplified. It can be best understood with visuals. So I'll move on to the next slide and show you very quickly. I'm not gonna go into details of this slide where it shows a difference between Kubehp proxy, which is non-EBBF and with Calico EBBF, how there is benefit for users to go with the EBBF design. So very quickly on a high level, what you can see is that with EBBF, you can actually save the source IP of the host external client. So what you see on top of the image of both the images is external client and assume that this is a human user or a computer outside the cluster. And the bottom row is the external client and the bottom you can see two nodes, communities cluster nodes in blue. And the external client connects to a service load balancer to one of the cluster nodes. So in both the cases, it hits the load balancer, but what happens next is what differentiates between non-EBBF setup and then EBBF implementation. And the other advantage is depending on how your network is set up, if you set it up in a way that it supports static server return, it considerably reduces the latency, at least by half, so that it doesn't have to go through the first node, the first part that traffic hits from the external client and it directly goes back to the client. Without the need to routing it through additional points. I will move on to the main topic for today, main agenda for today, which is Azure AKS with bring your own CNI. So as I mentioned, Microsoft recently announced a BYO CNI program. Prior to this, there were two options. I think the default was a KubeNet and also the option of using Azure CNI for AKS clusters. So you can actually configure network interfaces, manage connections and provide all the IPAM functionalities with Azure CNI and IPAM or KubeNet on AKS clusters. But Calico's responsibility was to just insert hooks for network policies and also maybe do encryption and few other features. So CNI, if some of you are not familiar is basically providing a network interface and it's the brains behind cluster interconnection or communication between pods. And what IPAM does is it's IP address management and it assigns, simply assigns IP addresses for all the pods in the cluster. So now with the recent announcement, you can actually choose an option CNI equal to none. I'll show you in a bit in the next slides how this is done. So what you can do is actually choose a no CNI option and install Calico to use as a choice for CNI and IPAM. It's a simpler approach and what it does is it provides fine-grained dynamic IP address management. And I'll also explain why this could be beneficial instead of using the Azure CNI or KubeNet. So this is how you enable the Calico CNI, bring your own CNI preview plugin. It's documented by Microsoft and on Calico documents talks. So our pages are updated to show you how you can run Calico with AKS. So this is actually a preview feature and it's provided as is and the recommendation is to not directly use it in production. So word of caution there. I'm not sure if you can see the screenshot with all the details in it, but it's just a sample screenshot of how you can create a group within the cluster in a specific location. Here it is Northern Europe with type as Microsoft resource groups. And you can actually reference the resource group where you can create the VMs, the number of VMs and other feature flags. And you can notice that hyphen network plugin option is set to none. And on the next slide, once you do a get node, you see that the status is not ready. On the top, if you see the cubicle get nodes hyphen A, you see that it's not ready because there is no CNI running. The pod status will be impending because DNS is not going to work in the scenario until the CNI is up. There was one question that came in asking, when might this be out of tech preview? I'm hoping in three months or within six months. I'm not guaranteeing that, but that's my guess. But if you really want to know, I mean, you could get back in a couple of weeks to, or send us a message on Slack to find out. But that's my guess. Cool, thank you, thank you. Yeah, so the next screenshot I'll be, I can show you how the operator based install for Calico works. So we see that it's still not ready here in this screen. And now, you can see that it's running. All the pods are running and cubicle get nodes shows that everything is ready and running. Few more things to note here. Right now the implementation with AKS supports only VXLAN. Calico usually supports IP or NBGP, but in AKS at the moment, we support only VXLAN as the encapsulation methodology. You can see that the API server, can't quickly look at that, but you can see it waits until the CNI is running. And once you get a cubicle get pods, you can see most of the Calico system pods, actually all the pods running here. So what it means is that all the relevant components for Calico is installed on each node. So Calico was initially designed for standard Linux. So what this picture represents is that we've gone beyond just that and Calico as a project extends to, started extending to other data planes. And what we've noticed that EVPF has garnered a lot of attention recently. And as we saw in the first few slides, it allows you to write kernel level hooks for observability and security. Observability is the buzzword right now. Everyone wants to look at what's going on within your cluster node and your complete infrastructure. And not just that, it also gives you performance gains and scalability. So if you're working with an EVPF data plane in AKS, Calico is available now, you can use it there. And of course, it's in preview stage currently. So the word of caution, do not use it in production environments. And another thing to note that is Calico also supports Windows workloads. So there are some links here. Note that on Azure HITCI, Calico is the default option right now for CNIs, but there are a couple of links here for how to use Calico in the VXLAN mode and in both self-managed and managed AKS clusters. So let's move on to some use cases and fits with Calico on AKS. Why are we talking about Calico? Someone need Calico on AKS. So you could use, Kubernetes, native Kubernetes services, you can use network policies, but what you get beyond that is all the capabilities of Calico network policy. I'll show you three major benefits in the next few slides, but you could take full advantage of all the advanced features that Calico provides by going beyond the Azure CNI or the Kubernetes CNIs. So the first benefit that we talk about is you can dynamically grow and shrink your IP into space, your side is. So let's say you're migrating pods from one IP pool to another. How do you do this without network disruption? So we have documented steps. So for all these benefits, there are steps on how you do, I would call these features and you could actually go to Project Calico docs and see how this is done. It's a simple five-step process of adding and disabling new and old IP pools, removing it from the pod and adding it to the pod. It's as simple as five steps and the use case is that you can actually migrate pods from one pool to another without network disruption. So I believe this cannot be done without Calico. So, and I'm sure folks will benefit from a feature like this. The other benefit is floating IPs. So, Kubernetes services, just to refresh, it's an abstract way to expose an application according to the Kubernetes document. That's what Kubernetes services mean. So it's very similar to that and what you can do with floating IPs is that it can front a workload and depending on how these workloads move around the cluster, you can actually use the same IPs for the workloads. So for Kubernetes services, the host uses a NAT for incoming traffic. So to change the floating IP to the workloads real IP before delivering packets to the workload, you could use this feature. And another advantage of using floating IPs with Calico is that it doesn't work only with TCP, UDP, or SCDP, it works on all network protocols. And the other use case is when you're operating with legacy firewalls, you still need some of the, what we typically call, not-south traffic perimeter firewalls. And if you want to integrate those firewalls with your cloud native applications, what we can do is create an IP pool for the entire Kubernetes pod slider. But you can also break it up into smaller pods and change the IP pool. So you can actually control which pool Calico uses for each pod using node selectors. You can also use annotations on the pod or even the pod's namespace for IP address assignment. You could also restrict a pod to use an IP address range or you can restrict all pods within a particular namespace to use an IP address range. And again, the documentation for this particular feature or functionality is also shown in this slide. I'm not sure how many of you have seen this table. So what it shows is, this is a benchmark study done by an independent person, Alex. But I forgot where it was published. I think it was itinex.io. But what it shows is how Calico compares to the other CNIs in the market, especially when you look at encryption, which Calico offers through WireGuard, you can see that it's a clear winner there. And it's also excelling in all the other categories. But since the publication of this benchmark, what we've done is for MTUs, we've further strengthened and offer automated MTU configuration. So you can actually automatically determine the best MTU, Calico will determine the best MTU for new pods based on the underlying network MTU and enabled encapsulation methods. So what it does is it provides a not optimal network performance without any need for manual configuration. A lot of text on this slide, but just a quick overview is that you can configure MTU to maximize network performance. So based on your underlying network, you can either decrease or increase your MTU for optimal performance, but by default, Calico can auto-detect and use the correct MTU for your cluster based on node configurations. So with that, it brings me to the end of the presentation. So if you have more questions, I would be here. I did see one question in terms of asking about EVPF deployments, didn't know if you either know of a demo or might have something on that front. Any good resources? Unfortunately, I would, I'm not going to demo that. My technical counterpart would have done that if he or she was available. I'm not sure who was supposed to demo it today. I'm not very technical savvy to demo it, but I don't know if Alara is going to work with you for future talks and someone can come and demo the EVPF solution there. Sorry about that. Absolutely, no worries, no worries. Thank you for that question. I think one other question that I had was if you've learned any interesting lessons while working with workloads or anything that you've heard from people that have Linux and Windows workloads together. That's seemed to be an interesting area for conversation as well as context and running those workflows. Good question, interesting question, but unfortunately, I don't think I have the, I've not spent enough time here to talk about Windows workloads. As far as I know, I think most of the conversations that I've had with folks here at Tigera, Linux, or EVPF, so I cannot speak much for Windows workloads at the moment. Gotcha, gotcha, no worries. Thank you, thank you. We do have a question here from Adrian asking, are you planning to add Kubernetes multi-cluster capabilities in the open source version? Multi-cluster capabilities. I don't see anything in the roadmap at the moment, but I'll definitely take it back to the team and find out. So will these questions be available for me to, is it saved anywhere? Yeah, yeah, absolutely, I can get these to you. Okay, yeah, I'll definitely get back with the right answer after talking to the engineering team, yeah. Absolutely, thank you, thank you, Adrian. Thank you all for asking so many questions, it's fantastic. And I apologize, I think the person who was supposed to give this talk was much more technical, but since they were not available, I had to do the presentation, but I'm sorry, I'm not able to answer most of the questions today. We can get you synced up, eventual consistency, we'll get you in touch with the right person. Sure, yeah. The next question that we had come up was from James saying, is it possible to get an external IP address with Calico on a self-managed Kubernetes cluster in an Azure VM instance? So you can get an external IP address, if the question means that will a static IP address work? So there is a functionality called egress gateway that we use, so I'm assuming that's what the question means. So yes, with again, a caveat that I'm not 100% technical on this, so don't assume what I'm saying is right, but yes is my answer at the moment. Cool, excellent, excellent, excellent. Thank you very much. Our next question is, what is the name of the tool used to test network stack performance? It was Kupo. Gotcha. Yeah. And how do you spell that? I can post that to the chat. Q, just Q and P-E-R-F. P-E-R-F is the name of the tool. Passet work performance. Thank you very much. All right, awesome. It looks like that, those are all of the questions that I have so far. Again, if you all have any more, please feel free to throw them into the chat and we can get everything synced up. I did see a question earlier too, asking if the slides or those links are going to be available at any point in time. I can always publish them to this video afterwards if they're open, otherwise I could sync up with you on any links that might be good to put into the video description. Okay. I think I forgot to mention one more thing. So there's actually an Azure course for you can become a certified Calico operator for Azure. You can find the links here. I'm sure if you share the slides, they can definitely get it. And there's also a Calico BigCats ambassador program for which I have a link here too. So I just wanted to share that. To the chat. At least the Azure course. Awesome. Awesome, awesome. Wonderful. Again, feel free to throw any questions you might have into the chat. We can get those answered here. Otherwise we can give you, ah, yes, Q perf very much. Otherwise we can close things up and give you a few minutes back. Okay, we do have one more question. Is it also supported or plans in support for AWS or GCP? Yeah, yeah, definitely. So I think Azure was the only platform which was not supported, but AWS and GCP were always supported for Calico. You could, so if you go to the docs, you can see how you can install Calico on AWS or GCP. Excellent, awesome. Yeah, I do remember the early days of Calico. I think I got to see some presenters on that front, like working with the canal project and like so many others. I think it was like back in the early times of, ah, what was that? It was a core OS, I think there was like a core OS summit and it was really interesting back then. It's amazing to see how far the project is coming. Are there any things that you're particularly excited about that are going to be coming out here in the future or just any kind of thoughts or comments on the direction of the project? I think EBPF is the most exciting. I see a lot of, you know, even enterprise customers starting to use EBPF and talking about EBPF. So I think that's going to be interesting to see how it pans out. Absolutely agree. Yeah. Awesome. Well, I don't see any more questions that have come in. So with that, I would like to thank y'all for joining us today. It was great to see you all here at the latest episode of Cloud Native Live. Great to learn from Geary. We really enjoyed the interaction and questions from the audience. All of you have the best questions and thank y'all for coming and asking those. It's always great to see it, to chat with you as well. Thank you so much for joining us today. We do hope to see you again soon. Again, thank you so much Geary for coming and being able to talk about EBPF, Calico and everything else on AKS. And we definitely hope to see you around the community. Thank y'all so much. My pleasure. Thank you. Thank you all. See everybody. Bye.