Kubernetes資源擴容、項目發布策略
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
發布時，將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屬性來操作：
Kubernetes資源擴容、項目發布策略