{"id":237,"date":"2026-03-16T14:55:58","date_gmt":"2026-03-16T12:55:58","guid":{"rendered":"https:\/\/blog.twis7.com\/?p=237"},"modified":"2026-03-16T14:55:58","modified_gmt":"2026-03-16T12:55:58","slug":"one-public-ipv4-many-kubernetes-apps","status":"publish","type":"post","link":"https:\/\/blog.twis7.com\/index.php\/2026\/03\/16\/one-public-ipv4-many-kubernetes-apps\/","title":{"rendered":"One Public IPv4, Many Kubernetes Apps"},"content":{"rendered":"\n

I have an on-premise Kubernetes cluster <\/a>with persistent storage<\/a>. Now it\u2019s time to find a way to expose my applications to the internet.<\/p>\n\n\n\n

I only have a single public IPv4 address and a \/24 private subnet behind NAT, managed by OPNsense. This means I\u2019ll need a few creative (and slightly dirty) hacks to make everything work.<\/p>\n\n\n\n

I\u2019m starting to realize how much the cloud has spoiled me. Without unlimited load balancers and public IP addresses, things quickly become a bit more complex.<\/p>\n\n\n\n

For this setup, my main tools will be MetalLB<\/a> and NGINX Ingress<\/a>. NGINX Ingress will be retired soon, and I plan to replace it in the near future. However, for a home lab environment it will work just fine for now.<\/p>\n\n\n\n

This setup is far from perfect, so don\u2019t try this in real production.<\/p>\n\n\n\n\n\n\n\n

\"\"
Network diagram. I will use wordpress as an app example<\/figcaption><\/figure>\n\n\n\n

Traffic Flow Summary:<\/p>\n\n\n\n

    \n
  • User visits https:\/\/blog.yourdomain.com<\/code><\/li>\n\n\n\n
  • DNS resolves to your PUBLIC IP<\/code><\/li>\n\n\n\n
  • Router\/NAT forwards :443 \u2192 172.16.17.200:443 (MetalLB Virtual IP)<\/code><\/li>\n\n\n\n
  • MetalLB delivers to NGINX Ingress Controller pod<\/code><\/li>\n\n\n\n
  • Ingress Controller matches Host: blog.yourdomain.com<\/code><\/li>\n\n\n\n
  • Terminates TLS (cert from cert-manager\/Let's Encrypt)<\/code><\/li>\n\n\n\n
  • Proxies plain HTTP to wordpress-svc:80<\/code><\/li>\n\n\n\n
  • Service routes to a WordPress pod<\/code> (ClusterIP Service<\/strong><\/em>)<\/li>\n<\/ul>\n\n\n\n

    Why just do not install ngnix ingress controller and connect it with ClusterIp service ? Why I need MetalLB?<\/em><\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n


    The Ingress Controller is just a pod inside your cluster. Pods get internal IPs like 10.244.x.x that nobody outside the cluster can reach. MetalLB gives the Ingress Controller a real IP on your network(node network 172.16.17.0\/24) that external machines can reach. MetalLB is NOT a load balancer like AWS application load balancer. It just assigns an IP address. The NGINX Ingress Controller does ALL the real work \u2014 it is my load balancer and NGINX in one. The name “MetalLB” is misleading. It’s really just “MetalIP” \u2014 it makes a virtual IP exist on my bare-metal network. Nothing more<\/strong>.<\/p>\n\n\n\n

      \n
    1. You install MetalLB
      \u2192 It watches for Services of type LoadBalancer
      \u2192 It has a pool: 172.16.17.200-172.16.17.210<\/li>\n\n\n\n
    2. You install NGINX Ingress Controller
      \u2192 It creates a Service of type LoadBalancer<\/strong>
      \u2192 Kubernetes says: “I need an external IP for this Service”<\/strong><\/li>\n\n\n\n
    3. MetalLB sees the request
      \u2192 Assigns 172.16.17.200 from its pool
      \u2192 Starts answering ARP: “I own 172.16.17.200”<\/li>\n\n\n\n
    4. Traffic to 172.16.17.200:80
      \u2192 MetalLB directs it to the Service
      \u2192 Service forwards to NGINX Ingress pod
      \u2192 NGINX reads Host header, routes to app
      They Don’t Know About Each Other!<\/strong><\/li>\n<\/ol>\n\n\n\n

      My cluster uses Calico for CNI. Before starting make sure it will not interfere with MetalLB<\/p>\n\n\n\n

      <\/circle><\/circle><\/circle><\/g><\/svg><\/span>