在自动缩放条件下重新部署时，Kubernetes 滚动更新不遵守“maxUnavailable”副本

Question

简而言之，我们的大多数应用都在 Deployment 中配置了以下strategy -

  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate

Horizo​​ntal Pod Autoscaler 是这样配置的

spec:
  maxReplicas: 10
  minReplicas: 2

现在，当重新部署我们的应用程序时，它没有运行滚动更新，而是立即终止了 8 个 Pod，并将 Pod 的数量减少到 2，这是可用副本的最小数量。正如您在此处看到的，这发生在几分之一秒内。

这是kubectl get hpa的输出 -

由于maxUnavailable 是 25%，不应该只有大约 2-3 个 pod 最多下降吗？为什么这么多豆荚同时崩溃？如果这样操作，滚动更新似乎毫无用处。

我错过了什么？

Answer 1

看了这个问题后，我决定在我想检查它是否不起作用的测试环境中尝试这个。

我已设置metrics-server 来获取指标服务器并设置 HPA。我已按照以下步骤设置 HPA 和部署：

How to Enable KubeAPI server for HPA Autoscaling Metrics

有一次，我在系统上运行了 HPA 和 max 10 pods，我使用以下方法更新了图像：

[root@ip-10-0-1-176 ~]# kubectl get hpa
NAME         REFERENCE               TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
php-apache   Deployment/php-apache   49%/50%   1         10        10         87m

[root@ip-10-0-1-176 ~]# kubectl get pods
NAME                              READY   STATUS    RESTARTS   AGE
load-generator-557649ddcd-6jlnl   1/1     Running   0          61m
php-apache-75bf8f859d-22xvv       1/1     Running   0          91s
php-apache-75bf8f859d-dv5xg       1/1     Running   0          106s
php-apache-75bf8f859d-g4zgb       1/1     Running   0          106s
php-apache-75bf8f859d-hv2xk       1/1     Running   0          2m16s
php-apache-75bf8f859d-jkctt       1/1     Running   0          2m46s
php-apache-75bf8f859d-nlrzs       1/1     Running   0          2m46s
php-apache-75bf8f859d-ptg5k       1/1     Running   0          106s
php-apache-75bf8f859d-sbctw       1/1     Running   0          91s
php-apache-75bf8f859d-tkjhb       1/1     Running   0          55m
php-apache-75bf8f859d-wv5nc       1/1     Running   0          106s
[root@ip-10-0-1-176 ~]# kubectl set image deployment php-apache php-apache=hpa-example:v1 --record
deployment.extensions/php-apache image updated

[root@ip-10-0-1-176 ~]# kubectl get pods
NAME                              READY   STATUS              RESTARTS   AGE
load-generator-557649ddcd-6jlnl   1/1     Running             0          62m
php-apache-75bf8f859d-dv5xg       1/1     Terminating         0          2m40s
php-apache-75bf8f859d-g4zgb       1/1     Terminating         0          2m40s
php-apache-75bf8f859d-hv2xk       1/1     Terminating         0          3m10s
php-apache-75bf8f859d-jkctt       1/1     Running             0          3m40s
php-apache-75bf8f859d-nlrzs       1/1     Running             0          3m40s
php-apache-75bf8f859d-ptg5k       1/1     Terminating         0          2m40s
php-apache-75bf8f859d-sbctw       0/1     Terminating         0          2m25s
php-apache-75bf8f859d-tkjhb       1/1     Running             0          56m
php-apache-75bf8f859d-wv5nc       1/1     Terminating         0          2m40s
php-apache-847c8ff9f4-7cbds       1/1     Running             0          6s
php-apache-847c8ff9f4-7vh69       1/1     Running             0          6s
php-apache-847c8ff9f4-9hdz4       1/1     Running             0          6s
php-apache-847c8ff9f4-dlltb       0/1     ContainerCreating   0          3s
php-apache-847c8ff9f4-nwcn6       1/1     Running             0          6s
php-apache-847c8ff9f4-p8c54       1/1     Running             0          6s
php-apache-847c8ff9f4-pg8h8       0/1     Pending             0          3s
php-apache-847c8ff9f4-pqzjw       0/1     Pending             0          2s
php-apache-847c8ff9f4-q8j4d       0/1     ContainerCreating   0          4s
php-apache-847c8ff9f4-xpbzl       0/1     Pending             0          1s

另外，我在后台保留了工作，它每秒将kubectl get pods 输出推送到一个文件中。在升级所有镜像之前，Pod 的数量从未低于 8。

我认为您需要检查您是如何设置滚动升级的。您使用的是部署还是副本集？我将rolling update 策略与您的maxUnavailable: 25% 和maxSurge: 25% 部署保持一致，它对我来说效果很好。

Answer 2

我想指出minReadySeconds 属性。

minReadySeconds 属性指定新创建的 pod 在被视为可用之前应该准备好多长时间。实际上，没有minReadySeconds 的属性的重新部署已经在很短的时间内成功完成。但在短时间内 就绪探测 开始因任何原因失败，并且 pod 开始缩小。

maxUnavailable 属性仅在 RollingUpdate 时被关注。在 RollingUpdate 事件之后，此属性被忽略。

Kubernetes In Action 书中的注意事项：如果您只定义了就绪探针而没有正确设置 minReadySeconds，则当第一次调用就绪探针成功时，新的 pod 将被视为立即可用。如果就绪探测在不久之后开始失败，则会在所有 pod 中推出错误版本。因此，您应该适当地设置 minReadySeconds。