一场纠结，事关Microk8s，Alpine和kubedns
事情开始的很简单，并没有显露出日后狰狞的面孔。
我试图创建一个k8s的环境，用于测试和学习，选项不多：
- Microk8s（https://microk8s.io/）：Ubuntu安装非常简单
- Minikube（https://github.com/kubernetes/minikube）：得装一个Hypervisor，kvm或者virtualbox。
- Kind (https://github.com/kubernetes-sigs/kind)： 非常新，也很简单。
鬼才知道我为啥选择了Microk8s，不过后来的事实证明，选Kind，路途也不会平坦，但比起Miicrok8s，就是坦途了。
Microk8s安装非常简单，除了microk8s.kubectl需要用snap（https://tutorials.ubuntu.com/tutorial/basic-snap-usage#0）做个转换。
但很快发现了问题，我用于测试的Tekton-pipeline（https://github.com/tektoncd/pipeline）的例子死活跑不通，一直在保无法解析github.com, 这就奇怪了，难道k8s cluster中没有dns？一看还真是！
问题一：
Microk8s默认不启动kubedns，需要使用microk8s.enable dns， kubedns才会启动。
好吧，但是启动以后仍然不能解析，首先用kubectl exec登入不能工作的pod container， 使用ping 8.8.8.8（机器在墙外），是通的但是ping google.com得到的是bad address 'google.com'， 看来是DNS的问题了。
cat /etc/resolv.conf
nameserver 100.64.0.10
search namespace.svc.cluster.local svc.cluster.local cluster.local eu-west-1.compute.internal
options ndots:5大概是这样， nameserver所配置的ip是我kubedns的service，没有问题。
search domain开起来也还好
options ndots:引起了我的怀疑， 查了查(https://pracucci.com/kubernetes-dns-resolution-ndots-options-and-why-it-may-affect-application-performances.html)：
这个设置表示被解析的hostname中的点（.）数目如果超过该值，那么就直接解析该hostname，否则，解析hostname.${search domain}, 举个例子www.google.com, 因为点(.)的数目是2 < 5, 那么会依次尝试解析:
www.google.com.namespace.svc.cluster.local
www.google.com..svc.cluster.local
www.googl.com.cluster.local
www.google.com.en-west-1.computer.internal
www.google.com
这里就非常想知道直接解析www.google.com是什么结果，很简单，删掉options ndots:5 这个选项。结果是，通的!
接着开始怀疑是container镜像的问题，为了简化问题，抛弃了tekton，徒手创建了一个image是alpine的pod，发现同样的问题。
接着使用busybox做镜像，神奇的是没有问题，然后又换为ubuntu，也没问题，难道问题真处在alpine身上。
好吧，赶紧又找了一个k8s cluster，非Microk8s，神奇的事情继续发生，alpine和其他测试镜像都是OK的！
这使我陷入了沉思，难道得Microk8s背这个锅？
事情没那么简单，既然是DNS处的错，会不会问题在kubedns上呢？
赶紧查了查Microk8s的kubedns的镜像，呵呵，alpine，再查查那个正常cluster的kubedns，也是alpine，事情又陷入僵局。
找了找google，哈，还真是得alpine背：
https://github.com/kubernetes/kubernetes/issues/30215
https://github.com/gliderlabs/docker-alpine/issues/8
https://seanj.dev/post/alpine-kubernetes-dns/
https://github.com/gliderlabs/docker-alpine/issues/255
https://forums.docker.com/t/resolved-service-name-resolution-broken-on-alpine-and-docker-1-11-1-cs1/19307
什么叫做罄竹难书，这个问题从alpine3.3开始一直到现在都没解决，最后逼得有人发出警告，在k8s中请谨慎使用alpine。
可是alpine为啥不fix呢，原来这个问题来自musl libc（https://www.musl-libc.org/intro.html）
https://github.com/rancher/rancher/issues/5041
https://bugs.alpinelinux.org/issues/9017
怎么说呢，锅还是要有人被的，火速去Microk8s开了个issue：
https://github.com/ubuntu/microk8s/issues/493
怎么说呢，最后用以为无奈的程序员的打油诗结尾：
https://www.reddit.com/r/homelab/comments/5i6kza/a_haiku_about_dns/?st=j6vq0tcs&sh=f8e9032c