Understanding OpenShift 4.x API Server Exposure on Bare Metal Openshift API server

Running OpenShift 4.x on bare metal has a number of advantages: you get to maintain control of your own environment without being beholden to a cloud provider’s networking or load-balancing solution. But with that control comes a bit of extra work, especially around how the OpenShift API server is exposed.

In this post, we’ll discuss:

• How the OpenShift API server is bound on each control-plane (master) node.
• Load-balancing options for the API server in a bare-metal environment.
• The difference between external load balancers, keepalived/HAProxy, and MetalLB.

1. How OpenShift 4.x Binds the API Server

Static Pods with Host Networking

In Kubernetes, control-plane components like the API server can run as static pods on each control-plane node. In OpenShift 4.x, the kube-apiserver pods use hostNetwork: true, which means they bind directly to the host’s network interface—specifically on port 6443 by default.

• Location of static pod manifests: These are managed by the Machine Config Operator and typically live in /etc/kubernetes/manifests on each master node.
• Direct binding: Because these pods use host networking, port 6443 on the master node itself is used. This is not a standard Kubernetes Service or NodePort; it is bound at the OS level.

Implications

• There is no Service, Route, or Ingress object for the control-plane API endpoint.
• The typical Service/Route-based exposure flow doesn’t apply to these system components; they live outside the usual Kubernetes networking model to ensure reliability and isolation.

2. Load-Balancing the API Server

In a production environment, you typically want the API server to be highly available. You accomplish that by putting a load balancer in front of the master nodes, each listening on its own 6443 port. This helps ensure that if one node goes down, the others can still respond to API requests.

Below are three common ways to achieve this on bare metal.

Option A: External Hardware/Virtual Load Balancer (F5, etc.)

Overview
Many on-prem or private datacenter environments already have a load-balancing solution in place—e.g., F5, A10, Citrix, or Netscaler appliances. If that’s the case, you can simply:

1. Configure a virtual server that listens on api.<cluster-domain>:6443.
2. Point it to the IP addresses of your OpenShift master nodes on port 6443.

Pros

• Extremely common in enterprise scenarios.
• Well-supported by OpenShift documentation and typical best practices.
• Often includes advanced features (SSL offloading, health checks, etc.).

Cons

• Requires specialized hardware or a VM/appliance with a license in some cases.

Option B: Keepalived + HAProxy on the Master Nodes

Overview
If you lack a dedicated external load balancer, you can run a keepalived/HAProxy setup within your cluster’s control-plane nodes themselves. Typically:

• Keepalived manages a floating Virtual IP (VIP).
• HAProxy listens on the VIP (on port 6443) and forwards traffic to the local node or other master nodes.

Pros

• No extra hardware or external appliances needed.
• Still provides a single endpoint (api.<cluster-domain>:6443) that floats among the masters.

Cons

• More complex to configure and maintain.
• You’re hosting the load-balancing solution on the same nodes as your control-plane, so it’s critical to ensure these components remain stable.

Option C: MetalLB for LoadBalancer Services

Overview
MetalLB is an open-source solution that brings “cloud-style” LoadBalancer services to bare-metal Kubernetes clusters. It typically works in Layer 2 (ARP) or BGP mode to announce addresses, allowing you to create a Service of type: LoadBalancer that obtains a routable IP.

Should You Use It for the API Server?

• While MetalLB is great for application workloads requiring a LoadBalancer IP, it is generally not the recommended approach for the cluster’s control-plane traffic in OpenShift 4.x.
• The API server is not declared as a standard “service” in the cluster; instead, it’s a static pod using host networking.
• You would need additional customizations to treat the API endpoint like a load-balancer service. This is a non-standard pattern in OpenShift 4.x, and official documentation typically recommends either an external LB or keepalived/HAProxy.

Pros (for application workloads)

• Provides a simple way to assign external IP addresses to your apps without external hardware.
• Lightweight solution that integrates neatly with typical Kubernetes workflows.

Cons

• Not officially supported for the API server’s main endpoint.
• Missing advanced features you might find in dedicated appliances (SSL termination, advanced health checks, etc.).

3. Recommended Approaches

1. If You Have an Existing Load Balancer
   • Point it at your master nodes’ IP addresses, forwarding :6443 to each node’s :6443.
   • You’ll typically have a DNS entry like api.yourcluster.example.com that resolves to the load balancer’s VIP or IP.
2. If You Don’t Have One
   • Consider deploying keepalived + HAProxy on the master nodes. You can designate one floating IP that is managed by keepalived. HAProxy on each node can route requests to local or other masters’ API endpoints.
3. Use MetalLB for App Workloads, Not the Control Plane
   • If you are on bare metal and need load-balancing for normal application services (i.e., front-end web apps), then MetalLB is a great choice.
   • However, for the control-plane API, it’s best to stick to the official recommended approach of an external LB or keepalived/HAProxy.

Conclusion

The API server in OpenShift 4.x is bound at the host network level (port 6443) on each control-plane node via static pods, which is different from how typical workloads are exposed. To achieve high availability on bare metal, you need some form of load balancer—commonly an external appliance or keepalived + HAProxy. MetalLB is excellent for exposing standard application workloads via type: LoadBalancer, but it isn’t the typical path for the OpenShift control-plane traffic.

By understanding these different paths, you can tailor your OpenShift 4.x deployment strategy to match your on-prem infrastructure, making sure your cluster’s API remains accessible, robust, and highly available.

---