Kubernetes使用時需要注意的坑點
在Kubernetes實踐的過程中，積累了一些填坑經驗，小做總結，拿來分享一下。
希望能對準備或正在使用Kubernetes的小伙伴提供幫助。
滾動升級之更新太慢
默認情況下，滾動升級是逐個更新的，當有幾十上百個Pod需要更新時，再加上就緒檢測，整個過程將會更慢。如果你想和更多Kubernetes技術專家交流，可以加我微信liyingjiese，備注『加群』。群里每周都有全球各大公司的***實踐以及行業***動態
解決方法：
- rollingUpdate:
- maxSurge: 20% #每個滾動更新的實例數量
- maxUnavailable: 10% #允許更新過程中有多少實例不可用
就緒檢測之無損更新
通常，服務重啟的時候會有一小段時間是無法正常提供服務的。
為了避免這個過程中有請求的流量進來，我們可以使用就緒檢測來檢測服務是否就緒可正常接收并處理請求。
- ......
- readinessProbe:
- httpGet:
- host: api.xxx.com
- path: /
- port: 80
- initialDelaySeconds: 3 # 容器啟動3秒后開始***次檢測
- periodSeconds: 60 # 每隔60s檢測一次
- timeoutSeconds: 3 # http檢測請求的超時時間
- successThreshold: 1 # 檢測到有1次成功則認為服務是`就緒`
- failureThreshold: 1 # 檢測到有1次失敗則認為服務是`未就緒`
- ......
就緒檢測之全面癱瘓
就緒檢測是把雙利劍，用不好，反而容易出大問題，比如服務全面癱瘓。
我們可以看到上面就緒檢測的配置，漏洞百出。
比如：超時，高并發情況下，請求處理不過來，個別服務很容易導致檢測請求的超時(504)，立馬被認為未就緒，于是流量被轉移到其它服務，進而讓本來就高負荷的其它服務出現同樣情況，惡性循環，很快，所有服務都被認為是未就緒，結果產生全面癱瘓現象。
解決方法：設置更長的超時時間，以及更高的失敗次數。
重新部署，這種情況可能是誤操作，也可能是其它異常導致服務掛了。總之，你需要在用戶還在不斷嘗試請求你服務的時候重啟。你會驚訝的發現，一直無法正常啟動為就緒狀態，所有服務都是未就緒。同樣的原因，服務啟動過程不是一次全部起來，而是逐批啟動，這樣每批服務啟動后都無法hold住流量，于是還是惡性循環，全面癱瘓。
解決方法：先去掉就緒檢測再重新部署。
自動擴展之瞬時高峰
自動擴展POD雖然好用，但如果擴展的指標(CPU、內存等)設置的過高，如：50%以上，那么，當突然有翻倍的流量過來時，根本來不及擴展Pod，服務直接就超時或掛掉。
解決方法：盡可能的把指標設置在一個較小的值，對以往流量做參考評估，確保了當有2倍、3倍甚至5倍的流量突襲時不至于hold不住。
自動伸縮之提前擴容
通常，節點的自動伸縮依賴于Pod的自動擴展時資源是否充足。然而在面對定時突然流量高峰的業務時，這種伸縮顯然來不及，甚至常常出現高峰10分鐘后才擴容的機器，流量已經回到低谷，完全啟不到作用。并且，流量到底是因為業務屬性很快回落，還是因為擴容不及時導致的流失?
解決方法：根據自身業務，參考以住流量數量及推廣時間，找到規律，提前或定時觸發自動擴容。
容器運行之僵尸進程
這是一個Docker舊版(<1.13)已知問題，有些容器啟動后會出現defunct進程(ps aux | grep defunct)，而且會越來越多，稱為僵尸進程，可能導致內存泄漏，而且kill不掉，除非重啟容器。
解決方法：tini
集群節點之移除節點
如何安全地移出節點?這個節點上面部署了你的業務，甚至包括kube-system的東西。
解決方法：kubectl drain，可以先把節點上的Pod驅逐到其它節點，然后再移出該節點。
