1. 京東
   • Openstack Icehouse + docker1.3 + OVS2.1.3/2.3.2+Centos6.6 ==> K8s + Docker + Flannel +Neutron + OVS + DPDK +JFS
   • 某個容器失效,自動觸發RC(保持IP丌變“遷移”)
   • OVS-VLAN
2. 知乎
   • 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
     • 支持自定義指標
3. 攜程
   • Openstack + Mesos + Docker + Chronos + ELK
   • 監控：telegraf -> Influxdb -> Grafana
   • 日誌：elk
     • mesos stdout、stderr
4. 去哪兒
   • OpenStack + nova-docker + VLAN =>Mesos + Marathon + Docker(--net=host) + 隨機端口 => Mesos + Marathon + Docker + Calico
5. 阿裏電商雲
   • 自研EWS, 基於compose, 參考Kubernetes的設計. 支持多region.
     • cAdvisor + InfuxDB + prometheus
     • etcd + consul + zk + docker overlay
       • 使用RDS,OSS,OCS等服務化存儲
   • docker容器的正確姿勢
     • 每次代碼提交重新構建鏡像
     • 禁止修改運行中的鏡像
     • 利用volume保存持久化數據
   • 存儲管理
     • 利用docker volume plugin支持不同的存儲類型
       • 塊存儲，雲盤
       • 對象存儲，OSSFS
       • 網絡文件系統 NFS
6. 同程
   • 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模式： 如數據分析
7. 網易蜂巢
   • openstack + K8S + etcd + OpenFlow + iscsi + Ceph + billing + 多機房
8. 騰訊
   • 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 方案。
9. 滴滴
   • Kubernetes
   • 目前了解的資料,滴滴使用docker化的時間不長,沒有太多參考架構設計
10. uber
    • 待補充
11. 蘑菇街
    • Kubernetes + VLAN
12. 七牛雲
    • Mesos + 自研容器調度框架（DoraFramework) + Bridge+ NAT + Open vSwitch + Consul + Prometheus + Ansible
    • 七牛目前已經達到近千臺物理機的規模, mesos支持大規模調度更合適
    • 不選擇Mesos的核心框架Marathon 而選擇自研
      • Marathon有些方面不支持我們期望的使用姿勢，比如不太好無縫對接服務發現
      • Marathon采用 scala 開發，出了問題不好排查，也不方便我們做二次開發
      • 如果選用 Marathon的話，我們上面還是要再做一層對 Marathon的包裝才能作為Dora的調度服務，這樣模塊就會變多，部署運維會復雜
13. 魅族雲
    • 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調度到不同機櫃
14. 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

主要問題

1. 單實例性能調優 + 萬兆卡的性能發揮出來。需要對OVS（Open vSwitch）做一些改進
2. 多機房:多機房及可用域支持
3. 容器網絡需求
   • Iptables 有些坑
   • 跨主機容器間網絡訪問
   • 容器網絡是否需要具備IP地址漂移能力
4. 容器網絡面臨的問題
   • Docker Host 模式,混布存在端口沖突。
   • Docker NAT 模式,Ip地址敏感服務改造大,無法支持服務發現
   • Overlay網絡,涉及IP地址規劃,MAC地址分配,網絡設備收斂比等問題
   • Overlay網絡安全性,可維護性, 容量規劃
5. 版本升級(docker/mesos/k8s)本身的升級
6. docker 對有狀態的服務進行容器化的問題
   • kafka / mysql
     網絡選型(k8s和mesos)

思考 && 痛點

1. 可否跨機器訪問? 跨域訪問?
   • flannel可以跨容器通信
   • 跨主機的容器互聯
   • 容器與外部互聯
2. 是否支持靜態ip , 固定ip ? 域名訪問?
   • 固定ip的話,那麽就需要每次部署或者更新或重啟的時候,ip保持不變
   • overlay network, Docker 1.6 可以實現跨主機通信
3. 是否支持dns?
4. 4層/7層訪問
5. 容器庫容後的網絡
6. ip端口,最好不要自行手動規劃
7. 網絡策略,防禦 ,隔離 ?
   • 容器集群不同應用之間的網絡隔離和流量限制

8. docker 網絡

   • host模式: 容器都是直接共享主機網絡空間的，容器需要使用-p來進行端口映射, 無法啟動兩個都監聽在 80 端口的容器, 並且沒有做到隔離
   • container模式: 一個容器直接使用另外一個已經存在容器的網絡配置：ip 信息和網絡端口等所有網絡相關的信息都共享
   • Bridge模式: 從docker0子網中分配一個IP給容器使用，並設置docker0的IP地址為容器的默認網關
     • 容器的IP在容器重啟的時候會改變
     • 不同主機間容器通信需要依賴第三方方案如:pipework
       方案
9. 方案類別
   • 隧道方案, 通過隧道，或者說Overlay Networking的方式：
     • Weave，UDP廣播，本機建立新的BR，通過PCAP互通。
     • Open vSwitch（OVS），基於VxLAN和GRE協議，但是性能方面損失比較嚴重。
     • Flannel，UDP廣播，VxLan。
   • 路由方案
     • Calico，基於BGP協議的路由方案，支持很細致的ACL控制，對混合雲親和度比較高。
     • Macvlan，從邏輯和Kernel層來看隔離性和性能最優的方案，基於二層隔離，所以需要二層路由器支持，大多數雲服務商不支持，所以混合雲上比較難以實現。
     • 性能好,沒有NAT，效率比較高, 但是受限於路由表,另外每個容器都有一個ip,那麽業務ip可能會被用光.
10. 網絡的兩大陣營
    • 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
11. 常見的解決方案有：
    • 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 設置為三層交換機的子網網段，容器之間通信走二層交換，容器與外部走三層交換機的網關。
12. 業界常用網絡選型
    • 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的模塊中。

1. 方案介紹
   • 采用容器外收集。將主機磁盤掛在為容器中的日誌目錄和文件。
   • 將容器中應用的控制到日誌也重定向到日誌目錄。
   • 在主機上對應用日誌目錄和docker日誌目錄做日誌收集和輪換。
2. 監控可選方案
   • cAdvisor + InfluxDB + Grafana
   • cAdvisor + Prometheus + Grafana
   • Graphite
   • Zabbix
   • Datadog
3. 日誌可選方案
   • logstash
   • ELK
   • Graylog
   • flume
   • heka
   • fluentd

4. 業界方案

   • 阿裏雲 : cAdvisor + InfuxDB + prometheus
   • 協程: ELK
   • 知乎: Graphite + cAdvisor
     鏡像管理
5. 鏡像總是從Dockerfile生成
6. 鏡像之間應該避免依賴過深，建議為三層，這三層分別是基礎的操作系統鏡像、中間件鏡像和應用鏡像
7. 所有鏡像都應該有對應的Git倉庫，以方便後續的更新

8. Registry

   • 單點問題，對應的解決方案可以考慮DRBD、分布式存儲以及雲存儲
   • Regitry的性能問題，目前可用的解決方案是通過HTTP反向代理緩存來加速Layer的下載, 或者提供鏡像mirror
   • Registry用戶權限，Nginx LUA可以提供一個簡單快速的實現方案
     個人理解
9. 選型不能只看編排, 還要看存儲/網絡等方面的支持
   • swarm以前有些缺陷,如不能檢測失敗節點並重啟,最新版的也實現
   • k8s 只是用來調度docker
   • mesos是用來管理機器集群. 通過Marathon才能間接管理docker
10. 對應網絡的支持
    • 是否能夠跨主機/跨域
    • 是否能夠固定ip/ dns解析?
    • CNI 標準的支持?
11. 對於存儲的支持
    • 是否能夠固化?
    • 是否支持分布式存儲?
12. 對於編排/調度/升級
    • 是否支持回滾? 在線升級? 滾動升級?
    • 是否能夠細粒度分配cpu/內存等
    • 是否支持有狀態服務的容器化 和 調度
    • 自動擴縮容能力?
13. 服務註冊/發現機制 / 負載均衡
    • 是否有合適的服務註冊機制?
    • 負載均衡是否能夠滿足各種業務場景需求?
14. 其他
    • 隔離, 除了cgroup和namespace, 還有其他的隔離,比如網絡隔離

業界docker實現的技術