dns | 伪架构师

实测：Kubernetes 1.6 中的混合 DNS

Sat, 03 Jun 2017 08:39:03 +0800

在之前的文章中提到过，Kubernetes 1.6 新增的混合 DNS 功能。这一功能不大，但是在企业私有云环境下有着非常重要的衔接作用，能够有效的将 Kubernetes 内的应用和集群外甚至互联网上的的 Consual 或者类似系统管理的服务连接起来，形成更好的协同效果。

上篇文章主要侧重点是概念和一些 YAML 例子，本文则会从操作出发，用一个例子从头到尾的逐步操作这一功能的具体操作。

DNS Server

我们使用一个 Ubuntu Server 运行 dnsmasq 来担任 Kubernetes 集群外的 DNS 服务器角色，只为了满足测试需要的话，就不需要太复杂的配置了。

安装

具体安装步骤如下：

#!/bin/sh
# 安装 dnsmasq
apt install dnsmasq
# 停止自动启动的 dnsmasq 服务
systemctl stop dnsmasq
# 生成一个 Host 文件并写入一条记录
echo " 114.114.114.114 server.out-of.kubernetes" > /tmp/hosts
# 显示 IP
ifconfig
# 启动 DNS 服务
# -d 用 debug 模式启动，在前台运行
# -q 输出查询记录
# -h 不使用 /etc/hosts
# -R 不使用 /etc/resolve.conf
# -H 使用刚才生成的文件作为 dns 记录
dnsmasq -q -d -h -q -R -H /tmp/hosts

这样，我们就启动了一个 DNS 服务器，并且可以直观的看到其工作状况如下：

dnsmasq: started, version 2.76 cachesize 150
dnsmasq: compile time options: IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC lo
op-detect inotify
dnsmasq: warning: no upstream servers configured
dnsmasq: bad address at /tmp/hosts line 1
dnsmasq: read /tmp/hosts - 0 addresses

Kubernetes 配置

前文说过，我们需要用一个 Configmap 对象来让 Kubernetes 应用新的 DNS 解析配置，这里我们简单的新建一个存根域，就是上文提到的 out-of.kubernetes 域名，让其使用我们前面安装的 DNS 服务器进行解析，其他域名则使用 8.8.8.8 和 8.8.4.4 这一公共 DNS 解析。配置情况如下：

apiVersion: v1
kind: ConfigMap
metadata:
  name: kube-dns
  namespace: kube-system
data:
  stubDomains: |
    {"out-of.kubernetes": ["10.140.0.5"]}
  upstreamNameservers: |
    ["8.8.8.8", "8.8.4.4"]

利用 kubectl apply -f 命令使之生效。

注意：系统可能缺省带有这一 configmap，因此需要用 apply 进行操作，建议使用 kubectl get configmap kube-dns -o yaml --namespace kube-system 进行复查。

测试 Pod

这里使用一个 Alpine Linux 的镜像作为测试工具：

apiVersion: v1
kind: Pod
metadata:
  name: tester
spec:
  containers:
  - name: alpine
    image: alpine
    imagePullPolicy: IfNotPresent
    command: ["sleep"]
    args: ["3600"]

测试

测试 Pod 运行之后，可以使用kubectl exec -it tester sh命令进入 Pod开始测试。

在 Pod 的 Shell 中我们可以尝试执行 ping server.out-of.kubernetes，会看到返回了我们写入在 Hosts 中的地址，在 DNS 服务器端，也会看到相关的查询记录。
如果 ping 其他的主机名，则会返回正常的结果。

在 Kubernetes（1.6）中配置私有 DNS 区域以及上级域名服务

Sat, 03 Jun 2017 01:43:33 +0800

原文：Configuring Private DNS Zones and Upstream Nameservers in Kubernetes

很多用户都有自己的域名区域，并且希望能够集成到 Kubernetes DNS 的命名空间去。例如混合云用户可能希望能在集群内解析他们内部的 “.corp” 。其他用户用户可能有一个受非 Kubernetes管理的服务发现系统（例如 Consul）。我们在 Kubernetes 1.6 中推出了新功能，kube-dns 添加了可配置的私有 DNS 区域（通常称为存根域）以及外部的上级域名服务，本文将会讲解如何使用这一功能。

Kubernetes 目前在 Pod 定义中支持两个 DNS 策略：Default和ClusterFirst，dnsPolicy缺省为ClusterFirst：

如果dnsPolicy设置为Default，那么域名解析配置会从 Pod 所在节点继承而来。注意，本文所述功能在dnsPolicy设置为Default时无效。
如果dnsPolicy设置为ClusterFirst，DNS 查询会被发送到 kube-dns 服务。kube-dns 服务负责相应以集群域名为后缀（例如.cluster.local）的查询。其他的域名查询（例如 www.kubernetes.io ）会被转发给来自节点定义的上级域名服务器。

在这一功能推出之前，通常需要利用替换上级 DNS 为自定义解析的方式来完成存根域查询。然而这就使得这个自定义域名解析器成为 DNS 解析过程中的一个高风险因素。本功能让用户能够无需对整个 DNS 路径进行改造就完成自定义解析过程。

自定义 DNS 流程

从 Kubernetes 1.6 开始，集群管理员能够利用 ConfigMap 指定自定义的存根域以及上级 NameServer。下文的配置包含一个存根域和两个上级域名服务器。对域名后缀为.aceme.local的查询会被发送到地址为 1.2.3.4 的 DNS 服务。另外会把 Google 公共 DNS 作为上级服务器。注意本节末尾对 ConfigMap 中的数据格式进行的解释。


apiVersion: v1
kind: ConfigMap
metadata:
  name: kube-dns
  namespace: kube-system
data:
  stubDomains: |
    {"acme.local": ["1.2.3.4"]}
  upstreamNameservers: |
    ["8.8.8.8", "8.8.4.4"]

下图显示了配置中所指示的 DNS 查询过程。当dnsPolicy设置为ClusterFirst时，DNS 查询首先被发送到 kube-dns 的 DNS 缓存层。从这里开始检查域名后缀，然后发送到指定的 DNS。在本例中，集群后缀的域名（.cluster.local），被发送到 kube-dns，最后不符合上面后缀的其他查询被转发到上级 DNS 去进行解析。

下文表格用来说明域名解析的过程：

域名	解析服务
kubernetes.default.svc.cluster.local	kube-dns
foo.acme.local	自定义 DNS（1.2.3.4）
widget.com	上级 DNS（8.8.8.8 和 8.8.4.4）中的一个

ConfigMap 配置说明

stubDomains (可选)
- 格式：一个 JSON 编码的 Map 格式，其 Key 为 DNS 后缀（也就是acme.local），值是一个 JSON 数组，代表一组 DNS IP。
- 注意：目标域名服务器也可以是 Kuernetes 服务。例如可以用 dnsmasq 把自定义 DNS 导出到 ClusterDNS 的命名空间中。
upstreamNameservers
- 格式：一个 DNS IP 组成的 JSON 数组。
- 注意：如果指定了这个值，那么从节点的 /etc/resolv.conf 继承过来的值就会被覆盖。
- 限制：最多可以指定三个。

例 1：添加一个 Consul DNS 存根域

这个例子中，用户希望把 Consul DNS 服务集成到 kube-dns。Consul 服务位于10.150.0.1，所有的 consul 命名后缀都是.consul.local。Kubernetes 管理员简单的创建一个ConfigMap对象就可以完成。注意：本例中管理员不想覆盖节点的上级 DNS 定义，所以不需要指定upstreamNameservers：

apiVersion: v1
kind: ConfigMap
metadata:
  name: kube-dns
  namespace: kube-system
data:
  stubDomains: |
    {"consul.local": "10.150.0.1"}

例 2：替换上级 Nameserver

这个例子中，集群管理员希望所有的集群外 DNS 查询由172.16.0.1的服务来完成，同样的用一个 ConfigMap 完成：

apiVersion: v1
kind: ConfigMap
metadata:
  name: kube-dns
  namespace: kube-system
data:
  upstreamNameservers: |
    ["172.16.0.1"]