 Hi everybody, I'm Yuri, I'm creator of Kubernetes global balancing projects that I want to talk about today and What is KGB it is open source projects that is Targeted to solve interesting challenge of global traffic management So it basically makes your applications Globally available and resilient in a situation when you were dealing with a multi cluster Scenario when your Kubernetes clusters are deployed in a geographically dispersed manner so it can be multiple data centers multiple regions So highly distributed environment the main differentiators of the projects of the pro KGB project is that it's Kubernetes native So it's exposed as a gsob crd to control quite challenging global traffic management configuration There is no single point of failure because there is no need for management cluster. So you would deploy KGB next to your workloads We are using DNS protocol that is battle-tested. It's running the internet and Whole setup is distributed by design. We're supporting multiple load-bouncing Strategies like failover, run, robin and geo proximity The whole solution is designed to Solve high impact regional failures and why it is gsob global service load-bouncing solution It's also has a new property of figuring out what is actually happening on your cluster down to the pod status pod scale check granularity So roughly how it works We have A canonical example of KGB setup. We have two clusters deployed in a two different regions region A region B And it can be different data centers. It can be different cloud regions like AWS US Europe or any cloud provider and even hybrid mode whatever environment you need to target KGB is getting installed next to the workloads. So to your workload clusters and I guess there with the main orchestration KGB controller it also Ships within itself for two important components. It's external DNS and core DNS That is dedicated core DNS deployment not related to the standard Kubernetes one What external DNS integration is doing it that automatically configures the zone delegation in your Environment DNS provider so it can be routed to three Azure public DNS and Someone prep solutions cloudflare anything after the zone delegation is configured the DNS Request from the client is going to be automatically forwarded to the core DNS instances that are controlled by a KGB and this core DNS instances are going to response with dynamically crafted DNS responses according to to GSLB strategy and your application health status and last but not least KGB is also continuously monitoring your Associated application status through the ingress and service and pointer rate transitively. So this way KGB can steer The traffic in a global manner to the healthy application So in standard the most straightforward scenario you would have a failover strategy in a and you will pin geographical Tech to region cluster in region a and assuming application is filling there is a KGB will steer the traffic to the healthy cluster whenever The applications getting recovered on our original cluster is it will serve it back so and clusters are Thinking and cross pulling each other. So they are always aware of the status on the neighbor cluster of the status of this Associated application. So basically you can do very interesting global traffic steering failovers one scenario You can do a round robin and also more complex Geographical proximity stuff. So this is quite amount of moving parts controllers Etc. And luckily All these complexity is abstracted away with a single GSLB CRD As you can see the example we have a embedded ingress back there So it's really in great embedded ingress type and highlighted on the slides is a strategy stanza That's exactly the parameters that are controlling global load balancing strategy If you have a bunch of ingresses flying around in your home charts you can use an annotation since that and basically it will ease KGB just will be adoption you can enable the global load balancing for your application just to buy by setting an annotation on a standard ingress and KGB will pick it up and create a CRD for you CR for you the GSLB one. So As I mentioned it can be KGB can operate in virtually any Environment can on-prem cloud hybrid scenario. It's enough to have a KGB It is enough to have a Kubernetes conform at Kubernetes cluster And some form of DNS server Where you can basically configure the zone delegation and for a set of providers we we have this fully automated zone delegation Scenario and here is the list where we have a like a nicely tested set of the environment where you can just plug it in and It will work out of the box. Otherwise It will work with any DNS scenario and the new providers are easy to add Because we are building not from scratch, but we are we are using external DNS community and the set of providers The current project state of CNCF sandbox I plan to apply for and keep it in waiting Level this year. Let's see how it goes. We have a three companies who are Public other earth surrounding KGB in production Via the project via two times on a final list of very nice event CNCF security slam that enabled us to Heavily enhance security posture of the project highly related to that point. We have a Highest CLO monitor score on all the all the metrics We have a diverse set of maintainers up to where it was originally created upbound and catify And we have also very nice set of contributors including millennium bcp Who also both adopters and contributors and recently folks from Petra joint and send some PRs and participated in discussions? So, thank you so much To learn more, please visit website to try KGB locally And in your environment join slack starts in github add yourself to adopters if you're using it And last but not least please join our first ever KGB Contribute us it contributes this Friday at 11 the morning. Thank you so much