Files
kube-vip/docs/index.md
Chip Zoller f5a2bd8e59 Extensive linting, corrections, expansions
Signed-off-by: Chip Zoller <chipzoller@gmail.com>
2021-11-21 19:23:00 -05:00

3.9 KiB

kube-vip.png

Overview

Kubernetes Virtual IP and Load-Balancer for both control plane and Kubernetes services.

The idea behind kube-vip is a small, self-contained, highly-available option for all environments, especially:

  • Bare-Metal
  • On-Prem
  • Edge (ARM / Raspberry Pi)
  • Virtualisation
  • Pretty much anywhere else :)

Features

Kube-Vip was originally created to provide a HA solution for the Kubernetes control plane, but over time it has evolved to incorporate that same functionality for Kubernetes Services of type LoadBalancer.

  • VIP addresses can be both IPv4 or IPv6
  • Control Plane with ARP (Layer 2) or BGP (Layer 3)
  • Control Plane using either leader election or raft
  • Control Plane HA with kubeadm (static Pods)
  • Control Plane HA with K3s/and others (DaemonSets)
  • Control Plane LoadBalancing with IPVS (kube-vip ≥ 0.4)
  • Service LoadBalancer using leader election for ARP (Layer 2)
  • Service LoadBalancer using multiple nodes with BGP
  • Service LoadBalancer address pools per namespace or global
  • Service LoadBalancer address via (existing network DHCP)
  • Service LoadBalancer address exposure to gateway via UPnP
  • ... manifest generation, vendor API integrations and many more...

Why?

The "original" purpose of kube-vip was to simplify the building of HA Kubernetes clusters, which at the time involved a few components and configurations that all needed to be managed. This was blogged about in detail by thebsdbox here. Since the project has evolved, it can now use those same technologies to provide load balancing capabilities within a Kubernetes Cluster.

Architecture

The architecture for kube-vip (and associated Kubernetes components) is covered in detail here.

Installation

There are two main routes for deploying kube-vip: either through a static pod when bringing up a Kubernetes cluster with kubeadm or as a DaemonSet (typically with distributions like K3s).

The infrastructure for our example HA Kubernetes cluster is as follows:

Node Address
VIP 10.0.0.40
controlPlane01 10.0.0.41
controlPlane02 10.0.0.42
controlPlane03 10.0.0.43
worker01 10.0.0.44

All nodes are running Ubuntu 20.04, Docker CE and will use Kubernetes 1.21.0. We only have one worker as we're going to use our control plane in "hybrid" mode.

Usage

Flags/Environment Variables

© 2021 The Linux Foundation. All rights reserved.

The Linux Foundation has registered trademarks and uses trademarks.

For a list trademarks of The Linux Foundation, please see our Trademark Usage page.