Docker容器平臺選型調研

吳德寶AllenWu發表於2018-01-30
原文網址 : https://juejin.im/post/5a6dd118f265da3e3a6e0982
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的公司: 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、網易、普元、亞信, 樂視 , 騰訊, 京東

容器技術棧

技術點 技術方案
資源排程 & 編排 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的模組中。

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

相關文章