業界docker實作的技術

業界使用架構

京東

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

支援自定義名額

攜程

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

同程

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模式： 如資料分析

網易蜂巢

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可選

nat模式下會啟用nf_conntrack，造成性能下降，調節核心參數

docker鏡像

編寫dockfile規範、減少鏡像層數，基礎部分放前面

分地域部署鏡像registry

主要問題

單執行個體性能調優 + 萬兆卡的性能發揮出來。需要對ovs（open vswitch）做一些改進

多機房:多機房及可用域支援

容器網絡需求

跨主機容器間網絡通路

容器網絡是否需要具備ip位址漂移能力

容器網絡面臨的問題

docker host 模式,混布存在端口沖突。

docker nat 模式,ip位址敏感服務改造大,無法支援服務發現

overlay網絡,涉及ip位址規劃,mac位址配置設定,網絡裝置收斂比等問題

overlay網絡安全性,可維護性, 容量規劃

版本更新(docker/mesos/k8s)本身的更新

docker 對有狀态的服務進行容器化的問題

kafka / mysql

網絡選型(k8s和mesos)

思考 && 痛點

可否跨機器通路? 跨域通路?

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可能會被用光.

網絡的兩大陣營

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))

weave

macvlan

flannel

contiv

mesos cni

常見的解決方案有：

flannel vxlan，overlay方式

容器間網絡三層隔離，無需要擔心arp風暴

基于iptable/linux kernel包轉發效率高，損耗低

calico沒有多租戶的概念，所有容器節點都要求可被路由，ip位址不能重複

ipvlan macvlan，實體二層/三層隔離，目前需要pipework工具在單個節點上配置，僅做了vlan隔離，不解決arp廣播

swarm native vxlan，跟flannel vxlan類似

neutron sdn，選擇就多種了，ml2+ovsplugin，midonet，vlan or vxlan

能夠建立一個虛拟網絡來連接配接部署在多台主機上的docker容器, 外部裝置能夠通路weave網絡上的應用程式容器所提供的服務，同時已有的内部系統也能夠暴露到應用程式容器上

思科主導，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

日志監控選型(包括監控,統計)

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, 還有其他的隔離,比如網絡隔離

更多的部落格轉移到個人部落格上了，請點選以下連結：

個人部落格