近年來，云計算開源技術逐漸成為云計算發展的重要支撐和導向，改變了以往的信息技術進化模式，引領軟件技術標準的發展和創新，深刻影響著整個信息技術產業的發展格局。為進一步探索我國云計算開源技術發展模式，加速云計算與各行業的深度融合，更好地發揮云計算在經濟社會創新發展中的支撐和引領作用，促進我國云計算產業快速、健康發展。

南縣網站建設公司成都創新互聯公司,南縣網站設計制作，有大型網站制作公司豐富經驗。已為南縣上千提供企業網站建設服務。企業網站搭建\外貿網站建設要多少錢，請找那個售后服務好的南縣做網站的公司定做！

由中國信息通信研究院主辦、中國通信標準化協會支持的"OSCAR云計算開源產業大會"將于2018年3月21日－22日在國家會議中心舉行。在22日下午的工業使用開源論壇上，北京中油瑞飛信息技術有限公司資深架構師孫杰就《"容器技術在企業落地的探索和實踐"》進行了演講！

以下為演講實錄：

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

企業要用正確的姿態擁抱容器并且使用好容器，需要在應用容器技術時考慮清楚以下九個關鍵問題：

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

2、容器云技術產品如何選型？

3、容器云的網絡應該如何設計？

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

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

6、容器應用的監控方案如何設計？

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

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

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

那么，首先第一個問題企業容器云方案設計需要遵循什么原則？

首先，我們要明確企業上容器云的目的，容器是為業務服務的，任何技術都是為了能夠更好的服務業務，這是我們的出發點。其次，結合業務特點選擇合適的容器框架，比如我們的業務本身是不是可以基于新型微服務架構進行改造，業務是不是具有變化快、彈性大、更新迭代快等特點。還有要和已有系統較好地對接整合，在上容器之前，企業通常都已經有比較成熟和穩定的其他 IT 系統，例如網絡系統、集中監控系統、安全防護系統等。

為避免重復建設，同時也為了容器平臺能夠更容易被接受和使用，應讓容器平臺融入企業原有的整個 IT 系統，而不是另起爐灶重新建設。容器平臺要承載生產業務，也需要滿足安全的監管合規要求，例如隔離不同安全等級的應用、支持對應用容器的安全漏洞掃描、安全有效的防火墻策略管理等。生產環境的業務要求高可用性、連續性，還應該考慮整個容器應用層面的高可用性和數據連續性、安全可靠。

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

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

應用容器技術帶來的挑戰和改變，大家可以看到，容器帶來的改變，第一，它可以直接通過鏡像封裝你的應用，可以根據你的dockerfile命令行直接構建你所需要的應用，提供了一種比較廣泛認可的交付協議。第二，資源的提供者可以無差別的對待你的資源需求，為構建統一的IT支撐平臺提供了可行性。另外就是研發流程自動化（CI）、 應用模式化（微服務、彈性）、 標準化、自動化，這些都可以做到更快的響應業務的變化。

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

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

一個企業在應用新技術前，還需要考慮 IT 部門自身的技術能力，包括開發能力、運維能力，同時對自身業務系統從開發平臺、開發過程、開發規范等有決定能力。如果企業自身的開發和運維能力不強，則采用成熟的 PCF、OpenShift 等方案是不錯的選擇。如果考慮現有系統對接需求，包括監控、網絡、安全需求等，特別是現有網絡架構對容器的網絡方案有較大影響時，應該考慮使用 Kubernetes、Mesos、Swarm 等開源方案更便于定制，也能較好的融入現有 IT 系統。

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

企業規模不大，應用不是太復雜

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

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

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

企業規模大、業務復雜、應用粒度更細

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

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

隨著容器技術在企業生產系統的逐步落地，用戶對于容器云的網絡特性要求也越來越高，跨主機容器間的網絡互通已經成為最基本的要求。跨主機的容器網絡解決方案不外乎三大類：

隧道方案

比如 Flannel 的 VxLan，特點是對底層的網絡沒有過高的要求，一般來說只要是三層可達就可以，只要是在一個三層可達網絡里，就能構建出一個基于隧道的容器網絡。不過問題也很明顯，一個得到大家共識的是隨著節點規模的增長、復雜度會提升，而且出了網絡問題跟蹤起來比較麻煩，大規模集群情況下，這是需要考慮的一個點。

路由方案

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

VLAN

所有容器和物理機在同一個 VLAN 中。

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

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

從2017年3月1號開始，容器出了兩個版本，一個是Docker的CE，一個是Docker的EE，Docker的EE是企業版，也可以說是商業版，另外一個EE是它的社區版，也就是開源版。它的CE和EE版里的數據卷都已經可以支持持久化的存儲了。

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

在容器日志收集的時候，要注意以下兩點：1、避免寫日志沖突。最簡單的方式就是讓容器在運行時掛載外部共享存儲卷當做應用的日志目錄，這樣應用的日志會被實時寫入外部共享存儲以備后續處理。這種方式需要我們做好控制，不同的容器不能掛載同一個外部卷，否則就會出現寫日志沖突的問題，容器遷移的時候還需要重新掛卷。2、不可忽視日志標準化。當我們采用容器來運行微服務架構應用，一個業務調用往往需要經過多個微服務的調用鏈，整個業務處理過程的日志記錄分散在不同的微服務日志中，這對通過日志進行問題診斷帶來了很大的不便。通過標準化日志，例如帶上唯一的 ID 信息等，可以實現把同一個業務在不同微服務中的處理過程給關聯起來。通過標準化的應用日志，我們可以對交易率、成功率、響應時間等關鍵業務指標進行統一關聯分析，作為問題預警、診斷分析、容量擴縮的科學依據。

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

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

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

1、多租戶的問題。從多租戶的角度考慮，租戶租用容器云平臺的資源來托管、開發、部署運維自己的應用、服務。容器云平臺需要提供、維護保障租戶能正常使用這些資源，同時給租戶托管的應用提供服務注冊、服務發現、服務配置、日志、監控、預警告警、彈性伸縮、負載均衡、安全等能力。我們要明白的是租戶只是租用這些能力，它并不運維這些能力。租戶關注的是托管的應用和服務，它需要做的是利用平臺提供的這些能力來無縫的運維他們的應用和服務。一句話來總結：租戶只是使用/租用資源，容器云平臺管理運維這些資源。租戶側重于對自己的應用或服務進行運維。資源由租戶申請，容器云平臺來分配管理資源。

2、資源管理與分配。這部分功能建議統一由運維團隊或者系統團隊負責，應用系統上云前一般會進行壓測，有個容量估算的過程。通過容量估算和趨勢分析，系統人員可以規劃大致的資源池給相關應用，一般可以通過劃分底層資源池實現。如果用 K8S，可以在計算節點上通過 lables 進行規劃，另外還需要在編排文件上設置好最小資源和大資源，讓應用可以彈性擴容。

3、安全權限管理。多租戶的安全權限設計涉及到容器云平臺整體的權限控制架構，最好是實現一個權限中心，由權限中心來實現對容器云各組件及各功能的動態控制，以適應靈活的不同的場景需求。

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

第九個問題就是容器云如何實現高可用和跨區部署。容器云需要考慮平臺自身的高可用，實現多可用區多數據中心部署。容器上的應用高可用需要結合應用架構來實現。目前微服務架構是最適合云基礎設施的應用架構之一。微服務應用通過服務注冊發現、全局配置管理、熔斷、服務追蹤等容錯設計，保證應用的高可用。彈性擴容，增加微服務運行的實例數量，配合負載均衡策略的使用，減少因壓力過大而導致運行實例宕機的情況。

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

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

分享標題：孫杰：“容器技術在企業落地的探索和實踐”
文章源于：http://m.newbst.com/article26/sjjg.html

成都網站建設公司_創新互聯，為您提供Google、網站營銷、網站設計、關鍵詞優化、網站維護、面包屑導航

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯