Kubernetes：应用自动扩容、收缩与稳定更新

在前面我们已经学习到了 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 设置小一些。