 Hi everyone, my name is Alex Lee. Today I'll be talking about GitOps and controllers. Title is, it's not that simple for a multi-cluster and I'll be going through why, some value points today on what, where to use and what the value points between using GitOps and when to kind of match that with controllers. So, yeah, like I said, my name's Alex Lee. I'm a field engineer based at San Francisco at Solo. It's a pleasure to be here in Valencia. So, I think you've heard it all from a lot of people today that the GitOps, or the SEO approach to single cluster deployment is pretty simple. It's easy to manage a few microservices and get started with a single cluster. However, when you move to multi-cluster, it starts to require some context, right? So, you start have to focusing on your team, your networking team. How do I define your traffic or engineering policy intent and how do we effectively translate this intent into policy or configuration at scale? And this gets a lot more complicated as you move to more clusters. In this picture, it's just three, but, you know, we have some customers that run tens if not hundreds of clusters. So, one question I like to kind of talk to my customers about is, when you're going through these slides, think about who is the control plane, right? So, in this slide right here, we're kind of doing multi-cluster manually, right? And my networking admin team needs to focus on the stuff to the left of the network admin icon here, service routing, traffic processing, MTLS, rate limiting, ExAuth, all these API gateway features as well as service mesh features. On top of that, they need to kind of focus on the intent, right, the high-level policy intent and their tasks, which is, in this case, defining the high-level policy, translating those into the Istio resources, validating the expected behavior, committing it to Git, deploying and managing all these on each cluster ad hoc, maintaining control and drift of all these YAML manifests in Istio and managing this at scale. You know, it starts to see, yeah, as you can start to see, this becomes kind of a burden on that networking admin team. So, you know, what's the natural place is, the next step here is GitOps. GitOps is a great place to start. And as we start to leverage GitOps with the GitOps controller, you start to see some of those tasks that I was talking about that that networking admin team had to focus on, start to shift down into the controller, right? So now, with GitOps, I can actually allow software to manage or manage maintaining the control and drift of my YAML manifests. And then I can also start to kind of, you know, manage this at scale more effectively because I have this all declared in Git and my GitOps controller is deploying these and managing them on my clusters. However, you still see kind of focus, the networking admin, they still have to kind of focus on a lot of tasks, defining and translating those Istio resources can become a burden and managing that at scale, ad hoc is still pretty complicated. So, you know, here we start to introduce in the mix a controller mapped with GitOps. So this can be a control plane that's based off of an operator, a SAS or, you know, or just a Kubernetes controller. And you start to see some of those tasks actually shift away from the networking admin team, allowing them to focus primarily on, you know, defining that high level policy intent for their business use case, validating the expected behavior and committing that to Git. The GitOps controller continues to maintain and control the drift of those CRDs instead of direct YAML manifests. And then this allows GitOps controller and manage, you know, allow them GitOps to do what it does best, which is managing at scale, many apps and many clusters. However, we start to focus some of that, you know, those tasks that the networking admin team shift down to automation again, right, with the control plane. So we allow the control plane to translate Istio resources for us, provided that we have a simple to use API at the high level. We also allow that control plane map with GitOps here to deploy and manage each cluster as defined in our CRDs. And, you know, the GitOps and control plane here, married together, allow us to really, truly manage this at scale. So here's a couple of kind of examples of, you know, where the controller value here comes into play. One of the key pieces is the usage of labels and label selectors. So you see on the left, it's really more of kind of a manual approach to this. So I want to kind of, you know, provide ingress to an application on, and I have five clusters, cluster one, two, three, have applications, but I only want to expose my app, apps on cluster one and two. My networking admin team here needs to understand this context, understand that they need to create those Istio resources, the gateway and virtual service, and place them on cluster one and cluster two. And imagine this if you had, you know, tens or hundreds of clusters, right? So on the right, when you shift this to a, to the use of a controller, you can actually start to leverage labels and label selectors similar to how we do in Kubernetes. At the top here, you have a workload selector selecting by the label ingress is true. And then on each cluster, you would have a label ingress is true. And therefore the control plan can auto discover as we scale from, you know, tens to hundreds of clusters, automatically know that, hey, I need to deploy this gateway or virtual service there. And it no longer is a task of that admin networking admin group or team to manage that, you know, cumbersome task. So how we can expand that label and label selection idea here, really start to take this to policy and other things that are in the mesh. For example, in this diagram, we have our WAF policy. You can only, you can just create it once rather than having to kind of codify it into an envoy filter and deploy it in GitOps. Here I can just create the WAF policy, the control plan will now know to look for a label. WAF is true on the cluster and deploy that WAF policy to the clusters that need be. I can take and expand this label selection and poly uniform policy concept to many other pieces of the mesh, such as rate limiting, authentication, fault injections, failovers and transformations. And you can start to see how, you know, I hope you can start to see how the GitOps approach along with controllers can provide a lot of value to managing Istio at scale. Thanks everyone.