伸縮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
- 這個選項需要docker storgae切換到overlay2
- 并且把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
