Deploying multiple Traefik Ingresses with LetsEncrypt HTTPS certificates on Kubernetes
--
As detailed on my first article, I’ve set an architecture for Kubernetes to be as similar to “production” as possible even being run on small ARM boards.
Here I will detail the network where I use Weaveworks Net as the overlay and focus on the LoadBalancer and Ingress controllers.
Network Topology
IP Plan
Network: 192.168.1.0/24Gateway: 192.168.1.1
DNS: 192.168.1.1 (running dnsmasq on DD-WRT Router)
Router DHCP range: 192.168.1.101 - 192.168.1.200Reserved: 192.168.1.2 - 192.168.1.15* 192.168.1.1 - Router
* 192.168.1.3 - Managed Switch
* 192.168.1.4 - RPi3 (media server)Kubernetes Nodes:
- Master1: 192.168.1.50
- Node1: 192.168.1.55
- Node2: 192.168.1.56MetalLB CIDR: 192.168.1.16/28
- 192.168.1.17 - 192.168.1.30Traefik Internal Ingress IP: 192.168.1.20
Traefik External Ingress IP: 192.168.1.21
As detailed in the architecture above, I’ve deployed two Traefik instances to the cluster. One instance to serve the local requests in the internal wildcard domain managed in my router and another Traefik instance to serve the external requests coming from the internet thru a wildcard domain configured in my external DNS.
These instances have separate service IP addresses and each instance have it’s own ingress rules.
To allow external access, I’ve configured my external DNS server, managed by my domain registrar, to resolve all calls to the external domain *.cloud.domain.com using a wildcard entry. This “A” entry can be dynamically updated by the DynDNS config in the router and the CNAME points the wildcard to the A record.
Another option in case you use GoDaddy as registrar/DNS is generating their API key and using this project to dynamically update the subdomain used here. I’ve created a deployment and configMap to run a pod updater.
