<\/p>\n\n\n\n
If you\u2019ve ever used OpenShift, you\u2019re probably familiar with its feature-rich web console. It\u2019s a central hub for managing workloads, projects, security policies, and more. While the console is easy to access in a typical cloud environment, the mechanics behind exposing it on bare metal are equally interesting. In this article, we\u2019ll explore how OpenShift 4.x (including 4.16) serves and secures the console in a bare-metal setting.<\/p>\n\n\n\n
In OpenShift 4.x, there are two main entry points for cluster interactions:<\/p>\n\n\n\n
6443<\/code>, usually exposed by external load balancers or keepalived\/HAProxy in bare-metal environments.<\/li>\n\n\n\n- Web console<\/strong>: Typically accessed at port
443<\/code> via an OpenShift \u201croute,\u201d backed by the cluster\u2019s router\/ingress infrastructure.<\/li>\n<\/ol>\n\n\n\nThe API server uses a special out-of-band mechanism (static pods on master nodes). By contrast, the console takes a path much more familiar to standard Kubernetes applications: it\u2019s served by a deployment, a service, and ultimately a Route object in the openshift-console<\/code> namespace. Let\u2019s focus on that Route-based exposure.<\/p>\n\n\n\n2. How the Console Is Deployed<\/h2>\n\n\n\nConsole Operator<\/h3>\n\n\n\n
The console itself is managed by the OpenShift Console Operator<\/strong>, which:<\/p>\n\n\n\n\n- Deploys the console pods into the
openshift-console<\/code> namespace.<\/li>\n\n\n\n- Ensures they remain healthy and up-to-date.<\/li>\n\n\n\n
- Creates the relevant Kubernetes resources (Deployment, Service, and Route) that expose the console to external users.<\/li>\n<\/ul>\n\n\n\n
Where the Pods Run<\/h3>\n\n\n\n
By default, the console pods run on worker nodes (though in some topologies, you might have dedicated infrastructure nodes). The important point is that these pods are scheduled like normal Kubernetes workloads.<\/p>\n\n\n\n
3. How the Console Is Exposed<\/h2>\n\n\n\nThe OpenShift Router (Ingress Controller)<\/h3>\n\n\n\n
OpenShift comes with a built-in Ingress Controller<\/strong>\u2014often referred to as the \u201crouter.\u201d It\u2019s usually an HAProxy-based router deployed on worker (or infra) nodes. By default, it will listen on:<\/p>\n\n\n\n\n- HTTP port
80<\/code><\/strong><\/li>\n\n\n\n- HTTPS port
443<\/code><\/strong><\/li>\n<\/ul>\n\n\n\nWhen you create a Route, the router matches the host name in the incoming request and forwards traffic to the corresponding service. In the console\u2019s case, that route is typically named console<\/code> in the openshift-console<\/code> namespace.<\/p>\n\n\n\nTypical Hostname<\/strong>
During installation, OpenShift configures the default \u201capps\u201d domain. For instance:<\/p>\n\n\n\nconsole-openshift-console.apps.<cluster-domain><\/pre>\n\n\n\nSo when you browse to, say, https:\/\/console-openshift-console.apps.mycluster.example.com<\/code>, your request hits the router, which looks for the matching route and then forwards you to the console service.<\/p>\n\n\n\nThe Route Object<\/h3>\n\n\n\n
OpenShift 4.x uses the Route resource to direct external traffic to an internal service. You can find the console route by running:<\/p>\n\n\n\n
oc get route console -n openshift-console<\/pre>\n\n\n\nYou\u2019ll usually see something like:<\/p>\n\n\n\n
NAME HOST\/PORT PATH SERVICES PORT TERMINATION WILDCARD
console console-openshift-console.apps.mycluster.example.com console https edge None
<\/pre>\n\n\n\n
\n- Service<\/strong>: The route points to the
console<\/code> service in the openshift-console<\/code> namespace.<\/li>\n\n\n\n- Edge Termination<\/strong>: The router typically provides TLS termination, ensuring secure communication.<\/li>\n\n\n\n
- Host<\/strong>: The domain you\u2019ll use to access the console externally.<\/li>\n<\/ul>\n\n\n\n
4. Traffic Flow on Bare Metal<\/h2>\n\n\n\nExternal Access<\/h3>\n\n\n\n
On bare metal, you typically have one of the following configurations:<\/p>\n\n\n\n
\n- Direct Node Access<\/strong>: If each worker node has a publicly (or at least internally routable) IP, you create a wildcard DNS record (or direct DNS records) that point to those node IPs (or to a load balancer fronting them).<\/li>\n\n\n\n
- External Load Balancer<\/strong>: You can place an external L4 or L7 load balancer in front of the worker nodes\u2019 port 443, distributing traffic across the router pods. This approach mirrors the cloud LB approach but uses an on-prem solution (F5, Netscaler, etc.).<\/li>\n<\/ol>\n\n\n\n
Either way, the router\u2019s service IP on each node is listening on port 443. By default, the Ingress Operator<\/strong> ensures that all router pods share a common DNS domain like *.apps.<cluster-domain><\/code>. This means that any Route you create automatically becomes externally accessible, assuming your DNS points to the router\u2019s IP or load balancer VIP.<\/p>\n\n\n\nTLS Certificates<\/h3>\n\n\n\n
By default, the console route has a certificate created and managed by the cluster. You can optionally configure a custom TLS certificate for the router if you want to serve the console (and all other routes) with your own wildcard certificate.<\/p>\n\n\n\n
5. Customizing the Console Domain or Certificate<\/h2>\n\n\n\n
You might want to customize how users access the console\u2014maybe you don\u2019t like the default subdomain or you want to serve it at a corporate domain. There are a couple of ways:<\/p>\n\n\n\n
\n- Change the
apps<\/code> domain<\/strong>: During installation, you can specify a custom domain.<\/li>\n\n\n\n- Edit the Console Route<\/strong>: You can change the route\u2019s host name, but you must ensure DNS for that host name points to your router\u2019s public IP.<\/li>\n\n\n\n
- Configure a Custom Cert<\/strong>: If you have a wildcard certificate for
mycompany.com<\/code>, you can apply it at the router level, so the console route and all other routes share the same certificate authority.<\/li>\n<\/ol>\n\n\n\n6. Scaling and Availability<\/h2>\n\n\n\n
Since the console runs as a standard Deployment, you can scale it up (e.g., set replicas: 3<\/code>) if you anticipate heavy usage. The router itself is typically deployed on multiple nodes for high availability\u2014ensuring that even if one node goes down, the router remains functional, and your console remains accessible.<\/p>\n\n\n\n7. How This Differs From the API Server<\/h2>\n\n\n\n
One point of confusion is that both the API server and the console run in the cluster\u2014so why is the API server not also behind a Route?<\/p>\n\n\n\n
\n- API Server<\/strong>: Runs as static pods with
hostNetwork: true<\/code> on each master node, typically exposed on port 6443<\/code>. It\u2019s not<\/em> a normal deployment and doesn\u2019t rely on the cluster\u2019s router. Instead, it usually sits behind a separate load balancer (external or keepalived\/HAProxy).<\/li>\n\n\n\n- Console<\/strong>: A normal deployment plus a Route, served by the ingress router on port
443<\/code>.<\/li>\n<\/ul>\n\n\n\nSo while the console takes advantage of standard Kubernetes networking patterns, the API server intentionally bypasses them for isolation, reliability, and the ability to run even if cluster networking is partially down.<\/p>\n\n\n\n
8. Frequently Asked Questions<\/h2>\n\n\n\n
Q: Can I use MetalLB to expose the console on a LoadBalancer-type service?<\/strong>
A: You technically could<\/em> set up a LoadBalancer service if you had MetalLB. However, the standard approach in OpenShift is to rely on the built-in router for console traffic. The console route is automatically configured, and the router takes care of HTTPS termination and routing.<\/p>\n\n\n\nQ: Do I need a separate load balancer for the console traffic?<\/strong>
A: If your bare-metal nodes themselves are routable (for example, each worker node has a valid IP and your DNS points console-openshift-console.apps.mycluster.example.com<\/code> to those nodes), then you may not need an additional LB. However, some organizations prefer to place a load balancer in front of all worker nodes for consistency, health checks, and easier SSL management.<\/p>\n\n\n\nQ: How do I get a custom domain to work with the console?<\/strong>
A: You can edit the route\u2019s hostname or specify a custom domain in your Ingress configuration. Then, point DNS for that new domain (e.g. console.internal.mycompany.com<\/code>) to the external IP(s) of your router or your load balancer. Make sure TLS certificates match if you\u2019re providing your own certificate.<\/p>\n\n\n\nConclusion<\/h2>\n\n\n\n
In OpenShift 4.x, the web console<\/strong> is exposed via a standard Kubernetes Route and served by the built-in router on port 443. The Console Operator<\/strong> takes care of deploying and managing the console pods, while the Ingress Operator<\/strong> ensures a default router is up and running. On bare metal, the key to making the console accessible is to ensure your DNS points at the router\u2019s external interface\u2014whether that\u2019s a dedicated IP on each worker node or an external load balancer VIP.<\/p>\n\n\n\nBy understanding these mechanics, you can customize the console domain, certificate, and scaling strategy to best fit your environment. And once your console is online, you\u2019ll have the full power of the OpenShift UI at your fingertips\u2014no matter where your cluster happens to be running!<\/p>\n","protected":false},"excerpt":{"rendered":"
If you\u2019ve ever used OpenShift, you\u2019re probably familiar with its feature-rich web console. It\u2019s a central hub for managing workloads, projects, security policies, and more. While the console is easy to access in a typical cloud environment, the mechanics behind exposing it on bare metal are equally interesting. In this article, we\u2019ll explore how OpenShift … <\/p>\n