3.6 Pod 缩放

在前面我们已经学习到了 Pod 的扩容、滚动更新等知识,我们可以手动为 Deployment 等设置 Pod 副本的数量,而这里会继续学习 关于 Pod 扩容、收缩 的规则,让 Pod 根据节点服务器的资源自动增加或减少 Pod 数量。

缩放 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 个副本数量。如果在机器管够的情况下,可以去掉 minmax 参数。

算法细节请查看: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,此时可以指定 maxUnavailablemaxSurge 来控制滚动更新 过程。这个我们之前提到过,就是 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 设置小一些。

Copyright © 痴者工良 2021 all right reserved,powered by Gitbook文档最后更新时间: 2021-11-05 20:51:15

results matching ""

    No results matching ""