kubernetes - 集群自动扩缩器未降级

Question

我在 中设置了区域集群谷歌 kubernetes 引擎 (GKE) .节点组是单个 每个区域的虚拟机(共 3 个) .我有一个部署 最少 3 个副本 由 HPA 控制。
节点组配置为自动缩放 (集群自动缩放又名 CA)。
问题场景:

更新部署镜像。 Kubernetes 会自动创建新的 pod，CA 识别出需要一个新节点。我现在有4个。
当所有新 Pod 启动时，旧 Pod 会被删除，这意味着我的 CPU 请求与前一分钟完全相同。但是在 10 分钟的最大缩减时间之后，我仍然有 4 个节点。

节点的 CPU 请求现在是:

CPU Requests  CPU Limits  Memory Requests  Memory Limits
  ------------  ----------  ---------------  -------------
  358m (38%)    138m (14%)  516896Ki (19%)   609056Ki (22%)
--
  CPU Requests  CPU Limits  Memory Requests  Memory Limits
  ------------  ----------  ---------------  -------------
  800m (85%)    0 (0%)      200Mi (7%)       300Mi (11%)
--
  CPU Requests  CPU Limits  Memory Requests  Memory Limits
  ------------  ----------  ---------------  -------------
  510m (54%)    100m (10%)  410Mi (15%)      770Mi (29%)
--
  CPU Requests  CPU Limits  Memory Requests  Memory Limits
  ------------  ----------  ---------------  -------------
  823m (87%)    158m (16%)  484Mi (18%)      894Mi (33%)

38% 的节点正在运行:

Namespace                  Name                                                            CPU Requests  CPU Limits  Memory Requests  Memory Limits
  ---------                  ----                                                            ------------  ----------  ---------------  -------------
  kube-system                event-exporter-v0.1.9-5c8fb98cdb-8v48h                          0 (0%)        0 (0%)      0 (0%)           0 (0%)
  kube-system                fluentd-gcp-v2.0.17-q29t2                                       100m (10%)    0 (0%)      200Mi (7%)       300Mi (11%)
  kube-system                heapster-v1.5.2-585f569d7f-886xx                                138m (14%)    138m (14%)  301856Ki (11%)   301856Ki (11%)
  kube-system                kube-dns-autoscaler-69c5cbdcdd-rk7sd                            20m (2%)      0 (0%)      10Mi (0%)        0 (0%)
  kube-system                kube-proxy-gke-production-cluster-default-pool-0fd62aac-7kls    100m (10%)    0 (0%)      0 (0%)           0 (0%)

我怀疑它不会因为 heapster 或 kube-dns-autoscaler 而缩小规模。
但 85% 的 pod 包含:

Namespace                  Name                                                            CPU Requests  CPU Limits  Memory Requests  Memory Limits
  ---------                  ----                                                            ------------  ----------  ---------------  -------------
  kube-system                fluentd-gcp-v2.0.17-s25bk                                       100m (10%)    0 (0%)      200Mi (7%)       300Mi (11%)
  kube-system                kube-proxy-gke-production-cluster-default-pool-7ffeacff-mh6p    100m (10%)    0 (0%)      0 (0%)           0 (0%)
  my-deploy                  my-deploy-54fc6b67cf-7nklb                                      300m (31%)    0 (0%)      0 (0%)           0 (0%)
  my-deploy                  my-deploy-54fc6b67cf-zl7mr                                      300m (31%)    0 (0%)      0 (0%)           0 (0%)

fluentd 和 kube-proxy pod 存在于每个节点上，所以我认为没有节点就不需要它们。这意味着我的部署可以重定位到其他节点，因为它只有 300m 的请求(31%，因为只有 94% 的节点 CPU 是可分配的)。

所以我想我会检查日志。但是如果我运行 kubectl get pods --all-namespaces对于 CA，GKE 上没有可见的 pod。如果我使用命令 kubectl get configmap cluster-autoscaler-status -n kube-system -o yaml它只告诉我它是否即将扩展，而不是为什么或为什么不。
另一种选择是查看 /var/log/cluster-autoscaler.log在主节点。我 SSH:ed 在所有 4 个节点中只找到了一个 gcp-cluster-autoscaler.log.pos文件说: /var/log/cluster-autoscaler.log 0000000000000000 0000000000000000意味着文件应该就在那里，但为空。
最后一个选项根据 FAQ , 是检查 pod 的事件，但据我所知它们是空的。

任何人都知道为什么它不会缩小或至少在哪里可以找到日志？

Answer 1

回答我自己的可见性。

问题是 CA 从不考虑移动任何东西，除非 FAQ 中提到的所有要求同时相遇。
所以可以说我有 100 个节点，有 51% 的 CPU 请求。它仍然不会考虑缩小规模。

一种解决方案是增加 CA 检查的值，现在是 50%。但不幸的是 GKE 不支持，请参阅谷歌支持@GalloCedrone 的回答:

Moreover I know that this value might sound too low and someone could be interested to keep as well a 85% or 90% to avoid your scenario. Currently there is a feature request open to give the user the possibility to modify the flag "--scale-down-utilization-threshold", but it is not implemented yet.

我发现的解决方法是减少 Pod 的 CPU 请求(100m 而不是 300m)，并让 Horizo​​ntal Pod Autoscaler (HPA) 按需创建更多。这对我来说很好，但是如果您的应用程序不适合许多小实例，那么您就不走运了。如果总利用率低，也许是一个封锁节点的 cron 作业？