CobiNet(寧波)推薦文章：

近年來(lái)，開(kāi)源技術(shù)逐漸成為云計(jì)算發(fā)展的重要支撐和導(dǎo)向，改變了以往的信息技術(shù)進(jìn)化模式，引領(lǐng)軟件技術(shù)標(biāo)準(zhǔn)的發(fā)展和創(chuàng)新，深刻影響著整個(gè)信息技術(shù)產(chǎn)業(yè)的發(fā)展格局。為進(jìn)一步探索我國(guó)云計(jì)算開(kāi)源技術(shù)發(fā)展模式，加速云計(jì)算與各行業(yè)的深度融合，更好地發(fā)揮云計(jì)算在經(jīng)濟(jì)社會(huì)創(chuàng)新發(fā)展中的支撐和引領(lǐng)作用，促進(jìn)我國(guó)云計(jì)算產(chǎn)業(yè)快速、健康發(fā)展。

由中國(guó)信息通信研究院主辦、中國(guó)通信標(biāo)準(zhǔn)化協(xié)會(huì)支持的"OSCAR云計(jì)算開(kāi)源產(chǎn)業(yè)大會(huì)"將于2018年3月21日－22日在國(guó)家會(huì)議中心舉行。在22日下午的工業(yè)使用開(kāi)源論壇上，北京中油瑞飛信息技術(shù)有限公司資深架構(gòu)師孫杰就《"容器技術(shù)在企業(yè)落地的探索和實(shí)踐"》進(jìn)行了演講！

以下為演講實(shí)錄：

孫杰： 當(dāng)今容器技術(shù)被廣泛關(guān)注，已經(jīng)有越來(lái)越多的企業(yè)開(kāi)始布局或者已經(jīng)采用容器技術(shù)來(lái)構(gòu)建自己的云基礎(chǔ)設(shè)施。很多傳統(tǒng)行業(yè)和互聯(lián)網(wǎng)企業(yè)相比在容器技術(shù)方面起步稍晚，但近兩年隨著容器關(guān)注度的空前火熱，企業(yè)進(jìn)步也很快，大力推進(jìn)容器相關(guān)能力的建設(shè)。基于 Docker 的容器，是一種更輕量級(jí)的虛擬化，我們稱之為 CaaS，就是容器級(jí)服務(wù)。它涵蓋了 IaaS 跟 PaaS 兩者的優(yōu)勢(shì)，可以解決應(yīng)用的部署、開(kāi)發(fā)運(yùn)維、微服務(wù)這些問(wèn)題，而且能夠更快的加速業(yè)務(wù)的交付。容器可以說(shuō)它是一種先進(jìn)的技術(shù)，但怎么把它變成一種先進(jìn)的生產(chǎn)力，企業(yè)能不能把這個(gè)技術(shù)給用好，怎么用好，大概有這樣九個(gè)問(wèn)題，這也是我們長(zhǎng)期的思考和探索實(shí)踐。

企業(yè)要用正確的姿態(tài)擁抱容器并且使用好容器，需要在應(yīng)用容器技術(shù)時(shí)考慮清楚以下九個(gè)關(guān)鍵問(wèn)題：

1、企業(yè)容器云方案設(shè)計(jì)需要遵循什么原則？

2、容器云技術(shù)產(chǎn)品如何選型？

3、容器云的網(wǎng)絡(luò)應(yīng)該如何設(shè)計(jì)？

4、容器的持久化存儲(chǔ)方案如何選擇和設(shè)計(jì)？

5、容器云上日志集中管理如何設(shè)計(jì)？

6、容器應(yīng)用的監(jiān)控方案如何設(shè)計(jì)？

7、容器云的多租戶和權(quán)限如何設(shè)計(jì)？

8、容器與 OpenStack 和 Kubernetes 集成的能力？

9、容器云如何實(shí)現(xiàn)高可用和跨區(qū)部署？

那么，首先第一個(gè)問(wèn)題企業(yè)容器云方案設(shè)計(jì)需要遵循什么原則？

首先，我們要明確企業(yè)上容器云的目的，容器是為業(yè)務(wù)服務(wù)的，任何技術(shù)都是為了能夠更好的服務(wù)業(yè)務(wù)，這是我們的出發(fā)點(diǎn)。其次，結(jié)合業(yè)務(wù)特點(diǎn)選擇合適的容器框架，比如我們的業(yè)務(wù)本身是不是可以基于新型微服務(wù)架構(gòu)進(jìn)行改造，業(yè)務(wù)是不是具有變化快、彈性大、更新迭代快等特點(diǎn)。還有要和已有系統(tǒng)較好地對(duì)接整合，在上容器之前，企業(yè)通常都已經(jīng)有比較成熟和穩(wěn)定的其他 IT 系統(tǒng)，例如網(wǎng)絡(luò)系統(tǒng)、集中監(jiān)控系統(tǒng)、安全防護(hù)系統(tǒng)等。

為避免重復(fù)建設(shè)，同時(shí)也為了容器平臺(tái)能夠更容易被接受和使用，應(yīng)讓容器平臺(tái)融入企業(yè)原有的整個(gè) IT 系統(tǒng)，而不是另起爐灶重新建設(shè)。容器平臺(tái)要承載生產(chǎn)業(yè)務(wù)，也需要滿足安全的監(jiān)管合規(guī)要求，例如隔離不同安全等級(jí)的應(yīng)用、支持對(duì)應(yīng)用容器的安全漏洞掃描、安全有效的防火墻策略管理等。生產(chǎn)環(huán)境的業(yè)務(wù)要求高可用性、連續(xù)性，還應(yīng)該考慮整個(gè)容器應(yīng)用層面的高可用性和數(shù)據(jù)連續(xù)性、安全可靠。

建設(shè)容器平臺(tái)的目的是為應(yīng)用帶來(lái)靈活、彈性、節(jié)省資源等優(yōu)勢(shì)，這要求應(yīng)用最好具備微服務(wù)架構(gòu)、無(wú)狀態(tài)化等特點(diǎn)，讓這些優(yōu)勢(shì)更好地發(fā)揮。但不適合容器化的應(yīng)用也不能勉強(qiáng)，否則容器平臺(tái)建設(shè)后，如果不能給應(yīng)用和業(yè)務(wù)帶來(lái)預(yù)期的價(jià)值，不僅浪費(fèi)了大量企業(yè)投入，還使得容器平臺(tái)的價(jià)值得不到認(rèn)可。這是每一個(gè)投入大量精力和熱情進(jìn)行容器平臺(tái)建設(shè)的人最不愿意看到的結(jié)果。

容器本身的特點(diǎn)和好處，我就不復(fù)述了，大家都比較清楚，容器一個(gè)是低成本、輕量級(jí)的，而且便于遷移，啟動(dòng)的時(shí)候特別快。它直接可以構(gòu)建在物理主機(jī)的OS系統(tǒng)上，像以前的虛擬化可能要多一層，然后在這之上才會(huì)有你的虛擬機(jī)的操作系統(tǒng)。容器和虛擬機(jī)占用CPU資源的情況對(duì)比，像Docker大概在1.6%，像KVM占用資源大概14.6%，占用的內(nèi)存資源對(duì)比，Docker平均每個(gè)容器只有46兆，KVM基本上185兆，同樣的規(guī)格，Docker的性能2倍于你的KVM.Docker的鏡像非常小，而虛擬機(jī)的鏡像基本上在3G、4G，甚至像Windows這樣的都在5G、6G.這樣來(lái)看容器有比較大的資源節(jié)省，而且性能又提高了。

應(yīng)用容器技術(shù)帶來(lái)的挑戰(zhàn)和改變，大家可以看到，容器帶來(lái)的改變，第一，它可以直接通過(guò)鏡像封裝你的應(yīng)用，可以根據(jù)你的dockerfile命令行直接構(gòu)建你所需要的應(yīng)用，提供了一種比較廣泛認(rèn)可的交付協(xié)議。第二，資源的提供者可以無(wú)差別的對(duì)待你的資源需求，為構(gòu)建統(tǒng)一的IT支撐平臺(tái)提供了可行性。另外就是研發(fā)流程自動(dòng)化（CI）、 應(yīng)用模式化（微服務(wù)、彈性）、 標(biāo)準(zhǔn)化、自動(dòng)化，這些都可以做到更快的響應(yīng)業(yè)務(wù)的變化。

容器面臨的主要挑戰(zhàn)，就是平臺(tái)化才能產(chǎn)生效益，但是標(biāo)準(zhǔn)不太統(tǒng)一。還有就是平臺(tái)化需要侵入應(yīng)用結(jié)構(gòu)。大量傳統(tǒng)應(yīng)用遺產(chǎn)需要改造，這是比較消耗人力和資源的。

第二個(gè)，容器云技術(shù)產(chǎn)品如何選型？技術(shù)選型這個(gè)問(wèn)題有很多復(fù)雜的影響因素，包括技術(shù)和非技術(shù)兩方面，不同的組織情況下也不盡相同。

一個(gè)企業(yè)在應(yīng)用新技術(shù)前，還需要考慮 IT 部門自身的技術(shù)能力，包括開(kāi)發(fā)能力、運(yùn)維能力，同時(shí)對(duì)自身業(yè)務(wù)系統(tǒng)從開(kāi)發(fā)平臺(tái)、開(kāi)發(fā)過(guò)程、開(kāi)發(fā)規(guī)范等有決定能力。如果企業(yè)自身的開(kāi)發(fā)和運(yùn)維能力不強(qiáng)，則采用成熟的 PCF、OpenShift 等方案是不錯(cuò)的選擇。如果考慮現(xiàn)有系統(tǒng)對(duì)接需求，包括監(jiān)控、網(wǎng)絡(luò)、安全需求等，特別是現(xiàn)有網(wǎng)絡(luò)架構(gòu)對(duì)容器的網(wǎng)絡(luò)方案有較大影響時(shí)，應(yīng)該考慮使用 Kubernetes、Mesos、Swarm 等開(kāi)源方案更便于定制，也能較好的融入現(xiàn)有 IT 系統(tǒng)。

Kubernetes、Mesos、Swarm 這三個(gè)開(kāi)源方案都是行業(yè)內(nèi)比較火熱的資源編排解決方案，但它們各自的立足點(diǎn)各有千秋。從應(yīng)用的發(fā)布環(huán)節(jié)來(lái)比較：Docker 的 Swarm 功能，以及 Kubenetes 的編排，Mesos 的調(diào)度管理，很難直接決出高低。換言之，如果加上企業(yè)級(jí)應(yīng)用場(chǎng)景，來(lái)輔佐容器技術(shù)選型，則會(huì)顯得更有意義。

企業(yè)規(guī)模不大，應(yīng)用不是太復(fù)雜

這時(shí) Docker Swarm Mode 還是比較好用的，集群的維護(hù)不需要 Zookeeper，Etcd 自己內(nèi)置，命令行和 Docker 一樣用起來(lái)順手，服務(wù)發(fā)現(xiàn)和 DNS 是內(nèi)置的，Overlay 網(wǎng)絡(luò)是內(nèi)置的。

企業(yè)規(guī)模大一些、應(yīng)用夠復(fù)雜

這時(shí)集群規(guī)模有幾百個(gè)節(jié)點(diǎn)，很多人就不愿意使用 Docker Swarm Mode 了，而是用 Mesos 和 Marathon.因?yàn)?Mesos 是一個(gè)非常優(yōu)秀的調(diào)度器，它的雙層調(diào)度機(jī)制可以使得集群規(guī)模大很多，Mesos 的優(yōu)勢(shì)在于第一層調(diào)度先將整個(gè) Node 分配給一個(gè) Framework，F(xiàn)ramework 的調(diào)度器面對(duì)的集群規(guī)模小很多，然后在里面進(jìn)行二次調(diào)度。如果有多個(gè) Framework，例如有多個(gè) Marathon，則可以并行調(diào)度不沖突，同時(shí) Mesos 在傳統(tǒng)數(shù)據(jù)計(jì)算方面擁有較多的案例，相信也是企業(yè)選型時(shí)考慮的要素之一。

企業(yè)規(guī)模大、業(yè)務(wù)復(fù)雜、應(yīng)用粒度更細(xì)

這時(shí) Kubenetes 就更適合了，因?yàn)?Kubernetes 模塊劃分得更細(xì)更多，比 Marathon 和 Mesos 功能豐富，而且模塊之間完全的松耦合，可以非常方便地進(jìn)行定制化。還有就是 Kubernetes 提供了強(qiáng)大的自動(dòng)化機(jī)制，從而使后期的系統(tǒng)運(yùn)維難度和運(yùn)維成本大幅降低，而且 Kubernetes 社區(qū)的熱度，可以使得使用 Kubernetes 的公司能夠很快地得到幫助，方便問(wèn)題和 Bug 的解決。

第三個(gè)問(wèn)題，關(guān)于容器云的網(wǎng)絡(luò)設(shè)計(jì)，這一塊是關(guān)鍵。因?yàn)榇蠹抑廊萜魉钤缡腔趩沃鳈C(jī)這種來(lái)設(shè)計(jì)的。當(dāng)容器技術(shù)逐步成熟之后，收購(gòu)了一家網(wǎng)絡(luò)解決方案公司 Socketplane，將原有的網(wǎng)絡(luò)部分抽離，單獨(dú)成了 Docker 的網(wǎng)絡(luò)庫(kù)，即 libnetwork.libnetwork 實(shí)現(xiàn)了 5 種驅(qū)動(dòng)，通過(guò)插件的形式允許用戶根據(jù)自己的需求來(lái)實(shí)現(xiàn) network driver，但 libnetwork 組件只是將 Docker 平臺(tái)中的網(wǎng)絡(luò)子系統(tǒng)模塊化為一個(gè)獨(dú)立庫(kù)的簡(jiǎn)單嘗試，離成熟和完善還有一段距離。

隨著容器技術(shù)在企業(yè)生產(chǎn)系統(tǒng)的逐步落地，用戶對(duì)于容器云的網(wǎng)絡(luò)特性要求也越來(lái)越高，跨主機(jī)容器間的網(wǎng)絡(luò)互通已經(jīng)成為最基本的要求?？缰鳈C(jī)的容器網(wǎng)絡(luò)解決方案不外乎三大類：

隧道方案

比如 Flannel 的 VxLan，特點(diǎn)是對(duì)底層的網(wǎng)絡(luò)沒(méi)有過(guò)高的要求，一般來(lái)說(shuō)只要是三層可達(dá)就可以，只要是在一個(gè)三層可達(dá)網(wǎng)絡(luò)里，就能構(gòu)建出一個(gè)基于隧道的容器網(wǎng)絡(luò)。不過(guò)問(wèn)題也很明顯，一個(gè)得到大家共識(shí)的是隨著節(jié)點(diǎn)規(guī)模的增長(zhǎng)、復(fù)雜度會(huì)提升，而且出了網(wǎng)絡(luò)問(wèn)題跟蹤起來(lái)比較麻煩，大規(guī)模集群情況下，這是需要考慮的一個(gè)點(diǎn)。

路由方案

路由技術(shù)從三層實(shí)現(xiàn)跨主機(jī)容器互通，沒(méi)有 NAT，效率比較高，和目前的網(wǎng)絡(luò)能夠融合在一起，每一個(gè)容器都可以像虛擬機(jī)一樣分配一個(gè)業(yè)務(wù)的 IP.但路由網(wǎng)絡(luò)也有問(wèn)題，路由網(wǎng)絡(luò)對(duì)現(xiàn)有網(wǎng)絡(luò)設(shè)備影響比較大，路由器的路由表應(yīng)該有空間限制，一般是兩三萬(wàn)條，而容器的大部分應(yīng)用場(chǎng)景是運(yùn)行微服務(wù)，數(shù)量集很大。如果幾萬(wàn)新的容器 IP 沖擊到路由表里，會(huì)導(dǎo)致下層的物理設(shè)備沒(méi)辦法承受；而且每一個(gè)容器都分配一個(gè)業(yè)務(wù) IP，業(yè)務(wù) IP 會(huì)很快消耗。

VLAN

所有容器和物理機(jī)在同一個(gè) VLAN 中。

綜合來(lái)看Calico 的方案和基于 HOST 的網(wǎng)絡(luò)解決方案性能較好。但基于 HOST 的端口沖突和網(wǎng)絡(luò)資源競(jìng)爭(zhēng)比較麻煩，相對(duì)來(lái)說(shuō) Calico 的是純?nèi)龑拥?SDN 實(shí)現(xiàn)，它基于 BPG 協(xié)議和 Linux 自己的路由轉(zhuǎn)發(fā)機(jī)制，不依賴特殊硬件，沒(méi)有使用 NAT 或 Tunnel 等技術(shù)。它能夠方便的部署在物理服務(wù)器、虛擬機(jī)（如 OpenStack）或者容器環(huán)境下，同時(shí)它自帶的基于 Iptables 的 ACL 管理組件非常靈活，能夠滿足比較復(fù)雜的企業(yè)安全隔離需求。關(guān)于容器應(yīng)用的網(wǎng)絡(luò)隔離還有多種解決方案，基本上就是把不同的應(yīng)用容器放置在不同的 vlan/vxlan 中，通過(guò)讓不同的 vlan/vxlan 不能互訪而實(shí)現(xiàn)隔離。企業(yè)里應(yīng)用目前是 OVS/Linux-bridge +VLAN 方案的比較多，但長(zhǎng)遠(yuǎn)看來(lái) Calico 方案前景不錯(cuò)。

第四個(gè)問(wèn)題就是容器的持久化存儲(chǔ)如何設(shè)計(jì)？在討論持久化存儲(chǔ)之前，首先聲明，運(yùn)行容器并不意味著完全摒棄數(shù)據(jù)持久化。在容器中運(yùn)行的應(yīng)用，應(yīng)用真正需要保存的數(shù)據(jù)，也可以寫入持久化的 Volume 數(shù)據(jù)卷。在這個(gè)方案中，持久層產(chǎn)生價(jià)值，不是通過(guò)彈性，而是通過(guò)靈活可編程，例如通過(guò)優(yōu)秀設(shè)計(jì)的 API 來(lái)擴(kuò)展存儲(chǔ)。目前，主要支持 Docker 或 Kubernetes 的 Volume.Docker 發(fā)布了容器卷插件規(guī)范，允許第三方廠商的數(shù)據(jù)卷在 Docker 引擎中提供數(shù)據(jù)服務(wù)。這種機(jī)制意味著外置存儲(chǔ)可以超過(guò)容器的生命周期而獨(dú)立存在，而且各種存儲(chǔ)設(shè)備只要滿足接口 API 標(biāo)準(zhǔn)，就可接入 Docker 容器的運(yùn)行平臺(tái)中。現(xiàn)有的各種存儲(chǔ)可以通過(guò)簡(jiǎn)單的驅(qū)動(dòng)程序封裝，從而實(shí)現(xiàn)和 Docker 容器的對(duì)接。另外一個(gè)就是K8S 的數(shù)據(jù)卷。K8S 的每個(gè) Pod 包含一個(gè)或多個(gè)容器。Pod 可部署在集群的任意節(jié)點(diǎn)中，存儲(chǔ)設(shè)備可通過(guò)數(shù)據(jù)卷提供給 Pod 的容器使用。為了不綁定特定的容器技術(shù)，K8S 沒(méi)有使用 Docker 的 Volume 機(jī)制，而是制定了自己的通用數(shù)據(jù)卷插件規(guī)范，以配合不同的容器運(yùn)行來(lái)使用（如 Docker 和 rkt）。數(shù)據(jù)卷分為共享和非共享兩種類型，其中非共享型只能被某個(gè)節(jié)點(diǎn)掛載使用（如 iSCSI、AWS EBS 等網(wǎng)絡(luò)塊設(shè)備）；共享型則可讓不同節(jié)點(diǎn)上的多個(gè) Pod 同時(shí)使用（如 NFS、GlusterFS 等網(wǎng)絡(luò)文件系統(tǒng)，以及可支持多方讀寫的塊設(shè)備）。對(duì)有狀態(tài)的應(yīng)用來(lái)說(shuō)，共享型的卷存儲(chǔ)能夠很方便地支持容器在集群各節(jié)點(diǎn)之間的遷移。為了給容器提供更細(xì)粒度的卷管理，K8s 增加了持久化卷的功能，把外置存儲(chǔ)作為資源池，由平臺(tái)管理并提供給整個(gè)集群使用。K8S 的卷管理架構(gòu)使用存儲(chǔ)可用標(biāo)準(zhǔn)的接入方式，并且通過(guò)接口暴露存儲(chǔ)設(shè)備所支持的能力，在容器任務(wù)調(diào)度等方面實(shí)現(xiàn)了自動(dòng)化管理。

從2017年3月1號(hào)開(kāi)始，容器出了兩個(gè)版本，一個(gè)是Docker的CE，一個(gè)是Docker的EE，Docker的EE是企業(yè)版，也可以說(shuō)是商業(yè)版，另外一個(gè)EE是它的社區(qū)版，也就是開(kāi)源版。它的CE和EE版里的數(shù)據(jù)卷都已經(jīng)可以支持持久化的存儲(chǔ)了。

第5個(gè)問(wèn)題日志的集中管理。容器常被用來(lái)運(yùn)行需要快速故障遷移、彈性伸縮的應(yīng)用或微服務(wù)，因此容器中運(yùn)行的應(yīng)用隨著遷移、彈性伸縮的發(fā)生，應(yīng)用日志很可能會(huì)在不同的運(yùn)行節(jié)點(diǎn)中產(chǎn)生，這對(duì)容器應(yīng)用的日志監(jiān)控和問(wèn)題排查帶來(lái)了很大的麻煩。相對(duì)來(lái)說(shuō)，和大多數(shù)傳統(tǒng)應(yīng)用把日志寫在本地文件系統(tǒng)不同的是，容器應(yīng)用需要考慮把日志進(jìn)行集中收集，然后寫入外部的集中日志管理系統(tǒng)中。傳統(tǒng)的日志匯總收集方案主要有商業(yè)軟件 Splunk、開(kāi)源軟件棧 ELK 和 Facebook 開(kāi)源的 Scribe 等，其中以 ELK 最為廣泛使用。典型的 ELK 架構(gòu)，優(yōu)點(diǎn)是搭建簡(jiǎn)單、易于上手，缺點(diǎn)是 Logstash 耗費(fèi)資源較大，運(yùn)行占用 CPU 和內(nèi)存高，另外沒(méi)有消息隊(duì)列緩存，存在數(shù)據(jù)丟失隱患，建議小規(guī)模集群使用。如果大規(guī)模使用，則可以引入 Kafka（或者 Redis），增加消息隊(duì)列緩存，均衡網(wǎng)絡(luò)傳輸，再把 Logstash 和 Elasticsearch 配置為集群模式，以減輕負(fù)荷壓力。Logstash 占用系統(tǒng)資源過(guò)多，后來(lái)又有了 Fluentd，替代了 Logstash，被稱作是社區(qū)方案中的 EFK，相比 Logstash 等傳統(tǒng)日志收集工具，F(xiàn)luentd 的日志收集功能對(duì)容器支持的更加完備。

在容器日志收集的時(shí)候，要注意以下兩點(diǎn)：1、避免寫日志沖突。最簡(jiǎn)單的方式就是讓容器在運(yùn)行時(shí)掛載外部共享存儲(chǔ)卷當(dāng)做應(yīng)用的日志目錄，這樣應(yīng)用的日志會(huì)被實(shí)時(shí)寫入外部共享存儲(chǔ)以備后續(xù)處理。這種方式需要我們做好控制，不同的容器不能掛載同一個(gè)外部卷，否則就會(huì)出現(xiàn)寫日志沖突的問(wèn)題，容器遷移的時(shí)候還需要重新掛卷。2、不可忽視日志標(biāo)準(zhǔn)化。當(dāng)我們采用容器來(lái)運(yùn)行微服務(wù)架構(gòu)應(yīng)用，一個(gè)業(yè)務(wù)調(diào)用往往需要經(jīng)過(guò)多個(gè)微服務(wù)的調(diào)用鏈，整個(gè)業(yè)務(wù)處理過(guò)程的日志記錄分散在不同的微服務(wù)日志中，這對(duì)通過(guò)日志進(jìn)行問(wèn)題診斷帶來(lái)了很大的不便。通過(guò)標(biāo)準(zhǔn)化日志，例如帶上唯一的 ID 信息等，可以實(shí)現(xiàn)把同一個(gè)業(yè)務(wù)在不同微服務(wù)中的處理過(guò)程給關(guān)聯(lián)起來(lái)。通過(guò)標(biāo)準(zhǔn)化的應(yīng)用日志，我們可以對(duì)交易率、成功率、響應(yīng)時(shí)間等關(guān)鍵業(yè)務(wù)指標(biāo)進(jìn)行統(tǒng)一關(guān)聯(lián)分析，作為問(wèn)題預(yù)警、診斷分析、容量擴(kuò)縮的科學(xué)依據(jù)。

第6個(gè)問(wèn)題容器的監(jiān)控怎么做。在虛擬機(jī)運(yùn)維的時(shí)代，Nagios 和 Zabbix 等都是十分經(jīng)典的性能監(jiān)控軟件。但在容器時(shí)代，這些曾經(jīng)耳熟能詳?shù)能浖?，大多不能提供方便的容器化服?wù)的監(jiān)控體驗(yàn)，社區(qū)對(duì)開(kāi)發(fā)這類插件和數(shù)據(jù)收集客戶端也并不積極。相反的是許多新生的開(kāi)源監(jiān)控項(xiàng)目將對(duì)容器的支持放到了關(guān)鍵特性的位置，一代新人換舊人，可以說(shuō)容器的應(yīng)用界定了一個(gè)全新的監(jiān)控軟件時(shí)代。在這些新生的監(jiān)控工具中，有三種比較流行且成熟的具體方案，分別是 cAdvisor、cAdvisor + InfluxDB + Grafana 和 Prometheus.其中基于 InfluxDB 的方案是一個(gè)多種開(kāi)源組件的組合方案，而基于 Prometheus 的方案是作為一種整體解決方案。它本身對(duì)容器信息的收集能力以及圖表展示能力相比其他專用開(kāi)源組件較弱，通常在實(shí)際實(shí)施的時(shí)候依然會(huì)將它組合為 cAdvisor + Prometheus 或 cAdvisor + Prometheus+ Grafana 的方式來(lái)使用，但它多維度的數(shù)據(jù)模型，可方便的進(jìn)行數(shù)據(jù)過(guò)濾和聚合。說(shuō)到容器應(yīng)用的監(jiān)控設(shè)計(jì)，在這里要注意監(jiān)控是分層的，具體可以分為系統(tǒng)層面、應(yīng)用層面和服務(wù)層面，每個(gè)層面都有自己的監(jiān)控重點(diǎn)。1、系統(tǒng)層面，主要是針對(duì)資源使用情況、網(wǎng)絡(luò)連通性、節(jié)點(diǎn)健康情況的監(jiān)控。傳統(tǒng)的監(jiān)控系統(tǒng)在這方面已經(jīng)非常完備，我們直接可以利用傳統(tǒng)的監(jiān)控系統(tǒng)對(duì)容器平臺(tái)的宿主機(jī)進(jìn)行系統(tǒng)層面的監(jiān)控，對(duì)接監(jiān)控大屏幕等。宿主機(jī)上單個(gè)容器本身的性能和資源使用情況，對(duì)于外部資源監(jiān)控意義不大，也沒(méi)有多大必要傳送到外部的傳統(tǒng)監(jiān)控。2、應(yīng)用層面。容器平臺(tái)本身通常都帶有類似 K8S 的 replication control 這樣的機(jī)制保持某個(gè)服務(wù)運(yùn)行實(shí)例數(shù)量的能力，所以通常情況下容器平臺(tái)都能保證應(yīng)用和應(yīng)用下每個(gè)微服務(wù)的運(yùn)行正常。關(guān)于應(yīng)用層面的健康監(jiān)控，還是需要來(lái)對(duì)接傳統(tǒng)的監(jiān)控系統(tǒng)，進(jìn)行適當(dāng)?shù)母婢敵?，比如?dāng)遇到應(yīng)用邏輯錯(cuò)誤而導(dǎo)致啟動(dòng)反復(fù)失敗或資源不足，導(dǎo)致啟動(dòng)總是不成功等問(wèn)題時(shí)，容器平臺(tái)本身的 replication control 機(jī)制就不能解決問(wèn)題了。這種情況就需要我們把應(yīng)用的故障信息傳遞到外部監(jiān)控，并根據(jù)問(wèn)題的嚴(yán)重情況進(jìn)行不同等級(jí)的告警通知等，由相關(guān)的應(yīng)用人員介入來(lái)解決問(wèn)題，比如升級(jí)補(bǔ)丁或回退等。

3、服務(wù)層面。服務(wù)層面則是監(jiān)控應(yīng)用提供的服務(wù)是否運(yùn)行正常。例如某個(gè)提供 Web 服務(wù)的應(yīng)用，在一些時(shí)候雖然應(yīng)用和應(yīng)用中微服務(wù)的運(yùn)行實(shí)例數(shù)量正常，但它的 Web 服務(wù)已經(jīng)失去響應(yīng)，或者返回的是錯(cuò)誤的狀態(tài)，這種情況在多數(shù)容器平臺(tái)中是無(wú)法監(jiān)測(cè)到的。傳統(tǒng)的方式是通過(guò)打探針 Agent 方式，但在容器環(huán)境下，這種方式不一定可行，這就需要我們豐富容器故障的監(jiān)測(cè)手段或者自己編寫服務(wù)訪問(wèn)+檢測(cè)邏輯來(lái)判斷，并把檢測(cè)出現(xiàn)的問(wèn)題上報(bào)到外部監(jiān)控，在監(jiān)控中設(shè)立相應(yīng)的告警策略和告警等級(jí)。

第七就是容器的多租戶和權(quán)限設(shè)計(jì)，在這里面其實(shí)容器這塊處理的還不是特別好。比如給一個(gè)容器分配了200兆內(nèi)存，你看到的實(shí)際上是物理機(jī)的64G內(nèi)存，而不是真正你分給容器的這個(gè)內(nèi)存。多租戶，顧名思義，就是很多人來(lái)租用容器云平臺(tái)的資源來(lái)實(shí)現(xiàn)自己的應(yīng)用托管運(yùn)維需求。這里面主要涉及多租戶、資源管理與分配、安全權(quán)限管理這三個(gè)問(wèn)題。

1、多租戶的問(wèn)題。從多租戶的角度考慮，租戶租用容器云平臺(tái)的資源來(lái)托管、開(kāi)發(fā)、部署運(yùn)維自己的應(yīng)用、服務(wù)。容器云平臺(tái)需要提供、維護(hù)保障租戶能正常使用這些資源，同時(shí)給租戶托管的應(yīng)用提供服務(wù)注冊(cè)、服務(wù)發(fā)現(xiàn)、服務(wù)配置、日志、監(jiān)控、預(yù)警告警、彈性伸縮、負(fù)載均衡、安全等能力。我們要明白的是租戶只是租用這些能力，它并不運(yùn)維這些能力。租戶關(guān)注的是托管的應(yīng)用和服務(wù)，它需要做的是利用平臺(tái)提供的這些能力來(lái)無(wú)縫的運(yùn)維他們的應(yīng)用和服務(wù)。一句話來(lái)總結(jié)：租戶只是使用/租用資源，容器云平臺(tái)管理運(yùn)維這些資源。租戶側(cè)重于對(duì)自己的應(yīng)用或服務(wù)進(jìn)行運(yùn)維。資源由租戶申請(qǐng)，容器云平臺(tái)來(lái)分配管理資源。

2、資源管理與分配。這部分功能建議統(tǒng)一由運(yùn)維團(tuán)隊(duì)或者系統(tǒng)團(tuán)隊(duì)負(fù)責(zé)，應(yīng)用系統(tǒng)上云前一般會(huì)進(jìn)行壓測(cè)，有個(gè)容量估算的過(guò)程。通過(guò)容量估算和趨勢(shì)分析，系統(tǒng)人員可以規(guī)劃大致的資源池給相關(guān)應(yīng)用，一般可以通過(guò)劃分底層資源池實(shí)現(xiàn)。如果用 K8S，可以在計(jì)算節(jié)點(diǎn)上通過(guò) lables 進(jìn)行規(guī)劃，另外還需要在編排文件上設(shè)置好最小資源和最大資源，讓應(yīng)用可以彈性擴(kuò)容。

3、安全權(quán)限管理。多租戶的安全權(quán)限設(shè)計(jì)涉及到容器云平臺(tái)整體的權(quán)限控制架構(gòu)，最好是實(shí)現(xiàn)一個(gè)權(quán)限中心，由權(quán)限中心來(lái)實(shí)現(xiàn)對(duì)容器云各組件及各功能的動(dòng)態(tài)控制，以適應(yīng)靈活的不同的場(chǎng)景需求。

第八就是容器與 OpenStack 和 Kubernetes 集成的能力。在開(kāi)源云計(jì)算技術(shù)蓬勃發(fā)展的這幾年中，OpenStack、Kubernetes、Container 無(wú)疑成為了改變?cè)朴?jì)算格局的三項(xiàng)關(guān)鍵技術(shù)。但是這三者之間在技術(shù)上仍然存在一個(gè)空白：容器運(yùn)行時(shí)強(qiáng)安全隔離的同時(shí)保持精簡(jiǎn)尺寸以及輕量級(jí)，以及如何能夠很容易與 OpenStack 和 Kubernetes 兩大平臺(tái)集成從而獲取多租戶以及統(tǒng)一網(wǎng)絡(luò)和統(tǒng)一存儲(chǔ)等諸多好處，這個(gè)空白阻礙了用戶從中獲取更大價(jià)值。為了解決這一問(wèn)題，OpenStack 基金會(huì)在今年 12 月 5 日的 KubeCon 峰會(huì)上發(fā)布了一項(xiàng)新的開(kāi)源項(xiàng)目，Kata Containers.Kata 可以使用戶同時(shí)擁有虛擬機(jī)的安全和容器技術(shù)的迅速和易管理性。項(xiàng)目可以屏蔽硬件差異并且和 OCIspeciaification、Kubernetes 容器運(yùn)行時(shí)標(biāo)準(zhǔn)兼容，在支持標(biāo)準(zhǔn)鏡像格式的同時(shí)具有強(qiáng)隔離、輕量級(jí)以及快速啟動(dòng)能力。無(wú)疑 Kata 項(xiàng)目的發(fā)起為 OpenStack、Kubernetes 和 Container 更好的融合提供了有力的支撐，并為用戶從中收益鋪平了道路。期待容器真正輝煌時(shí)代的降臨，但未來(lái)的道路，依然任重道遠(yuǎn)！

第九個(gè)問(wèn)題就是容器云如何實(shí)現(xiàn)高可用和跨區(qū)部署。容器云需要考慮平臺(tái)自身的高可用，實(shí)現(xiàn)多可用區(qū)多部署。容器上的應(yīng)用高可用需要結(jié)合應(yīng)用架構(gòu)來(lái)實(shí)現(xiàn)。目前微服務(wù)架構(gòu)是最適合云基礎(chǔ)設(shè)施的應(yīng)用架構(gòu)之一。微服務(wù)應(yīng)用通過(guò)服務(wù)注冊(cè)發(fā)現(xiàn)、全局配置管理、熔斷、服務(wù)追蹤等容錯(cuò)設(shè)計(jì)，保證應(yīng)用的高可用。彈性擴(kuò)容，增加微服務(wù)運(yùn)行的實(shí)例數(shù)量，配合負(fù)載均衡策略的使用，減少因壓力過(guò)大而導(dǎo)致運(yùn)行實(shí)例宕機(jī)的情況。

最后總結(jié)一下，容器技術(shù)在企業(yè)的落地，不是一蹴而就的，是一個(gè)漸進(jìn)和價(jià)值普及的過(guò)程。通常我們聽(tīng)到一句話，就是說(shuō)先進(jìn)一步是先烈，先進(jìn)兩步是先驅(qū)，任何新技術(shù)出來(lái)之后不要跑的太快，因?yàn)檫€有很多坑沒(méi)有完全踩過(guò)，也不知道這條路能不能走的平坦和順暢，有時(shí)候跑的太快，就成為先驅(qū)了。技術(shù)的更迭方式可以是潛移默化的和平演變，亦或是轟轟烈烈的武裝革命，容器技術(shù)應(yīng)該歸屬于前者。我們可以看到，容器化技術(shù)已經(jīng)成為計(jì)算模型演化的一個(gè)開(kāi)端，可以預(yù)見(jiàn)在更高效和輕量化的平臺(tái)實(shí)踐之后，容器技術(shù)還將為整個(gè) IT 領(lǐng)域注入更多新鮮和活力，在未來(lái)生存和壯大下去，成為引領(lǐng)潮流的決定性力量！

我的分享就到這些，謝謝！

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

歡迎來(lái)電咨詢0574 88168918,郵箱sales@cobinet.cn，網(wǎng)址78867.cn