kubernetes 提供了 service 的概念可以通过 VIP 访问 pod 提供的服务，但是在使用的时候还有一个问题：怎么知道某个应用的 VIP？比如我们有两个应用，一个 app，一个 是 db，每个应用使用 rc 进行管理，并通过 service 暴露出端口提供服务。app 需要连接到 db 应用，我们只知道 db 应用的名称，但是并不知道它的 VIP 地址。
最简单的办法是从 kubernetes 提供的 API 查询。但这是一个糟糕的做法，首先每个应用都要在启动的时候编写查询依赖服务的逻辑，这本身就是重复和增加应用的复杂度；其次这也导致应用需要依赖 kubernetes，不能够单独部署和运行（当然如果通过增加配置选项也是可以做到的，但这又是增加负责度）。
开始的时候，kubernetes 采用了 docker 使用过的方法——环境变量。每个 pod 启动时候，会把通过环境变量设置所有服务的 IP 和 port 信息，这样 pod 中的应用可以通过读取环境变量来获取依赖服务的地址信息。这种方式服务和环境变量的匹配关系有一定的规范，使用起来也相对简单，但是有个很大的问题：依赖的服务必须在 pod 启动之前就存在，不然是不会出现在环境变量中的。
更理想的方案是：应用能够直接使用服务的名字，不需要关心它实际的 ip 地址，中间的转换能够自动完成。名字和 ip 之间的转换就是 DNS 系统的功能，因此 kubernetes 也提供了 DNS 方法来解决这个问题。
DNS 服务不是独立的系统服务，而是一种 addon ，作为插件来安装的，不是 kubernetes 集群必须的（但是非常推荐安装）。可以把它看做运行在集群上的应用，只不过这个应用比较特殊而已。
DNS 有两种配置方式，在 1.3 之前使用 etcd + kube2sky + skydns 的方式，在 1.3 之后可以使用 kubedns + dnsmasq 的方式。
本章节主要讲述kubedns+dnsmasq的部署方式
在 kubernetes 1.3 版本之后，kubernetes 改变了 DNS 的部署方式，变成了 kubeDNS + dnsmasq，没有了 etcd 。在这种模式下，kubeDNS 是原来 kube2sky + skyDNS + etcd，只不过它把数据都保存到自己的内存，而不是 kv store 中；dnsmasq 的引进是为了提高解析的速度，因为它可以配置 DNS 缓存。
虽然k8s启动一个rc会从指定地址下载镜像，如果搭建私有云，一般我比较喜欢先下载镜像到本地，然后push到自己的私有镜像仓库，后面使用比较方便速度更快
docker pull index.tenxcloud.com/google_containers/kubedns-amd64:v1.3
docker pull index.tenxcloud.com/google_containers/dnsmasq-amd64:v1.1
docker pull index.tenxcloud.com/google_containers/exechealthz-amd64:v1.0
不管以什么方式启动，对外的效果是一样的。要想使用 DNS 功能，还需要修改 kubelet的启动配置项，告诉 kubelet，给每个启动的 pod 设置对应的 DNS 信息，一共有两个参数：--cluster_dns=10.1.10.10 --cluster_domain=cluster.local，分别是 DNS 在集群中的 vip 和域名后缀，要和 DNS rc 中保持一致（rc见后面章节）。
下面是这种方式的部署配置文件（完整版请见附件kubedns-rc.yaml）：
第23，24行的是镜像拉取的密钥，为了保证在每个node上都可以拉取到私有仓库的镜像。其中，第24行的registrybaidu.registrykey是通过如下命令生成的密钥key（结果都是存储在etcd中）
kubectl create secret docker-registry registrybaidu.registrykey --docker-server= registry.baidu.com --docker-username=lixiaodong --docker-password=wZu9GZvFWa4lGb --docker-email=lixiaodong@ baidu.com --namespace=kube-system
如上的命令会生成一个密钥相关的字符串经过base64编码后在k8s中存储，如下图的。
就是dockercfg字段：eyJyZWdpc3RyeS5iYWlkdS5jb20iOnsidXNlcm5hbWUiOiJsaXhpYW9kb25nIiwicGFzc3dvcmQiOiJ3WnU5R1p2RldhNGxHYiIsImVtYWlsIjoibGl4aWFvZG9uZ0BiYWlkdS5jb20iLCJhdXRoIjoiYkdsNGFXRnZaRzl1WnpwM1duVTVSMXAyUmxkaE5HeEhZZz09In19
把这串字符串放入一个文件secret64文件中，通过base64 -d secret64可以看到内容，如下
其中，auth字段是通过docker login registry.baidu.com登录后在~/.docker/config.json中的registry.baidu.com下的值，如下图
如上命令是我为registry.baidu.com这个镜像仓库，以及lixiaodong/wZu9GZvFWa4lGb这个账户密码生成的。
kubectl get secret
可以看看所有生成的key，如下图
这里有两个需要根据实际情况配置的地方：
kube_master_url： kubedns 会用到 kubernetes master API，它会读取里面的 service 信息domain：域名后缀，跟kubelet添加的启动参数cluster_domain一致，默认是 cluster.local，你可以根据实际需要修改成任何合法的值启动kubedns-rc.yaml：
$ kubectl create -f ./kubedns-rc.yml参看是否启动成功：
$ kubectl get pod --namespace=kube-system 
见附件kubedns-svc.yaml
这里需要注意的是 clusterIP: 10.1.10.10 这一行手动指定了 DNS service 的 IP 地址，这个地址必须在预留的 vip 网段（见kubernetes最佳实践（一） - 集群部署的3.4节）。
手动指定的原因是为了固定这个 ip，这样启动 kubelet 的时候配置 --cluster_dns=10.1.10.10 比较方便（2.2节的kubelet启动参数），不需要再动态获取 DNS 的 vip 地址。
有了这两个文件，直接创建对象就行：
$ kubectl create -f ./kubedns-svc.yml 
启动成功。
不管那种部署很是，kubernetes 对外提供的 DNS 服务是一致的。每个 service 都会有对应的 DNS 记录，kubernetes 保存 DNS 记录的格式如下：
<service_name>.<namespace>.svc.<domain>
每个部分的字段意思：
cluster.local
在 pod 中可以通过 service_name.namespace.svc.domain 来访问任何的服务，也可以使用缩写 service_name.namespace，如果 pod 和 service 在同一个 namespace，甚至可以直接使用 service_name。
NOTE：正常的 service 域名会被解析成 service vip，而 headless service 域名会被直接解析成背后的 pods ip。
虽然不会经常用到，但是 pod 也会有对应的 DNS 记录，格式是 pod-ip-address.<namespace>.pod.<domain>，其中 pod-ip-address 为 pod ip 地址的用 - 符号隔开的格式，比如 pod ip 地址是 1.2.3.4 ，那么对应的域名就是 1-2-3-4.default.pod.cluster.local。
busybox镜像中有nslookup命令，如果自己的pod里面有nslookup命令也可以使用
下载镜像：docker pull index.tenxcloud.com/google_containers/busybox:latest
执行附件中的busybox-rc.yaml
$ kubectl create -f busybox-rc.yaml
进入容器内部查看dns是否配置成功
$ docker exec -it 637a21082cd9 /bin/sh
查看容器内部的resolve.conf文件（resolve.conf是linux上的DNS域名解析的配置文件，机器内部域名寻址先到resolve.conf查找，然后再到外部dns查找）
$ more /etc/resolve.conf
看到如下，已经按照3.2节的规则在容器的resolv.conf中生成域名搜索规则以及域名服务器地址（刚好是我们配置kubedns的service clusterIp地址，也是2.2节在kubelet中配置的cluster_dns地址），说明配置正确
看基于kubedns配置的域名是否生效（按照），找个已存在的service实验下，就用k8s默认启动的kubernetes这个service
可以看出，如果我们在默认的 namespace default 创建了名为 kubernetes 的服务，以下所有域名都能被正确解析：
kubernetes
kubernetes.default.svc
kubernetes.default.svc.cluster.local我们前面介绍了两种不同 DNS 部署方式，这部分讲讲它们内部的原理。
这种模式下主要有三个容器在运行：
[root@localhost ~]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
919cbc006da2 172.16.1.41:5000/google_containers/kube2sky:1.12 "/kube2sky /kube2sky " About an hour ago Up About an hour k8s_kube2sky.80a41edc_kube-dns-twl0q_kube-system_ea1f5f4d-15cf-11e7-bece-080027c09e5b_1bd3fdb4
73dd11cac057 172.16.1.41:5000/jenkins/etcd:live "etcd -data-dir=/var/" About an hour ago Up About an hour k8s_etcd.4040370_kube-dns-twl0q_kube-system_ea1f5f4d-15cf-11e7-bece-080027c09e5b_b0e5a99f
0b10ae639989 172.16.1.41:5000/jenkins/skydns:20150703-113305 "bootstrap.sh" About an hour ago Up About an hour k8s_skydns.73baf3b1_kube-dns-twl0q_kube-system_ea1f5f4d-15cf-11e7-bece-080027c09e5b_2860aa6d
这三个容器的作用分别是：
这种模式下，kubeDNS 容器替代了原来的三个容器的功能，它会监听 apiserver 并把所有 service 和 endpoints 的结果在内存中用合适的数据结构保存起来，并对外提供 DNS 查询服务。
每种模式都可以运行额外的 exec-healthz 容器对外提供 health check 功能，证明当前 DNS 服务是正常的。
/healthz 结果推荐使用 kubeDNS 的模式来部署，因为它有着以下的好处：
参考文献：http://cizixs.com/2017/04/11/kubernetes-intro-kube-dns
http://tonybai.com/2016/10/23/install-dns-addon-for-k8s/
http://blog.csdn.net/iiiiher/article/details/77099059
https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/