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

提问者：小点点

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

简而言之，我们的大多数应用在部署中都配置了以下< code >策略

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

水平Pod自动缩放器配置如下

spec:
  maxReplicas: 10
  minReplicas: 2

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

这是 kubectl 得到 hpa 的输出 -

由于maxUn可用为25%，最多不应该只有大约2-3个pod崩溃吗？为什么这么多pod同时崩溃？如果它以这种方式工作，滚动升级似乎毫无用处。

我错过了什么？

共3个答案

匿名用户

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

我已经设置了< code>metrics-server来获取度量服务器并设置HPA。我按照以下步骤设置了HPA和部署:

如何为HPA自动缩放度量启用KubeAPI服务器

有一次，我在系统上运行了工作 HPA 和最多 10 个 pod，我使用以下方法更新了图像：

[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输出。在所有图像升级之前，豆荚数量从未低于8个。

我相信您需要检查如何设置滚动升级。您使用的是部署集还是副本集？我一直保持滚动更新策略与您相同的最大不可用：25% 和最大激增：部署 25%，它对我来说效果很好。

匿名用户

我想指出< code>minReadySeconds属性。

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

maxUn可用属性仅在RollingUpdate时才会被注意。在RollingUpdate事件之后，此属性被忽略。

库伯内特斯在《行动》一书中的说明：如果您只定义了就绪探测，而没有正确设置minReady秒，则当就绪探测的第一次调用成功时，新pod将立即被视为可用。如果就绪探测不久后开始失败，则坏版本将在所有pod中推出。因此，您应该适当设置minReady秒。

匿名用户

在我们的例子中，我们刚才添加了副本字段，但在添加HPA时忘记删除它了。在部署期间，HPA与副本字段的效果不好，因此如果您有HPA，请删除副本字段。参见https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#migrating-deployments-and-statefulsets-to-horizontal-autoscaling

启用HPA后，建议从其清单中删除Deployment和/或StatefulSet的spec.replicates的值。如果没有做到这一点，则在任何时候应用对该对象的更改，例如通过kubectl apply-f deployment.yaml，这将指示Kubernetes将当前Pod的数量调整为spec.replicates键的值。这可能是不希望的，并且当HPA激活时可能会很麻烦。

请记住，删除spec.replicas可能会导致Pod计数的一次性降级，因为此键的默认值为1（参考部署副本）。更新后，除1之外的所有Pod都将开始其终止过程。之后的任何部署应用程序都将正常运行，并根据需要遵守滚动升级配置。