Hacker News Reader

Comment by tachion | Hacker News Reader

What I miss from all of these tutorials is one very important piece - how to handle network routing and dns automation within your home network, that's in typical scenario is being handled by the ingress/cloud controller. Without having automated (or easy enough) way of reaching the apps you're deploying there, each of these clusters is pretty much useless for users except for maybe learning basics of k8s, what's easier done with minikube.

View on HN

I use MetalLB to allocate RFC1918 IPs out of a dedicated pool to LoadBalancer services. MetalLB then publishes these to my router over BGP because, you know, why not?

I then have external-dns running (https://github.com/kubernetes-sigs/external-dns) which manages the relevant A/CNAME records on Google DNS (other DNS providers are supported) so that I can resolve "myservice.mydomain.com" to the service's IP address.

I wrote a bit about the BGP bit last year: https://www.growse.com/2019/04/13/at-home-with-kubernetes-me...

Admittedly, I have no desire to expose any of these service to the internet, but if I did I could use an IPv6 address on the service instead, or add a static NAT rule to the router to forward traffic to the service IPv4 address. Auto provisioning of NAT rules feels icky, so I'd probably go down the ipv6 route if I wanted to do this.

Thanks for pointing it out - I tried to cover this area and drew a diagram, but on second through, I don't think I managed to do it justice.

I have a static LAN IP for an Ingress Controller, say 192.168.2.100. All HTTP/HTTPS requests are port-forwarded to it from my router. From there, the Ingress is in charge of directing the request based on domain name.

As for DNS, I use a single domain name, and have a record for a wildcard subdomain - so any subdomain will end up at my router, I don't have to configure anything at my DNS registrar when I add yet another application, as long as it's using a subdomain.

ExternalDNS is a superior solution, but most people will only have 1 or 2 domain names.

Few things to do:

- specify a LAN IP for your ingress controller so it doesn't change.

- Use ddwrt/dnsmasq to point *.k8s.myhomenetwork.local to said IP

Once that's configured, you just configure the ingress hostname on services as you would "normally".

Also - do not use .local tld. It is a reserved one (RFC6762), for mDNS/Bonjour:

> This document specifies that the DNS top-level domain ".local." is a special domain with special semantics, namely that any fully qualified name ending in ".local." is link-local, and names within this domain are meaningful only on the link where they originate. This is analogous to IPv4 addresses in the 169.254/16 prefix or IPv6 addresses in the FE80::/10 prefix, which are link-local and meaningful only on the link where they originate.

Microsoft used to recommend .local TLD for AD deployment as a best practice, and nowadays there are companies stuck with this decision. Do not make the same mistake; unlike companies, you probably want your zeroconf stuff to work.

So what breaks if you use "*.[lastname].local" for your home network?

On zeroconf aware systems, it is still expected to be resolved via multicast; service discovery works by looking up srv/ptr/txt records on __$service.__$protocol.$hostname.local.

How it will behave will depend on your specific stack. Zeroconf aware (Macs, iOS devices, Linux with Avahi - i.e. most modern distributions) one will use multicast, zeroconf unaware (Windows) will use your DNS resolver. Devices (printers, etc) are a toss of a coin.

I'd like to note that a default behavior of Avahi in Debian/Ubuntu/RH/SUSE prevents resolving *.local via unicast DNS to avoid this collision.

Iirc, the last time I looked into this, .test is the recommended TLD to use because it’s reserved for non-production use I.e. it will never be bought or sold.

I use dynamic DNS with my Edgemax router. Something like inlets operator or cloudflare Argo are other options.

I think the OP might be more asking about how to get local DNS automatically provisioned with the IP address of a service/container that has been deployed to the LAN.

That's exactly what I meant. I know how to do it myself, but then again I'm not the target for these articles, but when I read them with the mindset of someone who is supposed to have a use of them, that's always the big missing bit for me.

Did davestephen's comment help though? Apart from suggesting a .local domain... that's a bad idea, try .lan instead.

Then you could type (for Plex, for example) plex.k8s.lan

Maybe we need the equivalent of traefik for DNS?

https://news.ycombinator.com/item?id=23040478

I know how to solve this problem, so I wasn't commenting on his comment, but rather on the fact that none of these tutorials so far solve this problem for new users that they target.

Aside from that, I don't think what he proposes is a great solution, because what we'd need is the automated way for deployments to get that DNS created (or announced) for their IP when they get it or when it changes. Having it done manually and being static is vastly different in usability from k8s does with ingress/cloud controllers.

Dns is part of stock k8s. It usually runs on the 10th ip of the services network.

It's the first service that goes up after you've initialized the cluster and initially serves only internal requests.

Nothing stops you from pointing the matching lookup zone to the internal dns of k8s, however. I've done it before and it worked great for lan requests.

If you want to expose it to the internet however, an automatically configured dns is probably not what you want, unless you actually have a public ip range to use with said services. In that case, the original comment makes more sense and you'd just add a wildcard dns to your ingress controller, which can be traefic or whatever else you want

Reply on news.ycombinator.com