Adventures in Freebernetes Tutorial: Build Your Own Bare-VM Kubernetes Cluster the Hard Way

Page 8: Bootstrapping the Kubernetes Control Plane

Most of this section should be executed as written, with the following exceptions:

• Set INTERNAL_IP as we did on the previous page
• If you’re on a slow Internet connection, you may also want to download the tarballs once and copy them from your FreeBSD host to the controller VMs.
• If you are using your own IP address ranges, you will need to make some additional changes.
• In place of the last section, The Kubernetes Frontend Load Balancer, follow these instructions:

The (Replacement) Kubernetes Frontend Load Balancer

We have three control plane servers, each running the Kubernetes API service. In a production system, we would want to use a load balancer that could also perform service health checks and avoid sending requests to unavailable servers, like the Google Cloud load balancing service in the original, but for this experimental cluster, we can just use a simple round-robin method using ipfw rules by creating a virtual IP address, 10.240.0.2.

First we create the rules, then we need to configure the three controllers to accept traffic for the virtual IP address. Note this second IP address will not persists across VM reboots. You will need to add 10.240.0.2/32 to the addresses field in /etc/netplan/50-cloud-init.yaml if you want to save the configuration.

These rules look odd, but each of the three controllers should get 1/3 of the requests over time. (Rules are evaluated in numerical order.)

• Rule 300 gives 10.240.0.10 a 1/3 probability
• Rule 301 gives 10.240.0.11 a .5 probability, but that’s half of the remaining two of the original three slots, so it has a 1/2 * 2/3 = 1/3 chance overall
• Rule 302 gives 10.240.0.12 a 100% probability of being the final 1/3 hosts selected.

After this section, we can exit the controller tmux session.

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14