Kubernetes使用時(shí)需要注意的坑點(diǎn)

作者：aoxiang 2019-06-23 16:02:12

云計(jì)算 在Kubernetes實(shí)踐的過(guò)程中，積累了一些填坑經(jīng)驗(yàn)，小做總結(jié)，拿來(lái)分享一下。希望能對(duì)準(zhǔn)備或正在使用Kubernetes的小伙伴提供幫助。

創(chuàng)新互聯(lián)專(zhuān)注于海滄企業(yè)網(wǎng)站建設(shè),成都響應(yīng)式網(wǎng)站建設(shè)公司,商城網(wǎng)站制作。海滄網(wǎng)站建設(shè)公司,為海滄等地區(qū)提供建站服務(wù)。全流程按需定制制作，專(zhuān)業(yè)設(shè)計(jì)，全程項(xiàng)目跟蹤，創(chuàng)新互聯(lián)專(zhuān)業(yè)和態(tài)度為您提供的服務(wù)

在Kubernetes實(shí)踐的過(guò)程中，積累了一些填坑經(jīng)驗(yàn)，小做總結(jié)，拿來(lái)分享一下。

希望能對(duì)準(zhǔn)備或正在使用Kubernetes的小伙伴提供幫助。

滾動(dòng)升級(jí)之更新太慢

默認(rèn)情況下，滾動(dòng)升級(jí)是逐個(gè)更新的，當(dāng)有幾十上百個(gè)Pod需要更新時(shí)，再加上就緒檢測(cè)，整個(gè)過(guò)程將會(huì)更慢。如果你想和更多Kubernetes技術(shù)專(zhuān)家交流，可以加我微信liyingjiese，備注『加群』。群里每周都有全球各大公司的***實(shí)踐以及行業(yè)***動(dòng)態(tài)

解決方法：

  
 
 
 
   
  
  
  
rollingUpdate: 
   
  
  
  
   maxSurge: 20% #每個(gè)滾動(dòng)更新的實(shí)例數(shù)量 
   
  
  
  
   maxUnavailable: 10% #允許更新過(guò)程中有多少實(shí)例不可用 
  
 
 

就緒檢測(cè)之無(wú)損更新

通常，服務(wù)重啟的時(shí)候會(huì)有一小段時(shí)間是無(wú)法正常提供服務(wù)的。

為了避免這個(gè)過(guò)程中有請(qǐng)求的流量進(jìn)來(lái)，我們可以使用就緒檢測(cè)來(lái)檢測(cè)服務(wù)是否就緒可正常接收并處理請(qǐng)求。

  
 
 
 
   
  
  
  
...... 
   
  
  
  
        readinessProbe: 
   
  
  
  
          httpGet: 
   
  
  
  
            host: api.xxx.com 
   
  
  
  
            path: / 
   
  
  
  
            port: 80 
   
  
  
  
          initialDelaySeconds: 3 # 容器啟動(dòng)3秒后開(kāi)始***次檢測(cè) 
   
  
  
  
          periodSeconds: 60 # 每隔60s檢測(cè)一次 
   
  
  
  
          timeoutSeconds: 3 # http檢測(cè)請(qǐng)求的超時(shí)時(shí)間 
   
  
  
  
          successThreshold: 1 # 檢測(cè)到有1次成功則認(rèn)為服務(wù)是`就緒` 
   
  
  
  
          failureThreshold: 1 # 檢測(cè)到有1次失敗則認(rèn)為服務(wù)是`未就緒` 
   
  
  
  
...... 
  
 
 

就緒檢測(cè)之全面癱瘓

就緒檢測(cè)是把雙利劍，用不好，反而容易出大問(wèn)題，比如服務(wù)全面癱瘓。

我們可以看到上面就緒檢測(cè)的配置，漏洞百出。

比如：超時(shí)，高并發(fā)情況下，請(qǐng)求處理不過(guò)來(lái)，個(gè)別服務(wù)很容易導(dǎo)致檢測(cè)請(qǐng)求的超時(shí)(504)，立馬被認(rèn)為未就緒，于是流量被轉(zhuǎn)移到其它服務(wù)，進(jìn)而讓本來(lái)就高負(fù)荷的其它服務(wù)出現(xiàn)同樣情況，惡性循環(huán)，很快，所有服務(wù)都被認(rèn)為是未就緒，結(jié)果產(chǎn)生全面癱瘓現(xiàn)象。

解決方法：設(shè)置更長(zhǎng)的超時(shí)時(shí)間，以及更高的失敗次數(shù)。

重新部署，這種情況可能是誤操作，也可能是其它異常導(dǎo)致服務(wù)掛了?？傊阈枰谟脩?hù)還在不斷嘗試請(qǐng)求你服務(wù)的時(shí)候重啟。你會(huì)驚訝的發(fā)現(xiàn)，一直無(wú)法正常啟動(dòng)為就緒狀態(tài)，所有服務(wù)都是未就緒。同樣的原因，服務(wù)啟動(dòng)過(guò)程不是一次全部起來(lái)，而是逐批啟動(dòng)，這樣每批服務(wù)啟動(dòng)后都無(wú)法hold住流量，于是還是惡性循環(huán)，全面癱瘓。

解決方法：先去掉就緒檢測(cè)再重新部署。

自動(dòng)擴(kuò)展之瞬時(shí)高峰

自動(dòng)擴(kuò)展POD雖然好用，但如果擴(kuò)展的指標(biāo)(CPU、內(nèi)存等)設(shè)置的過(guò)高，如：50%以上，那么，當(dāng)突然有翻倍的流量過(guò)來(lái)時(shí)，根本來(lái)不及擴(kuò)展Pod，服務(wù)直接就超時(shí)或掛掉。

解決方法：盡可能的把指標(biāo)設(shè)置在一個(gè)較小的值，對(duì)以往流量做參考評(píng)估，確保了當(dāng)有2倍、3倍甚至5倍的流量突襲時(shí)不至于hold不住。

自動(dòng)伸縮之提前擴(kuò)容

通常，節(jié)點(diǎn)的自動(dòng)伸縮依賴(lài)于Pod的自動(dòng)擴(kuò)展時(shí)資源是否充足。然而在面對(duì)定時(shí)突然流量高峰的業(yè)務(wù)時(shí)，這種伸縮顯然來(lái)不及，甚至常常出現(xiàn)高峰10分鐘后才擴(kuò)容的機(jī)器，流量已經(jīng)回到低谷，完全啟不到作用。并且，流量到底是因?yàn)闃I(yè)務(wù)屬性很快回落，還是因?yàn)閿U(kuò)容不及時(shí)導(dǎo)致的流失?

解決方法：根據(jù)自身業(yè)務(wù)，參考以住流量數(shù)量及推廣時(shí)間，找到規(guī)律，提前或定時(shí)觸發(fā)自動(dòng)擴(kuò)容。

容器運(yùn)行之僵尸進(jìn)程

這是一個(gè)Docker舊版(<1.13)已知問(wèn)題，有些容器啟動(dòng)后會(huì)出現(xiàn)defunct進(jìn)程(ps aux | grep defunct)，而且會(huì)越來(lái)越多，稱(chēng)為僵尸進(jìn)程，可能導(dǎo)致內(nèi)存泄漏，而且kill不掉，除非重啟容器。

解決方法：tini

集群節(jié)點(diǎn)之移除節(jié)點(diǎn)

如何安全地移出節(jié)點(diǎn)?這個(gè)節(jié)點(diǎn)上面部署了你的業(yè)務(wù)，甚至包括kube-system的東西。

解決方法：kubectl drain，可以先把節(jié)點(diǎn)上的Pod驅(qū)逐到其它節(jié)點(diǎn)，然后再移出該節(jié)點(diǎn)。

分享標(biāo)題：Kubernetes使用時(shí)需要注意的坑點(diǎn)
文章分享：http://www.5511xx.com/article/djcpoic.html