伸縮Kubernetes到2500個節點中遇到的問題和解決方法_Kubernetes中文社群
本片文章即分享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之間的網路流量
原因:
- 發現
- 調低兩個服務的抓取頻率,網路效能從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應用構建與交付、多資料中心資源管理等技術,為使用者提供雲原生應用全生命週期解決方案,構建應用與基礎設施、應用與應用、基礎設施與基礎設施之間互聯互通的生態體系,滿足支撐業務高速發展所需的敏捷開發、高效運維和精益管理需求。