Question

我在GKE k8s 1.9.4上进行了多区域测试设置。每个群集都有：

配置了kubemci
具有不同节点标签的3个节点池：
- default-pool system（1vCPU / 2GB RAM）
- frontend-pool frontend（2vCPU / 2GB RAM）
- backend-pool backend（1vCPU / 600Mb RAM）
按自定义指标进行缩放的HPA

prometheus-operator，prometheus-server，custom-metrics-api-server和kube-state-metrics之类的内容附加到标有system标签的节点。

前端和后端pod分别附加到分别带有frontend和backend标签的节点（单个pod到单个节点），请参阅podantiaffinity。

自动缩放后缩放backend或frontend个广告连播，其节点仍然保留，因为似乎有来自kube-system命名空间的广告连播，即heapster。这会导致这样一种情况：frontend / backend标签的节点在降尺度后仍保持活动状态，即使没有后端或前端窗口也没有。

问题是：我怎样才能避免在节点上创建kube-system pod，为我的应用程序提供服务（如果这真的很健全）？

猜猜，我应该对backend和frontend节点使用污点和容忍度，但它如何与HPA和群集内节点自动缩放器结合使用？

Answer 1

好像taints and tolerations这样做了。

创建一个带有默认节点池的集群（用于监控和kube-system）：

gcloud container --project "my-project-id" clusters create "app-europe" \
  --zone "europe-west1-b" --username="admin" --cluster-version "1.9.4-gke.1" --machine-type "custom-2-4096" \
  --image-type "COS" --disk-size "10" --num-nodes "1" --network "default" --enable-cloud-logging --enable-cloud-monitoring \
  --maintenance-window "01:00" --node-labels=region=europe-west1,role=system

为您的应用程序创建节点池：

gcloud container --project "my-project-id" node-pools create "frontend" \
      --cluster "app-europe" --zone "europe-west1-b" --machine-type "custom-2-2048" --image-type "COS" \
      --disk-size "10" --node-labels=region=europe-west1,role=frontend \
      --node-taints app=frontend:NoSchedule \
      --enable-autoscaling --num-nodes "1" --min-nodes="1" --max-nodes="3"

然后将nodeAffinity和tolerations部分添加到部署清单中的pods模板spec：

  tolerations:
  - key: "app"
    operator: "Equal"
    value: "frontend"
    effect: "NoSchedule"
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: beta.kubernetes.io/instance-type
            operator: In
            values:
            - custom-2-2048
        - matchExpressions:
          - key: role
            operator: In
            values:
            - frontend

Answer 2

我建议首先检查的是，您在PodSpec中拥有的请求资源量足以承载负载，并且系统节点上有足够的资源来安排所有系统容器。

您可以尝试使用更简单的nodeSelector或更灵活的Node Affinity来阻止调度系统容器前端或后端自动缩放的节点。

您可以在文档“Assigning Pods to Nodes”

中找到很好的解释和示例

Taints and Toleration功能类似于Node Affinity，但从节点角度来看更多。它们允许节点击退一组pod。如果选择这种方式，请检查文档“Taints and Tolerations”。

为自动扩展创建节点池时，可以添加labels和taints，这样当Cluster Autoscaler（CA）对池进行升级时，它们将应用于节点。

除限制system个广告单元在frontend / backend个节点上进行排定外，最好configure PodDisruptionBudget和自动缩放器{{1对于可能阻止CA在缩减期间删除节点的pod的选项。

根据Cluster Autoscaler FAQ，有几种类型的pod可能会阻止CA缩小群集规模：

具有限制性PodDisruptionBudget（PDB）的Pod。
Kube系统吊舱：
- 默认情况下不在节点上运行，
- 没有PDB或他们的PDB限制太多（因为CA 0.6）。
没有控制器对象支持的Pod（因此不是由部署，副本集，作业，有状态集等创建的）。
具有本地存储空间的Pod。 *
由于各种限制（缺少资源，不匹配的节点选择器或亲和力，匹配反亲和力等）而无法移动到其他地方的Pod

*除非pod具有以下注释（在CA 1.0.3或更高版本中受支持）：

safe-to-evict

在版本0.6之前，Cluster Autoscaler没有触及运行重要的kube系统pod的节点，如DNS，Heapster，Dashboard等。
如果这些pod落在不同的节点上，CA无法缩小群集，用户可能最终得到一个完全空的3节点群集。
在0.6中，添加了一个选项，告诉CA可以移动一些系统pod。如果用户为kube-system pod配置PodDisruptionBudget，则使用PDB设置覆盖不触及运行此pod的节点的默认策略。
因此，要启用kube-system pods迁移，应将minAvailable设置为0（如果有N + 1 pod副本，则设置为＆lt; = N.）
另请参阅I have a couple of nodes with low utilization, but they are not scaled down. Why?

Cluster Autoscaler FAQ可以帮助您为群集选择正确的版本。

要更好地了解Cluster Autoscaler的内幕，请查看official documentation

GKE kubernetes kube-system resources nodeAffinity

2 个答案: