容器雲平臺物理叢集配置實踐

在容器雲平臺應用中，虛擬節點和物理節點的不同資源配置是一個需要深入思考的問題，本文討論了容器雲平臺叢集建設過程中由虛擬化節點向物理節點過渡中的一些實踐和經驗總結，探討物理叢集節點資源配置和應用場景，以期他山之石可以攻玉。

前言

最初建設容器雲平臺的時候，筆者也討論過容器虛擬叢集和物理叢集的優缺點。在容器雲平臺應用實踐過程中，也逐漸部署了虛擬節點和物理節點。隨著實踐的深入，虛擬節點和物理節點的不同資源配置，也帶來了一些問題和思考。起初覺得容器既然是輕量化的，每個節點其實是不需要配置那麼高的資源的。不過很快就被現實打臉，不合適的節點資源配置不但增加了管理的複雜度，也帶來了資源的浪費。另外由於容器雲平臺自身功能的限制，以及總體架構和總體資源受限，難以實現真正的彈性排程、按需擴充套件。比如說經常會出現一臺宿主機上的虛擬機器資源爭搶現象，但從容器雲平臺看到的卻是容器節點資源使用不高但應用出現請求異常等問題。所以這並不是一個簡單的容器雲問題，需要實現各個層次的聯動，比如實現虛擬化平臺與容器雲平臺的聯動，基礎設施資源管理平臺與容器雲平臺的聯動以實現異構資源排程等。

從虛擬機器節點到物理機節點

基於虛擬化平臺來部署容器雲則相對容易實現容器節點的擴縮容，但由於缺乏統一的監控平臺和囿於單體豎井系統建設思路，虛擬化層宿主機的資訊往往在容器雲平臺無法看到，無法及時有效平衡容器節點在虛擬化宿主機上的負載。

筆者一直建議透過多雲管理平臺(也管理虛擬化平臺)來實現不同基礎設施資源的管理，但目前市面上的雲管平臺基本都是一個大雜燴，沒有真正理解雲管的定位和範圍。等等諸多原因，使難以實現基礎設施資源的自動化彈性擴容和平衡排程。

另外，虛擬化層也導致了機器效能損失約20%，造成很大的浪費。比如Java應用對資源的需求相對比較大，基於SpringCloud框架開發的微服務，如果部署在資源配置比較小的虛擬機器上，容器經常會因為資源不足而被驅逐，會看到很多Evicted狀態的容器。

再者，隨著容器節點的增多，很多問題就暴露出來了，比如說Master節點配置(隨著節點增多，Master節點資源不足響應變慢)、ETCD配置(pod、service等物件越來越多)、Ingress配置(高可用、負載均衡等不同需求所帶來配置的不同)、Portal配置(Portal元件劃分、元件集中部署或分散式部署、元件資源配額)問題等。

一方面可能國內很多容器平臺的應用都是浮於表面，缺乏真正的實踐經驗，沒有太多可以借鑑的，也導致很多功能不完善;另一方面，傳統單體豎井的建設思路，已經完全不適應雲端計算和雲原生的理念，從而也導致衝突，制約容器雲的深度應用和實踐。

為了更好的實現可見性和可管理性，為了更好的效能和資源節省，經過一段實踐之後，我們將一些物理伺服器部署到了容器虛擬叢集，用於部署執行重要的業務應用，形成虛實節點混合部署叢集。

混合節點叢集

私有云環境往往無法充分配置各種型別的資源，所以大都是通用性資源，用於部署各種業務應用。容器雲平臺既要考慮節點的敏捷擴容，也要考慮重點業務應用的穩定執行和執行效率。物理伺服器的採購往往需要一個週期，需要提前準備相應的資源。物理節點擴容相對於虛擬化來說就沒那麼方便，也難以實現資源的複用，這是物理節點不足的地方。但物理節點沒有效能損失，適合執行一些比較重要的業務，或對處理效能要求比較高的業務。因此可以在容器叢集中同時部署虛擬節點和物理節點，實現混合節點的叢集。在業務應用部署的時候，根據業務應用特點排程到合適的節點上。

節點配置多大的資源是合適的?坦率說到目前為止也沒有一個明確的標準，往往和具體的業務密切相關。筆者所在場景中虛擬機器可以配置16C 64G、16C48G或者32C64G，磁碟200G，CPU和記憶體的比為1:4、1:3、1:2。根據業務執行對資源的消耗需求，經過一段時間的執行觀察，可以根據實際資源使用再調整節點資源配置、容器資源配置。在交易高峰時段，CPU經常是滿負荷的，但其他時段CPU往往用的又比較低。共享分割槽、獨享分割槽、節點容量、資源碎片、縱向擴容能力、橫向擴容能力、遷移規則、服務優先順序、甚至異構資源的費用等等，都可能會影響到pod的排程。這其實帶來了一個物理節點資源配置的問題。物理機不做虛擬化，就無法從虛擬層來實現複用(不過也減少了虛擬化損耗)，另外，物理節點如果出現異常，需要維護重啟，其上面的服務都會受到影響。如果部署的服務比較多，帶來的影響就比較大。所以一個容器節點的資源配置也不是越大越好，需要基於實踐和實際找到一個平衡。

容器物理叢集配置

物理叢集中節點什麼樣的配置比較合適?可能需要從幾個方面來考慮。最初筆者也想當然覺得可以用很多低配PC機，不過從機房的使用效率來說，低配PC明顯不是很合適，畢竟需要佔據很多機房機位的，這個成本其實很高的。但如果配置過高，一個容器節點通常也不適合部署很多個容器，k8s建議不超過110個pod。另外，配置過高，節點數量相對就比較少，彈性排程的範圍就比較小。特別多個重要的容器部署到同一個節點上，一旦節點出現異常，影響可能會非常大。不過物理節點相對有效的減少了資源碎片和資源虛擬化損失，資源利用率相對更高。

基於前期的實踐和實際的情況，採購了一批96C 512G 4T的伺服器，用於搭建容器物理叢集，部署一些重要的業務應用。採用物理節點，對應用資源的排程能力要求反而更高了。資源排程可以有不同的規則，比如說是平衡排程?還是單節點優先排程?或是預留部分資源平衡排程等等;還有大的pod和小的pod的均衡排程、服務親和性和非親和性排程等需求。在節點量相對少的情況下，可能需要重點考慮應用pod的均衡排程問題。

深入認識容器使用場景

我們都知道容器輕量、無狀態、生命週期短。不過實際應用可能會發現，一個業務應用容器可能並不輕量、有眾多的資料需要持久化、往往需要長期持續穩定執行等等。可能也會經常遇到幾個G、十幾個G的映象，把容器直接當虛擬機器用。雖然說這是一些不好的習慣，不過問題確實是存在的。理論上，容器要儘可能刪除無用的元件和檔案，使容器儘可能輕量，但實際專案中，很多廠商都不會去做這些工作，因為這需要很多的時間來清理，需要遵循很多的規則，需要額外很多測試;另外在業務異常處理過程中可能會用到一些工具或元件，安裝這些工具和元件到容器就會導致這些容器比較重，同時也增加了安全的接觸面，帶來了更多的安全漏洞或潛在安全漏洞和安全風險。比如說，打包Java服務時用JDK映象還是用JRE映象?執行java，JRE就夠了，用JDK其實就額外浪費了很多資源。

筆者就一直強調像資料庫、Kafka、Redis、ES等不適合部署在容器中，當然，測試環境中為了敏捷構建業務測試環境，快速回歸初始狀態以便於執行迴歸測試等，是很便利的。不過生產環境追求的是穩定、可靠(這就是Google SRE的價值所在)，和測試環境的敏捷需求是不一樣的。不同的場景所採取的方案可能是不同的，因此在實現容器內小環境一致性的之外，企業內生產和測試環境可能還是會有差別的。在生產環境，穩定性和可靠性比彈性更重要，因此，生產環境除了資料庫、中介軟體等適合部署在物理機上外，一些重要的業務也可用容器物理節點更好的滿足效能等需求。

筆者曾經嘗試配置不同的容器節點以滿足不同業務應用的需求，但資源分配出去之後無法控制各團隊的使用，特別有眾多的廠商和外包人員，對容器和相關的技術理解不深，不知道怎麼設定資源配置、排程配置等引數，對業務服務的資源需求不知道怎麼預估，因此往往會不自覺地配置很大的資源以此來避免資源所帶來的問題，但這樣造成了很大的資源浪費(分出去的資源被獨佔，無法與其他服務共享)。因此也需要及時的監控提醒和培訓，調整不合理的資源配置。

容器在遷移、重啟、被驅逐等都會導致Pod重建，造成短時間的中斷;業務服務如果無法啟動比如初始化連線不上kafka或資料庫可能會導致Pod頻繁重建，k8s自身的一些bug也會導致系統某些資源耗盡，帶來節點異常。實際執行種也曾發現有容器服務建立了數百個到數千個程式。由於容器POD的封裝，不去檢查這些指標的話可能無法發現問題，導致環境經常出現異常，特別生產環境，業務不穩定不止體驗不好，更會帶來資金損失，所以容器的短生命週期自恢復特性，如果不注意其內封裝的業務應用和執行環境，依然會帶來很多問題。

一點建議

大家往往都喜歡最佳實踐，其實不同環境不同場景不同需求等所應採取的方案可能也不同的，所以筆者也一直建議基於實際來考慮。經驗可以作為參考，但不能照搬。容器雲平臺在使用虛擬節點和物理節點時各有優缺點，不過隨著管理手段的增強，以及政策的支援，物理叢集可能會越來越多。物理叢集的配置也需要基於具體的業務需求來確定。如果每個服務對資源的需求都不大，可以配置稍微低點的物理節點;如果部署的容器對資源需求比較大，比如部署Kafka、ES等中介軟體容器，可能一個Pod就需要32C64G甚至更多的資源，可能需要配置高些。隨著應用資源排程能力逐步完善，實現不同業務分時共享複用來有效提升資源利用率，可能會越來越普遍。已經有公司透過應用混合部署來提升資源效率，比如說白天處理交易業務為主，晚上處理批次計算為主，使業務忙時和閒時的資源都能充分利用。這對於容器物理節點來說可能會更合適些。