kube-vip
LoadBalancer VIP allocation — IP reservations, lease tuning, and the .200 invariant.
kube-vip provides LoadBalancer VIPs for Services in the cluster. It runs as a DaemonSet and uses leader election to decide which node advertises a given VIP.
Where it sits
| Chart | kube-vip/ in the parent repo |
| Mode | DaemonSet (per-node) |
| Pool | kubevip ConfigMap — range 120-199, 201-220, 10 |
The .200 reservation
.200 is reserved for the control-plane VIP. Never assign it to a Service.
The kubevip ConfigMap range explicitly excludes .200 (120-199,201-220,10);
manual assignment must respect the same exclusion.
When checking for LB IP collisions, cross-reference against LB-IPs.md in the parent
repo, which tracks every assigned VIP.
Lease tuning (2026-05-08)
The kube-vip DaemonSet env was tuned to shorten failover time:
| Env var | Value |
|---|---|
vip_leaseduration | 15 |
vip_renewdeadline | 10 |
vip_retryperiod | 2 |
Defaults were higher; the tuning was applied to make node failures recover the VIP in
seconds instead of tens of seconds. Roll back via kubectl rollout undo if a
regression is suspected.
Allocating a new LB IP
- Pick an IP from the
kubevipConfigMap range, avoiding.200and any IP already inLB-IPs.md. - Annotate the Service:
kube-vip.io/loadbalancerIPs: <ip>. - Update
LB-IPs.mdwith the assignment.
Operator quick-reference
| Symptom | First check |
|---|---|
Service shows <pending> for LoadBalancer IP | Pool exhausted? Annotation typo? Check kube-vip pod logs |
| VIP responds intermittently | Lease flapping — check which node currently advertises (kube-vip leader election) |
| Two services collide on the same VIP | Bad annotation or no annotation — check LB-IPs.md for the source of truth |