k8s1.6伸縮性升級，支援處理5000 Node 和 15 萬個 Pod_Kubernetes中文社群
本文中我們會討論到
- 效能測試的指標和結果
- 提高效能的改進
- 未來在伸縮性方面的發展計劃
XX 節點的叢集意味著什麼？
現在 Kubernetes 1.6 已經發布，那麼當我們說到支援多少個節點的叢集的時候，我們到底在說什麼？前文說過，我們有兩個效能相關的服務水平目標（SLO）：
- API 響應性：99% 的 API 呼叫應該在一秒之內返回。
- Pod 啟動時間：99% 的 Pod 及其容器（已拉取映象）在五秒之內完成啟動。
跟以前一樣，叢集規模是可以超過 5000 節點的，但是會引起效能下降，可能無法滿足 SLO 要求。
我們知道 SLO 的限制。還有很多我們沒有覆蓋到的系統因素。例如，新 Pod 啟動之後，需要多久才能通過服務 IP 進行訪問？這個資料我們就沒有測量。如果你在使用大規模 Kubernetes 叢集過程中，還有沒有被我們的 SLO 覆蓋的效能需要，請聯絡
接下來， Kubernetes 的伸縮性相關的最高優先順序任務就是清晰一下對於支援 XX 節點規模的叢集的定義：
- 強化現有的 SLO。
- 加入更多的 SLO（覆蓋 Kubernetes 相關的更多方面，包括網路）
Kuernetes 1.6 的效能指標
那麼在 Kubernetes 1.6 中，大規模叢集到底怎樣呢？下圖顯示了 2000 和 5000 節點的叢集規模下的端到端的 Pod 啟動時間。另外我們還加入了之前效能測試中釋出過的 Kubernetes 1.3 下 2000 節點規模叢集的相應指標來作對比。如圖所見，兩種規模的 Kubernetes 1.6 叢集的 Pod 啟動延遲都優於 2000 節點規模的 Kubernetes 1.3 叢集。
接下來的這種圖展示了 5000 節點規模的 Kubernetes 1.6 叢集的 API 響應時間。所有的百分位數都少於 500 毫秒，而且 90 百分位數下低於 100 毫秒。
如何達成現有的效能目標？
過去的九個月中（從上次的伸縮性部落格開始），Kubernetes 有很多效能和伸縮性的改進。本文中會談談兩個最大的變化，並會列出一些其他的改動。
etcd v3
在 Kubernetes 1.6 中，預設的儲存後端從 etcd v2 升級到了 v3。這一工作從 1.3 的釋出週期就開始了。為什麼花了這麼長的時間呢？
- 第一個穩定的支援 v3 API 的 etcd 釋出於 2016 年 6 月 30 日。
- 新 API 是和 Kubernetes 團隊合作設計的，以滿足 Kubenretes 的功能和伸縮性需求。
- 幾乎在 etcd v3 釋出的同時，就完成了 Kubernetes 的整合——事實上，CoreOS 就是使用 Kubernetes 作為 etcd v3 API 的概念驗證來使用的。
我們有很多做出這一變化的理由，下面列舉一些最重要的：
- 從 v2 到 v3 的不向後相容的升級，是一個巨大的變化，這是一個艱難的決定。我們在九月份發現，如果我們繼續使用 etcd v2 的話，是無法負載 5000 節點的叢集規模的。etcd v2 中的 watch 實現是一個主要障礙。在 5000 節點規模的叢集中，我們每秒需要向同一個 watcher 傳送至少 500 個 watch 事件，這在 v2 中是不可能的。
kubernetes/32361: https://github.com/kubernetes/kubernetes/issues/32361 裡面包含了一些這方面的討論。
- 在有了升級到 etcd v3 的動機之後，我們開始進行測試，過程中發現了一些問題。除了 Kubernetes 中出了一些小 Bug 之外，我們還向 etcd v3 的 watch 實現提出了更高的效能要求（etcd v2 中我們遇到的主要效能瓶頸）。這導致了 etcd 3.0.10 的補丁釋出。
- 做出這一變化之後，我們確信新的 Kubernetes 叢集能夠使用 etcd v3。但是還有遷移現有叢集的問題。為了自動實現遷移過程，對 CoreOS 的 etcd 升級工具進行了詳盡的測試，並且做出了回滾方案。
最終我們確信這一方案是可靠的。
資料格式切換為 protobuf
在 Kubernetes 1.3 中，我們在 Kubernetes 中啟用了 protobufs 作為元件通訊的資料格式（作為 JSON 的補充）。這給我們帶來巨大的效能提升。
雖說技術上我們已經做好了準備，但我們還在 etcd 儲存中使用了 JSON，這一變更的延遲，直接原因就是 etcd v3 的遷移。因為在 etcd v2 中我們無法使用二進位制格式儲存（只能用 base 64 編碼來勉強實現），而在 etcd v3 中就可以了。所以遷移到 etcd v3 能夠避免一些不必要的資料轉換，最終我們決定等待 etcd v3 的遷移完成後，才切換到 protobufs。
其他優化
我們在 Kubernetes 的最近三次釋出中做出了幾十項優化，包括：
- 排程器優化（ 5-10 倍的排程吞吐）
- 優化控制器設計，降低了 controller-manager 的資源消耗
參見：https://github.com/kubernetes/community/blob/master/contributors/devel/controllers.md
- 對 API Server 的部分操作進行優化（轉換、深度複製、patch）
- 降低 API Server 的記憶體佔用（顯著的降低了 API 呼叫的延遲時間）
需要強調的是，近期的幾個釋出中的優化工作，以及這個專案的整個歷史，都是 Kubernetes 社群很多公司和個人通力協作的結果。
下一步
經常有人問，我們到底要把 Kubernetes 的伸縮性提高到何種程度。目前我們還沒有在未來版本中把叢集規模提高到 5000 節點以上。如果超過 5000 節點，我們建議採用 federation 來結合多個 Kubernetes 叢集。
當然並不是說我們要停止對伸縮性和效能的追求。正如開篇所言，我們的最高優先順序工作是保證目前的 SLO 並擴充套件 SLO 到其他系統，例如網路。這些工作都已經在伸縮性 SIG 中啟動，我們在 SLO 的定義上已經取得了長足的進步，這些工作將在未來的幾個月中逐步完成。
原文: