 for the next session. So quick intro about Tamil manan. He's a cloud native tech lead at Arsissium and a former Kubernetes SME at VMware. Yeah. Thank you, Tamil man. Hey, hi. Hello. Vanakkam everyone. The lunch was really good. Hope everybody is not sleeping. Is anybody sleeping here? If yes, please check the Kubernetes Pish which is shared by KCD Chennai. It was really useful. It helps me to think on the feet. So take a moment to check the quiz. So today I'm going to talk about constructing a heterogeneous or remote Kubernetes control plane using connectivity. So before we get into the session, just a bit of introduction about myself. I'm Tamil manan. I'm working as a tech lead at Arsissium. My hobbies are playing batman. So I even bought the batman kit to KCD Chennai because I was traveling from Bangalore. So I thought I can play with my friends over here. So let's get into the session. So this is a quick overview of what we are going to cover for next 15 minutes. So I'm just going to talk about why we need to consider about remote control plane and what are the potential use cases for remote control plane and what are the building blocks and how things make this happen. So hope everybody is known to this slide either while preparing for CKA or your interviews. Definitely you have gone through this slide, this picture. So basically I was just trying to give a bit introduction about how the communication between the control plane and the worker plane will work here so that that will set the tone for rest of the slide. So basically we'll first bring up the control plane nodes and then the worker nodes will register to the control plane. Basically it's a hub and spoke model. So the worker's node will register itself. So whenever you use kubectl commands like kubectl get nodes, you'll get the status of the node whether the node was in ready state or pending state. So basically your worker node talks to the control plane. So the worker plane, worker node has a health probe and it sends the status to your control plane for every 30 seconds by talking to the API server. And we all know our API server should be reachable. And similarly the API server can reach to your kubelet API. So kubelet has also an API server running. So whenever node selector selects a particular node for running your pod, your API server will send the pod spec to your kubelet to spin up the pod in that particular node. And similarly whenever you use kubectl exe command or kubectl log command, so basically the user request goes to the API server and API server will talk to your kubelet API. So what I'm trying to say here is like the communication between the control plane and worker node is bi-directional and it requires a fast and reliable communication as well. So when you are within a same data center, basically within a in a general purpose use case, your control plane and your worker node will be in the same data center, which means it will be in the same L2, L3 domain. So the control plane can able to reach the worker nodes and worker node can also reach the control plane. So it works out of the box. But these are the few use cases like Kubernetes at edge. For example, running a Kubernetes for Internet of Things or autonomous vehicle or you have a telecom use case like 5G where your RAN network is running on edge devices. So for those use cases, right, you don't have a luxury of running your control plane and data plane in the edge premises. In those cases, your control plane will be mostly running in your cloud or your on-perman. You only have your worker nodes running in your edge premises. And similarly, in case of hybrid cloud where there are chances like you want to explore multiple cloud vendors, so you have started using with one cloud vendor and then you want to move to migrate to other cloud vendors. So you can spin up the worker nodes in other cloud platform so that you can have the control plane in one cloud provider. So the other use case is about co-located control plane, which is similar to the other talk like what Francis have talked earlier about like open cluster management. So to manage for multi-cluster management, so usually what you have, you have a control plane, which will be a control plane cluster where you run all your control planes. And you have worker nodes or clusters which basically tenant aligns. So basically, the tenant might be any user who runs in on-perm or cloud. So you basically spin up the worker nodes in that tenant-specified account or the VPC or cloud. And for ease of use, the SaaS provider might be running the control plane in their premises. So in this case also, you require a remote control plane sort of thing. So basically, this is a use case where you can easily manage the clusters, multiple clusters and give a cluster as a service if you want to provide. This is how typically any multi-cluster management system will work here actually. So whatever use cases which we have discussed so far, right? So for those use cases, your communication between the control plane and data plane won't happen directly. It happens through a firewall or it might go over an internet or untested network. So in this case as well, right? So you have an API server. We all know like API server should be reachable. It should be mostly have a public IP. So the worker node can able to reach the API server. But in this case, the API server can't reach the worker node because the worker nodes are behind the NAT. So it doesn't have a public IP. It is not directly reached from the control plane. So one easier option might be you can give a public IP to the worker nodes. But we all know, right? It is not a right option from a cost perspective and also from a security perspective. It is not advice to expose the worker nodes directly. So the option, I mean, Kubernetes have think about it earlier. So they had an option called SSH reverse tunnel. When you set up a remote control plane like this, earlier Kubernetes till version 1.19, they used to provide something called SSH reverse tunnel when you set up a controller. So in that the controller and worker node will have a SSH reverse tunnel. Basically, the worker node will have a SSH reverse tunnel with the controller. But there are few issues with SSH reverse tunnel. It requires a non-overlapping IP space between the controller nodes and the worker nodes. And also there are few CVs explored in those areas. So with version 1.19, Kubernetes support for SSH reverse tunnel to set up the control plane to worker node connectivity. And there are other options we have. We can set up a VPN between the controller and worker node so that on top of it, it will act as an overlaid network so that your controller will think your worker nodes are in the same node or in the sorry, it's in the same network. But the problem with setting up an VPN is like it adds additional cost and it is an, that is a vendor lock in whenever you go for a VPN based solution. So Kubernetes have thought about it. They have come up with a special interest group called APS server network proxy. Basically, the difference if you see from the previous slide on this right, it is the same topology. We have running a tunnel actually. So earlier it was an SSH tunnel. Now we are forming a GRPC tunnel. So the communication between the worker node and the control plane will happen through a GRPC tunnel. So the worker node when you register itself with the control plane, right, it will form a GRPC tunnel so that whatever API communication happens will go over GRPC. So what's going to make a difference between an SSH or GRPC? So basically, if you see how GRPC works, right? So GRPC is a protocol which is based on top of HTTP 2. So it natively supports multiplexing, connection multiplexing. So once you have a single connection which has happened between your worker node and the control plane, within the same connection, the further request will use the same connection. That's how a connection multiplexing works. And also, GRPC supports bidirectional streaming. So within the same connection, both server and client can talk to each other. And we all know GRPC scale much better. So that's the reason they have considered GRPC here actually. So I'm going to talk a bit about how this whole setup will work and how do we set up this in our cluster. So this is a configuration. So there is a two set of configuration. One is at the controller side and one is at the worker node. So the controller node, basically, first we need to tell from an API server, what are the egress traffic we want to do a proxy. So in this case, I have mentioned its cluster, which means basically the cluster traffic between control plane and the worker node needs to be proxy to GRPC. And as I was mentioning here is a transport protocol as UDS, which is Unix domain socket. So in this case, I was running my connectivity proxies in the same node as my control plane. But there are use cases if you want to have a better scaling, you can run the connectivity server in separate node outside your control plane as well. So in those cases, you need to mention the IP address of your connectivity server. So in this case, I was running connectivity server as a static part. So to run a static part, you can just have the connectivity image and run it in a control plane. And in the worker node, you need to run a demon set, which is nothing but a connectivity agent. And that needs a few details to reach the control plane. So basically, you need to have the VIP IP of your control plane or the domain name of your control plane that needs to pass on the certificates of the control plane. So that's how the Kubernetes connectivity agent will talk to the connectivity server and set up the tunnel to make the remote control plane work here. So this is just a 15-minute session, so I don't have any live DOMA set. So this is a Slack channel you can follow, which is APS server network proxy. So if you have any doubts in setting up the connectivity or APS server, you can reach out this Slack channel. And these are the reference slides you can watch. And if you feel this slide is useful, you can scan this QR code and get the slides. So thank you. So if you have any questions we can take or time permits. So I have a couple of minutes left. Any questions you have? So when we have a remote control plane, what about the latency? Because the data plane is in a different segment and it is using VPN tunnels to connect. There's a huge latency, right? Yeah, definitely. That's a good point. But it is only recommended for constrained use cases where you are for applications like Edge where you have a limited connectivity. So in those cases, I mean, you can configure your probe in such a way that your control plane doesn't tell that your application is dead. You can increase the time. The thing is each and every, everything uses APS server, right? Yes. So even for HPA, it needs to go for APS server and then come back. So even a small two MS, additional latencies, in terms of scalability, it is not a good thing, right? Yeah, I agree. But from a user to APS server, I don't think you have any issues because it is in your cloud permissions or in your on-prem. But from APS server to your data plane, yeah, definitely there was an latency. But you need to tune in such a way that it won't impact your workload which is running. So I agree there was an latency involved in it. But it is only for a few cases where it is not a good thing. And also, you said that it establishes GRPC pipelines, VPN tunnels, right? GRPC is an unencrypted tunnels. Then how can the data be safe? No, it is, if you see the slide, right, it was, it's an encrypted GRPCS actually. Because GRPC by natively, it is unencrypted. That's why it is faster than VXLand. No, it is like, it's an encrypted packet actually. Basically, GRPCS is on top of HTTPS. So it's an encrypted protocol, so. Thanks.