Introduction

On-prem Kubernetes clusters do not automatically get a cloud load balancer for ports 80 and 443, so exposing services requires an explicit edge design. In practice, the cleanest approach is usually an ingress controller listening on 80 and 443, plus either MetalLB or an external reverse proxy or firewall rule that forwards traffic into the cluster.

Separate the Problem into Layers

There are two different jobs to solve:

• expose an internal application inside the cluster
• expose the cluster edge on standard web ports

A Service object alone only solves internal or node-level networking. To serve public HTTP or HTTPS on 80 and 443, you typically add an ingress controller in front of the application.

Backend Service for the App

Start with a normal internal Service for the workload.

1apiVersion: v1
2kind: Service
3metadata:
4  name: web-app
5spec:
6  selector:
7    app: web-app
8  ports:
9    - port: 80
10      targetPort: 8080
11  type: ClusterIP

ClusterIP is appropriate because the service does not need to be exposed directly to the outside world. The ingress controller will talk to it inside the cluster.

Add an Ingress Resource

The ingress defines which hostnames and paths should route to that service.

1apiVersion: networking.k8s.io/v1
2kind: Ingress
3metadata:
4  name: web-app-ingress
5spec:
6  ingressClassName: nginx
7  rules:
8    - host: app.example.internal
9      http:
10        paths:
11          - path: /
12            pathType: Prefix
13            backend:
14              service:
15                name: web-app
16                port:
17                  number: 80

If you want HTTPS termination at the ingress layer, add TLS:

1spec:
2  ingressClassName: nginx
3  tls:
4    - hosts:
5        - app.example.internal
6      secretName: web-app-tls
7  rules:
8    - host: app.example.internal
9      http:
10        paths:
11          - path: /
12            pathType: Prefix
13            backend:
14              service:
15                name: web-app
16                port:
17                  number: 80

This still does not expose 80 and 443 to the outside network by itself. It defines routing once traffic reaches the ingress controller.

Give the Ingress Controller an On-Prem Address

In cloud environments, LoadBalancer services are often automatic. On-prem, you need something that can provide or forward a reachable IP.

One common option is MetalLB. It lets LoadBalancer services work on bare metal or local networks by assigning addresses from a configured pool.

A typical ingress controller service with MetalLB looks like this:

1apiVersion: v1
2kind: Service
3metadata:
4  name: ingress-nginx-controller
5  namespace: ingress-nginx
6spec:
7  type: LoadBalancer
8  selector:
9    app.kubernetes.io/name: ingress-nginx
10  ports:
11    - name: http
12      port: 80
13      targetPort: 80
14    - name: https
15      port: 443
16      targetPort: 443

If MetalLB assigns an address such as 192.168.1.240, external traffic to that IP on 80 and 443 reaches the ingress controller.

Alternative: External Reverse Proxy or Firewall NAT

If you do not want MetalLB, an external reverse proxy or firewall can forward traffic from 80 and 443 to a NodePort or directly to ingress-controller nodes.

That pattern often looks like this:

• ingress controller runs in the cluster
• ingress service is exposed as NodePort
• firewall or load balancer forwards public 80 and 443 to those node ports

Example ingress controller service:

1apiVersion: v1
2kind: Service
3metadata:
4  name: ingress-nginx-controller
5  namespace: ingress-nginx
6spec:
7  type: NodePort
8  ports:
9    - name: http
10      port: 80
11      targetPort: 80
12      nodePort: 30080
13    - name: https
14      port: 443
15      targetPort: 443
16      nodePort: 30443

An edge firewall can then map external 80 to 30080 and external 443 to 30443 on one or more cluster nodes.

DNS and TLS Still Matter

Even when networking is correct, the service is not truly usable until DNS and certificates match the public entry point.

Typical checklist:

• point DNS at the external IP or proxy
• ensure port 80 and or 443 are open on the firewall
• install the correct TLS secret if HTTPS is terminated in Kubernetes
• verify the ingress hostname matches what clients will request

Without these pieces, the cluster may be reachable but still fail at the application level.

Common Pitfalls

The most common mistake is exposing the application Service directly and expecting standard public 80 and 443 behavior without an ingress or other edge component. Another is using LoadBalancer on-prem without MetalLB or an equivalent network implementation, which leaves the service pending forever. Teams also often forget that DNS, certificates, and firewall rules are part of service exposure, not optional extras. A final issue is treating NodePort as a full internet-facing solution when it is usually only one piece of a larger edge-routing design.

Summary

• On-prem Kubernetes needs an explicit edge design to expose services on 80 and 443.
• A common pattern is ClusterIP backend service plus ingress controller plus MetalLB or external forwarding.
• 'Ingress handles host and path routing, not public reachability by itself.'
• MetalLB can provide on-prem LoadBalancer behavior for ingress controller services.
• DNS, TLS, and firewall rules must all line up with the network exposure plan.