業界docker實現的技術
阿新 • • 發佈:2019-01-14
插件 代理 輸出 distrib 形式 但是 work 避免 控制 業界使用架構
- 京東
- Openstack Icehouse + docker1.3 + OVS2.1.3/2.3.2+Centos6.6 ==> K8s + Docker + Flannel +Neutron + OVS + DPDK +JFS
- 某個容器失效,自動觸發RC(保持IP丌變“遷移”)
- OVS-VLAN
- 知乎
- Git+Jenkins(CI/CD) + mesos + 自研framework + group(隔離) + Consul + haproxy + DNS + Graphite + cAdvisor
- 通過group做故障隔離
- 鏡像倉庫通過hdfs和水平擴展做高可用
- Mesos 集群的橫向擴展
- docker網絡
- bridge
- NAT is not bad
- iptables 有些坑
- 服務發現
- DNS Client
- 自動Scale
- 突發響應 & 資源高效利用
- 根據cpu指標調整容器數量
- 快伸慢縮
- Max & Min Hard Limit
- 支持自定義指標
- Git+Jenkins(CI/CD) + mesos + 自研framework + group(隔離) + Consul + haproxy + DNS + Graphite + cAdvisor
- 攜程
- Openstack + Mesos + Docker + Chronos + ELK
- 監控:telegraf -> Influxdb -> Grafana
- 日誌:elk
- mesos stdout、stderr
- 去哪兒
- OpenStack + nova-docker + VLAN =>Mesos + Marathon + Docker(--net=host) + 隨機端口 => Mesos + Marathon + Docker + Calico
- 阿裏電商雲
- 自研EWS, 基於compose, 參考Kubernetes的設計. 支持多region.
- cAdvisor + InfuxDB + prometheus
- etcd + consul + zk + docker overlay
- 使用RDS,OSS,OCS等服務化存儲
- docker容器的正確姿勢
- 每次代碼提交重新構建鏡像
- 禁止修改運行中的鏡像
- 利用volume保存持久化數據
- 存儲管理
- 利用docker volume plugin支持不同的存儲類型
- 塊存儲,雲盤
- 對象存儲,OSSFS
- 網絡文件系統 NFS
- 利用docker volume plugin支持不同的存儲類型
- 自研EWS, 基於compose, 參考Kubernetes的設計. 支持多region.
- 同程
- swarm + swarm agent + etcd + zabbix + Jenkins + (Nginx+Lua) + 配置中心
- 使用現狀
- 容器5000個,高峰擴容到8000
- Docker應用600個, 塞入容器的還有:Mongodb, Redis,Mysql
- cpu利用率由20%提升為80%
- 資源隔離層面
- 物理機利用率提升,合理的編排應用
- 各應用間資源隔離,避免環境和資源的沖突,提示安全性
- 爆發式流量進入: 快速擴容和遷移
- 應用遷移: 減少買服務器的花費
- 運維工作: 更多的自動化,更精細化的監控和報警
- 優化
- dockfile 優化,縮小層數從20層到5層,構建速度快1倍
- 存儲驅動從devicemapper改到overlayfs,構建速度快1倍
- 發布一個較大應用,耗時只需40s
- 自動測試系統直接調用容器系統部署環境,測試完成就可回收,供其他測試使用
- 實測物理機和Container之間的性能幾乎沒有損耗
- redis性能對比: redis-benchmark -h 127.0.01 -p6379 -q -d 100
- 鏡像管理
- 基礎鏡像池的建設
- 基礎鏡像之上再構建應用鏡像
- 應用鏡像每次發布時重新構建
- 應用鏡像多版本存儲
- 一次構建鏡像,各處可用
- 各應用的回滾、擴容全部基於應用的鏡像來完成
- 網絡的思考
- 在私有雲的網絡可控性本身比較高
- 多租戶的隔離在私有雲的意義不多
- 穩定可控可擴展才是急需求
- 整體帶寬的高保證
- 對docker容器的網絡考慮
- 本機網絡模式和OVS模式
- 本機網絡模式:如web
- OVS模式: 如數據分析
- 本機網絡模式和OVS模式
- 網易蜂巢
- openstack + K8S + etcd + OpenFlow + iscsi + Ceph + billing + 多機房
- 騰訊
- Kubernetes + 網絡(Bridge + VLAN / SR-IOV / overlay) + lxcfs + Ceph + configmap\secret + 藍鯨管控平臺
- 目前,大概有15000多常駐的Docker容器, Docker平臺上已經跑了數十款端遊、頁遊和手遊
- 集群都是同時兼容Docker應用和非Docker類型的應用的
- Gaia將網絡和CPU、內存一樣,作為一種資源維度納入統一管理。業務在提交應用時指定自己的網絡IO需求,我們使用TC(Traffic Control)+ cgroups實現網絡出帶寬控制,通過修改內核,增加網絡入帶寬的控制
- 具體網絡選型
- 集群內 pod 與 pod 的之間的通信,由於不需要內網 IP(可以用虛擬 IP)所以采用 overlay 網絡,由 flannel 組件實現。
- 公司內網到集群內 pod 通信,例如 HAProxy,遊戲某些模塊,采用 SR-IOV 網絡,由自己定制的 sriov-cni 組件實現。這類 pod 具備雙重網絡, eth0 對應 overlay 網絡, eth1 對應 SR-IOV 網絡。
- pod 到公司內網之間的通信。在微服務場景下,遊戲的數據存儲,周邊系統等,部署在物理機或者虛擬機上,因此 pod 到這些模塊、系統的訪問,走的是 NAT 網絡。
- (Internet) 接入,采用公司的 TGW 方案。
- 滴滴
- Kubernetes
- 目前了解的資料,滴滴使用docker化的時間不長,沒有太多參考架構設計
- uber
- 待補充
- 蘑菇街
- Kubernetes + VLAN
- 七牛雲
- Mesos + 自研容器調度框架(DoraFramework) + Bridge+ NAT + Open vSwitch + Consul + Prometheus + Ansible
- 七牛目前已經達到近千臺物理機的規模, mesos支持大規模調度更合適
- 不選擇Mesos的核心框架Marathon 而選擇自研
- Marathon有些方面不支持我們期望的使用姿勢,比如不太好無縫對接服務發現
- Marathon采用 scala 開發,出了問題不好排查,也不方便我們做二次開發
- 如果選用 Marathon的話,我們上面還是要再做一層對 Marathon的包裝才能作為Dora的調度服務,這樣模塊就會變多,部署運維會復雜
- 魅族雲
- OVS & VLAN + SR-IOV +ceph(保證鏡像存儲可靠性) + 自己現有的監控系
- 主機間Container通過大二層網絡通訊,通過vlan隔離
- 異地鏡像同步
- 容器設計理念
- 容器化的虛擬機,創建的Container需要長時間運行
- 每個Container擁有獨立、唯一的IP
- 主機間Container通過大二層網絡通訊,通過vlan隔離
- Container開啟ssh服務,可通過堡壘機登陸
- Container開啟其他常用服務,如crond
- 網絡
- Iperf test: Bridge < OVS veth pair < OVS internal port
- Iperf test: Native > SR-IOV > OVS > Bridge
- Docker with DPDK
- 輪詢處理數據包,避免中斷開銷
- 用戶態驅動,避免內存拷貝、系統調用 - CPU親和、大頁技術
- Idea
- virtio作後端接口
- 用戶態socket掛載到Container
- Container內跑DPDK applications
- Container存儲
- Devicemapper: 成熟穩定, 裸設備, snapshot
- IOPS: Native 基本等於 Devicemapper
- 數據盤存儲-LVM
- 按Container進行配額, 支持在線更改配額
- 鏡像存儲與同步
- 鏡像存儲
- LVS前端負載均衡,保證高可用
- distribution管理鏡像
- 後端ceph保證鏡像存儲可靠性
- 異地鏡像同步
- webhook notification機制
- 強一致同步機制
- 鏡像存儲
- 容器集群調度系統
- 調度請求落到集群相應節點
- 根據IDC、資源與區、Container類型篩選宿主機
- 根據宿主機資源狀態、請求的CPU/內存/磁盤大小動態調度
- 機櫃感知,將同一業務Container調度到不同機櫃
- ucloud
- kubernetes + Jenkins
- -v 掛載到主機, Flume/Logstash/rsyslog + elasticserach (日誌)
- vswitch overlay的"大二層"網絡SDN組網方案 + ipvlan
- 主要問題類型和解決思路
- 模塊配置
- 模塊上下遊關系, 後端服務
- 運行環境,機房的差異性配置等
- 一致性和依賴
- 開發、測試、運行環境的不一致性
- 依賴於不同的基礎庫
- 部署
- 部署效率低下,步驟多,耗時長
- 部署狀態缺少檢查機制
- 應用管理
- 大量容器實例的管理、擴容、縮容成本高
- 程序構建、打包、運行和運維統一管理
- 監控、日誌分析
- 解決方案
- 模塊配置
- 分離環境、IDC、資源類等差異化的配置項信息
- 配置模板,提交到cedebase進行版本化管理
- 對不同的deploys派生不同配置值,填充模板,啟動腳本
- 運行在不同的deploys匯總,只需通過環境變量傳遞給container即可
- 一致性和依賴
- 開發、測試、線上運行環境均采用docker生成的鏡像,保證一致
- 基礎系統、基本工具、框架,分層構建
- 基礎鏡像在開發、測試、線上環境統一預部署
- 私有鏡像倉庫
- V2版本
- 支持UFile驅動
- 定時pull最新鏡像
- 模塊配置
- 一些經驗
- docker日誌
- 日誌打印耗費性能
- 最好關閉logdriver,將日誌打印在後臺
- docker daemon
- 退出kill container, 升級docker daemon, kill可選
- docker網絡
- NAT模式下會啟用nf_conntrack,造成性能下降,調節內核參數
- docker鏡像
- 編寫dockfile規範、減少鏡像層數,基礎部分放前面
- 分地域部署鏡像registry
- docker日誌
- 模塊配置
- kubernetes + Jenkins
主要問題
- 單實例性能調優 + 萬兆卡的性能發揮出來。需要對OVS(Open vSwitch)做一些改進
- 多機房:多機房及可用域支持
- 容器網絡需求
- Iptables 有些坑
- 跨主機容器間網絡訪問
- 容器網絡是否需要具備IP地址漂移能力
- 容器網絡面臨的問題
- Docker Host 模式,混布存在端口沖突。
- Docker NAT 模式,Ip地址敏感服務改造大,無法支持服務發現
- Overlay網絡,涉及IP地址規劃,MAC地址分配,網絡設備收斂比等問題
- Overlay網絡安全性,可維護性, 容量規劃
- 版本升級(docker/mesos/k8s)本身的升級
- docker 對有狀態的服務進行容器化的問題
- kafka / mysql
網絡選型(k8s和mesos)
- kafka / mysql
思考 && 痛點
- 可否跨機器訪問? 跨域訪問?
- flannel可以跨容器通信
- 跨主機的容器互聯
- 容器與外部互聯
- 是否支持靜態ip , 固定ip ? 域名訪問?
- 固定ip的話,那麽就需要每次部署或者更新或重啟的時候,ip保持不變
- overlay network, Docker 1.6 可以實現跨主機通信
- 是否支持dns?
- 4層/7層訪問
- 容器庫容後的網絡
- ip端口,最好不要自行手動規劃
- 網絡策略,防禦 ,隔離 ?
- 容器集群不同應用之間的網絡隔離和流量限制
-
docker 網絡
- host模式: 容器都是直接共享主機網絡空間的,容器需要使用-p來進行端口映射, 無法啟動兩個都監聽在 80 端口的容器, 並且沒有做到隔離
- container模式: 一個容器直接使用另外一個已經存在容器的網絡配置:ip 信息和網絡端口等所有網絡相關的信息都共享
- Bridge模式: 從docker0子網中分配一個IP給容器使用,並設置docker0的IP地址為容器的默認網關
- 容器的IP在容器重啟的時候會改變
- 不同主機間容器通信需要依賴第三方方案如:pipework
方案
- 方案類別
- 隧道方案, 通過隧道,或者說Overlay Networking的方式:
- Weave,UDP廣播,本機建立新的BR,通過PCAP互通。
- Open vSwitch(OVS),基於VxLAN和GRE協議,但是性能方面損失比較嚴重。
- Flannel,UDP廣播,VxLan。
- 路由方案
- Calico,基於BGP協議的路由方案,支持很細致的ACL控制,對混合雲親和度比較高。
- Macvlan,從邏輯和Kernel層來看隔離性和性能最優的方案,基於二層隔離,所以需要二層路由器支持,大多數雲服務商不支持,所以混合雲上比較難以實現。
- 性能好,沒有NAT,效率比較高, 但是受限於路由表,另外每個容器都有一個ip,那麽業務ip可能會被用光.
- 隧道方案, 通過隧道,或者說Overlay Networking的方式:
- 網絡的兩大陣營
- Docker Libnetwork Container Network Model(CNM)陣營(Docker Libnetwork的優勢就是原生,而且和Docker容器生命周期結合緊密)
- Docker Swarm overlay
- Macvlan & IP network drivers
- Calico
- Contiv(from Cisco)
- Container Network Interface(CNI)陣營 (CNI的優勢是兼容其他容器技術(e.g. rkt)及上層編排系統(Kuberneres & Mesos))
- Kubernetes
- Weave
- Macvlan
- Flannel
- Calico
- Contiv
- Mesos CNI
- Docker Libnetwork Container Network Model(CNM)陣營(Docker Libnetwork的優勢就是原生,而且和Docker容器生命周期結合緊密)
- 常見的解決方案有:
- flannel vxlan,overlay方式
- calico
- 容器間網絡三層隔離,無需要擔心arp風暴
- 基於iptable/linux kernel包轉發效率高,損耗低
- Calico沒有多租戶的概念,所有容器節點都要求可被路由,IP地址不能重復
- ipvlan macvlan,物理二層/三層隔離,目前需要pipework工具在單個節點上配置,僅做了vlan隔離,不解決arp廣播
- swarm native vxlan,跟flannel vxlan類似
- neutron sdn,選擇就多種了,ml2+ovsplugin,midonet,vlan or vxlan
- Weave
- 能夠創建一個虛擬網絡來連接部署在多臺主機上的Docker容器, 外部設備能夠訪問Weave網絡上的應用程序容器所提供的服務,同時已有的內部系統也能夠暴露到應用程序容器上
- contiv
- 思科主導,sdn解決方案,可以用純軟的ovs,也可以用ovs+cisco硬件sdn controller
- 基於 OpenvSwitch,以插件化的形式支持容器訪問網絡,支持 VLAN,Vxlan,多租戶,主機訪問控制策略等
- SDN能力,能夠對容器的網絡訪問做更精細的控制
- 京東基於相同的技術棧(OVS + VLAN)已支持10w+ 容器的運行
- linux bridge+三層交換機:host上 linux bridge 設置為三層交換機的子網網段,容器之間通信走二層交換,容器與外部走三層交換機的網關。
- 業界常用網絡選型
- kubernetes + flannel
- Kubernetes采用扁平化的網絡模型,要求每個Pod擁有一個全局唯一IP,Pod直接可以跨主機通信。目前比較成熟的方案是利用Flannel
- Flannel已經支持UDP、VxLAN、AWS VPC和GCE路由等數據轉發模式。
- kubernetes 下有 flannel、openvswitch和weave可以實現Overlay Network
- 唯品會 contiv netplugin方案(固定外網ip) + flannel
- 京東 Flannel + Neutron + OVS
- Flannel性能: 官方:帶寬沒有下降,延遲明顯變大
- Mesos + Caclio
- Mesos支持CNI標準規範
- 一容器一ip, 網絡隔離, DNS服務發現, ip分配, L3的虛擬網絡
- 去哪兒 Mesos + Caclio
- 七牛 Bridge+ NAT + Open vSwitch
- 魅族雲 OVS & VLAN + SR-IOV
- ucloud: vswitch overlay的"大二層"網絡SDN組網方案 + ipvlan
日誌監控選型(包括監控,統計)
- kubernetes + flannel
docker由於分層設計模式,容器裏面無法固化數據, 容器銷毀裏面的數據就會丟失, 因此建議將日誌掛載到宿主機上, 或者使用分布式存儲如ceph
stdout/stderr類型的日誌,可通過logspout轉發到syslog中心來收集
Docker 的LogDriver 能輸出日誌到特定的端點,例如Fluentd,Syslog,或者Journald。 Logspout能將容器日誌路由到Syslog或者第三方的諸如Redis,Kafka或者Logstash的模塊中。
- 方案介紹
- 采用容器外收集。將主機磁盤掛在為容器中的日誌目錄和文件。
- 將容器中應用的控制到日誌也重定向到日誌目錄。
- 在主機上對應用日誌目錄和docker日誌目錄做日誌收集和輪換。
- 監控可選方案
- cAdvisor + InfluxDB + Grafana
- cAdvisor + Prometheus + Grafana
- Graphite
- Zabbix
- Datadog
- 日誌可選方案
- logstash
- ELK
- Graylog
- flume
- heka
- fluentd
-
業界方案
- 阿裏雲 : cAdvisor + InfuxDB + prometheus
- 協程: ELK
- 知乎: Graphite + cAdvisor
鏡像管理
- 鏡像總是從Dockerfile生成
- 鏡像之間應該避免依賴過深,建議為三層,這三層分別是基礎的操作系統鏡像、中間件鏡像和應用鏡像
- 所有鏡像都應該有對應的Git倉庫,以方便後續的更新
-
Registry
- 單點問題,對應的解決方案可以考慮DRBD、分布式存儲以及雲存儲
- Regitry的性能問題,目前可用的解決方案是通過HTTP反向代理緩存來加速Layer的下載, 或者提供鏡像mirror
- Registry用戶權限,Nginx LUA可以提供一個簡單快速的實現方案
個人理解
- 選型不能只看編排, 還要看存儲/網絡等方面的支持
- swarm以前有些缺陷,如不能檢測失敗節點並重啟,最新版的也實現
- k8s 只是用來調度docker
- mesos是用來管理機器集群. 通過Marathon才能間接管理docker
- 對應網絡的支持
- 是否能夠跨主機/跨域
- 是否能夠固定ip/ dns解析?
- CNI 標準的支持?
- 對於存儲的支持
- 是否能夠固化?
- 是否支持分布式存儲?
- 對於編排/調度/升級
- 是否支持回滾? 在線升級? 滾動升級?
- 是否能夠細粒度分配cpu/內存等
- 是否支持有狀態服務的容器化 和 調度
- 自動擴縮容能力?
- 服務註冊/發現機制 / 負載均衡
- 是否有合適的服務註冊機制?
- 負載均衡是否能夠滿足各種業務場景需求?
- 其他
- 隔離, 除了cgroup和namespace, 還有其他的隔離,比如網絡隔離
業界docker實現的技術