11 月 23 日，Erda 與 OSCHINA 社群聯手發起了【高手問答第 271 期 -- 聊聊大規模 K8s 叢集管理】，目前問答活動已持續一週，由 Erda SRE 團隊負責人駱冰利為大家解答，以下是本次活動的部分問題整理合集，其他問題也將於近期整理後釋出，敬請期待！

----

**Q1：K8s 上面部署不通的應用對於儲存有不同的要求，有的要高吞吐，有的是要低響應。大規模 K8s 部署的時候是怎麼協調這種儲存差異的問題？還是說需要根據不同的場景，運維不同的儲存服務？又或者說盡量儲存使用解決方案？**

A1：儲存相對於 CPU 和記憶體確實會更復雜一些，就是因為它會包含更多型別，不同的儲存空間，不同的效能要求。所以儲存還是得從應用需求出發，來滿足不同的儲存需求。

----

**Q2：請問下你們維護的最大 K8s 叢集規模大小是多少？遇到了哪些效能、穩定性問題？做了哪些最佳化？**

A2：我們目前維護的單個叢集規模不大，總量相對大些，維護了幾百個叢集。量上來了就會碰到形形色色的問題，比如：如何提升運維效率？如何比使用者更早地發現問題？如何最佳化記憶體碎片問題？如何最佳化磁碟驅逐帶來的隱患？。我們也做了很多事情：第一步進行標準化，比如統一作業系統、統一版本、標準化節點規格、系統資料盤分離等等。接著開始建設診斷系統，覆蓋作業系統、容器、K8s、常規中介軟體、平臺（應用）等，目前就是先於使用者發現問題，能全方位進行巡檢覆蓋，可以將其理解為運維繫統的眼睛，近期我們剛好也開源了這個系統：kubeprober。當前也會有對應的一些最佳化，比如: 補充 docker k8s 的 log rotate 引數，最佳化 gc、eviction 引數，防止磁碟被寫滿；對 Pod PID 進行限制、EmtyDir 儲存、容器可寫層大小等進行限制；保障 K8s 關鍵 Pod 的排程；關閉 swap，最佳化 /proc/sys/vm/min_free_kbytes 等引數，最佳化記憶體回收。

問題有些大，涉及的工作也會特別多，我也只是列舉了部分，每個點上都還可以做更多的事情。

kubeprober 開源地址：
https://github.com/erda-project/kubeprober

----

**Q3：老師目前容器化部署編排企業私有成本遠沒有云廠商實惠，這會不會形成壟斷趨勢？還有 Serverless 的發展是不是對容器技術的衝擊呢?**

A3：會有些現狀問題，國內不少企業都有自建 IDC，尤其是一些頭部企業。不論考慮是進行利舊，還是資料安全性等，客戶都會有不同的決策，所以一定會有共存的情況。

----

**Q4：K8s 對標兩地三中心這樣的部署架構老師有什麼推薦麼？是一套 K8s 用 namespace 區分好，還是各自搭建，優缺點老師能分享一下嗎？**

A4：一套的好處，管理成本比較低，部署的業務可以直接基於地域標籤進行打散部署。但會有較大的問題，比如兩地三中心本身就跨地域的，網路質量的保障是個大問題。本身方案就需要能跨城市級的高可用，那單 K8s 叢集的 ETCD 高可用怎麼保障？如果真出現城市級自然災害，那就會導致你的 etcd 叢集異常。本身的容災方案還沒起作用，可能就會出現該 K8S 叢集因為網路等因素導致的不穩定。

容災方案本身就會有較大的複雜性，跟你的環境，跟你的場景，都會有較大的關係。我可能沒辦法直接告訴你一套方案，但可以一起探討下。?

----

**Q5：您好，請問需要把所有的服務都拆分為微服務嗎？併發量到多大才需要這樣？**

A5：微服務是否拆分，可能還不是僅跟併發量有關，很多時候你拆分後，效能可能比你單體架構還要差。核心還是得看你要解決什麼問題，比如研發效率太低了、團隊規模太大了、業務複雜度太高了等等。並不只是一個簡單的拆分動作，還得去考慮你開發運維方式的變化、組織結構的變化等。

----

**Q6：K8s 持久化儲存有推薦方案嗎？nfs 效能和穩定性都不行，ceph 蠻複雜的（還要區分 rbd、ceph），貌似也有人反應不穩定。local pv 的話 pod 要鎖死節點了，K8s 優勢大減呀～**

A6：是的，只是舉個例子。local pv 也是一個場景，你需要有更強的效能時，就是一個不錯的選擇，雖然和節點繫結了，但是可以透過應用層的架構來提升高可用的能力，解決單點故障問題。只是舉例子，所以關鍵是看場景去配對儲存實現。

----

**Q7：資料庫這類對儲存敏感的軟體，你們會部署到 K8s 上嗎？有什麼要注意的？**

A7：我們目前進行了區分，非生產環境採用了資料庫上 K8s，可以有更高的成本和運維能力。生產環境還沒有跑在 K8s 上，主要是考慮穩定性。很多中介軟體都一樣，不僅僅是資料庫，只考慮儲存還不夠，比如你需要注意擴縮容、監控、快照備份、故障恢復等等，還有一些特定中介軟體的運維需求。

----

**Q8：請問老師你們運維的 K8s 叢集是執行在物理機上還是虛擬機器上呢？現在不少公司都已經有虛擬化環境，虛擬機器和容器共存有什麼經驗、建議嗎？**

A8：我們現在運維的 K8s 叢集大部分都是在虛擬機器上。多一層虛擬機器，會多一些開銷，比如資源開銷、VM 平臺的管理開銷，甚至還會有采購成本。多一層虛擬化，可以彌補下容器的隔離性及安全性，擴縮容的成本也比物理機要低，現在不少 VM 平臺還提供了熱遷移等功能，運維能力上還是會強一些。有沒有虛擬機器這層，對 K8s 的使用層面關係不是特別大。

----

**Q9：老師您好，關於 K8s 我們主要是使用一些管理平臺去做管理如 Kubesphere、rancher 等等，針對 K8s 學習路線，想問一下怎麼能更地去結合現狀實踐學習？**

A9：很好的一點是你已經有了實際的環境去使用以及研究 K8s 了，帶著實際的場景以及問題去學習 K8s 往往是最有效的方式，但前提是你已經掌握了 K8s 的基本知識和原理，在這些知識背景下再碰到工作上的實際問題往往都能思考的更深，也對 K8s 掌握的更細緻，尤其是 kubesphere 、rancher 管理下的 K8s，往往遇到問題要先甄別是 K8s 的問題還是管理平臺的問題，這時基本的理論知識就顯得尤為重要，共勉。

----

**Q10：如果存在要跨地域建 K8s、跨時區的場景下，如何保障 K8s 叢集的穩定性，主機時間如何處理？**

A10：個人不建議跨地域、跨時區，構建同一個 K8s 叢集。建議考慮多叢集的方案。，主要是兩類: Pod IP + Service IP。叢集網路算是這兩類的統稱，看個人怎麼理解了。Service 核心是用於服務發現及 Pod 流量負載。

----

**Q11：如何理解 pod 內網路、叢集網路以及 service 網路呢？目前該如何選擇網路外掛 CNI？**

A11：如果沒有太多的需求，可以選擇 flannel，相對簡單一些。當然還有很多其他的外掛，比如 calico、weave 等，如果你想要有更強的效能，更豐的網路策略配置，可以考慮下它們。

----

<p style="text-align:center">更多技術乾貨請關注**【爾達 Erda】公眾號**，與眾多開源愛好者共同成長～</p>

大規模 K8s 叢集管理經驗分享 · 上篇

相關文章