Question

我在 google kubernetes引擎（GKE）中设置了区域群集。节点组在每个区域中是一个 vm（总共3个）。我有一个由HPA控制的 3个副本最低的部署。 节点组配置为自动扩展（群集自动缩放又称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%)

每个节点都有流利的和kube-proxy pod，因此我假设没有节点就不需要它们。这意味着我的部署可以重新定位到其他节点，因为它只有300米的请求（31％，因为只有94％的节点CPU是可分配的）。

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

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

Answer 1

回答自己的可见度。

问题在于CA从不考虑移动任何内容，除非同时满足FAQ中提到的所有要求。所以假设我有100个节点，有51％的CPU请求。它仍然不会考虑降尺度。

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

此外我知道这个值可能听起来太低了，有人可能有兴趣保持85％或90％以避免你的情况。目前有一个功能请求打开，可以让用户修改标志“--scale-down-utilization-threshold”，但尚未实现。

我找到的解决方法是减少pod的CPU请求（100米而不是300米），并让Horizontal Pod Autoscaler（HPA）按需创建更多。这对我来说很好，但如果你的应用程序不适合许多小实例，那你就不走运了。如果总利用率很低，也许是一个关闭节点的cron工作？

Answer 2

我同意根据Documentation，似乎＆＃34; gke-name-cluster-default-pool＆＃34;可以安全删除，条件：

此节点上运行的所有pod的cpu和内存请求总和小于节点可分配的50％。
节点上运行的所有pod（默认情况下在所有节点上运行的所有pod，例如由守护程序集创建的清单运行pod或pod）都可以移动到其他节点。
它没有缩小禁用的注释因此，应该在10分钟后将其移除，认为不需要它。

然而，检查我发现的Documentation：

哪些类型的pod可以阻止CA删除节点？

[...]   默认情况下未在节点上运行的Kube系统pod，*   [..]

heapster-v1.5.2 ---正在节点上运行，它是一个Kube系统pod，默认情况下不在节点上运行。

如果我发现更多有趣的信息，我会更新答案。

更新

节点是区域中的最后一个节点不是问题。

为了证明这一点，我在一个全新的集群上进行了测试，每个集群在不同的区域中有3个节点，其中一个节点除了＆＃34; kube-proxy＆＃34;之外没有任何工作量。和＃34;流利的＆＃34;并且即使它将区域的大小设置为零也被正确删除。

群集自动缩放器不缩减

2 个答案:

哪些类型的pod可以阻止CA删除节点？

更新