K8S 运维技巧--DNS 部分;

一.自定义dns ;

1.介绍;
2.怎样获取dns 名字;
3.支持的 DNS 模式;
4.自定义dns;

1.介绍

Kubernetes DNS 在群集上调度 DNS Pod 和服务，并配置 kubelet 以告知各个容器使用 DNS 服务的 IP 来解析 DNS 名称。

2.怎样获取 DNS 名字;

在集群中定义的每一个 Service（包括 DNS 服务器自身）都会被指派一个 DNS 名称。 默认，一个客户端 Pod 的 DNS 搜索列表将包含该 Pod 本身的 Namespace 和集群默认域。 经过以下示例能够很好地说明：

假设在 Kubernetes 集群的 Namespace bar 中，定义了一个Service foo。 运行在Namespace bar 中的一个 Pod，能够简单地经过 DNS 查询 foo 来找到该 Service。 运行在 Namespace quux 中的一个 Pod 能够经过 DNS 查询 foo.bar 找到该 Service。

如下各节详细介绍了受支持的记录类型和支持的布局。 其中代码部分的布局，名称或查询命令均被视为实现细节，若有更改，恕不另行通知。 有关最新规范请查看 Kubernetes 基于 DNS 的服务发现.

3.支持的 DNS 模式

下面各段详细说明支持的记录类型和布局。 若是任何其它的布局、名称或查询，碰巧也可以使用，这就须要研究下它们的实现细节，以避免后续修改它们又不能使用了。

Service

A 记录

“正常” Service（除了 Headless Service）会以 my-svc.my-namespace.svc.cluster-domain.example 这种名字的形式被指派一个 DNS A 记录。 这会解析成该 Service 的 Cluster IP。

“Headless” Service（没有Cluster IP）也会以 my-svc.my-namespace.svc.cluster-domain.example 这种名字的形式被指派一个 DNS A 记录。 不像正常 Service，它会解析成该 Service 选择的一组 Pod 的 IP。 但愿客户端可以使用这一组 IP，不然就使用标准的 round-robin 策略从这一组 IP 中进行选择。

SRV 记录

命名端口须要建立 SRV 记录，这些端口是正常 Service或 Headless Services 的一部分。 对每一个命名端口，SRV 记录具备 _my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster-domain.example 这种形式。 对普通 Service，这会被解析成端口号和 CNAME：my-svc.my-namespace.svc.cluster-domain.example。 对 Headless Service，这会被解析成多个结果，Service 对应的每一个 backend Pod 各一个， 包含 auto-generated-name.my-svc.my-namespace.svc.cluster-domain.example 这种形式 Pod 的端口号和 CNAME。

Pods

Pod的 hostname 和 subdomain 字段

当前，建立 Pod 后，它的主机名是该 Pod 的 metadata.name 值。

在 v1.2 版本中，用户能够配置 Pod annotation， 经过 pod.beta.kubernetes.io/hostname 来设置 Pod 的主机名。 若是为 Pod 配置了 annotation，会优先使用 Pod 的名称做为主机名。 例如，给定一个 Pod，它具备 annotation pod.beta.kubernetes.io/hostname: my-pod-name，该 Pod 的主机名被设置为 “my-pod-name”。

在 v1.3 版本中，PodSpec 具备 hostname 字段，能够用来指定 Pod 的主机名。这个字段的值优先于 annotation pod.beta.kubernetes.io/hostname。 在 v1.2 版本中引入了 beta 特性，用户能够为 Pod 指定 annotation，其中 pod.beta.kubernetes.io/subdomain 指定了 Pod 的子域名。 最终的域名将是 “...svc.”。 举个例子，Pod 的主机名 annotation 设置为 “foo”，子域名 annotation 设置为 “bar”，在 Namespace “my-namespace” 中对应的 FQDN 为 “foo.bar.my-namespace.svc.cluster.local”。

在 v1.3 版本中，PodSpec 具备 subdomain 字段，能够用来指定 Pod 的子域名。 这个字段的值优先于 annotation pod.beta.kubernetes.io/subdomain 的值。

4.Pod 的 DNS 设定

Pod 的 DNS 配置可以让用户对 Pod 的 DNS 设置进行更多控制。

dnsConfig 字段是可选的，它能够与任何 dnsPolicy 设置一块儿使用。 可是，当 Pod 的 dnsPolicy 设置为 “None” 时，必须指定 dnsConfig 字段。

用户能够在 dnsConfig 字段中指定如下属性：

• nameservers: 将用做于 Pod 的 DNS 服务器的 IP 地址列表。最多能够指定3个 IP 地址。 当 Pod 的 dnsPolicy 设置为 “None” 时，列表必须至少包含一个IP地址，不然此属性是可选的。列出的服务器将合并到从指定的 DNS 策略生成的基本名称服务器，并删除重复的地址。

• searches: 用于在 Pod 中查找主机名的 DNS 搜索域的列表。此属性是可选的。指定后，提供的列表将合并到根据所选 DNS 策略生成的基本搜索域名中。 重复的域名将被删除。    Kubernetes最多容许6个搜索域。

• options: 对象的可选列表，其中每一个对象可能具备 name 属性（必需）和 value 属性（可选）。 此属性中的内容将合并到从指定的 DNS 策略生成的选项。 重复的条目将被删除。

• 
  

如下是具备自定义DNS设置的Pod示例

(1).dns yaml 配置详细;

(2).运行dns ymal

(3).测试解析dns;

(4).建立上面的Pod后，容器 test 会在其 /etc/resolv.conf 文件中获取如下内容:

二.经过 kube-dns 配置私有dns;

1.准备开始
2.配置存根域和上游 DNS 服务器
3.理解 Kubernetes 中名字解析
4.ConfigMap 选项

在 Kubernetes 中配置私有 DNS 和上游域名服务器

准备开始

• 你必须拥有一个 Kubernetes 的集群，同时你的 Kubernetes 集群必须带有 kubectl 命令行工具。 若是你尚未集群，你能够经过 Minikube 构建一 个你本身的集群，或者你可使用下面任意一个 Kubernetes 工具构建：

• Katacoda

• Play with Kubernetes

要获知版本信息，请输入 kubectl version.

• Kubernetes 1.6 及其以上版本。

• 集群必须配置使用 kube-dns 插件。

配置存根域和上游 DNS 服务器

部署kube-dns 步骤以下;

(1).获取:kube-dns yaml

wget https://raw.githubusercontent.com/feiskyer/kubernetes-handbook/master/manifests/kubedns/kube-dns.yaml 

(2).设置 kube-dns.yaml  clusterIP 集群ip地址 （参考:kubernetes 网断中未使用ip地址）

kubectl get service --all-namespaces 

(3).注意kube-dns 镜像须要进行进行获取;

经过为 kube-dns （kube-system:kube-dns）提供 ConfigMap，集群管理员可以指定自定义存根域和上游域名服务器。

例如，下面的 ConfigMap 创建了一个 DNS 配置，它具备一个单独的存根域和两个上游域名服务器：

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"]

按如上说明，具备 “.acme.local” 后缀的 DNS 请求被转发到 DNS 1.2.3.4。Google 公共 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 选项 获取更多关于配置选项格式的详细信息。

理解 Kubernetes 中名字解析

能够为每一个 Pod 设置 DNS 策略。 当前 Kubernetes 支持两种 Pod 特定的 DNS 策略：“Default” 和 “ClusterFirst”。 能够经过 dnsPolicy 标志来指定这些策略。 注意：“Default” 不是默认的 DNS 策略。若是没有显式地指定 dnsPolicy，将会使用 “ClusterFirst”。

“Default” DNS 策略

若是 dnsPolicy 被设置为 “Default”，则名字解析配置会继承自 Pod 运行所在的节点。 自定义上游域名服务器和存根域不可以与这个策略一块儿使用。

“ClusterFirst” DNS 策略

若是 dnsPolicy 被设置为 “ClusterFirst”，处理名字解析有所不一样，*依赖因而否配置了存根域和上游 DNS 服务器*。

未进行自定义配置：没有匹配上配置的集群域名后缀的任何请求，例如 “www.kubernetes.io”，将会被转发到继承自节点的上游域名服务器。

进行自定义配置：若是配置了存根域和上游 DNS 服务器（相似于 前面示例 配置的内容），DNS 查询将基于下面的流程对请求进行路由：

1. 查询首先被发送到 kube-dns 中的 DNS 缓存层。

2. 从缓存层，检查请求的后缀，并根据下面的状况转发到对应的 DNS 上：

• *具备集群后缀的名字*（例如 “.cluster.local”）：请求被发送到 kube-dns。

• *具备存根域后缀的名字*（例如 “.acme.local”）：请求被发送到配置的自定义 DNS 解析器（例如：监听在 1.2.3.4）。

• *未能匹配上后缀的名字*（例如 “widget.com”）：请求被转发到上游 DNS（例如：Google 公共 DNS 服务器，8.8.8.8 和 8.8.4.4）。

ConfigMap 选项

kube-dns kube-system:kube-dns 对应的 ConfigMap 选项以下所示：

字段	格式	描述
stubDomains（可选）	使用 DNS 后缀做为键（例如 “acme.local”）的 JSON map，以及由 DNS IP 的 JSON 数组组成的值。	目标域名服务器多是一个 Kubernetes Service。例如，能够运行本身的 dnsmasq 副本，将 DNS 名字暴露到 ClusterDNS namespace 中。
upstreamNameservers（可选）	DNS IP 的 JSON 数组。	注意：若是指定，则指定的值会替换掉被默认从节点的 /etc/resolv.conf 中获取到的域名服务器。限制：最多能够指定三个上游域名服务器。

附加示例

示例：存根域

在这个例子中，用户有一个 Consul DNS 服务发现系统，他们但愿可以与 kube-dns 集成起来。 Consul 域名服务器地址为 10.150.0.1，全部的 Consul 名字具备后缀 “.consul.local”。 要配置 Kubernetes，集群管理员只须要简单地建立一个 ConfigMap 对象，以下所示：

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

注意，集群管理员不但愿覆盖节点的上游域名服务器，因此他们不会指定可选的 upstreamNameservers 字段。

示例：上游域名服务器

在这个示例中，集群管理员不但愿显式地强制全部非集群 DNS 查询进入到他们本身的域名服务器 172.16.0.1。 并且这很容易实现：他们只须要建立一个 ConfigMap，upstreamNameservers 字段指按期望的域名服务器便可：

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