Ingress Controllers

The simplest way to expose a Kubernetes service to the internet is type: LoadBalancer. Each service gets its own cloud load balancer. Easy, until you have 20 microservices. That's 20 load balancers, each costing ~$20/month, with 20 different public IP addresses, 20 SSL certificates to manage, and 20 DNS records to maintain.

An Ingress Controller is a single entry point, one load balancer, that routes HTTP traffic to different services based on the URL path or hostname. api.example.com goes to the API service. app.example.com goes to the web app. api.example.com/payments goes to the payments service. One load balancer, one IP, one wildcard SSL certificate.

It's the same concept as a reverse proxy (Nginx, HAProxy) but managed through Kubernetes-native YAML manifests, with automatic service discovery and TLS certificate management.

Two pieces:

1. Ingress Resource: A YAML manifest defining routing rules
2. Ingress Controller: A pod running a reverse proxy (Nginx, Traefik, etc.) that reads Ingress resources and configures itself

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: main-ingress
 annotations:
 cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
 tls:
 - hosts: ["api.example.com", "app.example.com"]
 secretName: tls-secret
 rules:
 - host: api.example.com
 http:
 paths:
 - path: /
 pathType: Prefix
 backend:
 service:
 name: api-service
 port:
 number: 80
 - host: app.example.com
 http:
 paths:
 - path: /
 pathType: Prefix
 backend:
 service:
 name: web-service
 port:
 number: 80