4

我创建了一个谷歌 Kubernetes 引擎，启用了最小和最大节点的自动缩放。几天前，我在生产环境中部署了几台服务器，这增加了预期的节点数。但是当我删除这些部署时，我希望它能够调整要缩小的节点的大小。我等了一个多小时，但它仍然没有缩小。

  • 自从我使用 kind: deployment 进行部署以来，我所有的其他 pod 都由副本控制器控制。
  • 我所有的 statefulset pod 都使用 PVC 作为卷。

我不确定是什么阻止了节点缩减，所以我现在手动扩展了节点。由于我手动进行了更改，因此我现在无法获取自动缩放器日志。

有谁知道这里可能是什么问题？

GKE 版本为 1.16.15-gke.4300

如本链接所述 https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md#what-types-of-pods-can-prevent-ca-from-removing-a-node

  • 我没有使用任何本地存储。
  • 没有 PodDisruptionBudget 的 pod（不知道那是什么）
  • Pod 由部署创建（掌舵图）
  • 唯一的问题是我没有 "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" 这个注释。这是必须的吗？
4

1 回答 1

2

我已经Cluster Autoscaler在我的 GKE 集群上进行了测试。它的工作方式与您预期的有所不同。

背景

您可以使用命令启用自动缩放，也可以在创建期间启用它，如本文档中所述。

在Cluster Autoscaler文档中，您可以找到各种信息，例如Operation criteria、Limitations等。

正如我在评论部分提到的，如果遇到以下情况之一，Cluster Autoscaler - 常见问题将不起作用：

具有限制性 PodDisruptionBudget 的 Pod。

Kube 系统 pod：

  • 默认不在节点上运行，*
  • 没有设置 pod 中断预算，或者他们的 PDB 过于严格（自 CA 0.6 起）。

不受控制器对象支持的 Pod（因此不是由部署、副本集、作业、有状态集等创建的）。*

具有本地存储的 Pod。*

由于各种限制（缺乏资源、不匹配的节点选择器或亲和性、匹配的反亲和性等）而无法移动到其他地方的 Pod

具有以下注释集的 Pod： "cluster-autoscaler.kubernetes.io/safe-to-evict": "false"

对于我的测试，我使用了 6 个节点，autoscaling range 1-6以及nginx带有请求的应用程序cpu: 200m和memory: 128Mi.

正如 OP 提到的那样，它无法提供自动缩放器日志，我将从Logs Explorer. 查看集群自动缩放器事件文档中描述了如何实现它们。

在这些日志中，您应该搜索noScaleDown事件。您会在那里找到一些信息，但最重要的是：

reason: {
parameters: [
0: "kube-dns-66d6b7c877-hddgs"
]
messageId: "no.scale.down.node.pod.kube.system.unmovable"

正如NoScaleDown 节点级原因中所述"no.scale.down.node.pod.kube.system.unmovable"：

Pod 正在阻止缩减，因为它是一个非守护程序集、非镜像、非 pdb 分配的 kube-system pod。有关更多详细信息，请参阅 Kubernetes集群自动扩缩器常见问题解答。

解决方案

如果要进行Cluster Autoscaler工作GKE，则必须使用适当的信息创建中断，如何创建它可以在如何设置 PDB 以使 CA 移动 kube-system pod？

kubectl create poddisruptionbudget <pdb name> --namespace=kube-system --selector app=<app name> --max-unavailable 1

您必须在哪里指定正确的selector和--max-unavailable/或--min-available取决于您的需要。有关更多详细信息，请阅读指定 PodDisruptionBudget文档。

测试

$ kubectl get deploy,nodes
NAME                               READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/nginx-deployment   16/16   16           16          66m

NAME                                            STATUS   ROLES    AGE     VERSION
node/gke-cluster-1-default-pool-6d42fa0a-1ckn   Ready    <none>   11m     v1.16.15-gke.6000
node/gke-cluster-1-default-pool-6d42fa0a-2j4j   Ready    <none>   11m     v1.16.15-gke.6000
node/gke-cluster-1-default-pool-6d42fa0a-388n   Ready    <none>   3h33m   v1.16.15-gke.6000
node/gke-cluster-1-default-pool-6d42fa0a-5x35   Ready    <none>   3h33m   v1.16.15-gke.6000
node/gke-cluster-1-default-pool-6d42fa0a-pdfk   Ready    <none>   3h33m   v1.16.15-gke.6000
node/gke-cluster-1-default-pool-6d42fa0a-wqtm   Ready    <none>   11m     v1.16.15-gke.6000
$ kubectl get pdb -A
NAMESPACE     NAME      MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
kube-system   kubedns   1               N/A               1                     43m

缩减部署

$ kubectl scale deploy nginx-deployment --replicas=2
deployment.apps/nginx-deployment scaled

在事件查看器中一段时间​​（约 10-15 分钟）后，您将找到该Decision事件，并在其中找到节点已删除的信息。

...
scaleDown: {
nodesToBeRemoved: [
0: {
node: {
mig: {
zone: "europe-west2-c"
nodepool: "default-pool"
name: "gke-cluster-1-default-pool-6d42fa0a-grp"
}
name: "gke-cluster-1-default-pool-6d42fa0a-wqtm"

节点数减少：

$ kubectl get nodes
NAME                                       STATUS   ROLES    AGE     VERSION
gke-cluster-1-default-pool-6d42fa0a-2j4j   Ready    <none>   30m     v1.16.15-gke.6000
gke-cluster-1-default-pool-6d42fa0a-388n   Ready    <none>   3h51m   v1.16.15-gke.6000
gke-cluster-1-default-pool-6d42fa0a-5x35   Ready    <none>   3h51m   v1.16.15-gke.6000
gke-cluster-1-default-pool-6d42fa0a-pdfk   Ready    <none>   3h51m   v1.16.15-gke.6000

另一个可以确认它正在缩小的地方是kubectl get events --sort-by='.metadata.creationTimestamp'

输出：

5m16s       Normal    NodeNotReady                                                                                             node/gke-cluster-1-default-pool-6d42fa0a-wqtm   Node gke-cluster-1-default-pool-6d42fa0a-wqtm status is now: NodeNotReady
4m56s       Normal    NodeNotReady                                                                                             node/gke-cluster-1-default-pool-6d42fa0a-1ckn   Node gke-cluster-1-default-pool-6d42fa0a-1ckn status is now: NodeNotReady
4m          Normal    Deleting node gke-cluster-1-default-pool-6d42fa0a-wqtm because it does not exist in the cloud provider   node/gke-cluster-1-default-pool-6d42fa0a-wqtm   Node gke-cluster-1-default-pool-6d42fa0a-wqtm event: DeletingNode
3m55s       Normal    RemovingNode                                                                                             node/gke-cluster-1-default-pool-6d42fa0a-wqtm   Node gke-cluster-1-default-pool-6d42fa0a-wqtm event: Removing Node gke-cluster-1-default-pool-6d42fa0a-wqtm from Controller
3m50s       Normal    Deleting node gke-cluster-1-default-pool-6d42fa0a-1ckn because it does not exist in the cloud provider   node/gke-cluster-1-default-pool-6d42fa0a-1ckn   Node gke-cluster-1-default-pool-6d42fa0a-1ckn event: DeletingNode
3m45s       Normal    RemovingNode                                                                                             node/gke-cluster-1-default-pool-6d42fa0a-1ckn   Node gke-cluster-1-default-pool-6d42fa0a-1ckn event: Removing Node gke-cluster-1-default-pool-6d42fa0a-1ckn from Controller

结论

默认情况下，kube-systempod 会阻止 CA 删除运行它们的节点。用户可以手动添加可以在其他地方安全地重新安排PDBs 的kube-systempod。可以使用以下方法实现：

kubectl create poddisruptionbudget <pdb name> --namespace=kube-system --selector app=<app name> --max-unavailable 1

可以在Cluster Autoscaler - 常见问题CA中找到无法自动缩放的可能原因列表。

要验证哪些 pod 仍然可以阻止CA缩减，您可以使用Autoscaler Events。

于 2021-01-20T14:19:44.777 回答