CobiNet(寧波)推薦文章：

近年來，開源(yuan)技術逐(zhu)漸(jian)成為云(yun)計(ji)算發(fa)展的重要支(zhi)撐(cheng)和導向(xiang)，改變了以往的信息(xi)技術進化(hua)模式，引(yin)(yin)領(ling)軟件技術標準的發(fa)展和創(chuang)新(xin)，深刻影響著(zhu)整個信息(xi)技術產(chan)業(ye)的發(fa)展格局。為進一步探(tan)索(suo)我國云(yun)計(ji)算開源(yuan)技術發(fa)展模式，加(jia)速云(yun)計(ji)算與各(ge)行業(ye)的深度融合，更好地(di)發(fa)揮(hui)云(yun)計(ji)算在(zai)經濟社(she)會創(chuang)新(xin)發(fa)展中的支(zhi)撐(cheng)和引(yin)(yin)領(ling)作用，促(cu)進我國云(yun)計(ji)算產(chan)業(ye)快速、健(jian)康發(fa)展。

由(you)中國(guo)信息(xi)通(tong)(tong)信研究(jiu)院主辦、中國(guo)通(tong)(tong)信標準化協(xie)會支持(chi)的(de)"OSCAR云計算開源(yuan)產業(ye)(ye)大(da)會"將于2018年3月21日(ri)－22日(ri)在(zai)國(guo)家會議中心(xin)舉行(xing)。在(zai)22日(ri)下午(wu)的(de)工業(ye)(ye)使用開源(yuan)論壇(tan)上，北京中油瑞飛信息(xi)技術(shu)有(you)限公司(si)資深架構師(shi)孫杰就(jiu)《"容(rong)器技術(shu)在(zai)企(qi)業(ye)(ye)落(luo)地的(de)探(tan)索(suo)和實踐"》進行(xing)了演(yan)講！

以下為演講實錄：

孫杰： 當今容(rong)(rong)器(qi)(qi)(qi)技(ji)術(shu)被廣泛關注，已經有(you)越來越多的(de)(de)企(qi)業(ye)開(kai)始布局或者已經采用(yong)容(rong)(rong)器(qi)(qi)(qi)技(ji)術(shu)來構建自(zi)己(ji)的(de)(de)云基礎設施。很多傳(chuan)統行(xing)業(ye)和互聯網企(qi)業(ye)相比在容(rong)(rong)器(qi)(qi)(qi)技(ji)術(shu)方(fang)面起(qi)步(bu)稍晚，但近兩年隨著容(rong)(rong)器(qi)(qi)(qi)關注度的(de)(de)空前火(huo)熱，企(qi)業(ye)進(jin)步(bu)也(ye)很快，大(da)力推進(jin)容(rong)(rong)器(qi)(qi)(qi)相關能力的(de)(de)建設。基于 Docker 的(de)(de)容(rong)(rong)器(qi)(qi)(qi)，是一種(zhong)更輕量級(ji)的(de)(de)虛擬化，我(wo)們稱之為 CaaS，就是容(rong)(rong)器(qi)(qi)(qi)級(ji)服務。它(ta)涵蓋了 IaaS 跟 PaaS 兩者的(de)(de)優勢，可以(yi)(yi)解決應用(yong)的(de)(de)部署、開(kai)發(fa)運(yun)維、微服務這些問題，而且能夠更快的(de)(de)加速業(ye)務的(de)(de)交付。容(rong)(rong)器(qi)(qi)(qi)可以(yi)(yi)說它(ta)是一種(zhong)先(xian)進(jin)的(de)(de)技(ji)術(shu)，但怎么(me)(me)把它(ta)變(bian)成(cheng)一種(zhong)先(xian)進(jin)的(de)(de)生產力，企(qi)業(ye)能不(bu)能把這個技(ji)術(shu)給用(yong)好，怎么(me)(me)用(yong)好，大(da)概(gai)有(you)這樣(yang)九個問題，這也(ye)是我(wo)們長期的(de)(de)思考和探(tan)索實踐(jian)。

企業要用正確的姿態擁抱(bao)容器并且(qie)使用好(hao)容器，需(xu)要在(zai)應用容器技術時考(kao)慮清楚以下九個關(guan)鍵問(wen)題：

1、企業容器云方案(an)設計需要遵循什么(me)原則？

2、容器(qi)云技術產(chan)品如何選型？

3、容器云的(de)網絡應該如何設計(ji)？

4、容器的持久化存儲方案如何選(xuan)擇和設計？

5、容器云上日志集中管理如何設計？

6、容器(qi)應用的監控(kong)方案(an)如何設計？

7、容器云(yun)的多租戶和權限如何設計？

8、容(rong)器與 OpenStack 和(he) Kubernetes 集(ji)成的能力？

9、容器云如何實現高可(ke)用和跨(kua)區部署？

那么，首(shou)先第一(yi)個(ge)問(wen)題企業容器云方案設(she)計需要遵循(xun)什么原則？

首先，我(wo)們(men)(men)要(yao)明確(que)企(qi)業(ye)(ye)(ye)上容器(qi)云的(de)(de)目的(de)(de)，容器(qi)是(shi)為業(ye)(ye)(ye)務(wu)服(fu)務(wu)的(de)(de)，任何技(ji)術都是(shi)為了能夠(gou)更(geng)好(hao)的(de)(de)服(fu)務(wu)業(ye)(ye)(ye)務(wu)，這(zhe)是(shi)我(wo)們(men)(men)的(de)(de)出發點。其次，結合業(ye)(ye)(ye)務(wu)特點選擇合適的(de)(de)容器(qi)框架(jia)，比如(ru)我(wo)們(men)(men)的(de)(de)業(ye)(ye)(ye)務(wu)本身是(shi)不(bu)是(shi)可以基于新(xin)型微服(fu)務(wu)架(jia)構進行改(gai)造，業(ye)(ye)(ye)務(wu)是(shi)不(bu)是(shi)具(ju)有變(bian)化快(kuai)(kuai)、彈性大、更(geng)新(xin)迭代快(kuai)(kuai)等(deng)(deng)特點。還有要(yao)和(he)已(yi)(yi)有系(xi)(xi)統(tong)較(jiao)好(hao)地對接整(zheng)合，在(zai)上容器(qi)之前，企(qi)業(ye)(ye)(ye)通常都已(yi)(yi)經有比較(jiao)成熟和(he)穩定的(de)(de)其他 IT 系(xi)(xi)統(tong)，例如(ru)網絡系(xi)(xi)統(tong)、集中監控系(xi)(xi)統(tong)、安(an)全防(fang)護系(xi)(xi)統(tong)等(deng)(deng)。

為避免(mian)重復建(jian)設，同(tong)時也(ye)為了(le)容(rong)器(qi)(qi)平(ping)臺(tai)能(neng)夠更容(rong)易(yi)被接受和使(shi)用(yong)，應讓容(rong)器(qi)(qi)平(ping)臺(tai)融(rong)入企業(ye)原有的整個 IT 系統(tong)，而不是另起爐灶重新建(jian)設。容(rong)器(qi)(qi)平(ping)臺(tai)要承(cheng)載(zai)生產業(ye)務，也(ye)需要滿足(zu)安(an)全(quan)的監管合規要求，例如隔離不同(tong)安(an)全(quan)等級的應用(yong)、支持對應用(yong)容(rong)器(qi)(qi)的安(an)全(quan)漏洞(dong)掃描、安(an)全(quan)有效的防火(huo)墻策略(lve)管理等。生產環境的業(ye)務要求高(gao)可(ke)用(yong)性、連(lian)續性，還應該考慮(lv)整個容(rong)器(qi)(qi)應用(yong)層面(mian)的高(gao)可(ke)用(yong)性和數據連(lian)續性、安(an)全(quan)可(ke)靠(kao)。

建(jian)設容器平臺的(de)目的(de)是(shi)為應用(yong)帶來靈活、彈性(xing)、節省資源等優勢，這要(yao)求(qiu)應用(yong)最(zui)好具備微服(fu)務架構、無狀態化等特點(dian)，讓這些優勢更好地發揮。但不(bu)適合容器化的(de)應用(yong)也不(bu)能(neng)(neng)勉強，否則容器平臺建(jian)設后，如果(guo)(guo)不(bu)能(neng)(neng)給應用(yong)和業務帶來預期的(de)價值，不(bu)僅浪費(fei)了大量企業投入，還使(shi)得容器平臺的(de)價值得不(bu)到(dao)認(ren)可。這是(shi)每一個投入大量精力(li)和熱情進行容器平臺建(jian)設的(de)人最(zui)不(bu)愿意(yi)看(kan)到(dao)的(de)結果(guo)(guo)。

容(rong)器(qi)本身的(de)(de)特點和(he)好處(chu)，我就不復述了，大(da)(da)家都比較(jiao)清(qing)楚，容(rong)器(qi)一個是低成本、輕量級的(de)(de)，而且(qie)(qie)便于遷移，啟動(dong)的(de)(de)時候特別快。它(ta)直接可以(yi)構建在(zai)物理主(zhu)機(ji)的(de)(de)OS系統上(shang)，像以(yi)前的(de)(de)虛(xu)擬化可能(neng)要多一層，然后在(zai)這(zhe)(zhe)之上(shang)才會(hui)有你的(de)(de)虛(xu)擬機(ji)的(de)(de)操(cao)作系統。容(rong)器(qi)和(he)虛(xu)擬機(ji)占用CPU資源的(de)(de)情(qing)況對比，像Docker大(da)(da)概在(zai)1.6%，像KVM占用資源大(da)(da)概14.6%，占用的(de)(de)內存資源對比，Docker平均(jun)每個容(rong)器(qi)只有46兆，KVM基(ji)本上(shang)185兆，同樣(yang)(yang)的(de)(de)規(gui)格(ge)，Docker的(de)(de)性能(neng)2倍于你的(de)(de)KVM.Docker的(de)(de)鏡像非(fei)常小，而虛(xu)擬機(ji)的(de)(de)鏡像基(ji)本上(shang)在(zai)3G、4G，甚至像Windows這(zhe)(zhe)樣(yang)(yang)的(de)(de)都在(zai)5G、6G.這(zhe)(zhe)樣(yang)(yang)來看(kan)容(rong)器(qi)有比較(jiao)大(da)(da)的(de)(de)資源節省，而且(qie)(qie)性能(neng)又提(ti)高了。

應用容器(qi)技術帶(dai)(dai)來的(de)挑戰和改變，大家可(ke)(ke)(ke)以(yi)看到，容器(qi)帶(dai)(dai)來的(de)改變，第一，它可(ke)(ke)(ke)以(yi)直接通過鏡像封(feng)裝你的(de)應用，可(ke)(ke)(ke)以(yi)根據(ju)你的(de)dockerfile命(ming)令行(xing)直接構建(jian)你所(suo)需(xu)要的(de)應用，提(ti)供了一種比較廣泛(fan)認(ren)可(ke)(ke)(ke)的(de)交(jiao)付協議。第二，資(zi)源的(de)提(ti)供者可(ke)(ke)(ke)以(yi)無差別(bie)的(de)對待你的(de)資(zi)源需(xu)求，為構建(jian)統(tong)一的(de)IT支撐平(ping)臺提(ti)供了可(ke)(ke)(ke)行(xing)性。另(ling)外(wai)就是研發流程自動(dong)化(hua)（CI）、 應用模式(shi)化(hua)（微服務、彈性）、 標準化(hua)、自動(dong)化(hua)，這些(xie)都可(ke)(ke)(ke)以(yi)做到更快的(de)響(xiang)應業務的(de)變化(hua)。

容器面臨的(de)主要(yao)挑戰(zhan)，就是平臺(tai)化才能產生(sheng)效(xiao)益，但是標準不太統一。還(huan)有就是平臺(tai)化需要(yao)侵入應用(yong)結(jie)構。大量傳統應用(yong)遺產需要(yao)改造(zao)，這是比較消(xiao)耗(hao)人力和資源的(de)。

第二(er)個，容(rong)器云技(ji)(ji)術(shu)(shu)產品如何(he)選型(xing)？技(ji)(ji)術(shu)(shu)選型(xing)這個問題有很(hen)多復(fu)雜(za)的影響(xiang)因素，包括(kuo)技(ji)(ji)術(shu)(shu)和非技(ji)(ji)術(shu)(shu)兩方面，不同的組織情況下也不盡相同。

一個企(qi)業(ye)在應(ying)用新技(ji)術前，還需(xu)要(yao)考慮 IT 部門自(zi)身(shen)的技(ji)術能力(li)，包括開發能力(li)、運維能力(li)，同時對(dui)自(zi)身(shen)業(ye)務系(xi)統從(cong)開發平臺(tai)、開發過程、開發規范等(deng)有決(jue)定(ding)能力(li)。如果企(qi)業(ye)自(zi)身(shen)的開發和運維能力(li)不(bu)強，則采(cai)用成熟的 PCF、OpenShift 等(deng)方案(an)是不(bu)錯的選擇。如果考慮現有系(xi)統對(dui)接需(xu)求，包括監(jian)控、網絡、安全需(xu)求等(deng)，特別(bie)是現有網絡架構對(dui)容器的網絡方案(an)有較大影響時，應(ying)該(gai)考慮使用 Kubernetes、Mesos、Swarm 等(deng)開源方案(an)更便于(yu)定(ding)制(zhi)，也能較好的融入現有 IT 系(xi)統。

Kubernetes、Mesos、Swarm 這三個開源方案都是(shi)行業(ye)內比較火熱的(de)(de)(de)資源編(bian)(bian)排(pai)解決(jue)方案，但(dan)它們(men)各自的(de)(de)(de)立足點(dian)各有千秋。從應用的(de)(de)(de)發布環節來比較：Docker 的(de)(de)(de) Swarm 功能(neng)，以及 Kubenetes 的(de)(de)(de)編(bian)(bian)排(pai)，Mesos 的(de)(de)(de)調(diao)度管理(li)，很難直接決(jue)出高(gao)低。換(huan)言之，如果(guo)加上企(qi)業(ye)級(ji)應用場景，來輔(fu)佐容器技術選型(xing)，則會顯得更有意義(yi)。

企業規模不大，應用(yong)不是太(tai)復雜

這時 Docker Swarm Mode 還是(shi)比較好用(yong)的(de)(de)，集群的(de)(de)維護不(bu)需(xu)要 Zookeeper，Etcd 自(zi)己內置(zhi)，命令行和 Docker 一樣用(yong)起來(lai)順手，服務發現和 DNS 是(shi)內置(zhi)的(de)(de)，Overlay 網絡是(shi)內置(zhi)的(de)(de)。

企業規模大一些、應用夠(gou)復雜

這時(shi)集群規模(mo)有(you)幾百個(ge)(ge)節(jie)點(dian)，很多人就不愿意使(shi)用 Docker Swarm Mode 了，而是用 Mesos 和 Marathon.因為(wei) Mesos 是一(yi)(yi)個(ge)(ge)非常優秀的(de)調度(du)器，它的(de)雙(shuang)層調度(du)機制(zhi)可以使(shi)得集群規模(mo)大很多，Mesos 的(de)優勢在(zai)于第一(yi)(yi)層調度(du)先將整個(ge)(ge) Node 分(fen)配給一(yi)(yi)個(ge)(ge) Framework，Framework 的(de)調度(du)器面(mian)對的(de)集群規模(mo)小很多，然(ran)后在(zai)里面(mian)進行二次(ci)調度(du)。如果有(you)多個(ge)(ge) Framework，例如有(you)多個(ge)(ge) Marathon，則可以并行調度(du)不沖(chong)突(tu)，同時(shi) Mesos 在(zai)傳統數據計算方(fang)面(mian)擁有(you)較(jiao)多的(de)案例，相信(xin)也是企業選型(xing)時(shi)考慮的(de)要素之(zhi)一(yi)(yi)。

企業(ye)規模大、業(ye)務復雜、應用粒度更(geng)細

這(zhe)時 Kubenetes 就(jiu)更(geng)適合(he)了，因(yin)為 Kubernetes 模(mo)塊劃(hua)分得更(geng)細更(geng)多，比 Marathon 和(he) Mesos 功能豐富，而且模(mo)塊之(zhi)間完(wan)全的(de)(de)松耦合(he)，可(ke)(ke)以(yi)非常方(fang)便地進行定制(zhi)化。還有就(jiu)是 Kubernetes 提供了強大(da)的(de)(de)自動化機制(zhi)，從而使后期的(de)(de)系(xi)統運(yun)維難度和(he)運(yun)維成本(ben)大(da)幅降低(di)，而且 Kubernetes 社區的(de)(de)熱度，可(ke)(ke)以(yi)使得使用 Kubernetes 的(de)(de)公司能夠很快地得到幫助，方(fang)便問題和(he) Bug 的(de)(de)解決。

第三個問題，關于容器(qi)(qi)云(yun)的(de)(de)(de)網絡設(she)計，這一(yi)塊(kuai)(kuai)是關鍵。因為大(da)家知道容器(qi)(qi)它最早是基于單主(zhu)機這種(zhong)來設(she)計的(de)(de)(de)。當容器(qi)(qi)技術逐步成(cheng)熟(shu)(shu)之后(hou)，收(shou)購了一(yi)家網絡解決方(fang)案公司 Socketplane，將原有的(de)(de)(de)網絡部(bu)分(fen)抽(chou)離，單獨成(cheng)了 Docker 的(de)(de)(de)網絡庫，即 libnetwork.libnetwork 實現了 5 種(zhong)驅(qu)動，通過插件的(de)(de)(de)形式允(yun)許用戶根據自己的(de)(de)(de)需求來實現 network driver，但 libnetwork 組件只是將 Docker 平臺中(zhong)的(de)(de)(de)網絡子系(xi)統模塊(kuai)(kuai)化為一(yi)個獨立庫的(de)(de)(de)簡單嘗(chang)試，離成(cheng)熟(shu)(shu)和完(wan)善還有一(yi)段距離。

隨著容(rong)器技術在(zai)企業生產系統的逐(zhu)步落地，用戶對于容(rong)器云的網絡特性要(yao)求(qiu)也越(yue)來越(yue)高(gao)，跨(kua)主(zhu)機容(rong)器間(jian)的網絡互通已經(jing)成為最基(ji)本的要(yao)求(qiu)。跨(kua)主(zhu)機的容(rong)器網絡解決方案不(bu)外(wai)乎三(san)大類：

隧道方案

比如(ru) Flannel 的(de)(de)(de) VxLan，特(te)點是(shi)對底層的(de)(de)(de)網絡(luo)沒(mei)有過高的(de)(de)(de)要(yao)求(qiu)，一(yi)般來說(shuo)只(zhi)要(yao)是(shi)三(san)層可達就(jiu)可以，只(zhi)要(yao)是(shi)在一(yi)個(ge)(ge)三(san)層可達網絡(luo)里，就(jiu)能構建出一(yi)個(ge)(ge)基于隧道的(de)(de)(de)容器網絡(luo)。不過問題(ti)也(ye)很明(ming)顯(xian)，一(yi)個(ge)(ge)得(de)到(dao)大(da)家共(gong)識(shi)的(de)(de)(de)是(shi)隨著節點規(gui)模(mo)的(de)(de)(de)增長、復雜度會提(ti)升(sheng)，而且出了網絡(luo)問題(ti)跟蹤(zong)起來比較麻(ma)煩，大(da)規(gui)模(mo)集群(qun)情況下，這(zhe)是(shi)需(xu)要(yao)考慮的(de)(de)(de)一(yi)個(ge)(ge)點。

路由方案

路(lu)由(you)技術從三層(ceng)實現跨主機容(rong)器(qi)互通，沒有(you) NAT，效率比較高(gao)，和(he)目(mu)前(qian)的網(wang)絡能夠(gou)融合在(zai)一(yi)起，每(mei)一(yi)個(ge)容(rong)器(qi)都可以(yi)像虛擬機一(yi)樣(yang)分配一(yi)個(ge)業務(wu)(wu)的 IP.但路(lu)由(you)網(wang)絡也有(you)問題，路(lu)由(you)網(wang)絡對現有(you)網(wang)絡設(she)備影(ying)響比較大(da)，路(lu)由(you)器(qi)的路(lu)由(you)表應該有(you)空(kong)間限制，一(yi)般是兩(liang)三萬條，而容(rong)器(qi)的大(da)部(bu)分應用(yong)場(chang)景是運行微服務(wu)(wu)，數量集很大(da)。如果(guo)幾萬新的容(rong)器(qi) IP 沖(chong)擊到(dao)路(lu)由(you)表里，會(hui)導致下(xia)層(ceng)的物(wu)理設(she)備沒辦法承受；而且每(mei)一(yi)個(ge)容(rong)器(qi)都分配一(yi)個(ge)業務(wu)(wu) IP，業務(wu)(wu) IP 會(hui)很快消耗。

VLAN

所有容器和(he)物理機(ji)在同(tong)一個 VLAN 中。

綜合來看Calico 的(de)(de)(de)方(fang)(fang)案(an)(an)和(he)基于(yu) HOST 的(de)(de)(de)網絡解(jie)決(jue)方(fang)(fang)案(an)(an)性(xing)能(neng)較好。但基于(yu) HOST 的(de)(de)(de)端口沖突和(he)網絡資(zi)源競爭比(bi)較麻煩，相(xiang)對來說(shuo) Calico 的(de)(de)(de)是純三層(ceng)的(de)(de)(de) SDN 實(shi)現，它基于(yu) BPG 協(xie)議和(he) Linux 自己的(de)(de)(de)路由轉(zhuan)發機制，不(bu)依賴特(te)殊(shu)硬件，沒有使用(yong) NAT 或 Tunnel 等(deng)技術。它能(neng)夠方(fang)(fang)便的(de)(de)(de)部署(shu)在(zai)物理(li)服(fu)務器、虛擬機（如 OpenStack）或者(zhe)容器環境下，同時它自帶的(de)(de)(de)基于(yu) Iptables 的(de)(de)(de) ACL 管理(li)組件非(fei)常靈活，能(neng)夠滿足比(bi)較復雜(za)的(de)(de)(de)企業安(an)全隔離需求。關于(yu)容器應(ying)用(yong)的(de)(de)(de)網絡隔離還(huan)有多種(zhong)解(jie)決(jue)方(fang)(fang)案(an)(an)，基本上就是把不(bu)同的(de)(de)(de)應(ying)用(yong)容器放置在(zai)不(bu)同的(de)(de)(de) vlan/vxlan 中，通過讓不(bu)同的(de)(de)(de) vlan/vxlan 不(bu)能(neng)互訪而實(shi)現隔離。企業里應(ying)用(yong)目前是 OVS/Linux-bridge +VLAN 方(fang)(fang)案(an)(an)的(de)(de)(de)比(bi)較多，但長遠看來 Calico 方(fang)(fang)案(an)(an)前景(jing)不(bu)錯。

第四個(ge)問題(ti)就(jiu)(jiu)是(shi)容(rong)(rong)(rong)(rong)器(qi)(qi)(qi)(qi)(qi)的(de)(de)(de)(de)(de)(de)(de)(de)持(chi)(chi)久(jiu)化(hua)(hua)存儲(chu)(chu)(chu)如何設計(ji)(ji)？在(zai)(zai)(zai)(zai)討論持(chi)(chi)久(jiu)化(hua)(hua)存儲(chu)(chu)(chu)之前，首先聲明(ming)，運(yun)行(xing)容(rong)(rong)(rong)(rong)器(qi)(qi)(qi)(qi)(qi)并不(bu)意味(wei)著完全摒棄(qi)數(shu)(shu)(shu)據(ju)(ju)持(chi)(chi)久(jiu)化(hua)(hua)。在(zai)(zai)(zai)(zai)容(rong)(rong)(rong)(rong)器(qi)(qi)(qi)(qi)(qi)中(zhong)(zhong)運(yun)行(xing)的(de)(de)(de)(de)(de)(de)(de)(de)應(ying)用(yong)(yong)(yong)，應(ying)用(yong)(yong)(yong)真(zhen)正需要保存的(de)(de)(de)(de)(de)(de)(de)(de)數(shu)(shu)(shu)據(ju)(ju)，也可(ke)(ke)以(yi)寫入(ru)持(chi)(chi)久(jiu)化(hua)(hua)的(de)(de)(de)(de)(de)(de)(de)(de) Volume 數(shu)(shu)(shu)據(ju)(ju)卷(juan)(juan)。在(zai)(zai)(zai)(zai)這個(ge)方(fang)案中(zhong)(zhong)，持(chi)(chi)久(jiu)層(ceng)產(chan)生價值，不(bu)是(shi)通(tong)(tong)過(guo)彈性，而(er)是(shi)通(tong)(tong)過(guo)靈活可(ke)(ke)編程，例如通(tong)(tong)過(guo)優秀(xiu)設計(ji)(ji)的(de)(de)(de)(de)(de)(de)(de)(de) API 來擴展存儲(chu)(chu)(chu)。目(mu)前，主要支(zhi)(zhi)持(chi)(chi) Docker 或 Kubernetes 的(de)(de)(de)(de)(de)(de)(de)(de) Volume.Docker 發布(bu)了(le)容(rong)(rong)(rong)(rong)器(qi)(qi)(qi)(qi)(qi)卷(juan)(juan)插件規范(fan)，允許(xu)第三方(fang)廠商的(de)(de)(de)(de)(de)(de)(de)(de)數(shu)(shu)(shu)據(ju)(ju)卷(juan)(juan)在(zai)(zai)(zai)(zai) Docker 引擎中(zhong)(zhong)提供數(shu)(shu)(shu)據(ju)(ju)服務(wu)。這種機(ji)制意味(wei)著外置(zhi)存儲(chu)(chu)(chu)可(ke)(ke)以(yi)超過(guo)容(rong)(rong)(rong)(rong)器(qi)(qi)(qi)(qi)(qi)的(de)(de)(de)(de)(de)(de)(de)(de)生命周期而(er)獨立存在(zai)(zai)(zai)(zai)，而(er)且各種存儲(chu)(chu)(chu)設備(bei)只要滿(man)足(zu)接口(kou) API 標準，就(jiu)(jiu)可(ke)(ke)接入(ru) Docker 容(rong)(rong)(rong)(rong)器(qi)(qi)(qi)(qi)(qi)的(de)(de)(de)(de)(de)(de)(de)(de)運(yun)行(xing)平臺(tai)中(zhong)(zhong)。現(xian)有(you)的(de)(de)(de)(de)(de)(de)(de)(de)各種存儲(chu)(chu)(chu)可(ke)(ke)以(yi)通(tong)(tong)過(guo)簡單(dan)的(de)(de)(de)(de)(de)(de)(de)(de)驅動程序(xu)封裝，從而(er)實現(xian)和(he) Docker 容(rong)(rong)(rong)(rong)器(qi)(qi)(qi)(qi)(qi)的(de)(de)(de)(de)(de)(de)(de)(de)對接。另外一個(ge)就(jiu)(jiu)是(shi)K8S 的(de)(de)(de)(de)(de)(de)(de)(de)數(shu)(shu)(shu)據(ju)(ju)卷(juan)(juan)。K8S 的(de)(de)(de)(de)(de)(de)(de)(de)每個(ge) Pod 包含一個(ge)或多(duo)(duo)個(ge)容(rong)(rong)(rong)(rong)器(qi)(qi)(qi)(qi)(qi)。Pod 可(ke)(ke)部署在(zai)(zai)(zai)(zai)集(ji)(ji)群的(de)(de)(de)(de)(de)(de)(de)(de)任意節(jie)點中(zhong)(zhong)，存儲(chu)(chu)(chu)設備(bei)可(ke)(ke)通(tong)(tong)過(guo)數(shu)(shu)(shu)據(ju)(ju)卷(juan)(juan)提供給 Pod 的(de)(de)(de)(de)(de)(de)(de)(de)容(rong)(rong)(rong)(rong)器(qi)(qi)(qi)(qi)(qi)使(shi)用(yong)(yong)(yong)。為(wei)了(le)不(bu)綁定特定的(de)(de)(de)(de)(de)(de)(de)(de)容(rong)(rong)(rong)(rong)器(qi)(qi)(qi)(qi)(qi)技(ji)術，K8S 沒有(you)使(shi)用(yong)(yong)(yong) Docker 的(de)(de)(de)(de)(de)(de)(de)(de) Volume 機(ji)制，而(er)是(shi)制定了(le)自己的(de)(de)(de)(de)(de)(de)(de)(de)通(tong)(tong)用(yong)(yong)(yong)數(shu)(shu)(shu)據(ju)(ju)卷(juan)(juan)插件規范(fan)，以(yi)配合不(bu)同的(de)(de)(de)(de)(de)(de)(de)(de)容(rong)(rong)(rong)(rong)器(qi)(qi)(qi)(qi)(qi)運(yun)行(xing)來使(shi)用(yong)(yong)(yong)（如 Docker 和(he) rkt）。數(shu)(shu)(shu)據(ju)(ju)卷(juan)(juan)分(fen)為(wei)共(gong)(gong)(gong)享(xiang)和(he)非(fei)共(gong)(gong)(gong)享(xiang)兩種類型(xing)，其中(zhong)(zhong)非(fei)共(gong)(gong)(gong)享(xiang)型(xing)只能(neng)被某個(ge)節(jie)點掛載(zai)使(shi)用(yong)(yong)(yong)（如 iSCSI、AWS EBS 等(deng)(deng)網(wang)絡(luo)塊(kuai)(kuai)設備(bei)）；共(gong)(gong)(gong)享(xiang)型(xing)則(ze)可(ke)(ke)讓不(bu)同節(jie)點上的(de)(de)(de)(de)(de)(de)(de)(de)多(duo)(duo)個(ge) Pod 同時使(shi)用(yong)(yong)(yong)（如 NFS、GlusterFS 等(deng)(deng)網(wang)絡(luo)文件系統，以(yi)及可(ke)(ke)支(zhi)(zhi)持(chi)(chi)多(duo)(duo)方(fang)讀寫的(de)(de)(de)(de)(de)(de)(de)(de)塊(kuai)(kuai)設備(bei)）。對有(you)狀(zhuang)態的(de)(de)(de)(de)(de)(de)(de)(de)應(ying)用(yong)(yong)(yong)來說(shuo)，共(gong)(gong)(gong)享(xiang)型(xing)的(de)(de)(de)(de)(de)(de)(de)(de)卷(juan)(juan)存儲(chu)(chu)(chu)能(neng)夠很方(fang)便地支(zhi)(zhi)持(chi)(chi)容(rong)(rong)(rong)(rong)器(qi)(qi)(qi)(qi)(qi)在(zai)(zai)(zai)(zai)集(ji)(ji)群各節(jie)點之間的(de)(de)(de)(de)(de)(de)(de)(de)遷移(yi)。為(wei)了(le)給容(rong)(rong)(rong)(rong)器(qi)(qi)(qi)(qi)(qi)提供更細粒度的(de)(de)(de)(de)(de)(de)(de)(de)卷(juan)(juan)管(guan)理(li)(li)，K8s 增加了(le)持(chi)(chi)久(jiu)化(hua)(hua)卷(juan)(juan)的(de)(de)(de)(de)(de)(de)(de)(de)功能(neng)，把外置(zhi)存儲(chu)(chu)(chu)作為(wei)資源池，由平臺(tai)管(guan)理(li)(li)并提供給整個(ge)集(ji)(ji)群使(shi)用(yong)(yong)(yong)。K8S 的(de)(de)(de)(de)(de)(de)(de)(de)卷(juan)(juan)管(guan)理(li)(li)架構使(shi)用(yong)(yong)(yong)存儲(chu)(chu)(chu)可(ke)(ke)用(yong)(yong)(yong)標準的(de)(de)(de)(de)(de)(de)(de)(de)接入(ru)方(fang)式，并且通(tong)(tong)過(guo)接口(kou)暴露存儲(chu)(chu)(chu)設備(bei)所支(zhi)(zhi)持(chi)(chi)的(de)(de)(de)(de)(de)(de)(de)(de)能(neng)力，在(zai)(zai)(zai)(zai)容(rong)(rong)(rong)(rong)器(qi)(qi)(qi)(qi)(qi)任務(wu)調度等(deng)(deng)方(fang)面實現(xian)了(le)自動化(hua)(hua)管(guan)理(li)(li)。

從2017年3月1號開始(shi)，容器出了兩(liang)個(ge)版(ban)本，一個(ge)是(shi)Docker的(de)(de)CE，一個(ge)是(shi)Docker的(de)(de)EE，Docker的(de)(de)EE是(shi)企(qi)業(ye)版(ban)，也可(ke)以說是(shi)商(shang)業(ye)版(ban)，另外(wai)一個(ge)EE是(shi)它(ta)(ta)的(de)(de)社區版(ban)，也就是(shi)開源版(ban)。它(ta)(ta)的(de)(de)CE和(he)EE版(ban)里的(de)(de)數據卷都已(yi)經可(ke)以支持(chi)持(chi)久化的(de)(de)存儲了。

第5個(ge)問(wen)題日(ri)(ri)(ri)志(zhi)(zhi)(zhi)的(de)(de)(de)(de)集(ji)中(zhong)(zhong)(zhong)(zhong)管(guan)理(li)。容(rong)(rong)器(qi)(qi)常被(bei)用(yong)(yong)來(lai)運行(xing)需(xu)要快(kuai)速故(gu)障遷(qian)移、彈(dan)(dan)性伸縮的(de)(de)(de)(de)應(ying)(ying)用(yong)(yong)或(huo)(huo)微服(fu)務，因此容(rong)(rong)器(qi)(qi)中(zhong)(zhong)(zhong)(zhong)運行(xing)的(de)(de)(de)(de)應(ying)(ying)用(yong)(yong)隨著(zhu)遷(qian)移、彈(dan)(dan)性伸縮的(de)(de)(de)(de)發(fa)生(sheng)，應(ying)(ying)用(yong)(yong)日(ri)(ri)(ri)志(zhi)(zhi)(zhi)很可(ke)能會在不同的(de)(de)(de)(de)運行(xing)節點(dian)(dian)(dian)中(zhong)(zhong)(zhong)(zhong)產生(sheng)，這對容(rong)(rong)器(qi)(qi)應(ying)(ying)用(yong)(yong)的(de)(de)(de)(de)日(ri)(ri)(ri)志(zhi)(zhi)(zhi)監控和(he)問(wen)題排查(cha)帶來(lai)了很大(da)的(de)(de)(de)(de)麻煩。相對來(lai)說，和(he)大(da)多數傳統(tong)(tong)(tong)應(ying)(ying)用(yong)(yong)把(ba)日(ri)(ri)(ri)志(zhi)(zhi)(zhi)寫(xie)在本地文件(jian)系(xi)統(tong)(tong)(tong)不同的(de)(de)(de)(de)是(shi)，容(rong)(rong)器(qi)(qi)應(ying)(ying)用(yong)(yong)需(xu)要考慮(lv)把(ba)日(ri)(ri)(ri)志(zhi)(zhi)(zhi)進行(xing)集(ji)中(zhong)(zhong)(zhong)(zhong)收(shou)(shou)集(ji)，然后寫(xie)入(ru)外部的(de)(de)(de)(de)集(ji)中(zhong)(zhong)(zhong)(zhong)日(ri)(ri)(ri)志(zhi)(zhi)(zhi)管(guan)理(li)系(xi)統(tong)(tong)(tong)中(zhong)(zhong)(zhong)(zhong)。傳統(tong)(tong)(tong)的(de)(de)(de)(de)日(ri)(ri)(ri)志(zhi)(zhi)(zhi)匯總(zong)收(shou)(shou)集(ji)方案(an)主要有商業軟件(jian) Splunk、開源軟件(jian)棧 ELK 和(he) Facebook 開源的(de)(de)(de)(de) Scribe 等(deng)，其中(zhong)(zhong)(zhong)(zhong)以 ELK 最為廣泛使(shi)用(yong)(yong)。典型的(de)(de)(de)(de) ELK 架構，優點(dian)(dian)(dian)是(shi)搭(da)建簡單、易于上手，缺點(dian)(dian)(dian)是(shi) Logstash 耗費資源較(jiao)大(da)，運行(xing)占(zhan)用(yong)(yong) CPU 和(he)內存(cun)高，另外沒有消(xiao)息隊列緩存(cun)，存(cun)在數據丟失隱(yin)患，建議小規模集(ji)群使(shi)用(yong)(yong)。如果大(da)規模使(shi)用(yong)(yong)，則可(ke)以引入(ru) Kafka（或(huo)(huo)者 Redis），增加(jia)消(xiao)息隊列緩存(cun)，均衡網絡傳輸，再把(ba) Logstash 和(he) Elasticsearch 配置為集(ji)群模式，以減輕(qing)負荷壓(ya)力。Logstash 占(zhan)用(yong)(yong)系(xi)統(tong)(tong)(tong)資源過多，后來(lai)又有了 Fluentd，替代(dai)了 Logstash，被(bei)稱作是(shi)社(she)區方案(an)中(zhong)(zhong)(zhong)(zhong)的(de)(de)(de)(de) EFK，相比 Logstash 等(deng)傳統(tong)(tong)(tong)日(ri)(ri)(ri)志(zhi)(zhi)(zhi)收(shou)(shou)集(ji)工具(ju)，Fluentd 的(de)(de)(de)(de)日(ri)(ri)(ri)志(zhi)(zhi)(zhi)收(shou)(shou)集(ji)功能對容(rong)(rong)器(qi)(qi)支持的(de)(de)(de)(de)更加(jia)完備。

在容(rong)器(qi)(qi)日(ri)(ri)(ri)志(zhi)收集(ji)的(de)(de)(de)(de)(de)(de)時(shi)候(hou)，要(yao)(yao)注(zhu)意以下兩點：1、避免寫日(ri)(ri)(ri)志(zhi)沖突。最(zui)簡單的(de)(de)(de)(de)(de)(de)方式(shi)就是讓(rang)容(rong)器(qi)(qi)在運行(xing)時(shi)掛(gua)載外部(bu)共享(xiang)存儲(chu)卷當(dang)做應(ying)用的(de)(de)(de)(de)(de)(de)日(ri)(ri)(ri)志(zhi)目錄(lu)，這樣應(ying)用的(de)(de)(de)(de)(de)(de)日(ri)(ri)(ri)志(zhi)會被實時(shi)寫入外部(bu)共享(xiang)存儲(chu)以備后(hou)續(xu)處(chu)理。這種方式(shi)需(xu)(xu)要(yao)(yao)我(wo)們做好(hao)控制，不(bu)同(tong)(tong)(tong)(tong)的(de)(de)(de)(de)(de)(de)容(rong)器(qi)(qi)不(bu)能掛(gua)載同(tong)(tong)(tong)(tong)一(yi)個(ge)(ge)外部(bu)卷，否則就會出現(xian)寫日(ri)(ri)(ri)志(zhi)沖突的(de)(de)(de)(de)(de)(de)問題，容(rong)器(qi)(qi)遷移的(de)(de)(de)(de)(de)(de)時(shi)候(hou)還需(xu)(xu)要(yao)(yao)重(zhong)新掛(gua)卷。2、不(bu)可忽視日(ri)(ri)(ri)志(zhi)標(biao)準(zhun)化。當(dang)我(wo)們采用容(rong)器(qi)(qi)來(lai)運行(xing)微(wei)服(fu)(fu)務(wu)架構(gou)應(ying)用，一(yi)個(ge)(ge)業務(wu)調用往(wang)往(wang)需(xu)(xu)要(yao)(yao)經(jing)過(guo)(guo)多個(ge)(ge)微(wei)服(fu)(fu)務(wu)的(de)(de)(de)(de)(de)(de)調用鏈(lian)，整個(ge)(ge)業務(wu)處(chu)理過(guo)(guo)程的(de)(de)(de)(de)(de)(de)日(ri)(ri)(ri)志(zhi)記(ji)錄(lu)分散(san)在不(bu)同(tong)(tong)(tong)(tong)的(de)(de)(de)(de)(de)(de)微(wei)服(fu)(fu)務(wu)日(ri)(ri)(ri)志(zhi)中，這對(dui)通(tong)(tong)過(guo)(guo)日(ri)(ri)(ri)志(zhi)進行(xing)問題診(zhen)斷帶來(lai)了(le)很大的(de)(de)(de)(de)(de)(de)不(bu)便。通(tong)(tong)過(guo)(guo)標(biao)準(zhun)化日(ri)(ri)(ri)志(zhi)，例(li)如帶上(shang)唯一(yi)的(de)(de)(de)(de)(de)(de) ID 信(xin)息(xi)等(deng)，可以實現(xian)把同(tong)(tong)(tong)(tong)一(yi)個(ge)(ge)業務(wu)在不(bu)同(tong)(tong)(tong)(tong)微(wei)服(fu)(fu)務(wu)中的(de)(de)(de)(de)(de)(de)處(chu)理過(guo)(guo)程給關(guan)聯起來(lai)。通(tong)(tong)過(guo)(guo)標(biao)準(zhun)化的(de)(de)(de)(de)(de)(de)應(ying)用日(ri)(ri)(ri)志(zhi)，我(wo)們可以對(dui)交易率(lv)、成功率(lv)、響應(ying)時(shi)間(jian)等(deng)關(guan)鍵業務(wu)指標(biao)進行(xing)統一(yi)關(guan)聯分析，作為問題預(yu)警(jing)、診(zhen)斷分析、容(rong)量擴縮(suo)的(de)(de)(de)(de)(de)(de)科學依據(ju)。

第(di)6個(ge)(ge)問題(ti)容(rong)(rong)器(qi)(qi)(qi)的(de)(de)(de)(de)(de)(de)監(jian)(jian)(jian)(jian)(jian)(jian)控(kong)(kong)(kong)(kong)(kong)(kong)怎(zen)么做。在虛擬機運維(wei)的(de)(de)(de)(de)(de)(de)時(shi)(shi)代，Nagios 和(he) Zabbix 等(deng)(deng)(deng)(deng)都(dou)是(shi)(shi)十分(fen)(fen)經典的(de)(de)(de)(de)(de)(de)性(xing)(xing)能監(jian)(jian)(jian)(jian)(jian)(jian)控(kong)(kong)(kong)(kong)(kong)(kong)軟件(jian)。但在容(rong)(rong)器(qi)(qi)(qi)時(shi)(shi)代，這(zhe)些(xie)曾(ceng)經耳熟能詳的(de)(de)(de)(de)(de)(de)軟件(jian)，大多(duo)(duo)不(bu)能提供(gong)方(fang)(fang)便(bian)的(de)(de)(de)(de)(de)(de)容(rong)(rong)器(qi)(qi)(qi)化服務(wu)(wu)的(de)(de)(de)(de)(de)(de)監(jian)(jian)(jian)(jian)(jian)(jian)控(kong)(kong)(kong)(kong)(kong)(kong)體(ti)(ti)驗，社區對(dui)(dui)開(kai)發這(zhe)類插(cha)件(jian)和(he)數據(ju)收(shou)集(ji)客戶端也并(bing)不(bu)積極。相反的(de)(de)(de)(de)(de)(de)是(shi)(shi)許多(duo)(duo)新(xin)(xin)生的(de)(de)(de)(de)(de)(de)開(kai)源(yuan)監(jian)(jian)(jian)(jian)(jian)(jian)控(kong)(kong)(kong)(kong)(kong)(kong)項目(mu)將(jiang)對(dui)(dui)容(rong)(rong)器(qi)(qi)(qi)的(de)(de)(de)(de)(de)(de)支持放到了(le)關鍵特性(xing)(xing)的(de)(de)(de)(de)(de)(de)位置，一(yi)代新(xin)(xin)人(ren)(ren)換(huan)舊(jiu)人(ren)(ren)，可以(yi)(yi)(yi)說容(rong)(rong)器(qi)(qi)(qi)的(de)(de)(de)(de)(de)(de)應(ying)(ying)(ying)用(yong)(yong)界定了(le)一(yi)個(ge)(ge)全新(xin)(xin)的(de)(de)(de)(de)(de)(de)監(jian)(jian)(jian)(jian)(jian)(jian)控(kong)(kong)(kong)(kong)(kong)(kong)軟件(jian)時(shi)(shi)代。在這(zhe)些(xie)新(xin)(xin)生的(de)(de)(de)(de)(de)(de)監(jian)(jian)(jian)(jian)(jian)(jian)控(kong)(kong)(kong)(kong)(kong)(kong)工具中，有三種(zhong)比(bi)較流(liu)行(xing)且成熟的(de)(de)(de)(de)(de)(de)具體(ti)(ti)方(fang)(fang)案，分(fen)(fen)別是(shi)(shi) cAdvisor、cAdvisor + InfluxDB + Grafana 和(he) Prometheus.其(qi)中基(ji)于 InfluxDB 的(de)(de)(de)(de)(de)(de)方(fang)(fang)案是(shi)(shi)一(yi)個(ge)(ge)多(duo)(duo)種(zhong)開(kai)源(yuan)組件(jian)的(de)(de)(de)(de)(de)(de)組合方(fang)(fang)案，而(er)基(ji)于 Prometheus 的(de)(de)(de)(de)(de)(de)方(fang)(fang)案是(shi)(shi)作為(wei)一(yi)種(zhong)整(zheng)體(ti)(ti)解(jie)決(jue)方(fang)(fang)案。它(ta)本(ben)身(shen)對(dui)(dui)容(rong)(rong)器(qi)(qi)(qi)信息的(de)(de)(de)(de)(de)(de)收(shou)集(ji)能力以(yi)(yi)(yi)及圖表展示能力相比(bi)其(qi)他專用(yong)(yong)開(kai)源(yuan)組件(jian)較弱(ruo)，通(tong)常在實際實施(shi)的(de)(de)(de)(de)(de)(de)時(shi)(shi)候依(yi)然會將(jiang)它(ta)組合為(wei) cAdvisor + Prometheus 或 cAdvisor + Prometheus+ Grafana 的(de)(de)(de)(de)(de)(de)方(fang)(fang)式(shi)來(lai)使(shi)用(yong)(yong)，但它(ta)多(duo)(duo)維(wei)度的(de)(de)(de)(de)(de)(de)數據(ju)模型，可方(fang)(fang)便(bian)的(de)(de)(de)(de)(de)(de)進(jin)(jin)行(xing)數據(ju)過濾和(he)聚合。說到容(rong)(rong)器(qi)(qi)(qi)應(ying)(ying)(ying)用(yong)(yong)的(de)(de)(de)(de)(de)(de)監(jian)(jian)(jian)(jian)(jian)(jian)控(kong)(kong)(kong)(kong)(kong)(kong)設計，在這(zhe)里要(yao)(yao)注意(yi)監(jian)(jian)(jian)(jian)(jian)(jian)控(kong)(kong)(kong)(kong)(kong)(kong)是(shi)(shi)分(fen)(fen)層(ceng)(ceng)的(de)(de)(de)(de)(de)(de)，具體(ti)(ti)可以(yi)(yi)(yi)分(fen)(fen)為(wei)系統(tong)(tong)(tong)層(ceng)(ceng)面(mian)(mian)(mian)(mian)(mian)、應(ying)(ying)(ying)用(yong)(yong)層(ceng)(ceng)面(mian)(mian)(mian)(mian)(mian)和(he)服務(wu)(wu)層(ceng)(ceng)面(mian)(mian)(mian)(mian)(mian)，每個(ge)(ge)層(ceng)(ceng)面(mian)(mian)(mian)(mian)(mian)都(dou)有自(zi)己的(de)(de)(de)(de)(de)(de)監(jian)(jian)(jian)(jian)(jian)(jian)控(kong)(kong)(kong)(kong)(kong)(kong)重點(dian)。1、系統(tong)(tong)(tong)層(ceng)(ceng)面(mian)(mian)(mian)(mian)(mian)，主要(yao)(yao)是(shi)(shi)針對(dui)(dui)資(zi)源(yuan)使(shi)用(yong)(yong)情況、網絡連通(tong)性(xing)(xing)、節點(dian)健(jian)康情況的(de)(de)(de)(de)(de)(de)監(jian)(jian)(jian)(jian)(jian)(jian)控(kong)(kong)(kong)(kong)(kong)(kong)。傳(chuan)(chuan)(chuan)統(tong)(tong)(tong)的(de)(de)(de)(de)(de)(de)監(jian)(jian)(jian)(jian)(jian)(jian)控(kong)(kong)(kong)(kong)(kong)(kong)系統(tong)(tong)(tong)在這(zhe)方(fang)(fang)面(mian)(mian)(mian)(mian)(mian)已經非常完備，我們直接可以(yi)(yi)(yi)利用(yong)(yong)傳(chuan)(chuan)(chuan)統(tong)(tong)(tong)的(de)(de)(de)(de)(de)(de)監(jian)(jian)(jian)(jian)(jian)(jian)控(kong)(kong)(kong)(kong)(kong)(kong)系統(tong)(tong)(tong)對(dui)(dui)容(rong)(rong)器(qi)(qi)(qi)平臺的(de)(de)(de)(de)(de)(de)宿主機進(jin)(jin)行(xing)系統(tong)(tong)(tong)層(ceng)(ceng)面(mian)(mian)(mian)(mian)(mian)的(de)(de)(de)(de)(de)(de)監(jian)(jian)(jian)(jian)(jian)(jian)控(kong)(kong)(kong)(kong)(kong)(kong)，對(dui)(dui)接監(jian)(jian)(jian)(jian)(jian)(jian)控(kong)(kong)(kong)(kong)(kong)(kong)大屏幕等(deng)(deng)(deng)(deng)。宿主機上單(dan)個(ge)(ge)容(rong)(rong)器(qi)(qi)(qi)本(ben)身(shen)的(de)(de)(de)(de)(de)(de)性(xing)(xing)能和(he)資(zi)源(yuan)使(shi)用(yong)(yong)情況，對(dui)(dui)于外(wai)部(bu)資(zi)源(yuan)監(jian)(jian)(jian)(jian)(jian)(jian)控(kong)(kong)(kong)(kong)(kong)(kong)意(yi)義不(bu)大，也沒有多(duo)(duo)大必要(yao)(yao)傳(chuan)(chuan)(chuan)送到外(wai)部(bu)的(de)(de)(de)(de)(de)(de)傳(chuan)(chuan)(chuan)統(tong)(tong)(tong)監(jian)(jian)(jian)(jian)(jian)(jian)控(kong)(kong)(kong)(kong)(kong)(kong)。2、應(ying)(ying)(ying)用(yong)(yong)層(ceng)(ceng)面(mian)(mian)(mian)(mian)(mian)。容(rong)(rong)器(qi)(qi)(qi)平臺本(ben)身(shen)通(tong)常都(dou)帶有類似 K8S 的(de)(de)(de)(de)(de)(de) replication control 這(zhe)樣的(de)(de)(de)(de)(de)(de)機制保持某個(ge)(ge)服務(wu)(wu)運行(xing)實例(li)數量的(de)(de)(de)(de)(de)(de)能力，所以(yi)(yi)(yi)通(tong)常情況下(xia)容(rong)(rong)器(qi)(qi)(qi)平臺都(dou)能保證應(ying)(ying)(ying)用(yong)(yong)和(he)應(ying)(ying)(ying)用(yong)(yong)下(xia)每個(ge)(ge)微(wei)服務(wu)(wu)的(de)(de)(de)(de)(de)(de)運行(xing)正常。關于應(ying)(ying)(ying)用(yong)(yong)層(ceng)(ceng)面(mian)(mian)(mian)(mian)(mian)的(de)(de)(de)(de)(de)(de)健(jian)康監(jian)(jian)(jian)(jian)(jian)(jian)控(kong)(kong)(kong)(kong)(kong)(kong)，還(huan)是(shi)(shi)需(xu)要(yao)(yao)來(lai)對(dui)(dui)接傳(chuan)(chuan)(chuan)統(tong)(tong)(tong)的(de)(de)(de)(de)(de)(de)監(jian)(jian)(jian)(jian)(jian)(jian)控(kong)(kong)(kong)(kong)(kong)(kong)系統(tong)(tong)(tong)，進(jin)(jin)行(xing)適當的(de)(de)(de)(de)(de)(de)告警輸出(chu)，比(bi)如(ru)當遇到應(ying)(ying)(ying)用(yong)(yong)邏輯錯誤(wu)而(er)導致(zhi)啟(qi)動反復失敗或資(zi)源(yuan)不(bu)足，導致(zhi)啟(qi)動總是(shi)(shi)不(bu)成功(gong)等(deng)(deng)(deng)(deng)問題(ti)時(shi)(shi)，容(rong)(rong)器(qi)(qi)(qi)平臺本(ben)身(shen)的(de)(de)(de)(de)(de)(de) replication control 機制就不(bu)能解(jie)決(jue)問題(ti)了(le)。這(zhe)種(zhong)情況就需(xu)要(yao)(yao)我們把應(ying)(ying)(ying)用(yong)(yong)的(de)(de)(de)(de)(de)(de)故障信息傳(chuan)(chuan)(chuan)遞到外(wai)部(bu)監(jian)(jian)(jian)(jian)(jian)(jian)控(kong)(kong)(kong)(kong)(kong)(kong)，并(bing)根據(ju)問題(ti)的(de)(de)(de)(de)(de)(de)嚴重情況進(jin)(jin)行(xing)不(bu)同等(deng)(deng)(deng)(deng)級的(de)(de)(de)(de)(de)(de)告警通(tong)知等(deng)(deng)(deng)(deng)，由相關的(de)(de)(de)(de)(de)(de)應(ying)(ying)(ying)用(yong)(yong)人(ren)(ren)員介(jie)入來(lai)解(jie)決(jue)問題(ti)，比(bi)如(ru)升級補丁或回退等(deng)(deng)(deng)(deng)。

3、服務(wu)(wu)層面(mian)。服務(wu)(wu)層面(mian)則是(shi)監(jian)控應(ying)用提(ti)供的(de)(de)(de)服務(wu)(wu)是(shi)否運行(xing)正常(chang)(chang)。例(li)如某(mou)個提(ti)供 Web 服務(wu)(wu)的(de)(de)(de)應(ying)用，在一些時(shi)候(hou)雖然應(ying)用和應(ying)用中微服務(wu)(wu)的(de)(de)(de)運行(xing)實例(li)數(shu)量(liang)正常(chang)(chang)，但(dan)它的(de)(de)(de) Web 服務(wu)(wu)已經失去響應(ying)，或者(zhe)返回的(de)(de)(de)是(shi)錯誤的(de)(de)(de)狀(zhuang)態，這種情(qing)況在多(duo)數(shu)容器(qi)平(ping)臺中是(shi)無法監(jian)測到(dao)的(de)(de)(de)。傳統的(de)(de)(de)方(fang)式是(shi)通過打探(tan)針 Agent 方(fang)式，但(dan)在容器(qi)環境(jing)下，這種方(fang)式不一定可行(xing)，這就需要(yao)我們豐富容器(qi)故(gu)障的(de)(de)(de)監(jian)測手段或者(zhe)自己編(bian)寫服務(wu)(wu)訪問+檢(jian)(jian)測邏輯來判斷，并把檢(jian)(jian)測出現的(de)(de)(de)問題上報到(dao)外部(bu)監(jian)控，在監(jian)控中設立相(xiang)應(ying)的(de)(de)(de)告警(jing)策略和告警(jing)等(deng)級。

第七就是(shi)容(rong)器的(de)多租(zu)戶(hu)和權限(xian)設計，在這(zhe)里(li)面其實容(rong)器這(zhe)塊處理的(de)還(huan)不(bu)是(shi)特別好。比如給一(yi)個容(rong)器分配了200兆內(nei)存(cun)，你看到的(de)實際上是(shi)物理機的(de)64G內(nei)存(cun)，而不(bu)是(shi)真正(zheng)你分給容(rong)器的(de)這(zhe)個內(nei)存(cun)。多租(zu)戶(hu)，顧名思義，就是(shi)很多人來租(zu)用容(rong)器云平臺(tai)的(de)資(zi)源(yuan)來實現自己(ji)的(de)應用托管(guan)運(yun)維(wei)需(xu)求。這(zhe)里(li)面主要涉及(ji)多租(zu)戶(hu)、資(zi)源(yuan)管(guan)理與分配、安全權限(xian)管(guan)理這(zhe)三(san)個問題。

1、多(duo)租(zu)戶(hu)(hu)(hu)的(de)(de)問(wen)題。從多(duo)租(zu)戶(hu)(hu)(hu)的(de)(de)角度考慮，租(zu)戶(hu)(hu)(hu)租(zu)用(yong)(yong)容(rong)器(qi)云平(ping)臺的(de)(de)資(zi)(zi)源來(lai)托管(guan)、開發(fa)、部署(shu)運維自(zi)(zi)己的(de)(de)應(ying)(ying)用(yong)(yong)、服(fu)(fu)務(wu)(wu)。容(rong)器(qi)云平(ping)臺需要提供、維護(hu)保障租(zu)戶(hu)(hu)(hu)能正常使(shi)用(yong)(yong)這(zhe)些(xie)(xie)(xie)資(zi)(zi)源，同時給租(zu)戶(hu)(hu)(hu)托管(guan)的(de)(de)應(ying)(ying)用(yong)(yong)提供服(fu)(fu)務(wu)(wu)注冊、服(fu)(fu)務(wu)(wu)發(fa)現、服(fu)(fu)務(wu)(wu)配(pei)(pei)置(zhi)、日志、監控、預警告警、彈性伸縮、負(fu)載均衡(heng)、安全等能力(li)(li)。我(wo)們要明(ming)白的(de)(de)是(shi)租(zu)戶(hu)(hu)(hu)只(zhi)是(shi)租(zu)用(yong)(yong)這(zhe)些(xie)(xie)(xie)能力(li)(li)，它并(bing)不運維這(zhe)些(xie)(xie)(xie)能力(li)(li)。租(zu)戶(hu)(hu)(hu)關注的(de)(de)是(shi)托管(guan)的(de)(de)應(ying)(ying)用(yong)(yong)和服(fu)(fu)務(wu)(wu)，它需要做的(de)(de)是(shi)利(li)用(yong)(yong)平(ping)臺提供的(de)(de)這(zhe)些(xie)(xie)(xie)能力(li)(li)來(lai)無縫的(de)(de)運維他們的(de)(de)應(ying)(ying)用(yong)(yong)和服(fu)(fu)務(wu)(wu)。一句話(hua)來(lai)總結(jie)：租(zu)戶(hu)(hu)(hu)只(zhi)是(shi)使(shi)用(yong)(yong)/租(zu)用(yong)(yong)資(zi)(zi)源，容(rong)器(qi)云平(ping)臺管(guan)理(li)運維這(zhe)些(xie)(xie)(xie)資(zi)(zi)源。租(zu)戶(hu)(hu)(hu)側重(zhong)于對自(zi)(zi)己的(de)(de)應(ying)(ying)用(yong)(yong)或服(fu)(fu)務(wu)(wu)進行運維。資(zi)(zi)源由租(zu)戶(hu)(hu)(hu)申(shen)請，容(rong)器(qi)云平(ping)臺來(lai)分配(pei)(pei)管(guan)理(li)資(zi)(zi)源。

2、資源管(guan)理與分(fen)配(pei)。這(zhe)部分(fen)功能建議統一(yi)由運(yun)維團隊(dui)或者系(xi)統團隊(dui)負責，應用系(xi)統上(shang)云前(qian)一(yi)般(ban)會(hui)進(jin)行壓測，有個容量(liang)估(gu)算(suan)的(de)過(guo)程(cheng)。通(tong)(tong)過(guo)容量(liang)估(gu)算(suan)和趨勢(shi)分(fen)析(xi)，系(xi)統人員可(ke)以(yi)(yi)(yi)規(gui)劃(hua)大致的(de)資源池給相關應用，一(yi)般(ban)可(ke)以(yi)(yi)(yi)通(tong)(tong)過(guo)劃(hua)分(fen)底(di)層資源池實(shi)現。如果用 K8S，可(ke)以(yi)(yi)(yi)在計算(suan)節點上(shang)通(tong)(tong)過(guo) lables 進(jin)行規(gui)劃(hua)，另外還需要在編排(pai)文件上(shang)設(she)置好最小資源和最大資源，讓應用可(ke)以(yi)(yi)(yi)彈(dan)性(xing)擴(kuo)容。

3、安(an)全(quan)權限(xian)(xian)(xian)管(guan)理。多(duo)租戶的安(an)全(quan)權限(xian)(xian)(xian)設計涉(she)及到容器云平臺整(zheng)體的權限(xian)(xian)(xian)控制架構，最(zui)好是實(shi)現一個(ge)權限(xian)(xian)(xian)中心，由權限(xian)(xian)(xian)中心來實(shi)現對容器云各組件(jian)及各功能(neng)的動(dong)態(tai)控制，以適應(ying)靈(ling)活的不同的場景需求。

第八就是容(rong)(rong)器(qi)與(yu) OpenStack 和(he)(he) Kubernetes 集成的能力(li)。在(zai)(zai)開(kai)源云(yun)計(ji)算(suan)技(ji)(ji)術(shu)(shu)(shu)蓬勃(bo)發(fa)展的這幾年中，OpenStack、Kubernetes、Container 無疑成為了(le)改變云(yun)計(ji)算(suan)格(ge)局的三項關鍵(jian)技(ji)(ji)術(shu)(shu)(shu)。但(dan)是這三者(zhe)之間在(zai)(zai)技(ji)(ji)術(shu)(shu)(shu)上仍然存(cun)在(zai)(zai)一(yi)個(ge)空(kong)白：容(rong)(rong)器(qi)運行(xing)時(shi)(shi)強(qiang)安全(quan)(quan)隔離(li)的同時(shi)(shi)保(bao)持精簡(jian)尺寸以(yi)及(ji)(ji)輕量級，以(yi)及(ji)(ji)如何能夠很容(rong)(rong)易與(yu) OpenStack 和(he)(he) Kubernetes 兩大(da)平臺集成從(cong)而(er)獲取多(duo)租戶以(yi)及(ji)(ji)統一(yi)網絡(luo)和(he)(he)統一(yi)存(cun)儲等諸多(duo)好處，這個(ge)空(kong)白阻礙了(le)用(yong)(yong)戶從(cong)中獲取更大(da)價(jia)值。為了(le)解決這一(yi)問題(ti)，OpenStack 基金會在(zai)(zai)今(jin)年 12 月 5 日的 KubeCon 峰會上發(fa)布了(le)一(yi)項新的開(kai)源項目，Kata Containers.Kata 可以(yi)使用(yong)(yong)戶同時(shi)(shi)擁(yong)有虛擬機的安全(quan)(quan)和(he)(he)容(rong)(rong)器(qi)技(ji)(ji)術(shu)(shu)(shu)的迅(xun)速(su)和(he)(he)易管(guan)理性。項目可以(yi)屏蔽硬件差異(yi)并且和(he)(he) OCIspeciaification、Kubernetes 容(rong)(rong)器(qi)運行(xing)時(shi)(shi)標(biao)準兼容(rong)(rong)，在(zai)(zai)支(zhi)持標(biao)準鏡像(xiang)格(ge)式的同時(shi)(shi)具有強(qiang)隔離(li)、輕量級以(yi)及(ji)(ji)快(kuai)速(su)啟動能力(li)。無疑 Kata 項目的發(fa)起為 OpenStack、Kubernetes 和(he)(he) Container 更好的融合提供了(le)有力(li)的支(zhi)撐，并為用(yong)(yong)戶從(cong)中收益(yi)鋪平了(le)道路(lu)。期待容(rong)(rong)器(qi)真(zhen)正輝煌時(shi)(shi)代的降臨，但(dan)未來的道路(lu)，依(yi)然任重道遠！

第九(jiu)個問(wen)題(ti)就是容(rong)器云(yun)(yun)如何(he)實(shi)(shi)現高可(ke)(ke)用(yong)(yong)和跨區部(bu)署。容(rong)器云(yun)(yun)需(xu)要考慮平臺自身(shen)的(de)高可(ke)(ke)用(yong)(yong)，實(shi)(shi)現多可(ke)(ke)用(yong)(yong)區多部(bu)署。容(rong)器上的(de)應用(yong)(yong)高可(ke)(ke)用(yong)(yong)需(xu)要結合應用(yong)(yong)架構(gou)來實(shi)(shi)現。目前微服(fu)務(wu)架構(gou)是最(zui)適合云(yun)(yun)基(ji)礎設施的(de)應用(yong)(yong)架構(gou)之一。微服(fu)務(wu)應用(yong)(yong)通過服(fu)務(wu)注冊發現、全局配置管理、熔斷、服(fu)務(wu)追(zhui)蹤(zong)等(deng)容(rong)錯設計，保證應用(yong)(yong)的(de)高可(ke)(ke)用(yong)(yong)。彈性擴容(rong)，增加微服(fu)務(wu)運行(xing)的(de)實(shi)(shi)例數量，配合負載均(jun)衡策略(lve)的(de)使用(yong)(yong)，減少因壓力過大而(er)導(dao)致(zhi)運行(xing)實(shi)(shi)例宕機的(de)情(qing)況。

最(zui)后(hou)(hou)總結一(yi)(yi)下，容器(qi)技(ji)(ji)術在(zai)企業的(de)(de)(de)(de)落地，不(bu)(bu)是(shi)(shi)(shi)一(yi)(yi)蹴而就的(de)(de)(de)(de)，是(shi)(shi)(shi)一(yi)(yi)個漸進(jin)(jin)和(he)(he)價值普及的(de)(de)(de)(de)過(guo)程(cheng)。通常我(wo)們聽到一(yi)(yi)句話，就是(shi)(shi)(shi)說先(xian)(xian)(xian)進(jin)(jin)一(yi)(yi)步是(shi)(shi)(shi)先(xian)(xian)(xian)烈，先(xian)(xian)(xian)進(jin)(jin)兩步是(shi)(shi)(shi)先(xian)(xian)(xian)驅，任(ren)何(he)新技(ji)(ji)術出來之后(hou)(hou)不(bu)(bu)要跑(pao)的(de)(de)(de)(de)太快，因(yin)為(wei)還有很多(duo)坑沒有完全踩過(guo)，也不(bu)(bu)知道這條(tiao)路能不(bu)(bu)能走的(de)(de)(de)(de)平(ping)坦和(he)(he)順(shun)暢(chang)，有時候跑(pao)的(de)(de)(de)(de)太快，就成(cheng)為(wei)先(xian)(xian)(xian)驅了。技(ji)(ji)術的(de)(de)(de)(de)更(geng)迭方式可(ke)以是(shi)(shi)(shi)潛移默化(hua)的(de)(de)(de)(de)和(he)(he)平(ping)演變(bian)，亦或是(shi)(shi)(shi)轟轟烈烈的(de)(de)(de)(de)武裝革(ge)命，容器(qi)技(ji)(ji)術應該歸屬于前者(zhe)。我(wo)們可(ke)以看(kan)到，容器(qi)化(hua)技(ji)(ji)術已(yi)經成(cheng)為(wei)計算模型演化(hua)的(de)(de)(de)(de)一(yi)(yi)個開端，可(ke)以預見在(zai)更(geng)高效和(he)(he)輕(qing)量化(hua)的(de)(de)(de)(de)平(ping)臺實踐之后(hou)(hou)，容器(qi)技(ji)(ji)術還將為(wei)整個 IT 領(ling)域(yu)注入更(geng)多(duo)新鮮和(he)(he)活力，在(zai)未來生存和(he)(he)壯大下去，成(cheng)為(wei)引領(ling)潮(chao)流的(de)(de)(de)(de)決定性力量！

我的分享就到這些(xie)，謝謝！

文章編輯：CobiNet(寧波)  
本公司專注于電訊配件,銅纜綜合布線系列領域產品研發生產超五類，六類,七類線，屏蔽模塊，配線架及(ji)相關模塊配(pei)件的(de)研發(fa)和生產。

歡迎來電咨詢0574 88168918,郵箱sales@aliance.cn，網址aliance.cn