 Hi everybody. I'm Yuri. I work as principal engineer for Apsa Group and let's chat about crossplane and how it helped us to scale our Kubernetes global load balancer. So quickly about the crossplane setup in Apsa. Apsa is a huge financial organization that serves multiple countries in an Africa continent and we have a pretty reasonable scale and we are operating over a hybrid setup part of the workload on-prem and part of the my AWS. Crossplane instances are currently deployed within our on-prem data centers and Kubernetes clusters. We are using a set of crossplane providers, main ones AWS and Helm, and we use our special summit operators that we developed to automatically propagate credentials as Kubernetes secrets in an automated way. We use crossplane composite resource model and associated composite resource definitions to create our very own platform and provide an abstracted resources to our technical customers. So main XRDs, composite resource definitions that we operate as a moment, are a three bucket to provide a specially configured data storage, object storage, PostgreSQL instance, ECS clusters and KAGB for global load balancing. So we mostly focus on a KAGB part today. Meanwhile the principles of crossplane-based compositions are shared between these resources. So what is KAGB? It is a open source project that we developed in Apsa. It is a cloud native global Kubernetes global balancer. It is a Kubernetes native and it enables global service load balancing function for workloads that are deployed on top of Kubernetes clusters, typically in geographically dispersed data centers or different cloud regions, like different AWS regions is a common reference setup. One of the distinction points of a KAGB project is the absence of a single point of failure. So we do not have any control clusters and no instance where traffic is going through. So there is no single bottleneck and the system is architected and the way to be really reliable at a global scale and it is all based on a DNS protocol that is battle tested by internet and is a good match for global load balancing traffic steering. We faced obvious KAGB deployment challenges because we operate on more than 120 Kubernetes clusters and this number continuously growing. And there is an obvious challenge of repetitive helm configuration where we, given we are packaging KAGB as a helm chart, we're providing flexible enough configuration parameters to enable customization of every part of a KAGB as a distributed system. Meanwhile, our special specific setup is relatively stable. So we need to parameterize not all of them but a minimum amount. And that's how cross-plane helps its abstracted resources. So here is an example of a cross-plane composite resource plane which provides an interface for end-users, a little technical customers or whatever services or human interfaces with a Kubernetes API. We're exposing just five configuration endpoints to drive the KAGB installation of multiple clusters. So it provides very effective abstraction, a very minimal configuration, only required params are getting exposed and you decide what kind of these params are with the help of cross-plane abstraction power. This setup is very good for GitOps. So we can easily automate the application of this XRC manifest with tools like Argo CD or Flux. And we don't need any client-site implanting like a Customized with K because the XRC yamls are very minimalistic and we can just drop them into GitOps repo and let Argo or Flux apply it to the target clusters. So let's perform a very quick demo and demonstration how it all works. So we already have a couple of clusters where cross-plane is already deployed. We have an empty KAGB name space which we will use to deploy KAGB installation. Let's quickly look how XRDs are composed. So we have a package that's a starter XRD definition. So it's a compositor research definition and that's how we expose the required parameters. It is an open IPA history schema and the heavy lifting is done in a composition where we actually provide the default parameters and then patching them from XRD down to the specific resource instantiation. We have examples, resource claims. So let's be the European one. So that's exactly this minimalistic abstraction that was demonstrated in the slides. So let's create a KAGB installation where it's tagged this EUS 1 and it's going to talk by configuration with Africa. So it is as easy as applied with KubeControl and we can check the status of abstracted resource with the standard KubeControl commands. It's not yet ready. Meanwhile, we can check and demonstrate that it is under the hood of the standard health facility thanks to cross-plane provider health. We can check abstracted resource again. It should be already ready and it's true and we can quickly check the ports of the service evaporate and let's quickly describe this port and double check that the environment variables were properly propagated down to the port configuration. And here we go, cluster geotech as expected, labeled as Europe. We can do the same same application of resource in another cluster in another data center. The only difference is in this specific instantiation is it's totally the same. It just the geotechs are flipped because this cluster resize is another geographic location. So we can quickly check the ports there. It should be already ready and let's make the same and double check as in another cluster. Here we go. So we have a properly configured system in both of clusters in both data centers and that's how we minimize the setup and make it very concise and declarative. To dive into this cross-plane composition concept, you can visit a very good official documentation which describes composition in a very practical way. There is a very nice video of a core cross-plane developer providing you ideas of cross-plane composition to be used to build your own cloud platform. That's pretty much what we do in Xenopsa. KGBI official website for Kubernetes global balancer in case you're interested in this topic, please visit it and visit our GitHub repo and provide feedback and you can grab these slides right in sketch so you can click all these links and follow through. So thank you so much. That was an example of how we using cross-plane and in-substruction power to scale a distributed system as an example KGB and you can use the same approach to scale and compose your own unique platform instructions on top of Kubernetes. Thank you so much for watching and have a great rest of the conference. Goodbye.