【51CTO.com原創(chuàng)稿件】2018年5月18-19日，由51CTO主辦的全球軟件與運(yùn)維技術(shù)峰會(huì)在北京召開。來自全球企業(yè)的技術(shù)精英匯聚北京，暢談軟件技術(shù)前沿，共同探索運(yùn)維技術(shù)的新邊界。在本次大會(huì)上，除了眾星云集的主論壇環(huán)節(jié)，12場(chǎng)分論壇更是各具特色，分別聚焦了時(shí)下最受關(guān)注的容器、AI、區(qū)塊鏈、大數(shù)據(jù)、高并發(fā)、物聯(lián)網(wǎng)等前沿技術(shù)領(lǐng)域。

WOT2018開源與容器技術(shù)分論壇現(xiàn)場(chǎng)

其中，開源與容器技術(shù)分論壇著眼于開源容器的構(gòu)建，結(jié)合實(shí)際場(chǎng)景，旨在幫助開發(fā)者了解國(guó)內(nèi)外相關(guān)企業(yè)的容器應(yīng)用案例，在選型、落地過程中的實(shí)踐經(jīng)驗(yàn)以及總結(jié)思考。

知乎容器平臺(tái)演進(jìn)及與大數(shù)據(jù)融合實(shí)踐

知乎計(jì)算平臺(tái)負(fù)責(zé)人張阜興結(jié)合知乎在生產(chǎn)環(huán)境集群中所遇到的問題，和大家交流容器使用方式和注意事項(xiàng)，以及在大數(shù)據(jù)處理和容器技術(shù)融合方面所做的嘗試探索。張阜興表示，知乎容器平臺(tái)演進(jìn)分為四個(gè)階段：從 Mesos 到 Kubernetes，從單集群到混合云架構(gòu)，從滾動(dòng)部署到部署發(fā)布分離，以及從無狀態(tài)到有狀態(tài)。

[[232933]]

知乎計(jì)算平臺(tái)負(fù)責(zé)人 張阜興

由于容器平臺(tái)是基礎(chǔ)組件中的基礎(chǔ)組件，因此每一個(gè)坑可能都是一個(gè)生產(chǎn)環(huán)境的重大故障。張阜興為聽眾著重分享了在容器平臺(tái)會(huì)遇到的幾個(gè)坑：

·K8S events：在一個(gè)月黑風(fēng)高的夜晚，K8S API Server無法訪問開始報(bào)警，整個(gè)K8S 集群失去控制。后來查明原因，是 events 引起的鍋。它是 K8S 集群變更事件記錄，默認(rèn)會(huì)寫入到etcd中，etcd 的 TTL 是采用遍歷實(shí)現(xiàn)，效率比較差，隨著集群規(guī)模變大，終于導(dǎo)致 etcd 集群崩潰了。查明原因后，通過 K8S 的配置將 events 隔離到獨(dú)立的 etcd 集群，同時(shí)這個(gè) etcd 集群只用單節(jié)點(diǎn)去除 raft 的開銷，在每天晚上清空這個(gè)節(jié)點(diǎn)，替代 TTL 機(jī)制。

·K8S Eviction：在 1.5 版本之前的 Kubernetes 里，Controller Manager 會(huì)將不能訪問的 Node 上的 Pods 刪除，如果 API server 全部掛掉超過一定時(shí)間再恢復(fù)后，Controller Manager 會(huì)刪除所有 Pod 實(shí)例。在 1.5 版本后，可以通過配置 unhealthy-zone-threshold， 防止在 node 節(jié)點(diǎn)大規(guī)模異常時(shí)對(duì)集群Pods進(jìn)行誤驅(qū)逐。

·Docker 容器端口泄露：Docker Daemon 從分配使用端口到記錄下這個(gè)端口的過程不是原子 的，如果 Docker Daemon 在中間階段退出后，在重啟恢復(fù)流程中忽略了這個(gè)已經(jīng)分配的端口，就會(huì)導(dǎo)致容器端口泄露。

·TCP Connection Reset：在 Docker NAT 網(wǎng)絡(luò)模式下會(huì)出現(xiàn) TCP Connection Reset 的問題。主要是系統(tǒng)默認(rèn)的配置對(duì)于網(wǎng)絡(luò)數(shù)據(jù)包亂序過于嚴(yán)格，對(duì)于公網(wǎng)等比較差的網(wǎng)絡(luò)環(huán)境，當(dāng)亂序包超過 TCP 窗口后連接被 Reset 掉了。

張阜興總結(jié)說，從實(shí)踐的經(jīng)驗(yàn)看，基本思路就是按業(yè)務(wù)方進(jìn)行集群隔離，利用K8S進(jìn)行多集群部署和管理，利用Docker進(jìn)行資源隔離和監(jiān)控，利用Docker實(shí)現(xiàn)更細(xì)粒度資源分配。在管理運(yùn)維上，踐行DevOps理念，讓平臺(tái)更加專注于工具開發(fā)本身，而不是限于瑣碎的運(yùn)維操作中不能自拔。

展望未來，知乎將嘗試更多的組件利用K8S實(shí)現(xiàn)集群隔離，更細(xì)粒度的資源分配和進(jìn)程級(jí)資源監(jiān)控，從而在生產(chǎn)環(huán)境中更好的管理和維護(hù)，提升資源利用率，并在此之上，為業(yè)務(wù)提供更好的PaaS平臺(tái)服務(wù)，最終實(shí)現(xiàn)數(shù)據(jù)中心資源統(tǒng)一交由 K8S 來分配調(diào)度的 DCOS。

容器技術(shù)在雪球的實(shí)踐

雪球網(wǎng)***運(yùn)維開發(fā)架構(gòu)師董明鑫的演講，主要介紹雪球在測(cè)試及生產(chǎn)環(huán)境的容器技術(shù)使用實(shí)踐以及網(wǎng)絡(luò)模式、負(fù)載均衡、日志收集、監(jiān)控系統(tǒng)等相關(guān)組件的演進(jìn)迭代。從雪球最初引入容器技術(shù)的原因開始說起，探討各種方案的優(yōu)劣，向大家展示了雪球如何一點(diǎn)一點(diǎn)變更基礎(chǔ)設(shè)施，逐漸發(fā)展完善的過程，以及通過數(shù)據(jù)展示容器技術(shù)對(duì)于穩(wěn)定性和生產(chǎn)效率的巨大提升。 

[[232934]]

雪球網(wǎng)***運(yùn)維開發(fā)架構(gòu)師 董明鑫

隨著業(yè)務(wù)的發(fā)展，不同業(yè)務(wù)之間受到影響的概率比較高，雪球希望業(yè)務(wù)之間不被相互打擾，為了滿足這種隔離的需求，雪球發(fā)現(xiàn)容器技術(shù)其實(shí)比較合適，因?yàn)槿萜鞅旧礴R像比較小，比較靈活，啟動(dòng)速度快，相比虛擬機(jī)，更適合雪球的業(yè)務(wù)發(fā)展，經(jīng)過比較，雪球最終選擇了Docker。

在運(yùn)行過程中，雪球發(fā)現(xiàn)，使用Docker需要解決的問題主要有三個(gè)：網(wǎng)絡(luò)連通性、多節(jié)點(diǎn)的服務(wù)部署更新、以及優(yōu)秀的監(jiān)控方案。雪球希望做一個(gè)平臺(tái)，實(shí)現(xiàn)容器的物理機(jī)管理、容器的管理，以及IP和MAC地址和流程控制的管理。

經(jīng)過一段時(shí)間的使用，雪球發(fā)現(xiàn)自研的容器管理平臺(tái)雖然實(shí)現(xiàn)了流程控制與權(quán)限控制，并且將代碼與環(huán)境固化，使多版本鏡像管理更加方便，部署效率和擴(kuò)縮容效率都有所提升，但是，流程控制邏輯與機(jī)器管理、網(wǎng)絡(luò)管理之間耦合嚴(yán)重，而且，無法實(shí)現(xiàn)自動(dòng)選擇物理機(jī)和自動(dòng)分配容器 IP，沒有自愈功能。于是，雪球引入了Swarm，做了一個(gè)三層部署的模式。

后期，雪球又對(duì)此進(jìn)行了優(yōu)化，自助化的流程解放了運(yùn)維的工作，引入了優(yōu)化的調(diào)度方案，支持多機(jī)房多云環(huán)境。

***，雪球引入Kubernetes，每一個(gè)項(xiàng)目里可能有多個(gè)互聯(lián)網(wǎng)數(shù)據(jù)中心(IDC)，每一個(gè)IDC有不同的集群(Cluster)，為每一個(gè)項(xiàng)目分配一個(gè)命名空間(Namespace)，有自己的部署(Deployment)。由于Kubernetes本身的解決方案比較全面，而雪球也已經(jīng)有了很多解決方案，例如日志、負(fù)載均衡、監(jiān)控等。如何才能更低成本地引入Kubernetes，而且讓開發(fā)盡量感知不到，***的辦法是做合約的兼容性，最終，雪球只使用了Kubernetes的Deployment和HPA。

Kubernetes 網(wǎng)絡(luò)更進(jìn)一步

靈雀云K8S***專家劉夢(mèng)馨的演講圍繞Kubernetes 網(wǎng)絡(luò)模型、Kubernetes網(wǎng)絡(luò)模型問題和網(wǎng)絡(luò)改進(jìn)三部分展開。他表示，Kubernetes網(wǎng)絡(luò)模型在功能、性能和穩(wěn)定性方面均存在一些問題，靈雀云通過固定IP、IP虛擬服務(wù)器(IP Virtual Server，簡(jiǎn)寫為IPVS)和自研Ingress的方式加以改進(jìn)。 

[[232935]]

靈雀云K8S***專家 劉夢(mèng)馨

首先，在功能方面，Kubernetes 網(wǎng)絡(luò)模型由于IP不固定，無法對(duì)IP資源進(jìn)行精細(xì)管控，無法使用基于IP的監(jiān)控和基于IP的安全策略，此外，一些IP發(fā)現(xiàn)的服務(wù)部署十分困難，給運(yùn)維人員增加了很大的工作難度。

為了解決這一問題，靈雀云把IP當(dāng)做重要資源，進(jìn)行單獨(dú)管理。靈雀云自研的CNI IPAM 插件，實(shí)現(xiàn)了IP導(dǎo)入和IP權(quán)限管理功能，可以進(jìn)行網(wǎng)段的添加和刪除，可在Kubernetes進(jìn)行網(wǎng)段的精細(xì)化配置。

其次，在性能方面，由于Kubernetes最早是基于Iptables來做的，Iptables 沒有增量更新功能，更新一條規(guī)則需要整體flush，更新時(shí)間長(zhǎng)，這段時(shí)間之內(nèi)流量會(huì)有不同程度的影響；Iptables規(guī)則串行，沒有預(yù)料到Kubernetes在一個(gè)機(jī)器上會(huì)有很多規(guī)則的情況，流量需要經(jīng)過所有規(guī)則的匹配，匹配之后再進(jìn)行轉(zhuǎn)發(fā)，否則對(duì)時(shí)間、CPN和內(nèi)存都是極大的消耗，尤其在大規(guī)模情況下對(duì)性能的影響十分明顯。

劉夢(mèng)馨指出，Kubernetes升級(jí)到1.8或1.9版本以后，安裝時(shí)可以選擇IPVS模式，它是對(duì)Iptables的替換，在IPVS模式下添加規(guī)則是增量式的，不會(huì)強(qiáng)制進(jìn)行全量更新，也不會(huì)進(jìn)行串行的匹配，會(huì)通過一定的規(guī)則進(jìn)行哈希map映射，很快地映射到對(duì)應(yīng)的規(guī)則，不會(huì)出現(xiàn)大規(guī)模情況下性能線性下降的狀況。

***，在穩(wěn)定性方面，Kubernetes網(wǎng)絡(luò)缺少健康檢查功能，NodePort 屏蔽了Pod的直接訪問，上層健康檢查失效，網(wǎng)絡(luò)分區(qū)、網(wǎng)絡(luò)問題導(dǎo)致的轉(zhuǎn)發(fā)異常時(shí)有發(fā)生。

靈雀云采用自研的OpenResty Ingress，方便新增功能，可以進(jìn)行多端口監(jiān)聽。官方的Nginx Ingress只能監(jiān)聽80和43端口，但很多客戶要對(duì)更多的端口進(jìn)行監(jiān)聽，如根據(jù)端口區(qū)分的服務(wù)，靈雀云對(duì)此進(jìn)行了一些改動(dòng)，其自研的Ingress支持多端口功能。

分布式鏡像倉(cāng)庫(kù)技術(shù)解析

資深容器技術(shù)開發(fā)者肖徳時(shí)的演講主題是《分布式鏡像倉(cāng)庫(kù)技術(shù)實(shí)戰(zhàn)解析》，主要涉及OCI Distribution Specification解析、鏡像分發(fā)的現(xiàn)狀和痛點(diǎn)、業(yè)界對(duì)鏡像分發(fā)技術(shù)實(shí)戰(zhàn)解析和經(jīng)驗(yàn)總結(jié)。肖徳時(shí)表示，容器鏡像倉(cāng)庫(kù)一直以單機(jī)版本存在于社區(qū)，當(dāng)前國(guó)內(nèi)***的開源鏡像倉(cāng)庫(kù)管理系統(tǒng)Harbor也只能在架構(gòu)上提供簡(jiǎn)單的前端HA或者復(fù)制模式，無法實(shí)現(xiàn)Cloud Native下的真正分布式應(yīng)用實(shí)現(xiàn)。

[[232936]]

資深容器技術(shù)開發(fā)者 肖徳時(shí)

肖徳時(shí)介紹說，OCI是開放容器聯(lián)盟的縮寫，是業(yè)界容器標(biāo)準(zhǔn)的行業(yè)聯(lián)盟，目前主要發(fā)布了以下容器標(biāo)準(zhǔn)：runc是符合容器行業(yè)標(biāo)準(zhǔn)的創(chuàng)建和啟動(dòng)容器的命令行工具，runtime-spec是符合容器行業(yè)標(biāo)準(zhǔn)的容器運(yùn)行時(shí)標(biāo)準(zhǔn)，image-spec是符合容器行業(yè)標(biāo)準(zhǔn)的容器鏡像格式標(biāo)準(zhǔn)，distribution-spec是符合容器行業(yè)標(biāo)準(zhǔn)的容器分發(fā)標(biāo)準(zhǔn)。

distribution-spec目前還沒正式發(fā)布1.0，基本圍繞鏡像倉(cāng)庫(kù)(Docker Registry HTTP API V2)的標(biāo)準(zhǔn)作為基礎(chǔ)規(guī)范，定義范圍包括：Namespace-oriented URI Layout、PUSH/PULL registry server for V2 image manifest format、Resumable layer PUSH support、V2 Client library implementation等。

對(duì)于目前鏡像分發(fā)的現(xiàn)狀和痛點(diǎn)，他表示，Docker Registry所缺少的特性非常多，會(huì)導(dǎo)致企業(yè)無法落地，無法滿足企業(yè)的任何生產(chǎn)需求。

鏡像分發(fā)的目的就是需要一個(gè)倉(cāng)庫(kù)，是能打包、存儲(chǔ)、分發(fā)容器的倉(cāng)庫(kù)：

·Docker Hub是公有云實(shí)現(xiàn)，沒有可以參考的技術(shù)架構(gòu)；

·私有Docker DTR實(shí)現(xiàn)，偏向主備HA單機(jī)模式管理，無法適應(yīng)分布式環(huán)境下的復(fù)雜鏡像分發(fā)需求；

·Docker Registry 2.0的開源代碼distribution，沒有考慮企業(yè)特性，只能當(dāng)作類庫(kù)使用。

針對(duì)這些痛點(diǎn)，業(yè)界對(duì)鏡像分發(fā)技術(shù)進(jìn)行了很多實(shí)戰(zhàn)性的探索：

騰訊的做法就是要進(jìn)行快速分發(fā)，以更快的速度，向200個(gè)節(jié)點(diǎn)分發(fā)500M的鏡像比Docker原生方式的分發(fā)時(shí)間降低了91%；部署FID，上層系統(tǒng)如Kubernetes，無需修改任何代碼與邏輯，即可享受P2P加速。

目前，國(guó)內(nèi)使用的比較多的是Harbor，例如Vmware所推出的 Harbor 基于Docker Distribution 的企業(yè)級(jí) Registry 服務(wù)。Harbor是一個(gè)開源項(xiàng)目，提供了一個(gè)管理界面，可以實(shí)現(xiàn)分組，并可以加入一些企業(yè)特性。

***，肖徳時(shí)總結(jié)說，P2P技術(shù)可以提高分發(fā)鏡像的效率，單層體積越大分發(fā)效率越高。鏡像存儲(chǔ)可以采用共享層模式降低存儲(chǔ)的冗余度。高可用方案仍然需要大量生產(chǎn)實(shí)踐，分發(fā)標(biāo)準(zhǔn)正在進(jìn)化中。

以上內(nèi)容是51CTO記者根據(jù)WOT2018全球軟件與運(yùn)維技術(shù)峰會(huì)的《開源與容器技術(shù)》分論壇演講內(nèi)容整理，更多關(guān)于WOT的內(nèi)容請(qǐng)關(guān)注51cto.com。

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文作者和出處為51CTO.com】