Floating IP / Virtual IP in Kubernetes: What It Is and How to Use It
When building a highly available Kubernetes cluster, one of the most important networking concepts to understand is the Virtual IP (VIP), sometimes called a Floating IP.
A VIP provides a stable network endpoint that clients can use even when multiple Kubernetes control-plane nodes are available behind it.
This becomes particularly important when building a Kubernetes cluster with multiple control-plane nodes and a load balancer such as HAProxy.
A VIP gives your Kubernetes cluster a stable IP address that clients can use instead of connecting directly to a particular control-plane node.
What Is a Virtual IP?
A Virtual IP, or VIP, is an IP address that represents a service or network endpoint rather than being permanently associated with one particular server.
For example, imagine three Kubernetes control-plane nodes:
- Control Plane 1 — 10.0.0.11
- Control Plane 2 — 10.0.0.12
- Control Plane 3 — 10.0.0.13
Instead of asking administrators and clients to remember all three addresses, we can provide a single VIP:
10.0.0.100
Clients can then use the VIP as the stable endpoint for accessing the Kubernetes API.
What Is a Floating IP?
The term Floating IP describes an IP address that can move between network endpoints or be reassigned during a failover event.
For example, suppose two load balancers are used:
- Load Balancer 1
- Load Balancer 2
A floating IP can provide a common address that is available through whichever load-balancer instance is currently active.
10.0.0.100
If the active load balancer fails, a suitable high-availability mechanism can move or make the VIP available through another load-balancer instance.
VIP vs Floating IP
The terms are often used together, but there is a useful distinction.
| Term | Meaning |
|---|---|
| Virtual IP | A stable IP used as an endpoint for a service or group of systems. |
| Floating IP | An IP that can move or fail over between network endpoints. |
In real infrastructure discussions, people may use VIP and floating IP almost interchangeably, depending on the architecture.
Why Does Kubernetes Need a VIP?
A highly available Kubernetes cluster can contain multiple control-plane nodes. Each control-plane node can run a Kubernetes API server.
For example:
API Server
API Server
API Server
If clients connect directly to Control Plane 1, they depend on that particular node. If it fails, clients may lose access to the Kubernetes API.
A stable VIP provides another approach:
10.0.0.100:6443
Why Port 6443?
The Kubernetes API server normally listens on TCP port 6443.
Therefore, a common Kubernetes high-availability endpoint can look like:
https://10.0.0.100:6443
The actual IP address and configuration depend on the environment.
VIP Is Not the Same as a Load Balancer
This is one of the most important concepts to understand.
The VIP provides the stable network address.
The load balancer receives traffic and decides which backend should receive that traffic.
For example:
10.0.0.100
The VIP is the stable address. HAProxy is responsible for forwarding traffic to the appropriate backend.
How HAProxy Can Use a Kubernetes VIP
HAProxy can listen for connections arriving at the Kubernetes API endpoint and forward them to the available control-plane nodes.
A simplified architecture looks like this:
Client
|
| https://VIP:6443
|
v
+----------------+
| HAProxy |
+----------------+
|
+--------> Control Plane 1:6443
|
+--------> Control Plane 2:6443
|
+--------> Control Plane 3:6443
The load balancer can perform health checks so that an unavailable API server is removed from the active backend pool.
Example HAProxy Configuration
A simplified TCP configuration for Kubernetes API traffic could look like this:
frontend kubernetes_api
bind *:6443
mode tcp
default_backend kubernetes_masters
backend kubernetes_masters
mode tcp
balance roundrobin
server master1 10.0.0.11:6443 check
server master2 10.0.0.12:6443 check
server master3 10.0.0.13:6443 check
This configuration tells HAProxy to:
- Listen for Kubernetes API traffic.
- Use TCP mode.
- Forward traffic to the Kubernetes API servers.
- Use health checks.
- Distribute connections between available backend servers.
The exact HAProxy configuration should be adapted to the network architecture and security requirements of the Kubernetes environment.
Where Does the VIP Actually Live?
This is where the architecture becomes more interesting.
A VIP is not necessarily an IP address permanently assigned to every server. Its ownership depends on how the infrastructure implements high availability.
There are several possible designs.
Design 1: VIP on a Load Balancer
The VIP can be associated with a load-balancing system that receives client traffic and forwards it to the Kubernetes control-plane nodes.
VIP | v Load Balancer | +---- Master 1 | +---- Master 2 | +---- Master 3
Design 2: Two Load Balancers with a Floating VIP
For higher availability, two load balancers can be used.
Floating VIP
10.0.0.100
|
+-------+-------+
| |
v v
HAProxy 1 HAProxy 2
Active Standby
|
+---- Kubernetes API Servers
If the active load balancer fails, a failover mechanism can make the VIP available through the standby load balancer.
The exact failover technology depends on the environment. Common approaches can include network-level mechanisms such as VRRP or other infrastructure-specific high-availability solutions.
What Happens During a Failover?
Consider this example:
VIP → HAProxy 1 → Kubernetes API Servers
After HAProxy 1 fails:
VIP → HAProxy 2 → Kubernetes API Servers
The objective is that clients continue using the same VIP rather than having to change their Kubernetes configuration.
This is one of the biggest advantages of a floating IP in a high-availability design.
VIP vs DNS
A common question is:
DNS and VIPs solve different problems.
| Technology | Primary Role |
|---|---|
| DNS | Maps a name to an IP address or other DNS record. |
| VIP | Provides a stable network endpoint that can be backed by a highly available architecture. |
You can actually use both together.
k8s-api.example.com
|
v
10.0.0.100
|
v
VIP
|
v
HAProxy
|
+---- API Server 1
+---- API Server 2
+---- API Server 3
VIP vs Kubernetes Service LoadBalancer
Another common source of confusion is the Kubernetes LoadBalancer Service.
They are related to networking but are not automatically the same thing.
A VIP used for a Kubernetes control-plane endpoint is part of the infrastructure providing access to the Kubernetes API.
A Kubernetes Service of type LoadBalancer is normally used to expose
a Kubernetes application externally, depending on the cluster's infrastructure
and load-balancing implementation.
A control-plane VIP and a Kubernetes application LoadBalancer Service can have completely different purposes.
Why a VIP Is Important for Kubernetes HA
A highly available Kubernetes cluster should provide a stable API endpoint.
Without a stable endpoint, administrators may need to configure clients against individual control-plane addresses.
A VIP provides a consistent endpoint such as:
https://k8s-api.example.com:6443
or:
https://10.0.0.100:6443
The Kubernetes clients can continue using that endpoint while the infrastructure handles which backend control-plane node should receive the traffic.
How Kubernetes Uses the API Endpoint
When you run:
kubectl get nodes
kubectl communicates with the Kubernetes API server.
In a highly available environment, the kubeconfig can point to the stable API endpoint:
server: https://k8s-api.example.com:6443
The hostname can resolve to the VIP, which then reaches the load-balancing layer and ultimately one of the available API servers.
What Happens If One Control Plane Fails?
Suppose the cluster has three control-plane nodes.
Healthy
Failed
Healthy
VIP → Load Balancer → Master 1 / Master 3
If health checks detect that Master 2 is unavailable, the load balancer can stop sending new connections to that backend.
The VIP itself remains the same.
The backend can change while the client-facing endpoint remains stable.
Does a VIP Automatically Make Kubernetes Highly Available?
No.
A VIP is only one component of a highly available architecture.
A production Kubernetes cluster also needs appropriate redundancy for the control plane, networking, storage, load-balancing infrastructure and other critical components.
For example, having three Kubernetes control-plane nodes but only one load balancer can still leave a single point of failure in the architecture.
Common Mistakes When Designing a Kubernetes VIP
- Thinking the VIP itself is the load balancer.
- Using an IP address already assigned to another device.
- Ignoring network routing requirements.
- Forgetting firewall rules for TCP 6443.
- Configuring a VIP without considering failover.
- Using a single load balancer and assuming the entire design is highly available.
- Not configuring health checks for Kubernetes API servers.
- Confusing a control-plane VIP with a Kubernetes application LoadBalancer Service.
How to Test a Kubernetes VIP
Once the VIP and load-balancing configuration are in place, basic network testing can help verify connectivity.
Test TCP connectivity
nc -vz 10.0.0.100 6443
Test the Kubernetes API endpoint
curl -k https://10.0.0.100:6443/version
The -k option is useful for a basic TLS connectivity test when certificate
validation is not being performed in that particular test.
For production troubleshooting, certificate validation and authentication should be handled correctly rather than bypassed.
Test through kubectl
kubectl get nodes
If kubectl is configured to use the VIP endpoint, this verifies connectivity through the complete path to the Kubernetes API.
Troubleshooting a Kubernetes VIP
When a Kubernetes API endpoint is unreachable, troubleshoot from the outside toward the backend.
Step 1: Check DNS
nslookup k8s-api.example.com
Step 2: Check VIP reachability
ping 10.0.0.100
Note that ICMP may be blocked, so a failed ping does not necessarily mean TCP connectivity is unavailable.
Step 3: Check TCP 6443
nc -vz 10.0.0.100 6443
Step 4: Check HAProxy
Verify that HAProxy is running and listening on the expected port.
ss -lntp | grep 6443
Step 5: Check backend health
Verify that the Kubernetes API servers are reachable from the load balancer.
nc -vz 10.0.0.11 6443 nc -vz 10.0.0.12 6443 nc -vz 10.0.0.13 6443
Step 6: Check firewall rules
Make sure the required traffic is permitted between clients, the VIP/load balancer, and the Kubernetes control-plane nodes.
Practical Kubernetes HA Exercise
If you have access to a lab environment, try designing the following architecture.
- Create three Kubernetes control-plane nodes.
- Assign each node its own management IP.
- Reserve a separate IP for the Kubernetes VIP.
- Configure a load balancer such as HAProxy.
- Configure the load balancer to forward TCP 6443.
- Add all control-plane API servers as backends.
- Enable health checks.
- Configure the Kubernetes API endpoint to use the VIP or DNS name pointing to it.
- Test kubectl connectivity.
- Simulate failure of one API server.
- Confirm that the other API servers can continue handling connections.
Example Production-Style Architecture
A more highly available architecture can contain redundant load balancers as well:
Kubernetes Clients
|
|
k8s-api.example.com
|
v
Floating VIP
10.0.0.100
|
+---------+---------+
| |
v v
HAProxy 1 HAProxy 2
Active Standby
|
+-----------------------+
| | |
v v v
Master 1 Master 2 Master 3
API :6443 API :6443 API :6443
The exact implementation varies between data centers, cloud platforms and virtualization environments, but the architectural principle remains the same: provide a stable endpoint in front of redundant backend systems.
VIP and Kubernetes CNI
The VIP and the Kubernetes CNI solve different networking problems.
The CNI provides networking for Kubernetes workloads such as Pods.
The VIP provides a stable network endpoint for infrastructure or services that need a consistent address.
| Component | Main Purpose |
|---|---|
| CNI | Provides networking for Kubernetes Pods. |
| VIP | Provides a stable IP endpoint. |
| HAProxy | Can distribute traffic between backend servers. |
These components can work together as part of a larger Kubernetes network architecture.
Key Takeaways
- VIP means Virtual IP.
- A floating IP can be moved or failed over between network endpoints.
- A Kubernetes HA cluster benefits from a stable API endpoint.
- The Kubernetes API server normally uses TCP port 6443.
- HAProxy can distribute API traffic to multiple control-plane nodes.
- The VIP and load balancer are not the same thing.
- DNS can be used together with a VIP.
- A VIP alone does not make the entire Kubernetes cluster highly available.
- Redundant load-balancing infrastructure is important when eliminating single points of failure.
- CNI and VIP solve different networking problems.
Frequently Asked Questions
What is a VIP in Kubernetes?
A Kubernetes VIP is a stable Virtual IP used as an endpoint for Kubernetes infrastructure, commonly including the Kubernetes API in highly available cluster designs.
What is a floating IP?
A floating IP is an IP address that can be moved or failed over between network endpoints, allowing clients to continue using the same address.
Is a VIP a load balancer?
No. A VIP is an IP endpoint. A load balancer is responsible for receiving traffic and distributing it to backend systems.
Why use a VIP for the Kubernetes API server?
A VIP provides a stable endpoint so Kubernetes clients do not have to depend on a specific control-plane node.
What port does the Kubernetes API server use?
The Kubernetes API server normally listens on TCP port 6443.
Can HAProxy provide Kubernetes API load balancing?
Yes. HAProxy can be configured to distribute TCP connections to multiple Kubernetes API servers.
Can DNS replace a VIP?
DNS and VIPs serve different purposes. DNS can provide a stable name while the VIP provides a stable network endpoint. They can also be used together.
Does Kubernetes CNI provide the VIP?
Not necessarily. CNI provides networking for Kubernetes workloads, while the VIP is normally part of the infrastructure or load-balancing architecture.
Kubernetes VIP Interview Questions
- What is a Virtual IP?
- What is the difference between a VIP and a floating IP?
- Why is a VIP useful in a Kubernetes HA cluster?
- What is the Kubernetes API server port?
- Is a VIP the same thing as a load balancer?
- How can HAProxy be used with a Kubernetes VIP?
- What happens when one Kubernetes API server fails?
- What happens when the active load balancer fails?
- What is the difference between a VIP and DNS?
- What is the difference between a control-plane VIP and a Kubernetes LoadBalancer Service?
- How would you troubleshoot an unreachable Kubernetes VIP?
- Why should the load balancer use health checks?
- Can a single load balancer provide complete high availability?
- What is the relationship between a Kubernetes CNI and a VIP?
Related Technical Topics
- Kubernetes CNI Explained
- Kubernetes Services Explained
- TCP vs UDP
- DNS Explained
- Load Balancing Explained
- HAProxy Configuration
- Kubernetes High Availability
- Kubernetes Control Plane Architecture
- Linux Networking Commands
- Reverse Proxy vs Load Balancer
No comments:
Post a Comment