lb_intro - OpenNebula/cluster-api-provider-opennebula GitHub Wiki

Overview

This section builds upon the previous cluster management overview by introducing the concept of a Load Balancer (LB), which is responsible for exposing Kubernetes services externally. The Load Balancer plays a crucial role in ensuring efficient traffic distribution, enhancing scalability, and improving the overall reliability of the infrastructure.

The following diagram shows how the Load Balancer fits into the previous setup, with public and private network connections, along with a new floating IP to expose the service externally.

Public Network
──────────────────────┬───────────────────────┬─────────────
                      |       one-vr Network  |
                      |       ────────────────┼─────────────
     PUBLIC_IP        |        FLOATING IP    |
      (172.20.0.200)  |         (172.20.0.201)|
      (ep0.eth0.vr)   |         (ep0.eth0.vr) |
                      β”‚                       |
              β”Œ ─ ─ ─ β”Ό ─ ─ ─ ┐       β”Œ ─ ─ ─ β”Ό ─ ─ ─ ┐
              β”‚  CAPONE vnf   β”‚       β”‚     CP lb     β”‚
              β”‚       β”‚       β”‚       β”‚       β”‚       β”‚
              β”‚  β”Œβ”€β”€eth0──┐   β”‚       β”‚  β”Œβ”€β”€eth0──┐   β”‚
              β”‚  β”‚        β”‚   β”‚       β”‚  β”‚        β”‚   β”‚
              β”‚  β”‚  VM-1  β”‚   β”‚       β”‚  β”‚  VM-5  β”‚   β”‚
              β”‚  β”‚        β”‚   β”‚       β”‚  β”‚        β”‚   β”‚
              β”‚  └──eth1β”€β”€β”˜   β”‚       β”‚  └──eth1β”€β”€β”˜   β”‚
              β”‚       β”‚       β”‚       β”‚       β”‚       β”‚
              β”‚  10.2.11.101  β”‚       β”‚  172.20.0.106 β”‚
              β”‚ (ep0.eth1.vr) β”‚       β”‚ (ep0.eth1.vr) β”‚
              β”‚       β”‚       β”‚       β”‚       β”‚       β”‚
              β”” ─ ─ ─ β”Ό ─ ─ ─ β”˜       β”” ─ ─ ─ β”Ό ─ ─ ─ β”˜
                      β”‚                       β”‚
─────────┬────────────┴──────┬────────────────┴──┬───────────
Private Network              β”‚                   β”‚
         β”‚                   β”‚                   β”‚
 β”Œ ─ ─ ─ β”Ό ─ ─ ─ ─┐  β”Œ ─ ─ ─ β”Ό ─ ─ ─ ─┐  β”Œ ─ ─ ─ β”Ό ─ ─ ─ ─┐
 β”‚  CAPONE master β”‚  β”‚  CAPONE worker β”‚  β”‚ CAPONE worker  β”‚
 β”‚       β”‚        β”‚  β”‚       β”‚        β”‚  β”‚       β”‚        β”‚
 β”‚  10.2.11.102   β”‚  β”‚  10.2.11.103   β”‚  β”‚  10.2.11.104   β”‚
 β”‚       β”‚        β”‚  β”‚       β”‚        β”‚  β”‚       β”‚        β”‚
 β”‚   β”Œβ”€β”€eth0──┐   β”‚  β”‚   β”Œβ”€β”€eth0──┐   β”‚  β”‚   β”Œβ”€β”€eth0──┐   β”‚
 β”‚   β”‚        β”‚   β”‚  β”‚   β”‚        β”‚   β”‚  β”‚   β”‚        β”‚   β”‚
 β”‚   β”‚  VM-2  β”‚   β”‚  β”‚   β”‚  VM-3  β”‚   β”‚  β”‚   β”‚  VM-4  β”‚   β”‚
 β”‚   β”‚        β”‚   β”‚  β”‚   β”‚        β”‚   β”‚  β”‚   β”‚        β”‚   β”‚
 β”‚   β””β”€β”€β”€β”€β”€β”€β”€β”€β”˜   β”‚  β”‚   β””β”€β”€β”€β”€β”€β”€β”€β”€β”˜   β”‚  β”‚   β””β”€β”€β”€β”€β”€β”€β”€β”€β”˜   β”‚
 β”” ─ ─ ─ ─ ─ ─ ─ β”€β”˜  β”” ─ ─ ─ ─ ─ ─ ─ β”€β”˜  β”” ─ ─ ─ ─ ─ ─ ─ β”€β”˜

From an OpenNebula point of view you'll see something like this for the example above:

ID USER     GROUP    NAME                   STAT  CPU     MEM HOST         TIME
5  oneadmin oneadmin vr-one-lb-0            runn    1    512M localhost    0d 00h35
4  oneadmin oneadmin one-md-0-dh2ls-dfxqb   runn    1      3G localhost    0d 00h40
3  oneadmin oneadmin one-md-0-dh2ls-prd6k   runn    1      3G localhost    0d 00h40
2  oneadmin oneadmin one-bmfkk              runn    1      3G localhost    0d 00h42
1  oneadmin oneadmin vr-one-cp-0            runn    1    512M localhost    0d 00h42

In this case, the component to VM mapping is as follows:

  • The virtual router is VM 1 (vr-one-cp-0)
  • The k8s control plane is VM 2 (one-bmfkk)
  • The k8s worker nodes are VMs 3, 4, 5 (capone-md-0-ccxpl-*)
  • The virtual router acting as the LoadBalancer is VM 5 (vr-one-lb-0)