KubernetesDNS的示例分析-乐山大橙子建站

新闻中心

这里有您想知道的互联网营销解决方案

KubernetesDNS的示例分析

这篇文章给大家分享的是有关Kubernetes DNS的示例分析的内容。小编觉得挺实用的，因此分享给大家做个参考，一起跟随小编过来看看吧。

创新互联服务紧随时代发展步伐，进行技术革新和技术进步，经过十多年的发展和积累，已经汇集了一批资深网站策划师、设计师、专业的网站实施团队以及高素质售后服务人员，并且完全形成了一套成熟的业务流程，能够完全依照客户要求对网站进行成都网站建设、网站制作、建设、维护、更新和改版，实现客户网站对外宣传展示的首要目的，并为客户企业品牌互联网化提供全面的解决方案。

环境

$ sudo lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 16.04.2 LTS
Release:	16.04
Codename:	xenial

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.4", GitCommit:"7243c69eb523aa4377bce883e7c0dd76b84709a1", GitTreeState:"clean", BuildDate:"2017-03-07T23:53:09Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.4", GitCommit:"7243c69eb523aa4377bce883e7c0dd76b84709a1", GitTreeState:"clean", BuildDate:"2017-03-07T23:34:32Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"}

介绍

从Kubernetes 1.3开始，DNS通过使用插件管理系统cluster add-on，成为了一个内建的自启动服务。
　　Kubernetes DNS在Kubernetes集群上调度了一个DNS Pod和Service，并配置kubelet，使其告诉每个容器使用DNS Service的Ip来解析DNS名称。

什么是DNS名称

集群中定义的每个Service（包括DNS Service它自己）都被分配了一个DNS名称。默认的，Pod的DNS搜索列表中会包含Pod自己的命名空间和集群的默认域，下面我们用示例来解释以下。
　　假设有一个名为foo的Service，位于命名空间bar中。运行在bar命名空间中的Pod可以通过DNS查找foo关键字来查找到这个服务，而运行在命名空间quux中的Pod可以通过关键字foo.bar来查找到这个服务。

支持的DNS模式

下面的章节详细的描述了支持的记录（record）类型和layout。

Services

普通（非headless）的Service都被分配了一个DNS记录，该记录的名称格式为my-svc.my-namespace.svc.cluster.local，通过该记录可以解析出服务的集群IP。
　　Headless（没有集群IP）的Service也被分配了一个DNS记录，名称格式为my-svc.my-namespace.svc.cluster.local。与普通Service不同的是，它会解析出Service选择的Pod的IP列表。

SRV records

SRV records用于为命名端口服务，这些端口是headless或者普通Service的一部分。对于每个命名端口，SRV record的格式为：_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster.local。对于普通服务来说，这会解析出端口号和CNAMEmy-svc.my-namespace.svc.cluster.local。对于headless服务来说，这会解析出多个结果，一个是service后端的每个pod，一个是包含端口号，和格式为auto-generated-name.my-svc.my-namespace.svc.cluster.local的pod的CNAME。

向后兼容性

kube-dns的之前版本，使用了格式为my-svc.my-namespace.cluster.local（svc这一层是后面加上的）的名称。但这种格式不再被支持了。

Pods

pod会被分配一个DNS记录，名称格式为pod-ip-address.my-namespace.pod.cluster.local。
　　比如，一个pod，它的IP地址为1.2.3.4，命名空间为default，DNS名称为cluster.local，那么它的记录就是：1-2-3-4.default.pod.cluster.local。
　　当pod被创建时，它的hostname设置在Pod的metadata.name中（写yaml的时候应该很清楚这点）。
　　在v1.2版本中，用户可以指定一个Pod注解，pod.beta.kubernetes.io/hostname，用于指定Pod的hostname。这个Pod注解，一旦被指定，就将优先于Pod的名称，成为pod的hostname。比如，一个Pod，其注解为pod.beta.kubernetes.io/hostname: my-pod-name，那么该Pod的hostname会被设置为my-pod-name。
　　v1.2中还引入了一个beta特性，用户指定Pod注解，pod.beta.kubernetes.io/subdomain，来指定Pod的subdomain。比如，一个Pod，其hostname注解设置为“foo”，subdomain注解为“bar”，命名空间为“my-namespace”，那么它最终的FQDN就是“foo.bar.my-namespace.svc.cluster.local”。
　　在v1.3版本中，PodSpec有了hostname和subdomain字段，用于指定Pod的hostname和subdomain。它的优先级则高于上面提到的pod.beta.kubernetes.io/hostname和pod.beta.kubernetes.io/subdomain。
　　示例：

apiVersion: v1
kind: Service
metadata:
  name: default-subdomain
spec:
  selector:
    name: busybox
  clusterIP: None
  ports:
    - name: foo # Actually, no port is needed.
      port: 1234 
      targetPort: 1234
---
apiVersion: v1
kind: Pod
metadata:
  name: busybox1
  labels:
    name: busybox
spec:
  hostname: busybox-1
  subdomain: default-subdomain
  containers:
  - image: busybox
    command:
      - sleep
      - "3600"
    name: busybox
---
apiVersion: v1
kind: Pod
metadata:
  name: busybox2
  labels:
    name: busybox
spec:
  hostname: busybox-2
  subdomain: default-subdomain
  containers:
  - image: busybox
    command:
      - sleep
      - "3600"
    name: busybox

如果一个headless service中，多个pod都在同一个命名空间里，并且subdomain名称也相同，集群的KubeDNS还是会为每个Pod返回完整而合格的hostname。给定一个Pod，其hostname设置为busybox-1，subdomain设置为default-subdomain，同一个命名空间中的headless Service名为default-subdomain，那么pod自己的FQDN就是“busybox-1.default-subdomain.my-namespace.svc.cluster.local”。
　　在Kubernetes v1.2里，Endpoint对象还使用了注解endpoints.beta.kubernetes.io/hostnames-map。它的值就是json格式中的map[string(IP)][endpoints.HostRecord]，比如 ‘{“10.245.1.6”:{HostName: “my-webserver”}}’。如果Endpoint是用于headless service的，就会为其创建一个格式为...svc的记录。以json格式为例，如果Endpoint用于名为“bar”的headless service，其中一个Endpoint的ip为“10.245.1.6”，就会创建一个名为“my-webserver.bar.my-namespace.svc.cluster.local”的记录，查询该记录就会得到“10.245.1.6”。这个Endpoint注解一般不需要终端用户来指定，但可以被内部服务控制器使用，来实现上面的特性。
　　在v1.3中，Endpoint对象可以为任何一个Endpoint指定hostname和IP。hostname字段会覆盖endpoints.beta.kubernetes.io/hostnames-map注解的值。
　　在v1.3中，以下注解被弃用了：pod.beta.kubernetes.io/hostname，pod.beta.kubernetes.io/subdomain， endpoints.beta.kubernetes.io/hostnames-map。

如何测试DNS是否工作

创建一个简单地Pod，使用测试环境

创建一个名为busybox.yaml文件，使用下面的内容：

apiVersion: v1
kind: Pod
metadata:
  name: busybox
  namespace: default
spec:
  containers:
  - image: busybox
    command:
      - sleep
      - "3600"
    imagePullPolicy: IfNotPresent
    name: busybox
  restartPolicy: Always

使用该文件创建pod：

kubectl create -f busybox.yaml

等待pod进入running状态

获取pod状态：

$ kubectl get pods busybox

你会看到：

NAME      READY     STATUS    RESTARTS   AGE
busybox   1/1       Running   0          7m

确认DNS是否工作

一旦pod处于running状态时，可以使用exec nslookup来查询状态：

$ kubectl exec -ti busybox -- nslookup kubernetes.default

你应该看到类似的结果：

Server:    10.0.0.10
Address 1: 10.0.0.10

Name:      kubernetes.default
Address 1: 10.0.0.1

如果出现上述结果，则说明DNS正常工作。

故障排查

如果nslookup失败，检查以下选项：

检查本地DNS配置

检查pod的resolv.conf文件。

$ kubectl exec busybox cat /etc/resolv.conf

确认搜索路径和name sever被设置成类似下面的样子（注意搜索路径可能因云提供商不同而有所差异）：

search default.svc.cluster.local svc.cluster.local cluster.local google.internal c.gce_project_id.internal
nameserver 10.0.0.10
options ndots:5

快速诊断

如下的错误表明kube-dns add-on或者相关服务有问题：

$ kubectl exec -ti busybox -- nslookup kubernetes.default
Server:    10.0.0.10
Address 1: 10.0.0.10

nslookup: can't resolve 'kubernetes.default'

或者

$ kubectl exec -ti busybox -- nslookup kubernetes.default
Server:    10.0.0.10
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local

nslookup: can't resolve 'kubernetes.default'

检查DNS pod是否运行

使用kubectl get pods命令来确认DNS pod是否正在运行。

$ kubectl get pods --namespace=kube-system -l k8s-app=kube-dns

应该会有如下的结果：

NAME                                                       READY     STATUS    RESTARTS   AGE
...
kube-dns-v19-ezo1y                                         3/3       Running   0           1h
...

如果没有相关的pod运行，或者pod状态为failed/completed，那么就说明你的环境下，没有默认部署DNS add-on，你需要手动部署它。

检查DNS pod中的错误

使用kubectl log命令来查看DNS守护程序的日志。

$ kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c kubedns
$ kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c dnsmasq
$ kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c healthz

如果有任何可疑的日志，每一行开头的W，E，F字母分别表示警告、错误和故障。请搜索这些错误日志的条目，或者通过kubernetes issues页面来报错非预期的错误。

DNS服务是否启动

使用kubectl get service命令来查看DNS服务是否已经启动。

$ kubectl get svc --namespace=kube-system

你会看到：

NAME                    CLUSTER-IP     EXTERNAL-IP   PORT(S)             AGE
...
kube-dns                10.0.0.10              53/UDP,53/TCP        1h
...

该服务会默认地被创建，或者如果你手动创建了该服务，但是该服务却并没有在上述命令中出现，请查看 debugging services page页面获取更多信息。

是否暴露了DNS Endpoint？

可通过kubectl get endpoints命令来确认是否暴露了DNS Endpoint。

$ kubectl get ep kube-dns --namespace=kube-system

你应该会看到下面的结果：

NAME       ENDPOINTS                       AGE
kube-dns   10.180.3.17:53,10.180.3.17:53    1h

如果没有看到Endpoint，那么请查看debugging services page页面。
　　若要查看更多的Kubernetes DNS示例，请在Kubernetes Github仓库中查看cluster-dns examples。

如何工作

运行的Kubernetes DNS pod包含3个容器——kubedns、dnsmasq和一个叫做healthz的健康检查容器。kubedns进程监视Kubernetes master上Service和Endpoint的改变，并在内存中维护lookup 结构用于服务DNS请求。dnsmasq容器增加DNS缓存，从而提升性能。healthz容器提供一个单点的健康检查Endpoint，检查dnsmasq和kubedns的健康程度。
　　DNS pod以服务的形式暴露出来，它拥有一个静态IP。一旦被创建，kubelet就使用--cluster-dns=10.0.0.10标识，将DNS配置信息传递给每个容器。
　　DNS名称也需要域。本地域是可以配置的，在kubelet中，使用--cluster-domain=参数。
　　Kubernetes集群的DNS服务（基于SkyDNS库）支持forward lookup（A recoreds），service lookup（SRV records）和反向IP地址查找（PTR recoreds）。

从node继承DNS

当运行pod时，kubelet会预先考虑集群的DNS服务，并在node本地的DNS设置中搜索路径。如果node能够解析DNS名称，那么pod也可以做到。
　　如果你希望在pod中使用不同的DNS，那么你可以使用kubelet的--resolv-conf参数。该设置意味着pod不会从node继承DNS。设置该值为其他的文件路径，意味着会使用该文件来配置DNS，而不是/etc/resolv.conf。

已知的问题

Kubernetes安装默认并不会使用集群的DNS配置来设置Kubernetes node的resolv.conf文件，因为该进程依赖于发行版的配置。
　　Linux的libc有着3个DNS nameserver和6个DNS搜索记录的限制，Kubernetes需要消耗一个nameserver和3个搜索记录。这意味着如果一个本地配置已经使用了3个nameserver或者使用了3个以上的搜索记录，那么这些配置可能会丢失。有一个临时方案，node可以运行dnsmasq，它可以提供更多的nameserver选项，但不能提供更多的搜索选项。你也可以使用kubelet的--resolv-conf选项。
　　如果你使用的是Alpine 3.3或更早的版本，DNS可能不能正常的工作，这是已知的问题。

感谢各位的阅读！关于“Kubernetes DNS的示例分析”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，让大家可以学到更多知识，如果觉得文章不错，可以把它分享出去让更多的人看到吧！

标题名称：KubernetesDNS的示例分析
文章路径：http://lswzjz.com/article/ghepep.html