1.k8s集(ji)群節點notready狀態的幾種情況(kuang)
情(qing)況1： 剛安(an)裝好k8s集群的node節點notready
現象：node節點(dian)notready，查看coredns的(de)pod狀態(tai)為pending
可能原(yuan)因： 可(ke)能是沒有部(bu)署網絡插件（calico或flannel），需(xu)要(yao)安裝網絡(luo)插件
情況2： k8s運行一段時間后(hou)，node節點notready
可能原因(yin)：
(1).查看node節點宿主機(ji)的網(wang)絡情況(kuang)、磁(ci)盤(pan)情(qing)況、內(nei)存情(qing)況、cpu情況，查看資源是否足夠
(2).查看node節點的(de)kubelet服務是否正常
如果node節(jie)點的kubelet服務不正常，也會顯示notready狀態(tai)
(3).查看node節點的詳細信息排(pai)查原因(yin)
#kubectl describe node node名
2.pod的幾種調度方式
當我們發送請求創建pod，調度器就會把pod調(diao)度到合適的(de)物理節點(dian)，大致分為以下過程：
1).Scheduler根據預選策略和優(you)選函(han)數，選擇合適node節點調度。
a).預選(xuan)階段(Predicates):過濾節點，調度(du)器用一組規則過濾掉(diao)不(bu)符合要求的node節點，比如pod設置了資源的request,那么可(ke)用(yong)資源比pod需要(yao)資源少的(de)主機顯(xian)然就會被過濾掉
b).優選階段(duan)(Priorities):為節點的優先(xian)級(ji)打分,將上一階段過濾出來的node列表進行(xing)打分(fen),調度器會考慮一(yi)些整體的優化策略,比(bi)如把deployment控(kong)制的多(duo)個pod 副本盡量分布(bu)到不同的主機上,使用最低負(fu)載的(de)主機等等策略
2).可以通過定義(yi)nodeName(一般不經過(guo)調度器,使用很少)或nodeSelector進行調度。
3).可以根(gen)據節點親和(he)性(xing)進(jin)行調度。
nodeAffinity: 節(jie)點(dian)親和(he)性，與(yu)nodeSelector作用(yong)一樣，但(dan)相比更靈活，滿(man)足更多條件(jian):
-匹(pi)配有更多的(de)(de)邏輯組(zu)合，不只是(shi)字符串的(de)(de)完全(quan)相(xiang)等。
-調(diao)度分為軟策略(lve)和硬策略(lve)，而不是硬性要求。
a).硬（required）： 必須滿足
b).軟（preferred）：嘗試滿足，但不(bu)保證(zheng)
操作符：In、NotIn、Exists、DoesNotExist、Gt、Lt （操作(zuo)(zuo)符(fu)支持這(zhe)些，標簽選擇不(bu)一定等(deng)于，也可是包含或(huo)其他(ta)等(deng)操作(zuo)(zuo)）
節點選(xuan)擇器2：nodeAffinity分(fen)兩(liang)種：硬性(xing)需(xu)求(qiu)：必須(xu)滿(man)足。軟(ruan)性(xing)需(xu)求(qiu):嘗試滿足(zu)，但不(bu)保證(zheng)。
硬性需(xu)求應用場景： 創建(jian)pod資源(yuan)或其他資源(yuan)時(shi)候，yaml文件里指定在打(da)了具(ju)體標簽的(de)node節點上，就必須只能在(zai)該node節點上創建資源，如果node節點上沒有符合(he)的(de)標簽(qian)，就不會被調度。所(suo)有node節點都(dou)不滿足，就(jiu)都(dou)不調度創建(jian)資源(yuan)。
軟(ruan)性需求應(ying)用(yong)場景： 創建pod資源或(huo)其他資源時候(hou)，yaml文件里指定(ding)在打了具體標簽的node節點上，則(ze)盡可能在該node節點上創建資源，如果所有node節點(dian)上都沒有(you)符合的(de)(de)標簽(qian)，就再按(an)其他調度算(suan)法創建在相應的(de)(de)node節(jie)點(dian)上
注意：pod在調度的(de)時(shi)候會(hui)找(zhao)到一個合適的(de)節點(dian)，所以如果節點(dian)資源(yuan)不足(zu)；pod定(ding)(ding)義了指(zhi)定(ding)(ding)的(de)節點，但是指(zhi)定(ding)(ding)的(de)節點出現故障(zhang)；或者pod定義了親和性(xing)，但是節點沒有(you)滿足(zu)的條件(jian)，都會(hui)導(dao)致調度失敗(bai)。
解釋：親(qin)和性和反親(qin)和性概(gai)念：
pod 親和性（podAffinity）主要解決pod可以和哪些pod部署在同(tong)一個(ge)拓撲域中的問(wen)題（其中拓撲域用(yong)主機(ji)標(biao)簽(qian)實現，可以是單個(ge)主機(ji)，也(ye)可以是多個(ge)主機(ji)組成的 cluster、zone 等(deng)等(deng)），而(er) pod 反親和性主(zhu)要是解決 pod 不能(neng)和哪些pod部署在同(tong)一個拓撲域中的問題，它們都(dou)是處理的 pod 與pod 之間的關系，比(bi)如(ru)一個Pod在一個(ge)節(jie)點上了，那么(me)我(wo)這(zhe)個(ge)也得在這(zhe)個(ge)節(jie)點，或(huo)者(zhe)你這(zhe)個(ge)Pod在節點上(shang)了(le)，那么我就不想和你待在同一個節點上(shang)。
3.k8s中一個node節點(dian)突然斷電，恢復后上面的pod無法啟動故障
1).故障(zhang)現象：
k8s中pod一(yi)直(zhi)正常運行(xing)，偶爾(er)一(yi)次(ci)node節(jie)點突然(ran)斷(duan)電，恢復之后，發現pod無法啟(qi)動
報錯日志： node節點(dian)包含污點(dian)，但是沒(mei)有(you)配置容忍(ren)度
2).排查思路(lu):
(1).首先查看node節(jie)點是(shi)否有污(wu)點存在
當node節點宕機，k8s會自動(dong)為這(zhe)個節點(dian)(dian)加(jia)上不可調度污(wu)(wu)點(dian)(dian)。有可能開(kai)機后，污(wu)(wu)點(dian)(dian)沒有自動(dong)消(xiao)失(shi)，導致有污(wu)(wu)點(dian)(dian)，讓pod調度不(bu)過去。
(2).檢(jian)查node節點的(de)主(zhu)機名(ming)是否更(geng)改，主(zhu)機名(ming)更(geng)改后連接不到集群(qun)，也會添加污點
如果初(chu)始化(hua)后的(de)集(ji)群的(de)某個node節(jie)點的主(zhu)機(ji)名更(geng)改后，重啟kubelet服務后，該(gai)node節點就注冊不到k8s集群(qun)了，這是(shi)該(gai)node節點也顯示notready狀(zhuang)態。即使將該node節點(dian)和master的hosts解析改(gai)成新主機名(ming)，也(ye)不行，kubelet還是(shi)按最初(chu)初(chu)始化集群時定(ding)義的主(zhu)機名注冊，除(chu)非再(zai)將node節點(dian)的主機(ji)名(ming)(ming)改成原來初始化時(shi)候(hou)的主機(ji)名(ming)(ming)才能恢復。所以，初始化時(shi)候(hou)一般(ban)要定義好主機(ji)名(ming)(ming)，后面不要隨意修改主機(ji)名(ming)(ming)。
(3).檢查node節點的kubelet服(fu)務是否正常
如果node節點的kubelet服務不(bu)正常，也會(hui)使node節點notready狀態。
注意：只要node節點的狀態為notready狀態，k8s就(jiu)會(hui)給該node節點打上一個污點,如果(guo)node節點恢復了(le)，污點一般會(hui)自動消失(shi)，但也有(you)可能沒消失(shi)，這時候(hou)可以手動刪除污點或看看別的(de)原因。
3).解決思(si)路：
(1).在相應node節點查看(kan)kubelet服務狀態，如(ru)果(guo)不(bu)行，重(zhong)啟kubelet服務。
(2).將相應(ying)node節點上(shang)的污點手動刪除。
#kubectl taint node node名(ming) 污點(dian)-
4.當前內置的污點包(bao)括：
node.kubernetes.io/not-ready：節點(dian)未準備(bei)好。這相當于節點(dian)狀(zhuang)況 Ready 的值為 "False"。
node.kubernetes.io/unreachable：節(jie)點(dian)控制器訪問不到節(jie)點(dian). 這(zhe)相當于節點狀況 Ready 的值為 "Unknown"。
node.kubernetes.io/memory-pressure：節點存在內存壓力。
node.kubernetes.io/disk-pressure：節點(dian)存在磁盤壓力。
node.kubernetes.io/pid-pressure: 節(jie)點(dian)的 PID 壓力。
node.kubernetes.io/network-unavailable：節點網絡不(bu)可用。
node.kubernetes.io/unschedulable: 節點不可調度。
node.cloudprovider.kubernetes.io/uninitialized：如果 kubelet 啟(qi)動時(shi)指定(ding)了一個“外部(bu)”云(yun)平臺驅動(dong)， 它將給當前節點添加一個污(wu)點將其標志(zhi)為不可用。在 cloud-controller-manager 的一個(ge)控制器初(chu)始化這個(ge)節(jie)點(dian)后，kubelet 將刪除(chu)這個污點。
在節點被驅逐時，節點控制器或者 kubelet 會添加帶有 NoExecute 效果(guo)的相關污(wu)點(dian)。 如果(guo)異常狀態恢復(fu)正常，kubelet 或節點控制器能(neng)夠移(yi)除相關的污點。
5.pod超過節(jie)點(dian)資源限制
1).pod數量太多超過物理(li)節點限制(zhi)
故障現象: 監控系(xi)統大量(liang)報警(jing),大量pod在批量重啟,還有pod一直處于pending狀態
處理思路：
(1).查(cha)看pod詳細信息,看有(you)(you)沒有(you)(you)報錯,污(wu)點: xx:NoExecute。（當pod數(shu)量太多不可調度時(shi)也會自動加污點）
#kubectl describe pod pod名
(2).查看相應node節(jie)點(dian)詳細信息，有沒有報錯: OOM內存泄露。
#kubectl describe node node名
(3).到相(xiang)應(ying)node節點，查看磁盤(pan)、cpu、內存等(deng)資源(yuan)情況是否足夠。 #df -h free top
(4).到(dao)相應node節點查看(kan)kubelet的狀態(tai)，看有(you)沒有(you)報錯(cuo)。
#systemctl status kubelet
(5).查看相應(ying)node節點數量(liang)是否超出(chu)了(le)默認的110個
#kubectl get pod | wc -l |grep node名
當node節點上pod數(shu)量(liang)太多，超過默認110個(ge)后(hou)，無(wu)法再運行pod的(de)處理：
(1).給相應node節點增加資(zi)源,磁盤/內存(cun)/cpu,在(zai)kubelet服務中增(zeng)加啟動參數,調大(da)node節點運行pod數(shu)量，如: --max-pods=300
(2).增加(jia)node節點數量。
2).pod資源(yuan)超過物(wu)理節點(dian)資源(yuan)限(xian)制
故障現(xian)象: 在k8s中部署pod，發現一直處于pending狀態
處(chu)理思路：
(1).查看(kan)pod詳細信息，看(kan)有沒有污點報(bao)錯，在查看(kan)有沒有資源限(xian)制報(bao)錯、內存/cpu/磁盤等(deng).
#kubectl describe pod pod名(ming)
(2).查看pod的yaml文件中limit相關的(de)資源限制，看定義(yi)資源范圍node節點(dian)是否(fou)能(neng)滿足(zu)。
解決(jue)方法：
(1).擴容相應(ying)的node宿主機節點的資(zi)源。
(2).增(zeng)加一個新的node節點(dian)。
(3).縮小部署的pod相(xiang)關的limit的(de)資源(yuan)限制(zhi)，資源(yuan)參數改(gai)小一(yi)點。
