Kubernetes集羣中使用阿里雲 SLB 實現四層金絲雀發佈

摘要: 上文介紹瞭如何使用Ingress實現藍綠髮布。可是對於不少只提供tcp/udp的服務來講,七層的ingress不能很好的實現藍綠髮布的需求。這裏咱們就來介紹一下如何使用 SLB 來進行四層的金絲雀發佈。nginx

前言後端

上文介紹瞭如何使用Ingress實現藍綠髮布。可是對於不少只提供tcp/udp的服務來講,七層的ingress不能很好的實現藍綠髮布的需求。這裏咱們就來介紹一下如何使用 SLB 來進行四層的金絲雀發佈。app

準備負載均衡

首先須要一個已經經過SLB對外提供服務的應用,這裏咱們仍是繼續使用nginx做爲例子,不過此次是經過SLB對外暴露的服務。curl

 

能夠直接在控制檯上,經過應用->部署 使用模板來部署應用。tcp

建立完畢後,就能夠在控制檯上看到對應的部署與服務。url

如今咱們能夠經過本地curl 來看一下部署的效果code

 

能夠看到已經正常訪問。blog

新服務上線資源

下面咱們模擬新的服務上線,如今建立新的應用。

值得注意的就是,新服務的pod的label,也是含有app:nginx標籤的。這個標籤就是爲了對應的service找到該pod,這樣就能夠將對應的流量導入進來。

建立完畢後就能夠在控制檯上看到新的應用。

下面咱們在執行一下curl 看一下效果。

 

能夠看到,十次請求裏面,有五次打到了老服務,五次打到了新服務。主要緣由是,service對於流量請求是平均的負載均衡策略,並且新老服務均爲一個pod,所以他們的流量百分比爲1:1 。

調整流量權重

這裏的權重調整就沒有ingress的那麼直接。須要調整後端的pod容器數量來調整對應的權重。好比咱們這裏但願新的服務權重更大一些,那麼想調整新的pod數量到3個。

能夠直接在控制檯上更新已有的應用。注意: Kubernetes的Deployment資源默認的更新方式就是rollingUpdate,因此在更新過程當中,會保證最小可服務的容器個數,這個個數也能夠在模板裏面調整。

 

更新完畢後,新老服務個數比爲3:1, 下面咱們再來curl一下,看一下效果。

 

能夠看到,10個請求裏面,有8個請求到新的服務,2個到老的服務。後面就能夠經過動態的調整pod的數量來調整新老服務的權重,實現金絲雀發佈。

完成

發佈完畢後,將對應的舊應用刪除便可。刪除完畢後,看一下curl的效果

 

這樣就實現了四層 SLB 金絲雀發佈的流程。

原文連接

相關文章
相關標籤/搜索