Kubernetes自动横向伸缩集群节点以及介绍PDB资源

Kubernetes自动横向伸缩集群节点以及介绍PDB资源

在kubernetes中，有HPA在需要的时候创建更多的pod实例。但万一所有的节点都满了，放不下更多pod了，怎么办？显然这个问题并不局限于Autoscaler创建新pod实例的场景。即便是手动创建pod,也可能碰到因为资源被已有pod使用殆尽，以至于没有节点能接收新pod的清况。

Kubernetes支持在需要时立即自动从云服务提供者请求更多节点。该特性由Cluster Autoscaler执行。

1.Cluster Autoscaler介绍

Cluster Autoscales负责在由于节点资源不足，而无法调度某pod到己有节点时，自动部署新节点。它也会在节点长时间使用率低下的情况下下线节点。

从云端基础架构请求新节点

如果在一个pod被创建之后，Scheduler无法将其调度到任何一个己有节点，一个新节点就会被创建。ClusterAutoscaler会注意此类pod，并请求云服务提供者启动一个新节点。但在这么做之前，它会检查新节点有没有可能容纳这个（些）pod,毕竟如果新节点本来就不可能容纳它们，就没必要启动这么一个节点了。

云服务提供者通常把相同规格（或者有相同特性）的节点聚合成组。因此ClusterAutoscaler不能单纯地说“给我多一个节点”，它还需要指明节点类型。

ClusterAutoscaler通过检查可用的节点分组来确定是否有至少一种节点类型能容纳未被调度的pod。如果只存在唯一一此种节点分组，ClusterAutoscaler就可以增加节点分组的大小，让云服务提供商给分组中增加一个节点。但如果存在多个满足条件的节点分组，ClusterAutoscaler就必须挑一个最合适的。这里“最合适”的精确含义显然必须是可配置的。在最坏的情况下，它会随机挑选一个。图15.5简单描述了ClusterAutoscaler面对一个不可调度pod时是如何反应的。

新节点启动后，其上运行的Kubelet会联系API服务器，创建一个Node资源以注册该节点。从这一刻起，该节点即成为Kubernetes集群的一部分，可以调度pod于其上了。

简单吧？那么缩容呢？

归还节点

当节点利用率不足时，Cluster Autoscaler也需要能够减少节点的数目。Cluster Autoscaler通过监控所有节点上请求的CPU与内存来实现这一点。如果某个节点上所有pod请求的CPU、内存都不到50%，该节点即被认定为不再需要。

这并不是决定是否要归还某一节点的唯一因素。Cluster Autoscaler也会检查是否有系统pod(仅仅）运行在该节点上（这并不包括每个节点上都运行的服务，比如DaemonSet所部署的服务）。如果节点上有系统pod在运行，该节点就不会被归还。对非托管pod,以及有本地存储的pod也是如此，否则就会造成这些pod提供的服务中断。换句话说，只有当Cluster Autoscaler知道节点上运行的pod能够重新调度到其他节点，该节点才会被归还。

当一个节点被选中下线，它首先会被标记为不可调度，随后运行其上的pod将被疏散至其他节点。因为所有这些pod都属于ReplicaSet或者其他控制器，它们的替代pod会被创建并调度到其他剩下的节点（这就是为何正被下线的节点要先标记为不可调度的原因）。

手动标记节点为不可调度、排空节点

节点也可以手动被标记为不可调度并排空。不涉及细节，这些工作可用以下kubectl命令完成:

kubectl cordon 标记节点为不可调度（但对其上的pod不做任何事）。kubectl drain 标记节点为不可调度，随后疏散其上所有pod。

两种情形下，在你用kubectl uncordon 解除节点的不可调度状态之前，不会有新pod被调度到该节点。

2.启用Cluster Autoscaler

集群自动伸缩在以下云服务提供商可用：

Google Kubernetes Engine(GKE)Google Compute Engine(GCE)Amazon Web Services(AWS)Microsoft Azure

启动Cluster Autoscaler的方式取决于Kubernetes集群运行在哪。如果你的kubia集群运行在GKE上，可以这样启用Cluster Autoscaler :

$ gcloud container clusters update kubia --enable-autoscaling \--min-nodes=3 --max-nodes=5

如果集群运行在GCE上，需要在运行kubi-ub.sh前设置以下环境变量：

KUBE ENABLE CLUSTER AUTOSCALER=trueKUBE AUTOSCALER MIN NODES=3KUBE AUTOSCALER MAX NODES=5

可以参考kubectl create pdb kubia-pdb --selector=app=kubia --min-available=3poddisruptionbudget "kubia-pdb"

现在获取这个PDB的YAML文件，如下代码:

#代码15.10 一个podDisruptioonBudget定义$ kubectl get pdb kubia-pdb -o yamlapiVersion: policy/v1beta1kind: PodDisruptionBudgetmetadata: name: kubia-pdbspec: minAvailable:3 #应该有多少个pod始终可用 selector: matchLabels: #用来确定该预算应该覆盖哪些pod的标签选择器 app: kubia status: ....

也可以用一个百分比而非绝对数值来写minAvailable字段。比方说，可以指定60%带app=kubia标签的pod应当时刻保持运行。

注意:从Kubernetes1.7开始，podDismptionBudget资源也支持maxUnavailable。如果当很多pod不可用而想要阻止pod被剔除时，就可以用maxUnavailable字段而不是minAvailable。

关于这个资源，没有更多要讲的了。只要它存在，Cluster Autoscaler与kubectl drain命令都会遵守它；如果疏散一个带有app=kubia标签的pod会导致它们的总数小于3,那这个操作就永远不会被执行。

比方说，如果总共有4个pod,minAvailable像例子中一样被设为3，pod疏散过程就会挨个进行，待ReplicaSet控制器把被疏散的pod换成新的，才继续下一个。

作者：​​小家电维修​​

​

转世燕还故榻,为你衔来二月的花。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。