Kubernetes資源擴容、項目發佈策略

Master擴容

100臺node，2臺master足夠了

這個在集羣中講過，能夠參考以前的

Node擴容

這個在集羣中講過，能夠參考以前的

Pod 擴容

如下是手動擴容爲5個
kubectl scale --replicas=5 deployment php-demo -n test

如下是手動縮容爲3個
kubectl scale --replicas=3 deployment php-demo -n test

自動擴容還得在研究

項目發佈策略

藍綠髮布
如今咱們公司用的就是藍綠髮布策略
A組 預發佈環境 192.168.1.100 192.168.1.101
B組 生成環境 192.168.1.102
nginx 負載均衡 經過upstream 將192.168.1.100 192.168.1.101 192.168.1.102 都加入進來

發佈時，將B組上線（從upstream剔除A組的服務器），更新A組的代碼，等待A組代碼更新完成，將A組更新上線，B組下線，更新B組的，等待B組更新完成，
再將A組，B組一塊兒都上線，咱們公司經過shell腳本管理的

特色：
• 策略簡單
• 升級/回滾速度快
• 用戶無感知，平滑過渡

缺點：
• 須要兩倍以上服務器資源
• 好比當A組或者B組上線任意一臺上線後可否知足併發

灰度發佈
A組 192.168.1.100
B組 192.168.1.101
C組 192.168.1.102

配置：nginx.conf 判斷：遠程地址=公司的公網IP時，就須要轉發到C組上
發佈前：先將C組更新代碼，由於是公司的網絡能夠訪問到最新的代碼，先讓其測試驗證（此時外面的用戶訪問的仍是舊的代碼，服務並無中止），沒問題後，則發佈到A組，B組，讓全部用戶都能訪問最新代碼

滾動發佈
滾動發佈：每次只升級一個或多個服務，升
級完成後加入生產環境，不斷執行這個過程，
直到集羣中的所有舊版升級新版本。
特色：
• 用戶無感知，平滑過渡
缺點：
• 部署週期長
• 發佈策略較複雜
• 不易回滾

Kubernetes中的滾動更新

deployment 控制器默認就是滾動更新

如果有3個pod，若升級第一個pod沒問題的話，就升級第二個，第二個沒有問題就升級第三個

經過rs屬性來操做：