Question

简而言之，我们的大多数应用在“部署”中配置了以下strategy-

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

Horizonatal Pod自动缩放器已配置为

spec:
  maxReplicas: 10
  minReplicas: 2

现在，当重新部署我们的应用程序时，它没有终止滚动更新，而是立即终止了我们的8个容器，并将容器数降至2，这是可用副本的最小数目。正如您在此处看到的那样，这只发生了不到一秒钟。

这是kubectl get hpa-

的输出

由于maxUnavailable为25％，难道不应该只有大约2-3个豆荚掉落吗？为什么这么多豆荚一次崩溃？如果采用这种方式，滚动更新似乎毫无用处。

我想念什么？

Answer 1

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

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

How to Enable KubeAPI server for HPA Autoscaling Metrics

一旦我在系统上运行了HPA，并且最大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输出推送到文件中。在升级完所有映像之前，窗格的数量永远不会低于8。

我相信您需要检查如何设置滚动升级。您正在使用部署或副本集吗？在部署过程中，我一直将rolling update策略与您maxUnavailable: 25%和maxSurge: 25%保持一致，并且对我来说效果很好。

Answer 2

我想指出minReadySeconds属性。

minReadySeconds属性，用于指定新创建的容器应在准备就绪之前准备就绪的时间。实际上，没有minReadySeconds属性的重新部署已经在很短的时间内成功完成。但是不久之后，准备情况调查由于任何原因开始失败，并且窗格开始缩小。

maxUnavailable属性仅在RollingUpdate时需要注意。 RollingUpdate事件后，此属性将被忽略。

Kubernetes In Action的书中的注释：如果仅在未正确设置 minReadySeconds 的情况下定义就绪探针，则在首次成功调用就绪探针时，将立即认为新容器可用。如果就绪探针不久后开始出现故障，则不良版本将在所有Pod中推出。因此，您应该适当设置 minReadySeconds 。

在自动缩放条件下重新部署时，Kubernetes滚动更新不遵循``maxUnavailable''副本

2 个答案: