通过scale命令来实现副本集的扩展
比如我们此时跑了个kubernetes-bootcamp的pod：
然后将其副本扩展到三个：
1 | kubectl scale deployments/kubernetes-bootcamp --replicas=3 deployment.extensions/kubernetes-bootcamp scaled |
此时：
这时pod增加到了三个，我们去访问这个应用的时候，会将请求发送到不同的pod上面去处理，实现了均衡负载。减少副本的话使用：
1 | kubectl scale deployments/kubernetes-bootcamp --replicas=2 |
当然，如果是用yml文件创建的，直接修改副本集的数量就可以直接控制。
pod的更新回滚
通过yaml/yml文件
1、更新
滚动更新是一次只更新一小部分副本，成功之后再更新更多的副本，最终保证所有副本的更新。这样做的好处就是能过做到零停机，整个过程中始终有副本再保持运行，保证了业务的运行。
比如现在运行着http 2.2.31的副本：
然后将其更新到2.2.32，此时我们通过重修修改配置文件来实现：
这是一个逐渐更新并且替换的过程，我们可以通过查看日志来看：
从第二行开始看：
- 先增加一个pod，总数为1
- 减少一个pod，总数为1
- 增加一个pod，总数为2
- 减少一个，总数为0
每次都只更新一个pod，当然可以通过maxSurge和maxUnavaliable参数来控制每次更新的pod数量。
-
maxSurge：此参数控制滚动更新过程中副本总数超过DESIRED的上限，可以是具体的整数，也可以是百分数，向上取整，默认是25%。
-
maxUnavaliable：此参数控制滚动更新，不可用的副本占DESIRED的最大比例，下取整，默认值为25%。
前者越大，初始创建副本的数量也就越多；后者越大，初始销毁的旧副本数量也就越大。
2、回滚
kubectl apply每次更新应用的时候，都会记录下当前的配置，保存为一个revision，这样就可以回滚到某个特定的revision。
默认配置下，k8s只会保留最近几个revision，可以在配置文件下通过revisionHistoryLimit属性增加revision数量。
比如这时候存在httpd.v1.yml、httpd.v2.yml、httpd.v3.yml，然后镜像分别是2.4.16、2.4.17、2.4.18，然后我们分别执行：
1 | kubectl apply -f httpd.v1.yml --record |
–record的作用是将当前的命令记录到revision中，这样k8s就可以知道每个版本所对应的配置文件了，然后就可以通过kubectl rollout history deployment httpd可以查看revision的历史信息：
如果需要回滚到某一个版本，只需要执行：
1 | kubectl rollout undo deployment httpd --to-revision=1 |
这个时候我们再去看revision：
