 Hello everyone, thank you for joining this session. My name is Victor Valze, I'm in Calida, Adobe. And today I'm going to talk about five essential insights of why we are running Cilium as a CNI for a multi-tenant Kubernetes-based architecture. If you are about me, I'm a part of the developer productivity organization at Adobe which strives to help our customers, the developers, to write better software even faster. I'm one of the organizers of KCD Romania, which will be the first in-person KCD event in the southeast of Europe and which is going to happen next month. At Adobe, developer run their applications on a runtime platform named ethos, which is a multi-tenant Kubernetes-based platform. In terms of scalability, the platform operates at three main cloud providers and hosts more than one million pods which are running in 42,000 Kubernetes namespaces, namespaces which are owned by application development teams. The multi-tenancy approach at Adobe is very simple. We are using multi-tenancy architecture as a way to share multiple physical clusters with multiple teams from different organization and different projects. And we rely on Kubernetes namespaces and couple of Kubernetes primitives in order to provide a minimum isolation within the cluster. For this, we are using the concept of namespace profile template, which is made of few Kubernetes objects, such as Kubernetes namespace, roll binding, COTA, limit range, network policies, and selium network policies. And the reason that we are using selium network policies is because by default, we need some DNS-based policies and other layers of policies. But let's see why we choose selium as the CNI for this multi-tenant platform. We are running millions of pods and every time there is an issue with an application, the first thing that is blamed by the tenants is networking. Yes, but it's always the networking. For the most cases, no. From my experience doing on-call on the platform, when someone has an application issue like network latency, it's actually because of the CPU throttling. But you must have a reliable CNI because networking is one of the most important aspects of running applications on Kubernetes. We can build the best app in the world with the best features, but if it's not connected to the internet, it doesn't exist. When any team is on boarded to Hito's platform, they often ask, hey guys, we need to handle million or billion of requests. Is your networking fast enough? And the answer is yes, because selium does a great job in terms of performance by leveraging EBPF and because we don't need any more cube proxy with 1000 of IP tables rules. Another common question that we receive is, what if my neighbor in the same cluster is compromised? Here I would like to mention that Hito's platform is CCF certified. CCF stands for Common Controls Framework, which is an open foundational framework of security processes developed by Adobe. And it helped us to comply with a number of industry best practices, standards, regulations and certifications. So network security is also an important aspect in multi-tenancy. We are using selium to implement the network isolation from level three to level seven protocols, selective policies to enable east-west communication and XDP filtering of embargoed country IPs. But sometimes a connection between two applications doesn't work at all. And then it's asked, why are my connections not working? The answer is Hubble Observe. Hubble is a great observability tool for debugging your application's networking. And you can see very easy what is actually blocking your connections. But what if the tenants have other questions? Where should they go? The answer is very simple. Selium is an open source CNI with a great community around it. So if you have any questions or issues, you can always ask the community on GitHub on Slack or at the conferences. Thank you so much.