Many years ago there were a small enough machines on the Internet that everybody remembered their names and IP address. Later, this became a single file (hosts.txt) that was shared around. Life was good, shag carpet was considered in-style, and bell-bottoms pretty-neat. Disco ruled.
Fast forward to the early 80’s. DNS was invented. It scaled by a few key inventions: subdomains (so local administration could occur), and zone-files that were locally managed with some central authority to indirectly point there by top-level domain.
Along the way we got more users. The ‘eternal september‘ happened, bringing the proletariat AOL users into the bourgeoisie usenet. Browsers happened. People started to expect to refer to hostname (kittenwar.com). And this meant DNS got a lot of use. IP’s became things you knew existed, but didn’t remember (just like phone numbers, you got a contact list instead of dialing the digits).
And then suddenly a wild cloud appeared. Things are orchestrated all over, cloud native, short life span, yada yada. But, there’s still a bit of an expectation that DNS works. Some tools (e.g. Apache Zookeeper) went a different way than cloud native, allowing you to register a name as being ‘up’ and the other hosts would then contact you.
No problem, I got this. kube-dns, Deployment, work well together, right? Turns out no. If you read this issue you’ll see they only implemented this for StatefulSet, not Deployment. In a StatefulSet you can create a special Service called a ‘headless’ that has ClusterIP: None, and some magic of domain and subdomain set in the Pod template. But, in a Deployment, you can’t set the hostname, and thus you cannot set DNS.
Stalemate. I want to run Druid in Kubernetes. Druid wants to use Zookeeper rather than Kubernetes for service discovery. Zookeeper wants to use hostnames. So I either make each type of thing a StatefulSet instead of Deployment, or…
Sigh.
Leave a Reply