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

WOT2018開源與容器技術分論壇現場

其中，開源與容器技術分論壇著眼于開源容器的構建，結合實際場景，旨在幫助開發(fā)者了解國內外相關企業(yè)的容器應用案例，在選型、落地過程中的實踐經驗以及總結思考。

知乎容器平臺演進及與大數據融合實踐

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

[[232933]]

知乎計算平臺負責人 張阜興

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

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

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

·Docker 容器端口泄露：Docker Daemon 從分配使用端口到記錄下這個端口的過程不是原子 的，如果 Docker Daemon 在中間階段退出后，在重啟恢復流程中忽略了這個已經分配的端口，就會導致容器端口泄露。

·TCP Connection Reset：在 Docker NAT 網絡模式下會出現 TCP Connection Reset 的問題。主要是系統默認的配置對于網絡數據包亂序過于嚴格，對于公網等比較差的網絡環(huán)境，當亂序包超過 TCP 窗口后連接被 Reset 掉了。

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

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

容器技術在雪球的實踐

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

[[232934]]

雪球網***運維開發(fā)架構師 董明鑫

隨著業(yè)務的發(fā)展，不同業(yè)務之間受到影響的概率比較高，雪球希望業(yè)務之間不被相互打擾，為了滿足這種隔離的需求，雪球發(fā)現容器技術其實比較合適，因為容器本身鏡像比較小，比較靈活，啟動速度快，相比虛擬機，更適合雪球的業(yè)務發(fā)展，經過比較，雪球最終選擇了Docker。

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

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

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

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

Kubernetes 網絡更進一步

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

[[232935]]

靈雀云K8S***專家 劉夢馨

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

為了解決這一問題，靈雀云把IP當做重要資源，進行單獨管理。靈雀云自研的CNI IPAM 插件，實現了IP導入和IP權限管理功能，可以進行網段的添加和刪除，可在Kubernetes進行網段的精細化配置。

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

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

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

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

分布式鏡像倉庫技術解析

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

[[232936]]

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

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

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

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

鏡像分發(fā)的目的就是需要一個倉庫，是能打包、存儲、分發(fā)容器的倉庫：

·Docker Hub是公有云實現，沒有可以參考的技術架構；

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

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

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

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

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

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

以上內容是51CTO記者根據WOT2018全球軟件與運維技術峰會的《開源與容器技術》分論壇演講內容整理，更多關于WOT的內容請關注51cto.com。

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