Ingress on Custom Kubernetes

FOLIO XV 2018-05-16 · 6 MIN · SHORT-FORM

Ingress on Custom Kubernetes

Setting up ingress-nginx on a custom cluster.

Diagram · folio xv

flowchart TB
  EXT([External user])
  EXT --> LB[LoadBalancer or NodePort]
  LB --> ING[Ingress-nginx Controller pod]
  ING --> RULES{host / path rules}
  RULES -->|app1.example.com| S1[Service: app1]
  RULES -->|app2.example.com| S2[Service: app2]
  RULES -->|/api| S3[Service: api]
  S1 --> P1[(app1 pods)]
  S2 --> P2[(app2 pods)]
  S3 --> P3[(api pods)]

There are more than a handful of ways to set up port 80 and 443 web ingress on a custom Kubernetes cluster. Specifically a bare metal cluster. If you are looking to experiment or learn on a non-production cluster, but something more true to production than minikube, I suggest you check out my previous article Production Hobby Cluster, a step-by-step guide for setting up a custom production capable Kubernetes cluster.

This article builds on the Production Hobby Cluster guide. The following closely follows the official deploy ingress installation guide with a few adjustments suitable for the Production Hobby Cluster, specifically the use of a DaemonSet rather than a Deployment and leveraging hostNetwork and hostPort for the Pods on our DaemonSet. There are quite a few ingress nginx examples in the official repository if you are looking for a more specific implementation.

By now you may be managing multiple clusters. kubectl is a great tool to use on your local workstation to manage remote clusters, and with little effort you can quickly point it to a new cluster and switch between them all day. Check out my article kubectl Context Multiple Clusters for a quick tutorial.

§2026 Update

Two big things changed under this post, and both matter before you follow it.

First, the controller it installs is retired. The community ingress-nginx project was wound down, with maintenance ending in March 2026 and no further security patches (the IngressNightmare CVEs in 2025 were part of the story). I cover that in more detail in “413 Request Entity Too Large”. If you are standing up something new, look at the Gateway API or another maintained controller instead. The DaemonSet-with-hostNetwork pattern below is still a perfectly good way to claim ports 80 and 443 on bare metal, and most maintained controllers and Gateway implementations support it, usually paired with MetalLB to provide a real LoadBalancer service. The mechanics translate; the specific manifests do not.

Second, the Ingress API itself moved on. The extensions/v1beta1 Ingress used in the example near the end of this post was removed in Kubernetes 1.22 (2021). The current API is networking.k8s.io/v1, and the spec changed shape: serviceName and servicePort became a structured service.name and service.port.number, pathType is now required, and you set ingressClassName instead of the old annotation. Here is that same route in the current form:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ok
  labels:
    app: ok
    system: test
spec:
  ingressClassName: nginx
  rules:
  - host: ok.la.txn2.net
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: ok
            port:
              number: 8080

The manual, multi-gist install below (namespace, default backend, config maps, RBAC, DaemonSet) is dated too. By the end of its life, ingress-nginx shipped as a single manifest or a Helm chart. Treat the steps below as a 2018 snapshot of how the pieces fit together, useful for understanding, not for a fresh install.

Archived: the original 2018 post follows. The walkthrough below deploys the now-retired ingress-nginx using the removed extensions/v1beta1 Ingress API. It is kept for the archives and no longer reflects current practice. Use the 2026 Update above for the working setup.