[TOC]

Docker容器平臺選型調研

編排選型

Swarm

1. Swarm可以從一個Dockerfile來構建鏡像，但是構建的鏡像只能在單一節點上運行，而不能夠被分布到集群上的其他節點上。因此，應用被認為是一個容器，這種方式不是細粒度的。

2. Swarm需要使用docker-compose scale來擴展其中一個容器，這個新的容器將會根據調度器規則進行調度。如果容器負載過重，Docker Swarm并不會自動擴展容器

   • 正常情況下,必須去檢查容器是否達到瓶頸, 能夠及時的擴容

3. Swarm cluster ,在docker1.12版本中已經支持失敗節點自動檢測并拉取

4. 目前 Swarm 可以通過overlay networks 來支持多主機容器網絡的訪問, 舊版不支持.

Mesos & Marathon(最新版1.4.1)

1. Mesos 提供資源管理和調度框架抽象的功能，第三方應用需要實現 Mesos 框架提供的 API 才能接入 Mesos 所管理的資源.

   • mesos在底層添加一個輕量的共享層,提供一個統一的api接口,供其他框架集群訪問.
   • Mesos并不負責調度而是負責委派授權，有很多相應框架已經實現了復雜的調度,如Marathon

2. 相比于Swarm，Mesos的容錯性更強，因為Mesos能夠在JSON文件中對某個應用使用監測檢查

3. Marathon 有用戶UI界面，可以將其視為一個應用程序，它可以看作一個框架來管理容器, 容器可以通過REST API 與Marathon 一起工作, 方便運維。

   • 新版Marathon很好的支持了應用的更新和回滾，除去了容器啟動對靜態配置文件的依賴，使應用容器更新發布、回滾更加方便.

4. Mesos在彈性擴縮容后會導致宿主機上產生大量的 Exit 狀態的 Docker 容器，清除時較消耗資源，影響系統穩定性。

   • 默認 Mesos 只有基于時長的清除策略，比如幾小時，幾天后清除，沒有基于指定時間的清除策略，比如在系統閑時清除，也無法針對每個服務定制清除策略。
   • 可以修改 Marathon 的源碼程序，添加 Docker 容器垃圾清理接口，可以對不同服務按指定策略將Exit狀態的Docker容器進行清理。

5. Mesos不支持搶占，無法設置任務優先級

   • 目前 Apache Aurora 這個插件已經支持優先級和資源搶占, 但是它是和marathon同級別的.

6. 對于 mysql / Kafka這類有狀態的存儲類應用，目前 mesos+ Marathon還支持得不是很好

   • 在有失敗發生或者一個簡單的服務重啟的場景下，Marathon會隨機的在任何符合服務定義約束的資源上重啟服務，這樣對于有狀態服務是不適合的，因為這樣的話需要很高的操作代價來將本地狀態遷移到新的服務上
   • 但是可以通過Marathon本地持久化卷來達到能夠部署有狀態服務的目的
     • 本地持久化卷后,下次再啟動該容器的時候marathon與mesos會將這個容器再次部署到原先的宿主機上，而不是其他機器.

7. 可以自研所需的framwork.插件化處理. 不過Marathon本身是Scala編寫的，UI是React編寫,不利于二次開發

8. 其他組件如: mesos-dns 和 marathon-lb.

   • mesos-dns 是一個服務發現工具
   • marathon-lb 不僅是服務發現工具，還是負載均衡工具, 要使用marathonn-lb，每組app必須設置HAPROXY_GROUP標簽, 采用haproxy進行負載均衡

9. 接入mesos的公司: http://mesos.apache.org/documentation/latest/powered-by-mesos/

Kubernetes(最新版1.6)

1. Kubernetes使用ReplicationController來保證應用至少有一個實例在運行。當在Kubernetes集群中創建了一個pod時，需要創建一個叫做負載均衡的Kubernetes服務，它負責轉發流量到各個容器。

   • 如果只有一個實例，也可以使用這種服務，因為它決定了能否將流量準確的轉發到擁有動態IP的pod上。

2. Kubernetes添加了pod和replica的邏輯。這個為調度器和編排工具提供了更加豐富的功能，比如說負載均衡，擴展或者收縮應用的能力。并且還能夠更新正在運行中的容器實例。Kubernetes 擁有自我修復，自動化推出和回滾和存儲編排. 主要優點:

   • AutoScale：根據收集的業務 metric 來決定是否需要自動擴縮容
   • Rolling Deployents：滾動部署新版本并不中斷服務，在新版本部署完成后老版本退出
   • Work Queue：將 Service 從 1:1 的關系擴展到 1：N，為被訪問的 Service 前置一層代理 Agent，用來轉發請求

3. Kubernetes 擅長自動修復問題, 并且可以快速地對容器進行重啟. 這會導致使用方不會注意容器是否崩潰

   • 為了解決這個問題，可以添加一個集中式日志系統 或其他方式 進行監控

4. 有狀態服務集: StatefulSets (1.4版本叫PetSets )

   • 對于PetSet中的Pod，每個Pod掛載自己獨立的存儲，如果一個Pod出現故障，從其他節點啟動一個同樣名字的Pod，要掛在上原來Pod的存儲繼續以它的狀態提供服務。(保證ip/hostname不變)
   • 適合于PetSet的業務包括數據庫服務MySQL/PostgreSQL，集群化管理服務Zookeeper、etcd等有狀態服務。
   • 使用PetSet，Pod仍然可以通過漂移到不同節點提供高可用，而存儲也可以通過外掛的存儲來提供高可靠性，PetSet做的只是將確定的Pod與確定的存儲關聯起來保證狀態的連續性

5. golang語言編寫, 有助于二次開發, 社區活躍度高, 可以加入社區提高公司影響力

6. 大致統計下使用kubernetes的公司: eBay、Yahoo、微軟、IBM、英特爾、華為、VMware、HPE、Mirantis、網易、普元、亞信, 樂視 , 騰訊, 京東

容器技術棧

業界使用架構

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

方案

1. 方案類別

   • 隧道方案, 通過隧道，或者說Overlay Networking的方式：
     • Weave，UDP廣播，本機建立新的BR，通過PCAP互通。
     • Open vSwitch（OVS），基于VxLAN和GRE協議，但是性能方面損失比較嚴重。
     • Flannel，UDP廣播，VxLan。
   • 路由方案
     • Calico，基于BGP協議的路由方案，支持很細致的ACL控制，對混合云親和度比較高。
     • Macvlan，從邏輯和Kernel層來看隔離性和性能最優的方案，基于二層隔離，所以需要二層路由器支持，大多數云服務商不支持，所以混合云上比較難以實現。
     • 性能好,沒有NAT，效率比較高, 但是受限于路由表,另外每個容器都有一個ip,那么業務ip可能會被用光.

2. 網絡的兩大陣營

   • 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

3. 常見的解決方案有：

   • 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 設置為三層交換機的子網網段，容器之間通信走二層交換，容器與外部走三層交換機的網關。

4. 業界常用網絡選型

   • 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

鏡像管理

1. 鏡像總是從Dockerfile生成
2. 鏡像之間應該避免依賴過深，建議為三層，這三層分別是基礎的操作系統鏡像、中間件鏡像和應用鏡像
3. 所有鏡像都應該有對應的Git倉庫，以方便后續的更新
4. Registry
   • 單點問題，對應的解決方案可以考慮DRBD、分布式存儲以及云存儲
   • Regitry的性能問題，目前可用的解決方案是通過HTTP反向代理緩存來加速Layer的下載, 或者提供鏡像mirror
   • Registry用戶權限，Nginx LUA可以提供一個簡單快速的實現方案

總結

1. 選型不能只看編排, 還要看存儲/網絡等方面的支持

   • swarm以前有些缺陷,如不能檢測失敗節點并重啟,最新版的也實現
   • k8s 只是用來調度docker
   • mesos是用來管理機器集群. 通過Marathon才能間接管理docker

2. 對應網絡的支持

   • 是否能夠跨主機/跨域
   • 是否能夠固定ip/ dns解析?
   • CNI 標準的支持?

3. 對于存儲的支持

   • 是否能夠固化?
   • 是否支持分布式存儲?

4. 對于編排/調度/升級

   • 是否支持回滾? 在線升級? 滾動升級?
   • 是否能夠細粒度分配cpu/內存等
   • 是否支持有狀態服務的容器化 和 調度
   • 自動擴縮容能力?

5. 服務注冊/發現機制 / 負載均衡

   • 是否有合適的服務注冊機制?
   • 負載均衡是否能夠滿足各種業務場景需求?

6. 其他

   • 隔離, 除了cgroup和namespace, 還有其他的隔離,比如網絡隔離

【"歡迎關注我的微信公眾號：Linux 服務端系統研發，后面會大力通過微信公眾號發送優質文章"】

image.png