Remote Control Planes With Konnectivity; What, Why And How?

The presentation discusses the challenges of remote control planes in Kubernetes and the solution of using an external load balancer to connect to the API server pods.

• The hybrid model of running physical data centers and multi-cloud environments provides flexibility in workload management.
• The main challenge of remote control planes is the communication between the API server and in-cluster components.
• An external load balancer can be used to connect the API server pods to the agents.
• The use of open VPN tunnels or other networking solutions can be replaced by the external load balancer.
• There is an open PR for bi-directional tunneling.
• The main issues with this solution are misconfigured load balancers and sticky sessions.

The speaker mentions that they have been running this solution in production for multiple clusters and multi-cloud/bare metal environments without issues.

It’s a pretty common pattern to run the Kubernetes control plane on a dedicated node or a set of nodes co-located with the worker nodes. But what if we want to run the control plane as truly separated from the workers? Can the control plane be located in a completely different datacenter than the worker nodes even with some network-level disconnection separating the control and worker planes? We’ll start the talk by looking at why to build clusters with a remote control plane, and use cases for such setups. The second part of the talk will introduce the technical concepts that can be used to make it happen. We will look at how the api-server can be set up to use an egress selector proxy for different use cases. Next, we’ll look at a practical example of how it can be used with the Konnectivity API server network proxy. Lastly, we will showcase how all of this works together in open-source Kubernetes platforms like k0s and Kubermatic.