企業(yè)容器云持久化存儲方案設(shè)計(jì)及難點(diǎn)解讀

企業(yè)容器云持久化存儲方案設(shè)計(jì)及難點(diǎn)解讀

容器遷移過程中，同時需要對數(shù)據(jù)也進(jìn)行遷移，需要一套數(shù)據(jù)擴(kuò)容和管理的機(jī)制來滿足有狀態(tài)服務(wù)的數(shù)據(jù)存儲需要。在面向有狀態(tài)的容器服務(wù)時，需要考慮以下幾個方面的數(shù)據(jù)持久化需求：1、容器對應(yīng)的存儲卷在進(jìn)行故障恢復(fù)時，會帶來卷的掛載和卸載。為了保證整個生產(chǎn)環(huán)境的高可用，卷的掛載和卸載一方面需要具有足夠的穩(wěn)定性，同時也需要考慮性能需求，避免應(yīng)用延遲。2、存儲卷快照管理需求。傳統(tǒng)的存儲卷快照策略主要從資源角度進(jìn)行管理，而容器的存儲卷往往動態(tài)分配而來，快照策略需要與容器應(yīng)用備份需求保持一致。3、容量擴(kuò)容需求：隨著容器應(yīng)用數(shù)據(jù)的增長，存儲卷容量需要考慮擴(kuò)容的能力，最大程度避免對應(yīng)用運(yùn)行的影響。4、運(yùn)維管理需求：隨著容器有狀態(tài)應(yīng)用的增長，對傳統(tǒng)存儲運(yùn)維工作也會帶來挑戰(zhàn)，整體方案需要兼顧運(yùn)維敏捷和安全。5、分布式存儲需求：銀行創(chuàng)新業(yè)務(wù)的擴(kuò)展能力通常都是橫向擴(kuò)展的，需要容器云具備橫向擴(kuò)展的能力，需要引入分布式存儲架構(gòu)部署在容器云平臺上。為了能更好的解決大家在容器云持久化上的需求及方案設(shè)計(jì)下遇到的建設(shè)難點(diǎn)，twt社區(qū)不久前特別邀請了某大型銀行的容器云專家以及SmartX的容器持久化專家在線輔導(dǎo)答疑。本文對交流內(nèi)容進(jìn)行總結(jié)，供更多同行參考。分為四個部分：容器持久化存儲建設(shè)難點(diǎn)和關(guān)注點(diǎn)、容器持久化存儲的建設(shè)方案重點(diǎn)考慮的涉及層面、容器持久化技術(shù)層面的選擇、交流總結(jié)共識。一、容器持久化存儲建設(shè)難點(diǎn)和關(guān)注點(diǎn)1、企業(yè)容器云為支持有狀態(tài)應(yīng)用的容器應(yīng)用部署，存儲設(shè)計(jì)時需要考慮哪些因素？@rechen招商銀行云計(jì)算架構(gòu)師：有狀態(tài)應(yīng)用的狀態(tài)可細(xì)分指拓?fù)錉顟B(tài)、存儲狀態(tài)。其中拓?fù)錉顟B(tài)指應(yīng)用的多個實(shí)例之間不是對等關(guān)系，這些應(yīng)用實(shí)例，必須按照某種順序啟動。存儲狀態(tài)則是指應(yīng)用的多個實(shí)例分別綁定了不同的存儲數(shù)據(jù)，對于這些應(yīng)用實(shí)例來說。當(dāng)應(yīng)用因?yàn)槟承┰驅(qū)е铝隋礄C(jī)，重啟后依舊可以正常的讀取到數(shù)據(jù)。在容器云上部署的有狀態(tài)應(yīng)用，其部署需求有：維持穩(wěn)定且唯一的網(wǎng)絡(luò)標(biāo)識，提供穩(wěn)定持久的存儲，提供有序和優(yōu)雅的部署和伸縮能力，提供有序和自動的更新能力。因此存儲設(shè)計(jì)時，要綜合考慮到有狀態(tài)應(yīng)用的特征進(jìn)行設(shè)計(jì)，譬如在容器云上部署數(shù)據(jù)庫這類有狀態(tài)應(yīng)用，和部署日志監(jiān)控這類有狀態(tài)應(yīng)用就有不同的設(shè)計(jì)維度和優(yōu)先級。存儲產(chǎn)品的選型優(yōu)先考察穩(wěn)定、安全、性能和API能力。@asdf-asdfcloudstone研究學(xué)者：當(dāng)前有狀態(tài)應(yīng)用的容器應(yīng)用部署，如果有能力應(yīng)修改應(yīng)用。使其狀態(tài)保存在緩存服務(wù)器類似Rediscluster中，相關(guān)日志統(tǒng)一進(jìn)入ELK，或者Kafka完成持久化。這樣存儲設(shè)計(jì)相對簡單，只要保證ELK和Redis的存儲容量和訪問速度。如果無法修改應(yīng)用，需要掛載一個持久化卷，來持久化數(shù)據(jù)。使數(shù)據(jù)可以在不同節(jié)點(diǎn)漂移，需要所有主機(jī)對存儲的訪問權(quán)限，這個又會出現(xiàn)存儲訪問風(fēng)險。在實(shí)際業(yè)務(wù)場景，把存儲分多個區(qū)域，掛載到對應(yīng)區(qū)域的主機(jī)，進(jìn)行區(qū)別訪問，避免訪問風(fēng)險。2、持久化存儲選擇集中式存儲，還是分布式存儲？@rechen招商銀行云計(jì)算架構(gòu)師：容器云的持久化存儲的選型，還是要根據(jù)承載的工作負(fù)載進(jìn)行具體分析。譬如在容器云上部署關(guān)系型數(shù)據(jù)庫，且數(shù)據(jù)庫的數(shù)據(jù)是重要的業(yè)務(wù)系統(tǒng)數(shù)據(jù)，則選擇集中式存儲為宜。如果是業(yè)務(wù)應(yīng)用系統(tǒng)的日志，或者是配置文件，則建議優(yōu)先選擇分布式存儲，在擴(kuò)展性和成本收益上更佳。@nawangSmartX產(chǎn)品經(jīng)理：集中式存儲：可以在Kubernetes中使用已有的FC-SAN或NAS。然而，傳統(tǒng)存儲不可彈性擴(kuò)展、依賴專有硬件、運(yùn)維管理相對復(fù)雜等特點(diǎn)與云原生所要求的敏捷背道而馳，它們并不是K8s的首選。分布式存儲：分布式存儲天然具有橫向擴(kuò)展能力，在性能和高可用方面遠(yuǎn)優(yōu)于集中式存儲，非常適合應(yīng)對大規(guī)模虛擬化場景。不過在實(shí)際的使用過程中，大部分分布式存儲的性能和穩(wěn)定性都難以達(dá)到生產(chǎn)級別的標(biāo)準(zhǔn)，這使得很多運(yùn)維團(tuán)隊(duì)不敢輕易地部署分布式存儲產(chǎn)品。二、容器持久化存儲的建設(shè)方案重點(diǎn)考慮的涉及層面1、金融行業(yè)企業(yè)級容器持久化存儲方案，開源和商用應(yīng)該如何選擇？優(yōu)劣勢分析？@rechen招商銀行云計(jì)算架構(gòu)師：金融行業(yè)企業(yè)級容器持久化存儲方案，建議從穩(wěn)定性、安全性維度上，選擇商用產(chǎn)品。選擇走開源路線的話，則必須要自建研發(fā)團(tuán)隊(duì)補(bǔ)齊穩(wěn)定性和安全能力，以及高水平的運(yùn)維團(tuán)隊(duì)，這樣綜合成本上看，是投入大、風(fēng)險高且見效慢，不利于金融行業(yè)提升業(yè)務(wù)核心競爭力。@nawangSmartX產(chǎn)品經(jīng)理：建議選擇商用型存儲方案。商用型存儲方案，以IOMesh云原生存儲產(chǎn)品為例，相較Ceph、GlusterFS類開源架構(gòu)的分布式存儲，優(yōu)勢有以下幾點(diǎn)：1）掌握核心代碼，可控性更強(qiáng)。開源產(chǎn)品的演進(jìn)由社區(qū)主導(dǎo)，廠商無法根據(jù)客戶需要快速落地功能；出現(xiàn)嚴(yán)重問題時也不能特別快速地響應(yīng)，往往需要等待社區(qū)的修復(fù)。IOMesh選擇自主研發(fā)的形式，充分把控產(chǎn)品質(zhì)量和功能，可以根據(jù)眾多客戶的實(shí)際需求迭代產(chǎn)品，也能在出現(xiàn)問題時提供本地研發(fā)級別的快速響應(yīng)，為用戶業(yè)務(wù)運(yùn)轉(zhuǎn)提供強(qiáng)有力的保證。2）更靈活。通過元數(shù)據(jù)服務(wù)實(shí)現(xiàn)數(shù)據(jù)副本的精確放置，可以形成更加靈活的副本分配策略，并按照資源進(jìn)行調(diào)整副本分配位置，而不是簡單打散；3）性能更高?？梢詫?shí)現(xiàn)計(jì)算與存儲I/O路徑的深度融合，發(fā)揮更高的性能。2、容器持久化存儲方案重點(diǎn)考慮哪些層面設(shè)計(jì)？@nawangSmartX產(chǎn)品經(jīng)理：1.云原生存儲系統(tǒng)需要能夠良好的運(yùn)行在各種不同服務(wù)商提供的公有云環(huán)境或私有云環(huán)境，能夠很好地和其他云原生基礎(chǔ)設(shè)施配合，例如云原生數(shù)據(jù)庫，使得云原生數(shù)據(jù)庫可以真正的在公有云和私有云都能夠得到一致的用戶體驗(yàn)。2.云原生存儲系統(tǒng)需要為運(yùn)維人員提供相同接口和運(yùn)維方式，即運(yùn)行在K8s中，使用K8s的工具進(jìn)行運(yùn)維和管理，具備容器化部署、自動運(yùn)維、聲明式接口等特征，降低運(yùn)維團(tuán)隊(duì)的負(fù)擔(dān)。3、如何選擇合適的容器云持久化存儲方案，Rook+Ceph用于生產(chǎn)環(huán)境有何風(fēng)險？@nawangSmartX產(chǎn)品經(jīng)理：開源產(chǎn)品的演進(jìn)由社區(qū)主導(dǎo)，廠商無法根據(jù)客戶需要快速落地功能；出現(xiàn)嚴(yán)重問題時也不能特別快速地響應(yīng)，往往需要等待社區(qū)的修復(fù)。而商用型存儲方案，尤其是廠商具備自主研發(fā)能力的，可以充分把控產(chǎn)品質(zhì)量和功能，可以根據(jù)眾多客戶的實(shí)際需求迭代產(chǎn)品，也能在出現(xiàn)問題時提供本地研發(fā)級別的快速響應(yīng)，為用戶業(yè)務(wù)運(yùn)轉(zhuǎn)提供強(qiáng)有力的保證。4、容器數(shù)據(jù)備份有哪些好的方案？容器全備份？還是提取容器中的數(shù)據(jù)來備份?@rechen招商銀行云計(jì)算架構(gòu)師：需對容器的數(shù)據(jù)做好分層規(guī)劃，容器鏡像放在鏡像倉庫中，不必做備份；容器實(shí)例存取的數(shù)據(jù)，如果是存儲在分布式文件系統(tǒng)中，則做好分布式文件系統(tǒng)的高可用和備份即可。@強(qiáng)哥之神上汽云計(jì)算中心容器云架構(gòu)師及技術(shù)經(jīng)理：容器數(shù)據(jù)備份，首先是明確是哪些數(shù)據(jù)，是日志還是應(yīng)用產(chǎn)生的數(shù)據(jù)，還是應(yīng)用需要依賴的數(shù)據(jù)。如果是日志數(shù)據(jù)，就可以對接日志平臺，也可通過fluentd等日志組件收集；如果是應(yīng)用產(chǎn)生的數(shù)據(jù)，那么最好需要通過持久化進(jìn)行備份到分布式存儲中；如果是應(yīng)用依賴的數(shù)據(jù)，比如中間件數(shù)據(jù)庫等應(yīng)用，也可以持久化到分布式存儲中，但這種情況更多會追求存儲性能，就需要用本地卷如LocalPV來實(shí)現(xiàn)，但本身需要依賴應(yīng)用自身做好數(shù)據(jù)的同步，比如MySQL的主備通過binlog同步。@half_life上海驥步科技有限公司研發(fā)總監(jiān)：容器的數(shù)據(jù)備份，其實(shí)就是有狀態(tài)應(yīng)用在k8s的備份問題（不包括容器的鏡像），個人認(rèn)為實(shí)際上已經(jīng)不能把容器本身以及應(yīng)用的數(shù)據(jù)分開來了。備份的時候，應(yīng)該把應(yīng)用以及應(yīng)用相關(guān)的資源，如configmap，secret，pv，pvc，service，以及pv里面的數(shù)據(jù)，一起備份下來，并且拷貝或者上傳到第二存儲，同主存儲隔離開來。目前國外主流的產(chǎn)品有kasten的K10，PortworxPXbackup，以及社區(qū)的開源項(xiàng)目velero。這些產(chǎn)品的主流做法，就是把應(yīng)用的資源以及數(shù)據(jù)打包，一起備份到S3對象存儲，或者NFS等第二存儲。其中，PV，PVC還可以抓取CSI快照，然后對快照進(jìn)行備份，或者對快照進(jìn)行有選擇的數(shù)據(jù)導(dǎo)出。之所以這樣做，是因?yàn)樵趉8s容器時代，容器是一個動態(tài)變化的資源，例如正在運(yùn)行在哪個node上、配置的參數(shù)、版本等等信息都可能是變化的。而最關(guān)鍵的數(shù)據(jù)，是靠PV，PVC這樣的資源來描述的。換句話說，PV，PVC其實(shí)就記錄了容器同應(yīng)用數(shù)據(jù)的mapping關(guān)系。在備份的時候，如果容器跟底下使用的存儲（如分布式存儲）分開備份，這樣可能帶來幾個問題：容器的備份時間跟存儲的備份時間不一致，這樣就造成版本的不一致。存儲的備份一般是針對存儲本身的volume/LUN進(jìn)行備份，恢復(fù)的時候，還要處理volume/LUN同PV的關(guān)系。一個集群可能使用不止一個存儲，那備份的時候還要考慮不同存儲的備份策略。一個分布式存儲可能對多個集群供應(yīng)存儲，對某個集群的某個應(yīng)用的細(xì)粒度的數(shù)據(jù)恢復(fù)來說，可能不好處理。總之，如果備份時候?qū)θ萜骱痛鎯Ψ珠_考慮，那還是基本沿用了虛機(jī)時代備份的思路，在容器時代要用的好可能有點(diǎn)困難。在備份的時候，把應(yīng)用相關(guān)的資源一起打包備份，其實(shí)就是把資源跟數(shù)據(jù)的關(guān)系在同一個時間點(diǎn)一起備份下來，形成一個比較完整的可用的恢復(fù)點(diǎn)，將來恢復(fù)時候，也是根據(jù)應(yīng)用的顆粒度來進(jìn)行恢復(fù)的。@笑笑財(cái)險系統(tǒng)工程師：備份整個容器肯定不現(xiàn)實(shí)。提取容器中的數(shù)據(jù)也不用。因?yàn)槿绻菓?yīng)用需要持久化存儲，那么就備份持久化存儲上面的數(shù)據(jù)就好。比如你是商業(yè)存儲提供持久化存儲，那么可以通過存儲層面去做備份。如果是用Ceph這些分布式存儲，那么可以利用Veritas結(jié)合分布式存儲來備份。@guojin_cib興業(yè)軟件架構(gòu)設(shè)計(jì)師：這里暫且只討論容器數(shù)據(jù)備份，而不涉及集群的備份和恢復(fù)。容器里面實(shí)現(xiàn)持久化存儲的方式比較多，一方面通過hostpath掛載，隱射宿主機(jī)的目錄到容器的目錄，另一方便通過通過storage綁定掛載持久卷到容器的任何目錄。還有通過將NFS目錄作為容器的卷掛載的，當(dāng)談到備份數(shù)據(jù)時，上面的方法都存在一個相同的問題-如果容器內(nèi)的數(shù)據(jù)在備份過程中發(fā)生變更，那么就出現(xiàn)了數(shù)據(jù)的不一致性，當(dāng)然我們可以通過關(guān)閉卷的讀寫來獲得數(shù)據(jù)的一致性，不過關(guān)閉卷來備份，會導(dǎo)致業(yè)務(wù)連續(xù)性的中斷。這里建議在k8s集群中，把有狀態(tài)服務(wù)的信息存儲在數(shù)據(jù)中，獨(dú)立于容器的文件的系統(tǒng)。這樣就可以按照常規(guī)的方式備份數(shù)據(jù)，比如快照。這里介紹幾個開源項(xiàng)目一個是openebs，比較火的開源的云原生的存儲。另外一個就是velero項(xiàng)目，可對集群資源備份和恢復(fù)。@zhuqibsMcd軟件開發(fā)工程師：首先，容器中如果有數(shù)據(jù)，有三種方式放置，tmp、hostpath和storageclass。其次，如果要備份容器內(nèi)的數(shù)據(jù)，如果使用tmp顯然不可能，如果是hostpath，需要到指定的節(jié)點(diǎn)上去備份，但容器環(huán)境中，pod會切換，生產(chǎn)環(huán)境不會使用。所以，生產(chǎn)的容器環(huán)境數(shù)據(jù)要備份，必然容器中的數(shù)據(jù)是storageclass，也就是說，要么是分布式存儲，要么是集中存儲，而這種存儲，通常都是多副本的，多副本一般是無須備份的。如果，真的一定要備份，請?jiān)谌萜魉婕皯?yīng)用的邏輯層，進(jìn)行備份比較合適，比如如果是Elasticsearch，可以用reindex，把索引數(shù)據(jù)拉到另一個集群。@sabotageoxford研發(fā)工程師：設(shè)計(jì)上需要把容器盡可能做的無狀態(tài)服務(wù)，狀態(tài)保存在外部公共存儲池中或云組件里，這樣才能實(shí)現(xiàn)容器任意調(diào)度，遷移，按需擴(kuò)容縮容。狀態(tài)包括內(nèi)存狀態(tài)（保存在緩存池），數(shù)據(jù)庫（保存在云數(shù)據(jù)庫），文件（保存在分布式文件系統(tǒng)）典型如web服務(wù)的session信息，要么存儲于公共的kv存儲里，要么用類似jwttoken等分布式鑒權(quán)，總之需要避免在容器內(nèi)部保留超過一次交互以外的數(shù)據(jù)。容器最大優(yōu)勢是便于遷移縮放，部署靈活，帶上數(shù)據(jù)就失去了這個遷移能力，所以不是說不能存數(shù)據(jù)，而是從架構(gòu)層面把有狀態(tài)服務(wù)放容器就是錯的。@sf7071某大型銀行云計(jì)算研發(fā)工程師：容器中的數(shù)據(jù)要持久化，一般會掛載宿主機(jī)上的本地存儲，或者分布式存儲，即使容器銷毀了，數(shù)據(jù)仍然在，新建的容器照樣掛在原來的存儲就能恢復(fù)數(shù)據(jù)。在容器云上部署數(shù)據(jù)庫，部署架構(gòu)也要是高可用的集群，集群各節(jié)點(diǎn)間應(yīng)該有數(shù)據(jù)同步機(jī)制。所以，備份容器是沒用的，容器是靜態(tài)的鏡像運(yùn)行起來后的實(shí)例，容器里本身不應(yīng)該存放持久化的數(shù)據(jù)。@jakeyyu三甲醫(yī)院系統(tǒng)架構(gòu)師：容器備份能不能采用快照技術(shù)，如果能夠采用快照技術(shù)，可以考慮直接備份容器，最方便的。5、企業(yè)如何能解決容器數(shù)據(jù)持久化及數(shù)據(jù)備份恢復(fù)問題？@北京不眠夜產(chǎn)品經(jīng)理：通過容器平臺CSI標(biāo)準(zhǔn)接口調(diào)用現(xiàn)有存儲資源。常見存儲有NAS、IP-SAN、Ceph等。通過PV、PVC完成掛載。數(shù)據(jù)備份/恢復(fù)容器平臺側(cè)，實(shí)現(xiàn)對平臺數(shù)據(jù)庫、ETCD的數(shù)據(jù)庫高可用即可。同時，借助傳統(tǒng)備份軟件實(shí)現(xiàn)數(shù)據(jù)備份，增加一層保險。應(yīng)用軟件側(cè)，應(yīng)用程序有鏡像做背書，數(shù)據(jù)庫非容器化，參照傳統(tǒng)數(shù)據(jù)備份方式。如數(shù)據(jù)庫容器化，需要看平臺是否提供相應(yīng)能力。@jakeyyu

三甲醫(yī)院

系統(tǒng)架構(gòu)師：設(shè)置運(yùn)行容器的鏡像進(jìn)行數(shù)據(jù)同步，或者采用容器快照技術(shù)三、容器持久化技術(shù)層面的選擇1、容器使用nfs存儲對接時，能否限制命名空間pv的大小？@rechen招商銀行云計(jì)算架構(gòu)師：這和NFS服務(wù)器的能力有直接關(guān)系，建議選擇商用產(chǎn)品，譬如nexenta。@nawangSmartX產(chǎn)品經(jīng)理：NFSPV配額的限制需要由NFS的服務(wù)端來控制，如在服務(wù)端限制具體共享卷目錄的配額。2、針對企業(yè)容器云持久化存儲方案的存儲需求，如何選擇Kubernetes的哪種卷Volume？@rechen招商銀行云計(jì)算架構(gòu)師：需要綜合根據(jù)IAAS層的存儲服務(wù)的支持和容器云的應(yīng)用存儲需求而定。1）對于有狀態(tài)應(yīng)用的容器應(yīng)用部署，要考慮其對計(jì)算和存儲性能的需求，選擇兼具高性能、安全的靈活性的基礎(chǔ)架構(gòu)硬件設(shè)備。2）對于容器云有狀態(tài)應(yīng)用的數(shù)據(jù)持久化管理，盡量采用CSI插件的方式進(jìn)行管理，無論是塊存儲還是文件存儲，都可以通過CSI提供的iSCSI、NFS等方式去使用。3）應(yīng)用的配置數(shù)據(jù)存儲，主要是用來管理容器，可以借助現(xiàn)有的存儲來實(shí)現(xiàn)，主要是一些配置數(shù)據(jù)和日志記錄等管理數(shù)據(jù)，譬如可以使用ETCD和配置中心來存儲。4）應(yīng)用自身的數(shù)據(jù)存儲,是應(yīng)用真正需要保存的數(shù)據(jù)，需要寫入持久化的Volume數(shù)據(jù)卷，必須確保數(shù)據(jù)能被不同的節(jié)點(diǎn)所訪問，且數(shù)據(jù)存儲接口以文件形式會更適應(yīng)應(yīng)用訪問。5）容器持久化存儲一般可以通過兩種形式來實(shí)現(xiàn):一是本地盤的形式，優(yōu)勢是簡單易用，缺點(diǎn)是難以遷移共享以及伸縮;二是共享存儲集群的形式，優(yōu)勢是數(shù)據(jù)共享，可以提供多種存儲接口，可以彈性伸縮，缺點(diǎn)是架構(gòu)稍顯復(fù)雜。@nawangSmartX產(chǎn)品經(jīng)理：一般來說FileSystem類型的卷更通用，由存儲服務(wù)來負(fù)責(zé)管理文件系統(tǒng)，用戶只需要讀寫指定的目錄即可；但是如果需要更高的靈活性以及性能，可以采用Block類型的卷，在容器中會掛載為一個塊設(shè)備，用戶可以對塊設(shè)備進(jìn)行分區(qū)、創(chuàng)建文件系統(tǒng)、或是直接讀寫都是可以的。對于云原生時代的存儲系統(tǒng)選型，可以參考這篇文章《云原生時代需要什么樣的存儲系統(tǒng)》。3、應(yīng)用容器化后，建議日志是落盤后再采集還是直接通過網(wǎng)絡(luò)發(fā)到外部呢？@Hsia某消費(fèi)金融SA：三種常見日志收集解決方案1）每個app的鏡像中都集成日志收集組件：優(yōu)點(diǎn)：部署方便，kubernetes的yaml文件無須特別配置，可以為每個app自定義日志收集配置缺點(diǎn)：強(qiáng)耦合，不方便應(yīng)用和日志收集組件升級和維護(hù)且會導(dǎo)致鏡像過大2）單獨(dú)創(chuàng)建一個日志收集組件跟app的容器一起運(yùn)行在同一個pod中：優(yōu)點(diǎn)：低耦合，擴(kuò)展性強(qiáng)，方便維護(hù)和升級缺點(diǎn)：需要對kubernetes的yaml文件進(jìn)行單獨(dú)配置，略顯繁瑣3）將所有的Pod的日志都掛載到宿主機(jī)上，每臺主機(jī)上單獨(dú)起一個日志收集Pod：優(yōu)點(diǎn)：完全解耦，性能最高，管理起來最方便缺點(diǎn)：需要統(tǒng)一日志收集規(guī)則，目錄和輸出方式@actor168中國聯(lián)通軟件研究院研發(fā)工程師：可以考慮的方面：1）性能考量涉及到讀寫盤、讀寫網(wǎng)絡(luò)接口的性能問題，涉及到大量容器的讀寫時，IO孰高孰低，是否會因?yàn)槿罩緦?dǎo)致整體程序崩潰等。相比而言，本地落盤讀寫速速度快，但對容器云平臺來說，本地落盤容器日志的處理和收集又相對繁瑣，如：如何動態(tài)搜集日志數(shù)據(jù)、何時清理本地盤數(shù)據(jù)？2）數(shù)據(jù)量考量如果日志量非常大，因?yàn)槿罩緦?dǎo)致的帶寬增加性價比會更低?？紤]以上兩個方面，我們的方案是：日志先本地存儲，后再進(jìn)行轉(zhuǎn)儲搜集。@ruanyirong安全架構(gòu)師：目前我們內(nèi)部推薦的方案是采用雙日志方案，保存兩份日志，可進(jìn)一步保障日志數(shù)據(jù)安全，方便后續(xù)日志分析和故障定位。一方面容器應(yīng)用的日志可以輸入出到標(biāo)準(zhǔn)輸出或文件中，輸出到標(biāo)準(zhǔn)輸出的日志，可通過ELK組合開源工具收集到ElasticSearch集群中供后續(xù)查詢，如果應(yīng)用無法輸出到標(biāo)準(zhǔn)輸出，則使用sidecar方式直接發(fā)送到ElasticSearch集群，通過另外的日志服務(wù)系統(tǒng)提供日志查詢服務(wù)；另一方面日志文件持久化到共享存儲中，支持通過服務(wù)器查看。@JanXCnec系統(tǒng)架構(gòu)師：建議直接網(wǎng)絡(luò)發(fā)出吧，只是占用網(wǎng)絡(luò)io，可以配置單獨(dú)的網(wǎng)卡走日志流量，寫入到es或其他日志存儲分析工具中進(jìn)行分析。如果先落盤，最終還是要采集分析的，對于日志生產(chǎn)端，同時占用網(wǎng)絡(luò)和存儲的io。需要注意的是，不管走網(wǎng)絡(luò)，還是采集落盤在進(jìn)行分析，都聯(lián)系與生產(chǎn)讀寫及網(wǎng)絡(luò)做分開，特別是高負(fù)載的情況。但是網(wǎng)絡(luò)發(fā)出實(shí)現(xiàn)上應(yīng)該比較復(fù)雜，增加節(jié)點(diǎn)，而且萬一有問題，會出現(xiàn)日志丟失的情況。落盤采集簡單可靠，方案成熟，要求不是特別好的話，生產(chǎn)環(huán)境落盤采集感覺會好一些。@Steven99軟件架構(gòu)設(shè)計(jì)師：依我個人觀點(diǎn)，日志直接發(fā)出去。但這個方案通常會復(fù)雜些。要保證日志發(fā)送失敗不會導(dǎo)致服務(wù)異常。就優(yōu)先級別來說，前提是保障業(yè)務(wù)運(yùn)行。日志可以丟，服務(wù)不能受影響。至于選擇哪種方式，考慮自身的能力和整體的架構(gòu)和組件配置。1）落盤是簡單的方式，通常不會帶來額外影響，除非IO有問題。2）在業(yè)務(wù)里面直接發(fā)送日志到外部，比如通過消息方式，需要和消息服務(wù)器建立連接，在服務(wù)內(nèi)需要引入日志消息發(fā)送組件（也就是說需要先封裝日志發(fā)送client組件），連接可能會斷開，網(wǎng)絡(luò)io也可能會是瓶頸，等等，所以整體方案會復(fù)雜化不過這個方案是考慮整體趨勢和融合架構(gòu)的結(jié)果，有效率方面的考慮，日志發(fā)送通常也要考慮批量處理等這個方案有個好處是基于實(shí)時事件處理的事中處理可以構(gòu)建起來，所以說是從整體方案來考慮的。3）容器可以直接打印日志到標(biāo)準(zhǔn)輸出，從標(biāo)準(zhǔn)輸出采集然后發(fā)送到日志中心，目前我們采用的是這種方案。這種方案也相對簡單不過依然需要注意的問題是，日志信息一定要格式標(biāo)準(zhǔn)化，分級，運(yùn)行時可調(diào)整記錄級別。@強(qiáng)哥之神上汽云計(jì)算中心容器云架構(gòu)師及技術(shù)經(jīng)理：容器日志收集有三種方案：第一種，在Node上部署loggingagent，將日志文件轉(zhuǎn)發(fā)到后端存儲里保存起來，這里的核心就在于loggingagent，它一般都會以DaemonSet的方式運(yùn)行在節(jié)點(diǎn)上，然后將宿主機(jī)上的容器日志目錄掛載進(jìn)去，最后由logging-agent把日志轉(zhuǎn)發(fā)出去。舉個例子，我們可以通過Fluentd項(xiàng)目作為宿主機(jī)上的logging-agent，然后把日志轉(zhuǎn)發(fā)到遠(yuǎn)端的ElasticSearch里保存起來供將來進(jìn)行檢索。在Node上部署loggingagent最大的優(yōu)點(diǎn)，在于一個節(jié)點(diǎn)只需要部署一個agent，并且不會對應(yīng)用和Pod有任何侵入性。所以，這個方案，在社區(qū)里是最常用的一種。但是也不難看到，這種方案的不足之處就在于，它要求應(yīng)用輸出的日志，都必須是直接輸出到容器的stdout和stderr里。所以，Kubernetes容器日志方案的第二種，就是對這種特殊情況的一個處理，即:當(dāng)容器的日志只能輸出到某些文件里的時候，我們可以通過一個sidecar容器把這些日志文件重新輸出到sidecar的stdout和stderr上，這樣就能夠繼續(xù)使用第一種方案了。在這種情況下，你用kubectllogs命令是看不到應(yīng)用的任何日志的。而且最常用的方案一，也是沒辦法使用的。那么這個時候，我們就可以為這個Pod添加兩個sidecar容器，分別將上述兩個日志文件里的內(nèi)容重新以stdout和stderr的方式輸出出來。這時候，你就可以通過kubectllogs命令查看這兩個sidecar容器的日志，間接看到應(yīng)用的日志內(nèi)容了。由于sidecar跟主容器之間是共享Volume的，所以這里的sidecar方案的額外性能損耗并不高，也就是多占用一點(diǎn)CPU和內(nèi)存罷了。但需要注意的是，這時候，宿主機(jī)上實(shí)際上會存在兩份相同的日志文件:一份是應(yīng)用自己寫入的;另一份則是sidecar的stdout和stderr對應(yīng)的JSON文件。這對磁盤是很大的浪費(fèi)。所以說，除非萬不得已或者應(yīng)用容器完全不可能被修改，否則我還是建議你直接使用方案一，或者直接使用下面的第三種方案。第三種方案，就是通過一個sidecar容器，直接把應(yīng)用的日志文件發(fā)送到遠(yuǎn)程存儲里面去。也就是相當(dāng)于把方案一里的loggingagent，放在了應(yīng)用Pod里。在這種方案里，你的應(yīng)用還可以直接把日志輸出到固定的文件里而不是stdout，你的logging-agent還可以使用fluentd，后端存儲還可以是ElasticSearch。只不過，fluentd的輸入源，變成了應(yīng)用的日志文件。一般來說，我們會把fluentd的輸入源配置保存在一個ConfigMap里。Fluentd容器使用的輸入源，就是通過引用這個ConfigMap來指定的。需要注意的是，這種方案雖然部署簡單，并且對宿主機(jī)非常友好，但是這個sidecar容器很可能會消耗較多的資源，甚至拖垮應(yīng)用容器。并且，由于日志還是沒有輸出到stdout上，所以你通過kubectllogs是看不到任何日志輸出的。綜合對比以上三種方案，我比較建議你將應(yīng)用日志輸出到stdout和stderr，然后通過在宿主機(jī)上部署logging-agent的方式來集中處理日志。這種方案不僅管理簡單，kubectllogs也可以用，而且可靠性高，并且宿主機(jī)本身，很可能就自帶了rsyslogd等非常成熟的日志收集組件來供你使用。除此之外，還有一種方式就是在編寫應(yīng)用的時候