?前言

最初建設(shè)容器云平臺的時(shí)候，筆者也討論過容器虛擬集群和物理集群的優(yōu)缺點(diǎn)。在容器云平臺應(yīng)用實(shí)踐過程中，也逐漸部署了虛擬節(jié)點(diǎn)和物理節(jié)點(diǎn)。隨著實(shí)踐的深入，虛擬節(jié)點(diǎn)和物理節(jié)點(diǎn)的不同資源配置，也帶來了一些問題和思考。起初覺得容器既然是輕量化的，每個節(jié)點(diǎn)其實(shí)是不需要配置那么高的資源的。不過很快就被現(xiàn)實(shí)打臉，不合適的節(jié)點(diǎn)資源配置不但增加了管理的復(fù)雜度，也帶來了資源的浪費(fèi)。另外由于容器云平臺自身功能的限制，以及總體架構(gòu)和總體資源受限，難以實(shí)現(xiàn)真正的彈性調(diào)度、按需擴(kuò)展。

比如說經(jīng)常會出現(xiàn)一臺宿主機(jī)上的虛擬機(jī)資源爭搶現(xiàn)象，但從容器云平臺看到的卻是容器節(jié)點(diǎn)資源使用不高但應(yīng)用出現(xiàn)請求異常等問題。所以這并不是一個簡單的容器云問題，需要實(shí)現(xiàn)各個層次的聯(lián)動，比如實(shí)現(xiàn)虛擬化平臺與容器云平臺的聯(lián)動，基礎(chǔ)設(shè)施資源管理平臺與容器云平臺的聯(lián)動以實(shí)現(xiàn)異構(gòu)資源調(diào)度等。

從虛擬機(jī)節(jié)點(diǎn)到物理機(jī)節(jié)點(diǎn)

基于虛擬化平臺來部署容器云則相對容易實(shí)現(xiàn)容器節(jié)點(diǎn)的擴(kuò)縮容，但由于缺乏統(tǒng)一的監(jiān)控平臺和囿于單體豎井系統(tǒng)建設(shè)思路，虛擬化層宿主機(jī)的信息往往在容器云平臺無法看到，無法及時(shí)有效平衡容器節(jié)點(diǎn)在虛擬化宿主機(jī)上的負(fù)載。

筆者一直建議通過多云管理平臺（也管理虛擬化平臺）來實(shí)現(xiàn)不同基礎(chǔ)設(shè)施資源的管理，但目前市面上的云管平臺基本都是一個大雜燴，沒有真正理解云管的定位和范圍。等等諸多原因，使難以實(shí)現(xiàn)基礎(chǔ)設(shè)施資源的自動化彈性擴(kuò)容和平衡調(diào)度。

另外，虛擬化層也導(dǎo)致了機(jī)器性能損失約20%，造成很大的浪費(fèi)。比如Java應(yīng)用對資源的需求相對比較大，基于SpringCloud框架開發(fā)的微服務(wù)，如果部署在資源配置比較小的虛擬機(jī)上，容器經(jīng)常會因?yàn)橘Y源不足而被驅(qū)逐，會看到很多Evicted狀態(tài)的容器。

再者，隨著容器節(jié)點(diǎn)的增多，很多問題就暴露出來了，比如說Master節(jié)點(diǎn)配置（隨著節(jié)點(diǎn)增多，Master節(jié)點(diǎn)資源不足響應(yīng)變慢）、ETCD配置（pod、service等對象越來越多）、Ingress配置（高可用、負(fù)載均衡等不同需求所帶來配置的不同）、Portal配置（Portal組件劃分、組件集中部署或分布式部署、組件資源配額）問題等。

一方面可能國內(nèi)很多容器平臺的應(yīng)用都是浮于表面，缺乏真正的實(shí)踐經(jīng)驗(yàn)，沒有太多可以借鑒的，也導(dǎo)致很多功能不完善；另一方面，傳統(tǒng)單體豎井的建設(shè)思路，已經(jīng)完全不適應(yīng)云計(jì)算和云原生的理念，從而也導(dǎo)致沖突，制約容器云的深度應(yīng)用和實(shí)踐。

為了更好的實(shí)現(xiàn)可見性和可管理性，為了更好的性能和資源節(jié)省，經(jīng)過一段實(shí)踐之后，我們將一些物理服務(wù)器部署到了容器虛擬集群，用于部署運(yùn)行重要的業(yè)務(wù)應(yīng)用，形成虛實(shí)節(jié)點(diǎn)混合部署集群。

混合節(jié)點(diǎn)集群

私有云環(huán)境往往無法充分配置各種類型的資源，所以大都是通用性資源，用于部署各種業(yè)務(wù)應(yīng)用。容器云平臺既要考慮節(jié)點(diǎn)的敏捷擴(kuò)容，也要考慮重點(diǎn)業(yè)務(wù)應(yīng)用的穩(wěn)定運(yùn)行和執(zhí)行效率。物理服務(wù)器的采購?fù)枰粋€周期，需要提前準(zhǔn)備相應(yīng)的資源。物理節(jié)點(diǎn)擴(kuò)容相對于虛擬化來說就沒那么方便，也難以實(shí)現(xiàn)資源的復(fù)用，這是物理節(jié)點(diǎn)不足的地方。但物理節(jié)點(diǎn)沒有性能損失，適合運(yùn)行一些比較重要的業(yè)務(wù)，或?qū)μ幚硇阅芤蟊容^高的業(yè)務(wù)。因此可以在容器集群中同時(shí)部署虛擬節(jié)點(diǎn)和物理節(jié)點(diǎn)，實(shí)現(xiàn)混合節(jié)點(diǎn)的集群。在業(yè)務(wù)應(yīng)用部署的時(shí)候，根據(jù)業(yè)務(wù)應(yīng)用特點(diǎn)調(diào)度到合適的節(jié)點(diǎn)上。

節(jié)點(diǎn)配置多大的資源是合適的？坦率說到目前為止也沒有一個明確的標(biāo)準(zhǔn)，往往和具體的業(yè)務(wù)密切相關(guān)。筆者所在場景中虛擬機(jī)可以配置16C 64G、16C48G或者32C64G，磁盤200G，CPU和內(nèi)存的比為1:4、1:3、1:2。根據(jù)業(yè)務(wù)運(yùn)行對資源的消耗需求，經(jīng)過一段時(shí)間的運(yùn)行觀察，可以根據(jù)實(shí)際資源使用再調(diào)整節(jié)點(diǎn)資源配置、容器資源配置。在交易高峰時(shí)段，CPU經(jīng)常是滿負(fù)荷的，但其他時(shí)段CPU往往用的又比較低。共享分區(qū)、獨(dú)享分區(qū)、節(jié)點(diǎn)容量、資源碎片、縱向擴(kuò)容能力、橫向擴(kuò)容能力、遷移規(guī)則、服務(wù)優(yōu)先級、甚至異構(gòu)資源的費(fèi)用等等，都可能會影響到pod的調(diào)度。這其實(shí)帶來了一個物理節(jié)點(diǎn)資源配置的問題。物理機(jī)不做虛擬化，就無法從虛擬層來實(shí)現(xiàn)復(fù)用（不過也減少了虛擬化損耗），另外，物理節(jié)點(diǎn)如果出現(xiàn)異常，需要維護(hù)重啟，其上面的服務(wù)都會受到影響。如果部署的服務(wù)比較多，帶來的影響就比較大。所以一個容器節(jié)點(diǎn)的資源配置也不是越大越好，需要基于實(shí)踐和實(shí)際找到一個平衡。

容器物理集群配置

物理集群中節(jié)點(diǎn)什么樣的配置比較合適？可能需要從幾個方面來考慮。最初筆者也想當(dāng)然覺得可以用很多低配PC機(jī)，不過從機(jī)房的使用效率來說，低配PC明顯不是很合適，畢竟需要占據(jù)很多機(jī)房機(jī)位的，這個成本其實(shí)很高的。但如果配置過高，一個容器節(jié)點(diǎn)通常也不適合部署很多個容器，k8s建議不超過110個pod。另外，配置過高，節(jié)點(diǎn)數(shù)量相對就比較少，彈性調(diào)度的范圍就比較小。特別多個重要的容器部署到同一個節(jié)點(diǎn)上，一旦節(jié)點(diǎn)出現(xiàn)異常，影響可能會非常大。不過物理節(jié)點(diǎn)相對有效的減少了資源碎片和資源虛擬化損失，資源利用率相對更高。

基于前期的實(shí)踐和實(shí)際的情況，采購了一批96C 512G 4T的服務(wù)器，用于搭建容器物理集群，部署一些重要的業(yè)務(wù)應(yīng)用。采用物理節(jié)點(diǎn)，對應(yīng)用資源的調(diào)度能力要求反而更高了。資源調(diào)度可以有不同的規(guī)則，比如說是平衡調(diào)度？還是單節(jié)點(diǎn)優(yōu)先調(diào)度？或是預(yù)留部分資源平衡調(diào)度等等；還有大的pod和小的pod的均衡調(diào)度、服務(wù)親和性和非親和性調(diào)度等需求。在節(jié)點(diǎn)量相對少的情況下，可能需要重點(diǎn)考慮應(yīng)用pod的均衡調(diào)度問題。

深入認(rèn)識容器使用場景

我們都知道容器輕量、無狀態(tài)、生命周期短。不過實(shí)際應(yīng)用可能會發(fā)現(xiàn)，一個業(yè)務(wù)應(yīng)用容器可能并不輕量、有眾多的數(shù)據(jù)需要持久化、往往需要長期持續(xù)穩(wěn)定運(yùn)行等等?？赡芤矔?jīng)常遇到幾個G、十幾個G的鏡像，把容器直接當(dāng)虛擬機(jī)用。雖然說這是一些不好的習(xí)慣，不過問題確實(shí)是存在的。理論上，容器要盡可能刪除無用的組件和文件，使容器盡可能輕量，但實(shí)際項(xiàng)目中，很多廠商都不會去做這些工作，因?yàn)檫@需要很多的時(shí)間來清理，需要遵循很多的規(guī)則，需要額外很多測試；另外在業(yè)務(wù)異常處理過程中可能會用到一些工具或組件，安裝這些工具和組件到容器就會導(dǎo)致這些容器比較重，同時(shí)也增加了安全的接觸面，帶來了更多的安全漏洞或潛在安全漏洞和安全風(fēng)險(xiǎn)。比如說，打包Java服務(wù)時(shí)用JDK鏡像還是用JRE鏡像？運(yùn)行java，JRE就夠了，用JDK其實(shí)就額外浪費(fèi)了很多資源。

筆者就一直強(qiáng)調(diào)像數(shù)據(jù)庫、Kafka、Redis、ES等不適合部署在容器中，當(dāng)然，測試環(huán)境中為了敏捷構(gòu)建業(yè)務(wù)測試環(huán)境，快速回歸初始狀態(tài)以便于執(zhí)行回歸測試等，是很便利的。不過生產(chǎn)環(huán)境追求的是穩(wěn)定、可靠（這就是Google SRE的價(jià)值所在），和測試環(huán)境的敏捷需求是不一樣的。不同的場景所采取的方案可能是不同的，因此在實(shí)現(xiàn)容器內(nèi)小環(huán)境一致性的之外，企業(yè)內(nèi)生產(chǎn)和測試環(huán)境可能還是會有差別的。在生產(chǎn)環(huán)境，穩(wěn)定性和可靠性比彈性更重要，因此，生產(chǎn)環(huán)境除了數(shù)據(jù)庫、中間件等適合部署在物理機(jī)上外，一些重要的業(yè)務(wù)也可用容器物理節(jié)點(diǎn)更好的滿足性能等需求。

筆者曾經(jīng)嘗試配置不同的容器節(jié)點(diǎn)以滿足不同業(yè)務(wù)應(yīng)用的需求，但資源分配出去之后無法控制各團(tuán)隊(duì)的使用，特別有眾多的廠商和外包人員，對容器和相關(guān)的技術(shù)理解不深，不知道怎么設(shè)置資源配置、調(diào)度配置等參數(shù)，對業(yè)務(wù)服務(wù)的資源需求不知道怎么預(yù)估，因此往往會不自覺地配置很大的資源以此來避免資源所帶來的問題，但這樣造成了很大的資源浪費(fèi)（分出去的資源被獨(dú)占，無法與其他服務(wù)共享）。因此也需要及時(shí)的監(jiān)控提醒和培訓(xùn)，調(diào)整不合理的資源配置。

容器在遷移、重啟、被驅(qū)逐等都會導(dǎo)致Pod重建，造成短時(shí)間的中斷；業(yè)務(wù)服務(wù)如果無法啟動比如初始化連接不上kafka或數(shù)據(jù)庫可能會導(dǎo)致Pod頻繁重建，k8s自身的一些bug也會導(dǎo)致系統(tǒng)某些資源耗盡，帶來節(jié)點(diǎn)異常。實(shí)際運(yùn)行種也曾發(fā)現(xiàn)有容器服務(wù)創(chuàng)建了數(shù)百個到數(shù)千個進(jìn)程。由于容器POD的封裝，不去檢查這些指標(biāo)的話可能無法發(fā)現(xiàn)問題，導(dǎo)致環(huán)境經(jīng)常出現(xiàn)異常，特別生產(chǎn)環(huán)境，業(yè)務(wù)不穩(wěn)定不止體驗(yàn)不好，更會帶來資金損失，所以容器的短生命周期自恢復(fù)特性，如果不注意其內(nèi)封裝的業(yè)務(wù)應(yīng)用和運(yùn)行環(huán)境，依然會帶來很多問題。

一點(diǎn)建議

大家往往都喜歡最佳實(shí)踐，其實(shí)不同環(huán)境不同場景不同需求等所應(yīng)采取的方案可能也不同的，所以筆者也一直建議基于實(shí)際來考慮。經(jīng)驗(yàn)可以作為參考，但不能照搬。容器云平臺在使用虛擬節(jié)點(diǎn)和物理節(jié)點(diǎn)時(shí)各有優(yōu)缺點(diǎn)，不過隨著管理手段的增強(qiáng)，以及政策的支持，物理集群可能會越來越多。物理集群的配置也需要基于具體的業(yè)務(wù)需求來確定。

如果每個服務(wù)對資源的需求都不大，可以配置稍微低點(diǎn)的物理節(jié)點(diǎn)；如果部署的容器對資源需求比較大，比如部署Kafka、ES等中間件容器，可能一個Pod就需要32C64G甚至更多的資源，可能需要配置高些。隨著應(yīng)用資源調(diào)度能力逐步完善，實(shí)現(xiàn)不同業(yè)務(wù)分時(shí)共享復(fù)用來有效提升資源利用率，可能會越來越普遍。已經(jīng)有公司通過應(yīng)用混合部署來提升資源效率，比如說白天處理交易業(yè)務(wù)為主，晚上處理批量計(jì)算為主，使業(yè)務(wù)忙時(shí)和閑時(shí)的資源都能充分利用。這對于容器物理節(jié)點(diǎn)來說可能會更合適些。