在前面我们已经学习到了 Pod 的扩容、滚动更新等知识，我们可以手动为 Deployment 等设置 Pod 副本的数量，而这里会继续学习 关于 Pod 扩容、收缩 的规则，让 Pod 根据节点服务器的资源自动增加或减少 Pod 数量。
本文为作者的 Kubernetes 系列电子书的一部分，电子书已经开源，欢迎关注，电子书浏览地址：
https://k8s.whuanle.cn【适合国内访问】
https://ek8s.whuanle.cn 【gitbook】
缩放 Deployment
设置副本数量
很简单，使用 kubectl scale 命令直接设置：
kubectl scale deployment nginx --replicas=10
其它方式前面的章节已经提到过了，还有通过修改 YAML 文件的方式。
水平自动缩放
K8S 有个 Pod 水平自动扩缩（Horizontal Pod Autoscaler） 可以基于 CPU 利用率自动扩缩 ReplicationController、Deployment、ReplicaSet 和 StatefulSet 中的 Pod 数量。Pod 自动扩缩不适用于无法扩缩的对象，比如 DaemonSet。
除了 CPU 利用率，也可以基于其他应程序提供的自定义度量指标 来执行自动扩缩。
参考资料：https://kubernetes.io/zh/docs/tasks/run-application/horizontal-pod-autoscale/
命令：
kubectl autoscale deployment nginx --min=10 --max=15 --cpu-percent=80
表示目标 CPU 使用率为 80%(期望指标)，副本数量配置应该为 10 到 15 之间，CPU 是动态缩放 pod 的指标，会根据具体的 CPU 使用率计算副本数量，其计算公式如下。
期望副本数 = ceil[当前副本数 * (当前指标 / 期望指标)]
因为笔者这里只有一个 Worker 节点，不能控制 CPU 使用率模拟场景，所以不方便演示，读者只需要了解这个命令即可。
按照算法计算，加入当前副本数量为 12，且 CPU 使用率达到 90%，则期望副本数为 12*(90%/80%) = 13.5，那么理论上会部署 14 个 Pod，但是 CPU 再继续增加的话，最多 15 个副本数量。如果在机器管够的情况下，可以去掉 min 和 max 参数。
算法细节请查看：https://kubernetes.io/zh/docs/tasks/run-application/horizontal-pod-autoscale/#algorithm-details
比例缩放
比例缩放指的是在上线 Deployment 时，临时运行着应用程序的多个版本(共存)，比例缩放是控制上线时多个 Pod 服务可用数量的方式。
水平缩放只关心最终的期望 Pod 数量，直接修改副本数和水平缩放，决定最终 Pod 数量有多少个。
而比例缩放是控制对象上线过程中，新的 Pod 创建速度和 旧的 Pod 销毁速度、 Pod 的可用程度，跟上线过程中新旧版本的 Pod 替换数量有关。
查看上一章中创建的 Deployment 的部分 YAML 如下：
spec:
progressDeadlineSeconds: 600
replicas: 1
revisionHistoryLimit: 10
selector:
matchLabels:
app: nginx
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
type: RollingUpdate
strategy 可以配置 Pod 是怎么更新的。
当我们设置.spec.strategy.type==RollingUpdate时，便会采取滚动更新的方式更新 Pods，此时可以指定 maxUnavailable 和 maxSurge 来控制滚动更新 过程。这个我们之前提到过，就是 Deployment 默认会保证一直有 75% 的 pod处于可用状态，在完成更新前可能有多个版本的 pod 共存。
-
maxUnavailable
最大不可用数量或比例，旧的 Pod 会以这个数量或比例逐渐减少。
-
maxSurge
最大峰值，新的 Pod 会按照这个数量或比例逐渐创建。
3.5 章已经使用到了这两者，这里就不细说了，读者请参考：https://kubernetes.io/zh/docs/concepts/workloads/controllers/deployment/#max-unavailable
我们查看之前的 Deployment，执行命令 kubectl get deployment nginx -o yaml：
... ...
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
type: RollingUpdate
... ...
配置表示，每次只有 1/4 的 Pod 被更新、替换。
这个是所有 Deployment 的默认配置，在更新镜像版本时，旧的 Pod 会被新的 Pod 替换，但是不是一下子完成的，每次处理 25% 的 Pod，在更新过程中，我们必须保证我们的服务依然可用，即还有旧版本的 Pod 在运行。这个配置设定了更新过程中至少保证 75% 的 Pod 还可以使用，这个就是比例缩放。
下面我们来进行实验。
首先创建新的 Deployment ，设置副本数量为 10：
kubectl create deployment nginx --image=nginx:1.19.0 --replicas=10
# kubectl scale deployment nginx --replicas=10
我们执行 kubectl edit deployment nginx 修改缩放个数：
strategy:
rollingUpdate:
maxSurge: 3
maxUnavailable: 2
type: RollingUpdate
除了可用百分比表示，也可以使用个数表示。
旧的 Pod 按照最大 2 个的速度不断减少；新的 Pod 按照最大 3 个的速度不断增加；
比例缩放的配置处理好了，它会在我们上线新版本的时候生效，我们可以观察到这个过程，但是需要快一点执行命令查看状态。
快速执行以下命令：
kubectl set image deployment nginx nginx=nginx:1.20.0
kubectl get replicaset
root@instance-1:~# kubectl set image deployment nginx nginx=nginx:1.20.0
deployment.apps/nginx image updated
root@instance-1:~# kubectl get replicaset
NAME DESIRED CURRENT READY AGE
nginx-7b87485749 5 5 0 93m
nginx-85b45874d9 0 0 0 93m
nginx-bb957bbb5 8 8 8 35m
因为允许新的 Pod 创建较快(3个)，所以最终可能新的 Pod 数量达到 10 个了，旧的 Pod 还有很多，总数量大于 10。
最终：
NAME DESIRED CURRENT READY AGE
nginx-7b87485749 10 10 10 99m
nginx-85b45874d9 0 0 0 99m
nginx-bb957bbb5 0 0 0 41m
如果想新版本的 Pod 上线速度更快，则可以把 maxSurge 数量或比例设置大一些；为了保证上线过程稳定、服务可用程度高，可以把 maxUnavailable 设置小一些。