摘要：自從起便號(hào)稱可以承載個(gè)以上的節(jié)點(diǎn)，但是從數(shù)十到的路上，難免會(huì)遇到問(wèn)題。本片文章即分享在之路上的經(jīng)驗(yàn)，包括遇到的問(wèn)題嘗試解決問(wèn)題以及找到真正的問(wèn)題。

Kubernetes自從1.6起便號(hào)稱可以承載5000個(gè)以上的節(jié)點(diǎn)，但是從數(shù)十到5000的路上，難免會(huì)遇到問(wèn)題。

本片文章即分享Open API在kubernetes 5000之路上的經(jīng)驗(yàn)，包括遇到的問(wèn)題、嘗試解決問(wèn)題以及找到真正的問(wèn)題。

問(wèn)題：

kubectl 有時(shí)會(huì)出現(xiàn) timeout（p.s. kubectl -v=6 可以顯示所有API細(xì)節(jié)指令）

嘗試解決：

一開(kāi)始以為是kube-apiserver服務(wù)器負(fù)載的問(wèn)題，嘗試增加proxy做replica協(xié)助進(jìn)行負(fù)載均衡

但是超過(guò)10個(gè)備份master的時(shí)候，發(fā)現(xiàn)問(wèn)題不是因?yàn)閗ube-apiserver無(wú)法承受負(fù)載，GKE通過(guò)一臺(tái)32-core VM就可以承載500個(gè)節(jié)點(diǎn)

原因：

排除以上原因，開(kāi)始排查master上剩下的幾個(gè)服務(wù)(etcd、kube-proxy)

開(kāi)始嘗試調(diào)整etcd

通過(guò)使用datadog查看etcd吞吐量，發(fā)現(xiàn)有異常延遲(latency spiking ~100 ms)

通過(guò)Fio工具做性能評(píng)估，發(fā)現(xiàn)只用到10%的IOPS(Input/Output Per Second)，由于寫(xiě)入延遲(write latency 2ms)降低了性能

嘗試把SSD從網(wǎng)絡(luò)硬盤(pán)變?yōu)槊颗_(tái)機(jī)器有個(gè)local temp drive（SSD）

結(jié)果從~100ms —> 200us

問(wèn)題：

發(fā)現(xiàn)kube-apiserver每秒從etcd上讀取500mb

嘗試解決：

通過(guò)Prometheus查看container之間的網(wǎng)絡(luò)流量

原因：

發(fā)現(xiàn)Fluentd和Datadog抓取每個(gè)節(jié)點(diǎn)上資料過(guò)于頻繁

調(diào)低兩個(gè)服務(wù)的抓取頻率，網(wǎng)絡(luò)性能從500mb/s降低到幾乎沒(méi)有

etcd小技巧：通過(guò)--etcd-servers-overrides可以將Kubernetes Event的資料寫(xiě)入作為切割，分不同機(jī)器處理，如下所示

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

問(wèn)題：

無(wú)法再寫(xiě)入數(shù)據(jù)，報(bào)錯(cuò)cascading failure

kubernetes-ec2-autoscaler在全部的etcd都停掉以后才回傳問(wèn)題，并且關(guān)閉所有的etcd

嘗試解決：

猜測(cè)是etcd硬盤(pán)滿了，但是檢查SSD依舊有很多空間

檢查是否有預(yù)設(shè)的空間限制，發(fā)現(xiàn)有2GB大小限制

解決方法:

在etcd啟動(dòng)參數(shù)中加入--quota-backend-bytes

修改kubernetes-ec2-autoscaler邏輯——如果超過(guò)50%出現(xiàn)問(wèn)題，關(guān)閉集群

一般來(lái)說(shuō)，我們的架構(gòu)是一個(gè)kube-master（主要的 Kubernetes 服務(wù)提供組件，上面有kube-apiserver、kube-scheduler 和kube-control-manager）加上多個(gè)slave。但是要達(dá)到高可用，要參考一下方式實(shí)現(xiàn)：

kube-apiserver要設(shè)置多個(gè)服務(wù)，并且通過(guò)參數(shù)--apiserver-count重啟并且設(shè)定

kubernetes-ec2-autoscaler可以幫助我們自動(dòng)關(guān)閉idle的資源，但是這跟Kubernetes scheduler的原則相悖，不過(guò)通過(guò)這些設(shè)定，可以幫助我們盡量集中資源。

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

以上為調(diào)整kubernetes scheduler范例，通過(guò)調(diào)高InterPodAffinityPriority的權(quán)重，達(dá)到我們的目的。更多示范參考范例．

需要注意的是，目前Kubernetes Scheduler Policy并不支持動(dòng)態(tài)切換，需要重啟kube-apiserver(issue: 41600)

OpenAI使用了KubeDNS ，但不久后發(fā)現(xiàn)——

問(wèn)題：

經(jīng)常出現(xiàn)DNS查詢不到的情況（隨機(jī)發(fā)生）

超過(guò) ~200QPS domain lookup

嘗試解決：

嘗試查看為何有這種狀態(tài)，發(fā)現(xiàn)有些node上跑了超過(guò)10個(gè)KuberDNS

解決方法：

由于scheduler policy造成了許多POD的集中

KubeDNS很輕量，容易被分配到同一節(jié)點(diǎn)上，造成domain lookup的集中

需要修改POD affinity（相關(guān)介紹），盡量讓KubeDNS分配到不同的node之上

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

問(wèn)題：

每次新節(jié)點(diǎn)建立起來(lái)，docker image pull都要花30分鐘

嘗試解決：

有一個(gè)很大的container image Dota，差不多17GB，影響了整個(gè)節(jié)點(diǎn)的image pulling

開(kāi)始檢查kubelet是否有其他image pull選項(xiàng)

解決方法：

在kubelet增加選項(xiàng)--serialize-image-pulls=false來(lái)啟動(dòng)image pulling，讓其他服務(wù)可以更早地pull（參考：kubelet啟動(dòng)選項(xiàng)）

這個(gè)選項(xiàng)需要docker storgae切換到overlay2（可以參考docker教學(xué)文章）

并且把docker image存放到SSD，可以讓image pull更快一些

補(bǔ)充：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"`

此外，還可以通過(guò)以下方式來(lái)提高pull的速度

kubelet參數(shù)--image-pull-progress-deadline要提高到30mins
docker daemon參數(shù)max-concurrent-download調(diào)整到10才能多線程下載

Flannel性能限制

OpenAI節(jié)點(diǎn)間的網(wǎng)絡(luò)流量，可以達(dá)到10-15GBit/s，但是由于Flannel所以導(dǎo)致流量會(huì)降到 ～2GBit/s

解決方式是拿掉Flannel，使用實(shí)際的網(wǎng)絡(luò)

hostNetwork: true

dnsPolicy: ClusterFirstWithHostNet

這里還有一些注意事項(xiàng)需要詳細(xì)閱讀

想要簡(jiǎn)單易用、生產(chǎn)就緒的Kubernetes？試試好雨Rainbond——以應(yīng)用的方式包裝Kubernetes，理解和使用更簡(jiǎn)單，各種管理流程開(kāi)箱即用！

好雨Rainbond（云幫）是一款以應(yīng)用為中心的開(kāi)源PaaS，深度整合基于Kubernetes的容器管理、Service Mesh微服務(wù)架構(gòu)最佳實(shí)踐、多類型CI/CD應(yīng)用構(gòu)建與交付、多數(shù)據(jù)中心資源管理等技術(shù)，為用戶提供云原生應(yīng)用全生命周期解決方案，構(gòu)建應(yīng)用與基礎(chǔ)設(shè)施、應(yīng)用與應(yīng)用、基礎(chǔ)設(shè)施與基礎(chǔ)設(shè)施之間互聯(lián)互通的生態(tài)體系，滿足支撐業(yè)務(wù)高速發(fā)展所需的敏捷開(kāi)發(fā)、高效運(yùn)維和精益管理需求。