伸縮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應用構建與交付、多數據中心資源管理等技術，爲用戶提供雲原生應用全生命週期解決方案，構建應用與基礎設施、應用與應用、基礎設施與基礎設施之間互聯互通的生態體系，知足支撐業務高速發展所需的敏捷開發、高效運維和精益管理需求。