What does HackerNews think of external-dns?
Configure external DNS servers (AWS Route53, Google CloudDNS and others) for Kubernetes Ingresses and Services
I think this is an unfair summary of the post. Of course, using Kubernetes to orchestrate other AWS services is going to be a go-to example on the _AWS_ blog, but there is plenty of vendor-agnostic software doing similar things: DNS Records[1], Databases[2], even using Kubernetes CRDs to deploy Kubernetes[3].
The idea of using Kubernetes as an API to orchestrate external resources doesn't inherently lock you into any single vendor.
1: https://github.com/kubernetes-sigs/external-dns 2: https://github.com/kubedb/operator 3: https://cluster-api.sigs.k8s.io/
As for DNS records, external-dns[2] works perfectly as long as your DNS as some way to doing automatic updates.
Yes, I need to add A records with IPs for each domain, but that's one time setup. I did it manually, but you can automate it [1] (depends on what you use for DNS provider but you can extend it to support your provider or maybe there is another existing solution).
I'm not sure that one server in front of the cluster is more reliable than using all cluster nodes for load balancing. I guess that in automated solutions like [1] cluster's node could be automatically deleted from DNS if it went down.
My setup is not so big so I don't have real need for load balancing, but it seems possible with existing solutions.
I see this sentiment quite a lot that k8s is too complex for small scale setups, but in my experience it scales down very well to small setups. Granted, you do have to know how to work with k8s, but once you learn that you can apply that knowledge to many different kinds of setups like k0s, bare metal, EKS/AKS etc.
Maybe, although if you're fully happy with your current setup then probably not unless you just want to explore and learn new things.
I use kubernetes "at home" (ok, well it's an OVH server, but I use it for personal/home stuff), and I like it. I happen to run a wide variety of apps for myself and friends, already used docker, and I was somewhat reaching the limits of docker compose.
I really like the consistent ecosystem, and that k8s cleanly deals with problems like TLS termination with LE[1] and automatically updating my DNS[2]. I like that I can just write down what I want in a YAML file and don't have to mess around with docker commands or package managers or what else.
It's not for everyone, but I wouldn't say there's no value in it, especially if you're already using containers or a similar tool.
There is! I use external-dns. [1]
I haven't actually set up a Let's Encrypt wildcard cert, but I'm pretty certain cert-manager [2] supports it. I don't think you need a proxy if you use the DNS01 challenges.
For instance: https://github.com/kubernetes-sigs/aws-alb-ingress-controlle...
Also, and you probably already know about this, but it's true that ingress won't create the record automatically for you - but external-dns ( https://github.com/kubernetes-sigs/external-dns ) will - with the correct annotations (pretty simple), external-dns will watch for changes to ingress and publish the dns records on R53 (and many other DNS providers) for you. It works really well for us, even when the subdomain is shared with other infrastructure not managed by itself.
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.