kubernetes最佳实践(三) - kubedns部署

最新推荐文章于 2025-04-09 20:52:41 发布

男孩NoBad

最新推荐文章于 2025-04-09 20:52:41 发布

阅读量984

点赞数

分类专栏： kubernetes 文章标签： docker kubernetes k8s

本文链接：https://blog.youkuaiyun.com/lixiaodong037/article/details/79279100

版权

kubernetes 专栏收录该内容

4 篇文章

订阅专栏

1. 服务发现

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 方法来解决这个问题。

2. 部署 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 缓存。

2.1 先下载用到的三个镜像

虽然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

2.2 修改 kubelet 启动参数

不管以什么方式启动，对外的效果是一样的。要想使用 DNS 功能，还需要修改 kubelet的启动配置项，告诉 kubelet，给每个启动的 pod 设置对应的 DNS 信息，一共有两个参数：--cluster_dns=10.1.10.10 --cluster_domain=cluster.local，分别是 DNS 在集群中的 vip 和域名后缀，要和 DNS rc 中保持一致（rc见后面章节）。

2.3 kubedns-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

2.4 kubedns-svc service文件启动

见附件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

启动成功。

3. 测试 DNS 可用性

3.1 dns域名规则

不管那种部署很是，kubernetes 对外提供的 DNS 服务是一致的。每个 service 都会有对应的 DNS 记录，kubernetes 保存 DNS 记录的格式如下：

 
  <service_name>.<namespace>.svc.<domain>

每个部分的字段意思：

service_name: 服务名称，就是定义 service 的时候取的名字
namespace：service 所在 namespace 的名字
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。

3.2 运行busybox pod验证dns

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 
 

4. kubernetes DNS 原理解析

我们前面介绍了两种不同 DNS 部署方式，这部分讲讲它们内部的原理。

4.1 kube2sky 模式

这种模式下主要有三个容器在运行：

 
  [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
 
 

这三个容器的作用分别是：

etcd：保存所有的 DNS 数据
kube2sky：通过 kubernetes API 监听 Service 的变化，然后同步到 etcd
skyDNS：根据 etcd 中的数据，对外提供 DNS 查询服务

4.2 kubeDNS 模式

这种模式下，kubeDNS 容器替代了原来的三个容器的功能，它会监听 apiserver 并把所有 service 和 endpoints 的结果在内存中用合适的数据结构保存起来，并对外提供 DNS 查询服务。

kubeDNS：提供了原来 kube2sky + etcd + skyDNS 的功能，可以单独对外提供 DNS 查询服务
dnsmasq：一个轻量级的 DNS 服务软件，可以提供 DNS 缓存功能。kubeDNS 模式下，dnsmasq 在内存中预留一块大小（默认是 1G）的地方，保存当前最常用的 DNS 查询记录，如果缓存中没有要查找的记录，它会到 kubeDNS 中查询，并把结果缓存起来

每种模式都可以运行额外的 exec-healthz 容器对外提供 health check 功能，证明当前 DNS 服务是正常的。