https://blog.csdn.net/u011663005/article/details/87937800
這段時間一直在學習基於Docker和Kubernetes搭建服務器集群的知識，由於之前沒有雲計算相關的基礎，過程可以說是非常難受了，開始跟着大佬的帖子一步步來，即使這樣也是踩了無數的坑。
這里先貼上一位大佬的教程貼：個人覺得這篇帖子算是基於高版本Kubernetes構建集群環境比較全面的帖子了。
使用Kubeadm(1.13+)快速搭建Kubernetes集群
https://www.cnblogs.com/RainingNight/p/using-kubeadm-to-create-a-cluster-1-13.html
另外，把我去年個人研究Docker和Kubernetes技術過程中所看的電子書分享出來，供大家參考。其中有《Kubernetes權威指南(第2版)》、《Kubernetes實戰 》、《Docker 容器與容器雲（第2版）》、《第一本Docker書》、《開源容器雲OpenShift構建基於Kubernetes的企業應用雲平台》。所有的電子書均為高清PDF版本。鏈接如下：
鏈接：https://pan.baidu.com/s/1bVuLNN5MHjeYxIGV4L0Bow 提取碼：a6rp
下面開始正題:
先說下筆者的環境：
兩台主機組件一主一從的集群環境（主機（master節點）：czb-workstation:192.168.0.109/從機（工作節點）：dl4:192.168.0.111），兩台的軟件環境如下：
linux-ubuntu 16.04
Docker 18.03.1-ce
Kubernetes v1.13.3
在此之前由於不懂Docker和Kubernetes的原理，所以只能一步步按照帖子上的步驟進行嘗試，遇到不懂的地方再百度或者谷歌。這里着重說一下在構建過程中遇到的很常見但同時又比較棘手的問題：建立起來的pod 出現CrashLoopBackOff的問題，在筆者的構建過程中遇到了很多次coreDNS 組件出現CrashLoopBackOff的問題。
1. 剛開始的時候遇到的是安裝了網絡插件Calico后遇到兩個coreDNS組件均出現CrashLoopBackOff掛掉的問題，谷歌以后找到原因：由於本機環境中存在loop循環造成的。解決方法就是將主機環境中的127.0.0.1主機ip循環地址刪除即可，具體有這么幾個位置：/etc/resolv.conf /run/systemd/resolve/resolv.conf /etc/systemd/resolved.conf
參考帖子：https://stackoverflow.com/questions/53075796/coredns-pods-have-crashloopbackoff-or-error-state
2. 按照上述帖子的方法處理后，兩個coreDNS組件開始確實也顯示為running狀態，但是好景不長，幾分鍾后發現其中一個coreDNS組件有RESTART記錄，后來每隔兩分鍾便出現一次RESTART記錄，在三次嘗試重啟后，果不其然，該coreDNS組件CrashLoopBackOff掛掉。。。
無奈，硬着頭皮開始DEBUG過程，首先通過命令“kubectl describe pod coredns-xxxxxxx -n kube-system ”命令查看該pod的情況：
czb@czb-workstation:~$ kubectl describe pod coredns-78d4cf999f-2mjbj -n kube-system
Name: coredns-78d4cf999f-2mjbj
Namespace: kube-system
Priority: 0
PriorityClassName: <none>
Node: dl4/192.168.0.111
Start Time: Tue, 26 Feb 2019 10:05:49 +0800
Labels: k8s-app=kube-dns
pod-template-hash=78d4cf999f
Annotations: cni.projectcalico.org/podIP: 192.168.1.28/32
Status: Running
IP: 192.168.1.28
Controlled By: ReplicaSet/coredns-78d4cf999f
Containers:
coredns:
Container ID: docker://c178ebc8719657aff484fd5277a0ab7b5184c26c92f402218c7236dfe4e20c1b
Image: registry.aliyuncs.com/google_containers/coredns:1.2.6
Image ID: docker-pullable://registry.aliyuncs.com/google_containers/coredns@sha256:0e7e5387c73f4898a7251d91f27297d3a5b210421a0b234302276feb8b264a27
Ports: 53/UDP, 53/TCP, 9153/TCP
Host Ports: 0/UDP, 0/TCP, 0/TCP
Args:
-conf
/etc/coredns/Corefile
State: Running
Started: Tue, 26 Feb 2019 10:21:19 +0800
Last State: Terminated
Reason: Completed
Exit Code: 0
Started: Tue, 26 Feb 2019 10:16:49 +0800
Finished: Tue, 26 Feb 2019 10:18:38 +0800
Ready: True
Restart Count: 7
Limits:
memory: 170Mi
Requests:
cpu: 100m
memory: 70Mi
Liveness: http-get http://:8080/health delay=60s timeout=5s period=10s #success=1 #failure=5
Environment: <none>
Mounts:
/etc/coredns from config-volume (ro)
/var/run/secrets/kubernetes.io/serviceaccount from coredns-token-45bt9 (ro)
Conditions:
Type Status
Initialized True
Ready True
ContainersReady True
PodScheduled True
Volumes:
config-volume:
Type: ConfigMap (a volume populated by a ConfigMap)
Name: coredns
Optional: false
coredns-token-45bt9:
Type: Secret (a volume populated by a Secret)
SecretName: coredns-token-45bt9
Optional: false
QoS Class: Burstable
Node-Selectors: <none>
Tolerations: CriticalAddonsOnly
node-role.kubernetes.io/master:NoSchedule
node.kubernetes.io/not-ready:NoExecute for 300s
node.kubernetes.io/unreachable:NoExecute for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 15m default-scheduler Successfully assigned kube-system/coredns-78d4cf999f-2mjbj to dl4
Normal Pulled 12m (x3 over 15m) kubelet, dl4 Container image "registry.aliyuncs.com/google_containers/coredns:1.2.6" already present on machine
Normal Killing 12m (x2 over 14m) kubelet, dl4 Killing container with id docker://coredns:Container failed liveness probe.. Container will be killed and recreated.
Normal Created 12m (x3 over 15m) kubelet, dl4 Created container
Normal Started 12m (x3 over 15m) kubelet, dl4 Started container
Warning Unhealthy 5m31s (x26 over 14m) kubelet, dl4 Liveness probe failed: HTTP probe failed with statuscode: 503
Warning BackOff 44s (x12 over 3m) kubelet, dl4 Back-off restarting failed container
主要報錯信息為：活動探測失敗：HTTP探測失敗，狀態碼為：503 這個信息對我來說完全沒用，目前只知道是從機dl4上部署的coreDNS組件工作異常，僅此而已。
接着自然想到查看pod的日志，輸入”kubectl logs -f coredns-78d4cf999f-2mjbj -n kube-system“命令：
czb@czb-workstation:~$ kubectl logs -f coredns-78d4cf999f-2mjbj -n kube-system
.:53
2019-02-26T02:56:04.551Z [INFO] CoreDNS-1.2.6
2019-02-26T02:56:04.551Z [INFO] linux/amd64, go1.11.2, 756749c
CoreDNS-1.2.6
linux/amd64, go1.11.2, 756749c
[INFO] plugin/reload: Running configuration MD5 = f65c4821c8a9b7b5eb30fa4fbc167769
E0226 02:56:29.551969 1 reflector.go:205] github.com/coredns/coredns/plugin/kubernetes/controller.go:318: Failed to list *v1.Namespace: Get https://10.96.0.1:443/api/v1/namespaces?limit=500&resourceVersion=0: dial tcp 10.96.0.1:443: i/o timeout
E0226 02:56:29.552106 1 reflector.go:205] github.com/coredns/coredns/plugin/kubernetes/controller.go:313: Failed to list *v1.Endpoints: Get https://10.96.0.1:443/api/v1/endpoints?limit=500&resourceVersion=0: dial tcp 10.96.0.1:443: i/o timeout
E0226 02:56:29.552135 1 reflector.go:205] github.com/coredns/coredns/plugin/kubernetes/controller.go:311: Failed to list *v1.Service: Get https://10.96.0.1:443/api/v1/services?limit=500&resourceVersion=0: dial tcp 10.96.0.1:443: i/o timeout
E0226 02:57:00.552562 1 reflector.go:205] github.com/coredns/coredns/plugin/kubernetes/controller.go:318: Failed to list *v1.Namespace: Get https://10.96.0.1:443/api/v1/namespaces?limit=500&resourceVersion=0: dial tcp 10.96.0.1:443: i/o timeout
E0226 02:57:00.553712 1 reflector.go:205] github.com/coredns/coredns/plugin/kubernetes/controller.go:313: Failed to list *v1.Endpoints: Get https://10.96.0.1:443/api/v1/endpoints?limit=500&resourceVersion=0: dial tcp 10.96.0.1:443: i/o timeout
E0226 02:57:00.554783 1 reflector.go:205] github.com/coredns/coredns/plugin/kubernetes/controller.go:311: Failed to list *v1.Service: Get https://10.96.0.1:443/api/v1/services?limit=500&resourceVersion=0: dial tcp 10.96.0.1:443: i/o timeout
E0226 02:57:31.553284 1 reflector.go:205] github.com/coredns/coredns/plugin/kubernetes/controller.go:318: Failed to list *v1.Namespace: Get https://10.96.0.1:443/api/v1/namespaces?limit=500&resourceVersion=0: dial tcp 10.96.0.1:443: i/o timeout
E0226 02:57:31.554273 1 reflector.go:205] github.com/coredns/coredns/plugin/kubernetes/controller.go:313: Failed to list *v1.Endpoints: Get https://10.96.0.1:443/api/v1/endpoints?limit=500&resourceVersion=0: dial tcp 10.96.0.1:443: i/o timeout
E0226 02:57:31.555564 1 reflector.go:205] github.com/coredns/coredns/plugin/kubernetes/controller.go:311: Failed to list *v1.Service: Get https://10.96.0.1:443/api/v1/services?limit=500&resourceVersion=0: dial tcp 10.96.0.1:443: i/o timeout
[INFO] SIGTERM: Shutting down servers then terminating
czb@czb-workstation:~$ kubectl get pod --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system calico-node-7fwc7 2/2 Running 0 24h
kube-system calico-node-lxkr5 2/2 Running 2 24h
kube-system coredns-78d4cf999f-2mjbj 0/1 CrashLoopBackOff 21 78m
kube-system coredns-78d4cf999f-rnft5 1/1 Running 1 24h
kube-system etcd-czb-workstation 1/1 Running 1 24h
kube-system kube-apiserver-czb-workstation 1/1 Running 1 24h
kube-system kube-controller-manager-czb-workstation 1/1 Running 1 24h
kube-system kube-proxy-lddlb 1/1 Running 1 24h
kube-system kube-proxy-rd6kt 1/1 Running 0 24h
kube-system kube-scheduler-czb-workstation 1/1 Running 1 24h
從上面的信息大概知道，是由於從機無法通過coreDNS組件訪問10.96.0.1:443 該地址造成的，dial tcp 10.96.0.1:443: i/o timeout
之后繼續谷歌，之后在一篇求助貼中看到有人遇到跟我一樣的問題並且已經順利解決！！那個激動啊！！
帖子原地址：https://github.com/coredns/coredns/issues/2325
該作者將解決問題的思路又寫為博客並發布了出來：https://medium.com/@cminion/quicknote-kubernetes-networking-issues-78f1e0d06e12
大致描述如下：
症狀
工作節點(從機)上的Pod無法連接到API服務器
超時連接到10.96.0.1
但master上的pod（可能沒有污染）工作正常。
解
當您使用kubeadm init時，請指定pod-network-cidr。確保主機/主網絡的IP不在您引用的子網中。
即如果您的網絡運行在192.168.*.*使用10.0.0.0/16
如果您的網絡是10.0.*.*使用192.168.0.0/16
我忘了子網是如何工作的，所以我沒有意識到192.168.0.1與192.168.100.0/16在同一子網中。簡而言之，當您使用16子網標記時，它意味着使用192.168.*.*中的任何內容。
由於我的網絡運行在192.168.1。*主機在192.168.0上運行正常。*但我的工作人員無法通信，因為它試圖在192.168.1上運行。*因此很好地導致我的盒子上的路由問題。
也就是說，在使用”kubeadm init“命令初始化master節點時，在給Calico網絡插件分配CIDR網段時，自己環境中（master節點和工作節點）的ip地址不能夠跟Calico網絡插件的網段重合！！不得不說這個問題非常隱蔽啊！！新手非常容易忽略。
之后我又去Calico官方教程中找到了答案：
這里的注意就是這個意思。
接下來只能重新配置集群環境了，分別在master節點和工作節點上執行”kubeadm reset“命令，然后首先在master節點運行新的”kubeadm init“命令：”sudo kubeadm init --image-repository registry.aliyuncs.com/google_containers --kubernetes-version v1.13.1 --pod-network-cidr=10.0.0.0/16“，之后的步驟就跟博客中附上的第一篇教程貼的步驟一樣了！
這個問題前前后后困擾了我好多天，開始完全摸不到頭腦，面對滿屏的英文和通過谷歌翻譯出來的英文帖子中蹩腳的中文邏輯確實對新手理解造成極大困擾！但是我覺得如果能夠堅持，克服浮躁的心境，慢慢尋找問題所在，並積極在網絡中尋找解決問題的思路和答案，就一定能夠解決問題。有感網絡中那么多技術很牛的大佬能在網路中將自己的經驗無私地奉獻出來並不厭其煩的解答新手遇到的各種在他們看來小兒科的問題。又想起之前看到的一句話：取之於網絡，回饋於網絡！！
————————————————
版權聲明：本文為CSDN博主「北海的星辰大海」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/u011663005/article/details/87937800