Kubernetes使用時需要注意的坑點

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

云計算 在Kubernetes實踐的過程中，積累了一些填坑經(jīng)驗，小做總結(jié)，拿來分享一下。希望能對準備或正在使用Kubernetes的小伙伴提供幫助。

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

在Kubernetes實踐的過程中，積累了一些填坑經(jīng)驗，小做總結(jié)，拿來分享一下。

希望能對準備或正在使用Kubernetes的小伙伴提供幫助。

滾動升級之更新太慢

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

解決方法：

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

就緒檢測之無損更新

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

為了避免這個過程中有請求的流量進來，我們可以使用就緒檢測來檢測服務(wù)是否就緒可正常接收并處理請求。

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

就緒檢測之全面癱瘓

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

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

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

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

重新部署，這種情況可能是誤操作，也可能是其它異常導(dǎo)致服務(wù)掛了。總之，你需要在用戶還在不斷嘗試請求你服務(wù)的時候重啟。你會驚訝的發(fā)現(xiàn)，一直無法正常啟動為就緒狀態(tài)，所有服務(wù)都是未就緒。同樣的原因，服務(wù)啟動過程不是一次全部起來，而是逐批啟動，這樣每批服務(wù)啟動后都無法hold住流量，于是還是惡性循環(huán)，全面癱瘓。

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

自動擴展之瞬時高峰

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

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

自動伸縮之提前擴容

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

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

容器運行之僵尸進程

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

解決方法：tini

集群節(jié)點之移除節(jié)點

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

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

網(wǎng)頁名稱：Kubernetes使用時需要注意的坑點
本文鏈接：http://www.dlmjj.cn/article/djcpoic.html