伸缩Kubernetes到2500个节点中遇到的问题和解决方法

Kubernetes自从1.6起便号称能够承载5000个以上的节点，可是从数十到5000的路上，不免会遇到问题。

本片文章即分享Open API在kubernetes 5000之路上的经验，包括遇到的问题、尝试解决问题以及找到真正的问题。

遇到的问题以及如何解决

问题一：1 ~ 500个节点以后

问题：

kubectl 有时会出现 timeout（p.s. kubectl -v=6 能够显示全部API细节指令）

尝试解决：

• 一开始觉得是kube-apiserver服务器负载的问题，尝试增长proxy作replica协助进行负载均衡
• 可是超过10个备份master的时候，发现问题不是由于kube-apiserver没法承受负载，GKE经过一台32-core VM就能够承载500个节点

缘由：

• 排除以上缘由，开始排查master上剩下的几个服务(etcd、kube-proxy)
• 开始尝试调整etcd
• 经过使用datadog查看etcd吞吐量，发现有异常延迟(latency spiking ~100 ms)
• 经过Fio工具作性能评估，发现只用到10%的IOPS(Input/Output Per Second)，因为写入延迟(write latency 2ms)下降了性能
• 尝试把SSD从网络硬盘变为每台机器有个local temp drive（SSD）
• 结果从~100ms —> 200us

问题二：~1000个节点的时候

问题：

• 发现kube-apiserver每秒从etcd上读取500mb

尝试解决：

• 经过Prometheus查看container之间的网络流量

缘由：

• 发现Fluentd和Datadog抓取每一个节点上资料过于频繁
• 调低两个服务的抓取频率，网络性能从500mb/s下降到几乎没有
• etcd小技巧：经过--etcd-servers-overrides能够将Kubernetes Event的资料写入做为切割，分不一样机器处理，以下所示

--etcd-servers-overrides=/events#https://0.example.com:2381;https://1.example.com:2381;https://2.example.com:2381

问题三：1000 ～ 2000个节点

问题：

• 没法再写入数据，报错cascading failure
• kubernetes-ec2-autoscaler在所有的etcd都停掉之后才回传问题，而且关闭全部的etcd

尝试解决：

• 猜想是etcd硬盘满了，可是检查SSD依旧有不少空间
• 检查是否有预设的空间限制，发现有2GB大小限制

解決方法:

• 在etcd启动参数中加入--quota-backend-bytes
• 修改kubernetes-ec2-autoscaler逻辑——若是超过50%出现问题，关闭集群

各类服务的优化

Kube masters 的高可用

通常来讲，咱们的架构是一个kube-master（主要的 Kubernetes 服务提供组件，上面有kube-apiserver、kube-scheduler 和kube-control-manager）加上多個slave。可是要达到高可用，要参考一下方式实现：

• kube-apiserver要设置多个服务，而且经过参数--apiserver-count重启而且设定
• kubernetes-ec2-autoscaler能够帮助咱们自动关闭idle的资源，可是这跟Kubernetes scheduler的原则相悖，不过经过这些设定，能够帮助咱们尽可能集中资源。

{
"kind" : "Policy",
"apiVersion" : "v1",
"predicates" : [
  {"name" : "GeneralPredicates"},
  {"name" : "MatchInterPodAffinity"},
  {"name" : "NoDiskConflict"},
  {"name" : "NoVolumeZoneConflict"},
  {"name" : "PodToleratesNodeTaints"}
  ],
"priorities" : [
  {"name" : "MostRequestedPriority", "weight" : 1},
  {"name" : "InterPodAffinityPriority", "weight" : 2}
  ]
}

以上为调整kubernetes scheduler范例，经过调高InterPodAffinityPriority的权重，达到咱们的目的。更多示范参考范例．

须要注意的是，目前Kubernetes Scheduler Policy并不支持动态切换，须要重启kube-apiserver(issue: 41600)

调整scheduler policy形成的影响

OpenAI使用了KubeDNS ，但不久后发现——

问题：

• 常常出现DNS查询不到的状况（随机发生）
• 超过 ~200QPS domain lookup

尝试解决：

• 尝试查看为什么有这种状态，发现有些node上跑了超过10个KuberDNS

解决方法：

• 因为scheduler policy形成了许多POD的集中
• KubeDNS很轻量，容易被分配到同一节点上，形成domain lookup的集中
• 须要修改POD affinity（相关介绍），尽可能让KubeDNS分配到不一样的node之上

affinity:
 podAntiAffinity:
   requiredDuringSchedulingIgnoredDuringExecution:
   - weight: 100
     labelSelector:
       matchExpressions:
       - key: k8s-app
         operator: In
         values:
         - kube-dns
     topologyKey: kubernetes.io/hostname

新建节点时Docker image pulls缓慢的问题

问题：

• 每次新节点创建起来，docker image pull都要花30分钟

尝试解决：

• 有一个很大的container image Dota，差很少17GB，影响了整个节点的image pulling
• 开始检查kubelet是否有其余image pull选项

解决方法：

• 在kubelet增长选项--serialize-image-pulls=false来启动image pulling，让其余服务能够更早地pull（参考：kubelet启动选项）
• 这个选项须要docker storgae切换到overlay2（能够参考docker教学文章）
• 而且把docker image存放到SSD，可让image pull更快一些

补充：source trace

// serializeImagePulls when enabled, tells the Kubelet to pull images one
// at a time. We recommend *not* changing the default value on nodes that
// run docker daemon with version  < 1.9 or an Aufs storage backend.
// Issue #10959 has more details.
SerializeImagePulls *bool `json:"serializeImagePulls"`

提升docker image pull的速度

此外，还能够经过如下方式来提升pull的速度

kubelet参数--image-pull-progress-deadline要提升到30mins docker daemon参数max-concurrent-download调整到10才能多线程下载

网络性能提高

Flannel性能限制

OpenAI节点间的网络流量，能够达到10-15GBit/s，可是因为Flannel因此致使流量会降到 ～2GBit/s

解决方式是拿掉Flannel，使用实际的网络

• hostNetwork: true
• dnsPolicy: ClusterFirstWithHostNet

这里还有一些注意事项须要详细阅读

---

想要简单易用、生产就绪的Kubernetes？试试好雨Rainbond——以应用的方式包装Kubernetes，理解和使用更简单，各类管理流程开箱即用！

好雨Rainbond（云帮）是一款以应用为中心的开源PaaS，深度整合基于Kubernetes的容器管理、Service Mesh微服务架构最佳实践、多类型CI/CD应用构建与交付、多数据中心资源管理等技术，为用户提供云原生应用全生命周期解决方案，构建应用与基础设施、应用与应用、基础设施与基础设施之间互联互通的生态体系，知足支撑业务高速发展所需的敏捷开发、高效运维和精益管理需求。