一个纠正coredns在初始化失败重新部署的博客

前言：  在之前的实验中，有在deployment的部署中遇到了，在pod  pod之间无法相互的解析，甚至不能识别对应的域名的问题，那么也是遇到了很多种自己设想的可能性（  在filebeat种的 无法识别 以为是没有安装redis 而后安装了也没有成功） 后来在pod内部的nslookup也无法验证成功，后来使用dig验证的时候也是失败的，就在想这是为什么？  而后查看镜像，在查看名称空间kube-system的时候发现 coredns的状态并没有被Running，想到了可能是没有部署好 coredns ，原因：镜像拉取失败，那么在services之间的相互联系的pod之间是通过域名进行解析的内部的IP，假如没有DNS可能就导致本身的交互并不能被正确的识别这样。

由于coredns导致的dig 不出来的错误示例：

示例1：  在dig的时候出错，并不能成功的解析域名对应的ip

[root@server1 ~]# dig -t A myapp-svc.default.svc.cluster.local. @10.96.0.1

; <<>> DiG 9.9.4-RedHat-9.9.4-37.el7 <<>> -t A myapp-svc.default.svc.cluster.local. @10.96.0.1
;; global options: +cmd
;; connection timed out; no servers could be reached

示例2： 在nslookup的时候也不能成功的解析

[root@server1 ~]# kubectl exec -it redis-5b5d6fbbbd-bfs6j -- /bin/sh

/data # nslookup redis.default.svc.cluster.local 

nslookup: can't resolve '(null)': Name does not resolve

nslookup: can't resolve 'redis.default.svc.cluster.local': Try again

查看kube-system下的控制器以及相关的状态 ：      我们发现在查看pod的过程中coredns不论在哪个节点上都没有Running

[root@server1 ~]# kubectl get pods -n kube-system -o wide
NAME                              READY     STATUS             RESTARTS   AGE       IP             NODE
coredns-78fcdf6894-r94mq          0/1       ImagePullBackOff   0          1d        10.244.2.68    server3
coredns-78fcdf6894-v5nrt          0/1       ImagePullBackOff   0          1d        10.244.1.72    server2

因此我们测试一下上面的dig是不是因为coredns的失败而没有成功，

下来我们寻找方法来对coredns进行运行，因为镜像在国外，所以我们可以事先使用 docker load 读取镜像，但是之前的这些步骤都是在初始化k8s的时候做的，现在想要重新识别可能就不仅仅是把镜像load就好了，

思路1： 看coredns的状态，没有被重启过，再想有没有可能我们把这个pod重启一下，或者是dploy会自动的创建满足目标副本数的pod，那么还可以删除当前的pod，看会不会被自动的创建，然后就识别成功了 ，先选择 简单一点的方法，删除它，

在删除的时候我们要指定名称空间，因为coredns并不在默认的名称空间中，

[root@server1 ~]# kubectl delete pod coredns-78fcdf6894-r94mq -n kube-system
pod "coredns-78fcdf6894-r94mq" deleted
[root@server1 ~]# kubectl delete pod coredns-78fcdf6894-v5nrt -n kube-system
pod "coredns-78fcdf6894-v5nrt" deleted

在查看的时候我们发现镜像正在被拉取，不知道能不能成功............

[root@server1 ~]# kubectl get pod -n kube-system
NAME                              READY     STATUS             RESTARTS   AGE
coredns-78fcdf6894-wfz2f          0/1       ImagePullBackOff   0          2m
coredns-78fcdf6894-z759r          0/1       ImagePullBackOff   0          1m

注：  那么在查看的过程中我发现这个进行的拉取一直在进行，要不然就会显示 ErrImagePull

那么是不是拉取的镜像本身不存在，还是说我们在拉取的过程中出现了错误 ：

那么我们来查看一下coredns本身的镜像到底是什么：

[root@server1 ~]# kubectl describe pods -n kube-system  coredns-78fcdf6894-wfz2f

    Image:         k8s.gcr.io/coredns:1.1.3
    Image ID:      

    State:          Waiting
      Reason:       ErrImagePull

在给出的信息中，我们发现kubelet在server3的节点上拉取coredns的镜像的时候提示没有网，所以拉取不成功，

  Warning  Failed     5m               kubelet, server3   Failed to pull image "k8s.gcr.io/coredns:1.1.3": rpc error: code = Unknown desc = Error response from daemon: Get https://k8s.gcr.io/v2/: dial tcp: lookup k8s.gcr.io on 114.114.114.114:53: read udp 172.25.254.3:53299->114.114.114.114:53: i/o timeout

解决： 我们在server3上导入coredns的镜像：

[root@server3 ~]# docker load -i coredns.tar
5bef08742407: Loading layer  4.221MB/4.221MB
594f5d257cbe: Loading layer  9.335MB/9.335MB
53cb05deeb1b: Loading layer  32.66MB/32.66MB
Loaded image: k8s.gcr.io/coredns:1.1.3

再次查看的时候我们发现 coredns 已经被运行起来了 ：

[root@server1 ~]# kubectl get pod -n kube-system
NAME                              READY     STATUS             RESTARTS   AGE
coredns-78fcdf6894-wfz2f          1/1       Running            0          10m

但是另外一个coredns并没有被启动起来原因可能是，没有镜像的拉取。

coredns-78fcdf6894-z759r          0/1       ImagePullBackOff   0          10m

我们查看它的coredns被分配在哪个节点上：   同样我们在看coredns的另一个pod时发现，它时位于server2上的部署，因此我们应该在srever2上拉取coredns的镜像。

  Warning  Failed     11m                kubelet, server2   Failed to pull image "k8s.gcr.io/coredns:1.1.3": rpc error: code = Unknown desc = Error response from daemon: Get https://k8s.gcr.io/v2/: dial tcp: lookup k8s.gcr.io on 114.114.114.114:53: read udp 172.25.254.2:41128->114.114.114.114:53: i/o timeout

[root@server2 ~]# docker load -i coredns.tar
5bef08742407: Loading layer  4.221MB/4.221MB
594f5d257cbe: Loading layer  9.335MB/9.335MB
53cb05deeb1b: Loading layer  32.66MB/32.66MB
Loaded image: k8s.gcr.io/coredns:1.1.3

我们再次查看是否成功：   那么我们看到coredns的两个pod都已经被成功的Running了 。

[root@server1 ~]# kubectl get pod -n kube-system
NAME                              READY     STATUS    RESTARTS   AGE
coredns-78fcdf6894-wfz2f          1/1       Running   0          14m
coredns-78fcdf6894-z759r          1/1       Running   0          14m

那么我们可以测试一下dig是否正确呢？

[root@server1 ~]#  dig -t A myapp-svc.default.svc.cluster.local. @10.96.0.10

; <<>> DiG 9.9.4-RedHat-9.9.4-37.el7 <<>> -t A myapp-svc.default.svc.cluster.local. @10.96.0.10
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39381
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;myapp-svc.default.svc.cluster.local. IN    A

;; ANSWER SECTION:
myapp-svc.default.svc.cluster.local. 5 IN A    10.244.1.70
myapp-svc.default.svc.cluster.local. 5 IN A    10.244.1.71
myapp-svc.default.svc.cluster.local. 5 IN A    10.244.1.73
myapp-svc.default.svc.cluster.local. 5 IN A    10.244.2.65
myapp-svc.default.svc.cluster.local. 5 IN A    10.244.2.66

;; Query time: 1 msec
;; SERVER: 10.96.0.10#53(10.96.0.10)
;; WHEN: Sat May 11 18:44:54 CST 2019
;; MSG SIZE  rcvd: 319

总结： 在此次的错误中，首先是dig不成功，然后是nslookup不能用，那么就一直找原因，首先出现的第一个原因是：我一直觉得是master上没有coredns的镜像，所以检查了很久，发现有但是没有进行进一步的排查，其次因为思维的局限性，那么自己一直觉得那个coredns在master上安装呢，所以没有查看别的节点上的。

那么在查看的空间的空城话中，有显示过pod位于server2和server3上部署，但是自己并没有注意到，这是一个失误，其次在发现容器的镜像拉取错误时，不能善于运用所学的参数来查看到底为什么不能用，那么是后来查看镜像拉取失败的过程中，发现是在server2 和server3的节点上。

所以今后一定要吸取的教训是：

1.  有什么错误一定要当场写下来，

2. 在解决问题的过程中尽可能的多想多kaolv，如果实在没有什么思路，那么就说明收集的信息不全，尽可能多得去收集这个错误发生的信息。

3.在解决问题的过程中，学会举一反三的完成错误的多条路径。

注：  加油！  相信自己一定可以的 。