?前言

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

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

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

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

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

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

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

一方面可能國(guó)內(nèi)很多容器平臺(tá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)過(guò)一段實(shí)踐之后，我們將一些物理服務(wù)器部署到了容器虛擬集群，用于部署運(yùn)行重要的業(yè)務(wù)應(yīng)用，形成虛實(shí)節(jié)點(diǎn)混合部署集群。

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

私有云環(huán)境往往無(wú)法充分配置各種類型的資源，所以大都是通用性資源，用于部署各種業(yè)務(wù)應(yīng)用。容器云平臺(tái)既要考慮節(jié)點(diǎn)的敏捷擴(kuò)容，也要考慮重點(diǎn)業(yè)務(wù)應(yīng)用的穩(wěn)定運(yùn)行和執(zhí)行效率。物理服務(wù)器的采購(gòu)?fù)枰粋€(gè)周期，需要提前準(zhǔn)備相應(yīng)的資源。物理節(jié)點(diǎn)擴(kuò)容相對(duì)于虛擬化來(lái)說(shuō)就沒那么方便，也難以實(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)配置多大的資源是合適的？坦率說(shuō)到目前為止也沒有一個(gè)明確的標(biāo)準(zhǔn)，往往和具體的業(yè)務(wù)密切相關(guān)。筆者所在場(chǎng)景中虛擬機(jī)可以配置16C 64G、16C48G或者32C64G，磁盤200G，CPU和內(nèi)存的比為1:4、1:3、1:2。根據(jù)業(yè)務(wù)運(yùn)行對(duì)資源的消耗需求，經(jīng)過(guò)一段時(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)先級(jí)、甚至異構(gòu)資源的費(fèi)用等等，都可能會(huì)影響到pod的調(diào)度。這其實(shí)帶來(lái)了一個(gè)物理節(jié)點(diǎn)資源配置的問題。物理機(jī)不做虛擬化，就無(wú)法從虛擬層來(lái)實(shí)現(xiàn)復(fù)用（不過(guò)也減少了虛擬化損耗），另外，物理節(jié)點(diǎn)如果出現(xiàn)異常，需要維護(hù)重啟，其上面的服務(wù)都會(huì)受到影響。如果部署的服務(wù)比較多，帶來(lái)的影響就比較大。所以一個(gè)容器節(jié)點(diǎn)的資源配置也不是越大越好，需要基于實(shí)踐和實(shí)際找到一個(gè)平衡。

容器物理集群配置

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

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

深入認(rèn)識(shí)容器使用場(chǎng)景

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

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

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

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

一點(diǎn)建議

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

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