深刻玩轉K8S之智能化的業務彈性伸縮和滾動更新操做

在上篇咱們講到了較爲傻瓜初級的彈性伸縮和滾動更新，那麼接下來咱們來看看較爲高級的智能的滾動更新。本節的知識點呢是K8S的liveness和readiness探測，也就是說利用健康檢查來作更爲智能化的彈性擴容和滾動更新。

 

那爲何說是比較智能化呢，由於在實際生產環境中會遇到這樣那樣的問題，好比：容器裏面應用掛了或者說新啓動的容器裏面應用尚未就緒等等，因此說就須要進行探測來檢驗容器是否知足需求。

 

那麼通常的檢測分爲幾種，好比：進程檢測、業務檢測。

 

進程檢測呢很好理解，也就是說經過檢測容器進程來驗證容器內應用是否存活。Kubelet會按期經過Docker Daemon獲取全部Docker進程的運行狀況，若是發現某個Docker容器未正常運行，則從新啓動該容器進程。目前，進程級的健康檢查都是默認啓用的。

 

業務檢測呢也好理解，有些人會問，有了進程檢測不就挺好的麼，爲何要進行業務檢測？　由於在不少實際場景下，僅僅使用進程級健康檢查還遠遠不夠。有時，從Docker的角度來看，容器進程依舊在運行；可是若是從應用程序的角度來看，假設應用代碼處於死鎖狀態的話，那每次調度到這個容器的時候永遠都沒法正常響應用戶的業務。好比對於使用java web服務的應用來講，並非簡單地說tomcat啓動成功就能夠對外提供服務的，還須要等待spring容器初始化，數據庫鏈接鏈接上等等。

 

爲了解決以上問題，Kubernetes引人了一個在容器內執行的活性探針（liveness probe）的概念，以支持用戶本身實現應用業務級的健康檢查。這些檢查項由Kubelet代爲執行，以確保用戶的應用程序正確運轉，至於什麼樣的狀態纔算「正確」，則由用戶本身定義。Kubernetes支持3種類型的應用健康檢查動做，分別爲HTTP Get、Container Exec和TCP Socket。我的感受exec的方式仍是最通用的，由於不是每一個服務都有http服務，但每一個服務均可以在本身內部定義健康檢查的job，按期執行，而後將檢查結果保存到一個特定的文件中，外部探針就不斷的查看這個健康文件就OK了。

 

介紹完活性探針（liveness probe）以後咱們來看看就緒探針（readiness probe），就緒探針是來肯定容器是否已經就緒能夠接受訪問，只有當Pod中的容器都處於就緒狀態時kubelet纔會認定該Pod處於就緒狀態，至於什麼樣的狀態纔算 」就緒」，仍是由用戶本身定義。該狀態的做用就是控制哪些Pod能夠做爲service的後端，若是Pod處於非就緒狀態，那麼它們將會被從service的load balancer中移除。

 

介紹到此處是否是以爲咱們的彈性伸縮和滾動更新若是加上剛纔介紹的 」兩針神器」就會變得更加智能化了。那下面咱們來看看這兩個探針如何在應用到彈性伸縮和滾動更新上。

 

開始以前能夠先看看進程探測，咱們基於busybox鏡像建立一個Pod，下面是yml文件。

該配置文件給Pod配置了一個容器。periodSeconds 規定kubelet要每隔5秒執行一次liveness probe。 initialDelaySeconds 告訴kubelet在第一次執行probe以前要的等待5秒鐘。探針檢測命令是在容器中執行 cat /tmp/healthy 命令。若是命令執行成功，將返回0，kubelet就會認爲該容器是活着的而且很健康。若是返回非0值，kubelet就會殺掉這個容器並重啓它。

能夠看到，日誌顯示/tmp/healthy不存在，探測失敗因此容器重啓

 

 

OK，那下面來進行業務探測的場景，好比：彈性伸縮，由於在實際場景中咱們因爲業務的需求可能須要臨時擴容新建N個容器，那麼這個時候就須要業務探測來檢查哪一個容器就沒就緒，若是就緒的話就把它做爲service的後端，下面的yml文件

OK，能夠看到個人測試失敗了，由於nginx裏面沒有/healthz，因此探測反饋404，證實個人業務如今還沒就緒因此就沒把它加入到service後端。

 

該配置文件定義了一個容器，readinessProbe 指定kubelete須要每隔5秒執行一次readiness Probe。initialDelaySeconds 指定kubelet在該執行第一次探測以前須要等待10秒鐘。該探針將向容器中的server的80端口發送一個HTTP GET請求。若是server的/healthz路徑的handler返回一個成功的返回碼，kubelet就會認定該容器是活着的而且很健康。若是返回失敗的返回碼，kubelet將殺掉該容器並重啓它。

 

注意：任何大於200小於400的返回碼都會認定是成功的返回碼。其餘返回碼都會被認爲是失敗的返回碼。

 

OK，下面來看看滾動更新，由於在實際場景中程序應用確定避免不了進行更新，咱們在上一篇文章中講述了簡單的傻瓜式滾動更新，下面咱們來看看較爲智能化高級的滾動更新，也就是加上了業務探測，依舊是v一、v2的例子，下面是yml文件。

這裏模擬的是一個失敗的滾動更新，在咱們的設定中，新副本始終都沒法經過Readiness探測，能夠看到我在上面新建pod的時候在容器裏面新建了一個目錄，可是過一會就刪除了，因此說V2我在進行滾動升級的時候失敗了。不過幸運的是健康檢查幫咱們屏蔽了有問題的副本，同時也保留了原有的副本，業務並無由於更新失敗而受到影響。

 

OK，那既然更新失敗了，那就根據上篇文章所學的，咱們執行下回滾，利用kubectl rollout undo

最後注意下，滾動更新是能夠在yml文件裏面經過參數maxSurge和maxUnavailable來控制副本替換的數量，本文參考了Kubernetes官網和天天5分鐘玩轉K8S。