1.k8s集群的能力供應(ying)站(pod)的詳解
Pod是k8s中的最小(xiao)調度單元(yuan)，當(dang)指(zhi)派容(rong)器時(shi),容器(qi)實際上并不會指派到物(wu)理(li)硬件上，容器(qi)會被分配到一個pod里(li)，pod代表集群上正在運行的(de)一(yi)(yi)個(ge)進程，一(yi)(yi)個(ge)pod封裝(zhuang)一個容器(qi)(qi)（也可以封裝(zhuang)多個容器(qi)(qi)），pod里的容器共享存儲、網絡等。也就是說，應(ying)該把整個(ge)pod看作虛(xu)擬機，然后每個容器相當于運行(xing)在(zai)虛(xu)擬機的(de)進(jin)程。
2.k8s集群中的pod的用途(tu)
運行(xing)單(dan)個容(rong)器的(de)pod:
Pod里(li)封(feng)裝單個容(rong)器(qi)，k8s直(zhi)接管理pod，pod調度到(dao)哪個物理節(jie)點，pod里的容(rong)器就跟隨(sui)pod調度(du)到哪個節點。
運行多個協同工作的容(rong)器的pod:
Pod里可以運行多(duo)個(ge)容(rong)(rong)器(qi)，如初始化容(rong)(rong)器(qi)、業(ye)務容(rong)(rong)器(qi)，這些容(rong)(rong)器(qi)之間的互相作用，共享資源。
3.k8s集群中pod一般哪些方面容易出現(xian)問(wen)題
1).k8s資源(yuan)配置錯誤
例如部署deployment和statefuset時,資源清單(dan)書寫有問題(ti),導致pod無法正常創建。
2).代碼問(wen)題
應用程序代碼在容(rong)器(qi)啟動后失敗，那就需要(yao)通過檢查(cha)代碼找錯誤。
3).網絡問題(ti)
網絡插件部(bu)署(shu)有問題，導致pod啟動(dong)之后無法相互通(tong)信。
4).存(cun)儲問題
Pod掛載存(cun)儲，但是需要共享的(de)存(cun)儲連接不上(shang)導致pod啟動異常。
4.pod的(de)狀態為(wei)ContainerCreating狀態的(de)故(gu)障
一般原因(yin)是：后(hou)面node節點(dian)故(gu)障不能工作或網絡ip已被注冊(ce)、也可能是(shi)沒有掛載到(dao)pv的存儲(chu)卷(juan)。
診(zhen)斷方法流程(cheng):
#kubectl get pod -o wide |grep pod名 #查看pod在哪個節點(dian)
#kubectl describe pod pod名 #查(cha)看pod的(de)詳細事件(jian)信息
#kubectl logs pod pod名 [-c 容器名(ming)] #查看pod的日志或某(mou)個容器日志
#systemctl status kubelet #查看pod所在節點(dian)的kubelet服(fu)務狀態
#tailf /…/kubelet.xx.log #查看pod所在節(jie)點的kubelet服(fu)務日志
1).后面(mian)node節點故障不能工作的處理:
創建(jian)一(yi)個別(bie)的新的pod，看能否(fou)運行(xing)在該node1節點上，如果其他pod能創建在node1節(jie)點，說明可能只是(shi)無法創建的pod本身有(you)問題，如果(guo)所有(you)其他pod都無法在node1節點(dian)創(chuang)建(所有在node節點(dian)創建的pod狀態都是:ContainerCreating)，說明(ming)node1節點有問題。
如果已經確定(ding)某個(ge)node節(jie)點有問題(ti)不能(neng)使(shi)用時,需要將node節(jie)點重置(zhi)后(hou)重新加(jia)入集(ji)群：
步驟(zou)如下：
(1).先將該node節(jie)點(dian)上正在運行的pod驅逐(zhu)到其他node節點
(2).#kubeadm reset 在故障node節點(dian)上重(zhong)置k8s集群,執行完(wan)相當于這個節點所有東西都清空(kong)了(操作需要慎重,將pod全部驅逐后(hou)再操作)
(3).#systemctl stop kueblet
(4).#systemctl stop docker
(5).#rm -rf /var/lib/kubelet/*
(6).#rm -rf /etc/cni/
(7).#ifconfig cni0 down
(8).#ifconfig flannel.1 down （如(ru)果安裝的是(shi)flannel網絡(luo)）
(9).#ip link delete cni0
(10).#ip link delete flannel.1
(11).#systemctl start docker
(12).#systemctl start kubelet
(13)#kubeadmin join … 把node節點重新加入加入k8s集群
2).也可能(neng)是沒有掛載到pv的存儲(chu)卷的處(chu)理：
查(cha)看pv綁定的情況和需求。
步(bu)驟如下:
#kubectl get pod -o wide |grep pod名 #查看pod所在node節點(dian)
#kubectl describe pod pod名 #查(cha)看(kan)pod的詳細(xi)信息
若后(hou)臺存(cun)儲(chu)是ceph相關報錯,可能是沒有(you)安(an)裝(zhuang)相(xiang)關程序
#yum -y install ceph-common #再(zai)相應節點(dian)安(an)裝ceph相關程(cheng)序
安裝(zhuang)ceph-common程(cheng)序后，刪除pod: test-ceph后重新運(yun)行(xing)pod，再(zai)查看狀態。
如后臺(tai)存儲是nfs或其他，則查(cha)看相(xiang)關(guan)服務(wu)是否(fou)正常,是否能手動正常掛載。
安(an)裝ceph-common程(cheng)序后(hou)，刪除pod: test-ceph后(hou)重新運(yun)行pod，再查(cha)看狀態。
處理思路(lu)總(zong)結：
查看日志時候也(ye)可 -c 容(rong)器名
5.pod的狀態(tai)為pending狀態的故(gu)障(zhang)
Pending狀態：是掛起狀態。表示創建的(de)pod找不(bu)到可以運行(xing)它的物理節點(dian)，不(bu)能調度到相應(ying)的節點(dian)上運行(xing)。
1).從兩個層(ceng)面分(fen)析問(wen)題：
(1).物理節點層面分(fen)析：
查看(kan)節點資源(yuan)使用(yong)情況(kuang):
如free -m查看內存、top查看cpu使用率、df -h查看(kan)磁盤使用(yong)情(qing)(qing)況(kuang)，這樣可以定位節點資源情(qing)(qing)況(kuang)，判斷是(shi)不是(shi)節點有(you)問題。也可直接通過監控(kong)查詢(xun)資源使用(yong)情(qing)況(kuang)。
查看節點(dian)污點(dian)：
#kubectl describe node node節點名字 ,如(ru)果節點定義了污點，那么(me)pod不(bu)能容(rong)忍污點，就會調度失(shi)敗，可以在yaml文件(jian)里定義容(rong)忍度，則可以試下調度。
(2).pod本身分析：
在定義pod時，如果指(zhi)定了nodeName或nodeSelector選擇(ze)器是不存(cun)在的，那么也會調度失敗(bai)。
在定義(yi)pod時，如果定義(yi)的資源請求比較大，導致物理(li)節點資源不夠也是不會(hui)調度的。
2).查看(kan)node節點是(shi)否有污點的方法：
#kubectl describe node node名(ming)稱 |grep Taints
Taints xxx （看有沒(mei)有，沒(mei)有就是空(kong)）
6.pod的狀(zhuang)態為ImagePullBackOff狀態(tai)的故障
1).ImagePullBackOff狀(zhuang)態的原因：
(1).拉取鏡像時間長導致超時.
(2).配(pei)置(zhi)的鏡(jing)像有錯誤：如(ru)鏡(jing)像名字不存在等.
(3).配置的鏡(jing)像(xiang)無法訪(fang)問(wen):如(ru)網絡(luo)限制無法訪問hub上的鏡像(xiang).
(4).配置的私有鏡像(xiang)倉庫參(can)數錯誤：如imagePullSecret沒有配置或(huo)者配置錯誤(wu).
(5).dockerfile打包的鏡像(xiang)不(bu)可用.
2).ImagePullBackOff狀態的(de)排(pai)查思路:
#kubectl get pod -o wide 查看pod在哪個節點
#kubectl describe pod pod名 查看pod的(de)詳細信息
查看到(dao)時(shi)鏡(jing)像拉不下來問題時(shi),可以手動拉(la)一下看看
7.pod的狀態為CrashLoopBackOff狀態的故障
1).CrashLoopBackOff狀態的原因(yin)：
pod里(li)面的(de)容器(qi)退出(chu)、多次重啟或準備刪除(chu)。
k8s中的pod正常運行,但是里面的容器可能退(tui)出或者(zhe)(zhe)多次重啟(qi)或者(zhe)(zhe)準備刪除,導(dao)致出現(xian)這個狀態,這(zhe)個狀態具有偶發性,可能(neng)上(shang)一步(bu)還是running狀態,但是突然就變成CrashLoopBackOff狀態(tai)了。
2).CrashLoopBackOff狀態的排查(cha)思路：
#kubectl logs pod名 [-c 容器名] 查(cha)看pod日志，代碼或環境變量
查看日(ri)志(zhi),查看(kan)構建鏡像用(yong)的代碼是否有問題,如果代碼沒問題，再(zai)看環境變(bian)量是否有(you)問題。
#kubectl describe pod pod名(ming) 查看pod的詳細(xi)信息，limit資源限(xian)制
查看yaml文件(jian)里的limit資(zi)源限(xian)(xian)制，是(shi)否跟資(zi)源限(xian)(xian)制有關。
8.pod的狀態為Error狀態的故障
原因分析：
(1).依賴的configmap、secret、pv、storageClass等不存在.
(2).請(qing)求的(de)(de)資源(yuan)超過了管理員設置的(de)(de)限(xian)制，比如超過了limits等.
(3).無(wu)法操作集(ji)群內(nei)的資源，比如：開啟rbac后,需要為serviceAccount配置權限.
排(pai)查思(si)路:
#kubectl describe pod pod名 #查看pod詳細信息
#kubectl logs pod pod名 [-c 容器名] #查看(kan)pod或容器日(ri)志
#kubectl -f -u kubelet #查看kubelet服(fu)務日志
#tail -f /var/log/messages #查看主機日志
9.pod的狀態為Terminating或Unknown狀態的故(gu)障
原因分(fen)析：
Terminating故障是(shi)因為容器里的應用掛了或node節點失聯。
從k8s1.5開始，k8s不(bu)會因為node失聯而刪(shan)除(chu)其上正在運行的pod，而是(shi)將(jiang)其標記為Terminating或Unknown狀態。
相應刪除這些狀態的pod有4種方法:
1).手動刪除node節點(確定節(jie)點不能(neng)用再刪) # kubectl delete node node節點名稱
2).恢復(fu)正(zheng)常可(ke)選(xuan)擇性刪(shan)除(chu)
若node節(jie)點恢復(fu)正常(chang),kubelet會重新跟kube-apiserver通信確認這(zhe)些pod的期待狀(zhuang)態,進而(er)再決定刪(shan)除或者繼續運行這些pod，如果刪除可以通過
# kubectl delete pod pod名(ming) –grace-period=0 --force強制(zhi)刪除(chu)
3).使(shi)用參數重建容(rong)器
4).自動重建pod
注意：節點確實不能(neng)用(yong)了再刪node節(jie)點(dian)。刪除node節(jie)點前，先將部署的pod服務驅逐到其他node節點。
如果node節點已經刪(shan)除了(le)，但是使用命令kubectl get pod查看時(shi)該node節點(dian)上還顯示有pod，呈(cheng)現terminating狀態，可以用命令:
# kubectl delete pod pod名(ming) –grace-period --force 強制刪除(chu)該pod。
解決思路：
1).# kubectl get node #查看節(jie)點(dian)狀態(tai)和節(jie)點(dian)資(zi)源是否(fou)還充足,df -h free -m
2).# kubectl get pod -n kube-system |grep apiserver #查(cha)看apiserver是否異常
3).查看kubelet日志,查看相(xiang)應node節點的kubelet錯誤(wu)日志(zhi)
10.pod的健康(kang)檢查（存活性(xing)探(tan)測和就緒性(xing)探(tan)測）
1).為什么需要(yao)探針？
如(ru)果沒(mei)有(you)探針，k8s無(wu)法知道應用是否還活著，只(zhi)要pod還(huan)在運行，k8s則認為(wei)容器(qi)時健康的。但實際上，pod雖然運行(xing)了(le)，但里面容器中的應用可能(neng)還沒(mei)提供服務，那就需要(yao)做健(jian)康檢(jian)查，健(jian)康檢(jian)查就需要(yao)探針。
2).常(chang)見的(de)探針有以下幾種：
(1).httpGet
對容器的(de)ip地址（指定(ding)的端口(kou)和路(lu)徑）執(zhi)行http get請(qing)求，如果(guo)探測器收到(dao)響應，并且(qie)響應碼是2xx，則認為探測成(cheng)功。如果服務器沒有響(xiang)應或(huo)者返回錯誤(wu)響(xiang)應碼則說明探測失敗，容(rong)器將重啟(qi)。
(2).tcpSocket
探針(zhen)與(yu)容器(qi)指定端口(kou)建立tcp連接(jie)，如(ru)果連接(jie)建立則探測成功，否(fou)則探測失(shi)敗容器重(zhong)啟。
(3).exec
在容(rong)器內執行任(ren)意(yi)命令，并檢查命令退出(chu)狀態碼，如果狀態碼為0，則探(tan)(tan)測成功，否則探(tan)(tan)測失敗容器重啟。
3).健康檢查的兩(liang)種(zhong)方式: (livenessProbe和ReadinessProbe)
(1).LivenessProbe（存(cun)活探測）：
探(tan)測pod里的容器是否啟(qi)動成功，如果pod里的容器啟(qi)動成功那pod的狀態就是Running.
(2).ReadinessProbe（就(jiu)緒(xu)探測）:
Pod是Running的前提下，看pod里容器部署(shu)的(de)應(ying)用(yong)是否就緒，是否可(ke)以對外提供服(fu)務(wu)，如果應(ying)用(yong)正(zheng)常(chang)，可(ke)以接(jie)受客戶端的(de)請求，則ready是就緒(xu)的。
4).LivenessProbe和ReadinessProbe區別：
LivenessProbe決定是否重啟(qi)容(rong)器、ReadinessProbe主要來確定容器(qi)是(shi)否已經就緒,只有當pod里的容器部署的應(ying)用都處于(yu)就緒狀態(tai)，才會(hui)將請求轉發給容器。
11.token驗證(zheng)問題(ti)：（添加節點token過期(qi)）
默認kubeadm在安裝集群后，會打(da)印(yin)出join新(xin)節點的(de)命(ming)令(ling)。不過只有24小時(shi)的有效期
kubeadm init --kubernetes-version=1.18.5 --apiserver-advertise-address=${ip} --pod-network-cidr=10.244.0.0/16 --image-repository=dockerhub.example.com
若期望(wang)新增節點，則需要(yao)重新生(sheng)成token，默認是24小(xiao)時(shi)有效期，這(zhe)里(li)可以通(tong)過設置ttl=0為(wei)永久有效(xiao)
kubeadm token create --print-join-command --ttl=0
輸出：
kubeadm join 172.16.10.10:6443 --token q4ge2n.rnwke6l5wmtaglrj --discovery-token-ca-cert-hash sha256:b64218fa30ae1ca5f8f7e336f935fc7bf84d561a7e29521800b12d5fe34c6819
查(cha)看token列表
kubeadm token list
查看--discovery-token-ca-cert-hash值
openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | openssl dgst -sha256 -hex | sed 's/^.* //'
12.kubectl執(zhi)行異常(chang)，無權限連(lian)接到k8s問(wen)題(ti)定位(wei)
kubectl執行異(yi)常的排查：
1) .安(an)裝k8s之后默認是沒有(you)權限操作k8s資源的，可用如下方式(shi)解(jie)決(jue)：
mkdir -p $HOME/.kube
sudo cp -rf /etc/kubernetes/admin.conf $HOME/.kube/config
2).也可能是kube-apiserver異常導致。
