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属性来操作：
原文地址：http://blog.51cto.com/jacksoner/2340189