分布式存储环境 Kubernetes节点扩容规模至2500的历程(2)

Kube masters

我们在同一台机器上对kube-apiserver、kube- controllermanager和kube-scheduler进程进行定位。对于高可用性，我们总是至少有2个master，并将apiserver-count标志设置为我们正在运行的apiservers的数量（否则，Prometheus监视会在实例间混淆）。

我们主要使用Kubernetes作为批量调度系统，并依靠我们的自动调节器动态扩容和缩容我们的集群——这使我们可以显著降低空闲节点的成本，同时在快速迭代时仍然保证低延迟。 默认的kube-scheduler策略是在负载均匀分布在节点之间。但是我们希望相反，这样可以终止未使用的节点，也可以快速调度大的Pods。 所以我们切换到以下策略：

{

"kind": "Policy",

"apiVersion": "v1",

"predicates": [

{ "name": "GeneralPredicates"},

{ "name": "MatchInterPodAffinity"},

{ "name": "NoDiskConflict"},

{ "name": "NoVolumeZoneConflict"},

{ "name": "PodToleratesNodeTaints"}

],

"priorities": [

{ "name": "MostRequestedPriority", "weight": 1},

{ "name": "InterPodAffinityPriority", "weight": 2}

]

}

我们的服务发现功能广泛使用KubeDNS，但在推出新的调度策略后不久就开始出现可靠性问题。 我们发现，失败只发生在KubeDNS的某些Pods上。 在新的调度策略下一些机器最终运行了10多个KubeDNS副本，创建了热点，而且我们已经超过了每个Azure虚拟机允许的查询??200QPS限制。

我们通过为KubeDNS Pod添加一个anti-affinity规则[3]来解决这个问题：

affinity:

podAntiAffinity:

requiredDuringSchedulingIgnoredDuringExecution:

- weight: 100

labelSelector:

matchExpressions:

- key: k8s-app

operator: In

values:

- kube-dns

topologyKey: kubernetes.io/hostname

Docker image pulls

我们的Dota项目是在Kubernetes上起步的，随着规模的扩大，我们注意到新增的Kubernetes节点经常有很长一段时间处在Pending。 游戏镜像大概是17GB，通常需要30分钟才能拉上一个新的集群节点，所以我们理解了Dota容器为什么会暂停一段时间——但是其他容器也是如此。 进一步挖掘，我们发现kubelet有一个--serialize-image-pullsflag默认为true，这意味着Dota镜像阻塞了所有其他镜像。 更改为false需要将Docker切换到overlay2而不是AUFS。 为了进一步提高获取镜像的速度，我们也将Docker root 移到了实例连接的SSD上，就像我们为etcd机器所做的那样。

即使在优化获取镜像速度之后，我们也看到Pod无法启动一个诡异的错误信息：rpc error: code = 2 desc = net/http: request canceled。 kubelet和Docker日志消息显示“由于缺乏进度，镜像的获取已经取消”。 我们追踪了问题的根源是需要花费太多时间来获取/加压提取的大镜像，或者当我们很多积压的镜像要获取的时候。 为了解决这个问题，我们将kubelet的-image-pull-progress-deadline标志设置为30分钟，并将Docker守护进程的最大并发下载选项设置为10。（第二个选项没有加速获取大镜像，但允许镜像队列并行获取。）

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-85241-2.html