Docker容器平臺選型調研

[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的公司: mesos.apache.org/documentati…

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、網易、普元、亞信, 樂視 , 騰訊, 京東

容器技術棧

技術點	技術方案
資源調度 & 編排	Mesos + marathon Swarm(Compose) Kubernetes
鏡像 & 倉庫	harbor DockerHub Quay.io Artifactory
監控	cAdvisor Graphite Sysdig Datadog Prometheus ,Zabbix + pythonAgent
日誌	ELK Graylog flume heka fluentd
服務註冊和發現 / 負載均衡	HAProxy Etcd consul nginx Confd / DNS(好像有坑)
存儲	devicemapper, overlayfs, Volume, Ceph ，Gluster ， NFS, OpenStack swift， glance ,iSCSI SAN
網絡	HOST, VXLAN IPSEC . OpenFlow .Flannel. Docker Bridge, Calico, Neutron ,pipework ,weave , SocketPlane
分佈式計劃任務	chronos
安全	Notary Vault
自動化工具	ansible, salt

業界使用架構

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的模塊中。

0. 方案介紹

   • 採用容器外收集。將主機磁盤掛在爲容器中的日誌目錄和文件。
   • 將容器中應用的控制到日誌也重定向到日誌目錄。
   • 在主機上對應用日誌目錄和docker日誌目錄作日誌收集和輪換。

1. 監控可選方案

   • cAdvisor + InfluxDB + Grafana
   • cAdvisor + Prometheus + Grafana
   • Graphite
   • Zabbix
   • Datadog

2. 日誌可選方案

   • logstash
   • ELK
   • Graylog
   • flume
   • heka
   • fluentd

3. 業界方案

   • 阿里雲 : 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, 還有其餘的隔離,好比網絡隔離