K8s概述：幾種集群方案的對比

幾種集群方案簡介

下面以docker部署為主，主流的容器化集群部署方案主要有以下幾種：

• Docker Compose：幫助在 同一個節點 上部署多個容器，
• Docker Swarm：多臺機器上部署容器，開箱即用，快速部署容器，偏重容器部署
• K8s：社區活躍度高，組件豐富，微服務化，偏重應用的部署，
• Marathon+Mesos：大資料組件部署，雙層調度，側重底層資源管理，任務調度需自己實作

compose支持在 同一節點 上部署，swarm支持在多個節點上部署容器，這兩者都是docker原生支持的docker集群部署方式，開箱即用，比較方便，偏重于容器的部署，

swarm偏重的是容器的部署，而k8s偏重于應用的部署，k8s對容器的所有操作都滲透著為應用而服務的理念，比如pod是為了讓聯系緊密但又不適合部署在一起的應用分別部署在不同docker里面，但docker之間共享volume和network namespace方式，以便實作緊密地“交流”，在比如service是為了隱藏pod（容器的集合，下文會介紹到）的網路細節，讓pod提供固定的訪問入口，從而方便地讓其他應用訪問等，

在swarm中，被創建、調度和管理的最小單元就是docker，在k8s中，最小單元則是pod，

marathon+mesos，一開始是給大資料組件部署用的，這個框架是一個雙層調度框架，側重于底層資源管理，需要自己實作任務調度，

下面重點對比一下k8s和mesos，

k8s vs mesos

k8s

k8s一些概念

• Node：資源節點的抽象
• Pod：pod為kubernetes的最小管理單元，一個pod中可以部署多個容器，通常建議是一個容器
• Daemonset：每個node上有一個，比如使用gpu、聯通上的seman服務
• Statefulset：解決有狀態服務，保證部署和scale的順序，比如mysql，
• Deployment：一個Deployment通過多個ReplicaSet管理pod，一個Replica Set擁有一個或多個Pod，滾動升級的時候是用新的rs替代舊的rs
• Endpoint：一個資源物件，用于記錄一個service對應的所有pod的訪問地址
• Service：容器互聯或者對外暴露的服務，Service通過label選擇Pod，這些 Pod 通過endpoints 暴露出來，通過與具體后端pod解耦，使得后端pod遷移時訪問不受影響，

k8s組件

• kube-dns：用Service向集群內部提供服務的
• Etcd：存盤配置資料庫，存盤網路的配置資訊和各種物件的狀態和元資訊配置
• kube-apiserver：k8s主節點的管理中心，整個集群的控制入口，它有助于各個組件之間的通信，從而保持集群的健康，
• kube-controller-manager：確保通過向上和向下擴展作業負載來使群集的期望狀態與當前狀態相匹配，
• kube-scheduler：將作業負載放置在適當的節點上，
• Kubelet：從API服務器接收pod規范并管理在主機中運行的pod，

kubelet會在API Server上注冊節點資訊，定期向Master匯報節點資源使用情況，并通過cAdvisor監控容器和節點資源，可以把kubelet理解成【Server-Agent】架構中的agent，是Node上的pod管家，

scheduler負責集群的資源調度，為新建的pod分配機器，這部分作業分出來變成一個組件，意味著可以很方便地替換成其他的調度器，

controller-manager負責執行各種控制器，目前有兩類：

• endpoint-controller：定期關聯service和pod(關聯資訊由endpoint物件維護)，保證service到pod的映射總是最新的，
• replication-controller：定期關聯replicationController和pod，保證replicationController定義的復制數量與實際運行pod的數量總是一致的，

K8s概述：幾種集群方案的對比

提交流程

提交一個pod的流程

1. 用戶提交pod，APIServer記錄到etcd中；
2. scheduler周期性查詢APIServer，以獲取未系結的pod，嘗試為pod分配節點；
3. scheduler調度：首先過濾不符合pod資源要求的主機，然后考慮整體優化策略對主機打分，比如使用最低負載，使用分散主機等，最后選擇最高分的主機存盤系結資訊到etcd中；
4. kubelet周期查詢系結物件，獲取需要在本機啟動的pod并通過docker啟動，

K8s概述：幾種集群方案的對比

提交一個controller的流程

1. 用戶提交一個controller；
2. APIServer把controller物件保存到etcd中；
3. controller周期性查詢APIServer獲取未系結的pod：APIServer獲取每個節點上系結的kubeletkubelet請求docker獲取pod狀態kubelet回傳pod狀態
4. controller創建pod

K8s概述：幾種集群方案的對比

提交一個service的流程

1. APIServer創建service物件寫入etcd，
2. controller不斷掃描service對應的pod，
3. controller呼叫APIServer創建對應的訪問端點endpoint，
4. APIServer將endpoint物件寫入etcd，
5. proxy不斷發現有沒有可以放在自己上面的轉發規則，如果有則創建socket監聽埠，并且創建相應的iptables規則，

K8s概述：幾種集群方案的對比

mesos

mesos+marathon

mesos復制資源管理，主要有以下四個組件：

• Agent：即Slave，上報資源
• Master：接入framework和slave
• Framework：如Hadoop、Marathon，修改調度器，獲取Mesos分配給自己的資源
• Executor：如何啟動task

這里面有兩層的Scheduler，一層在Master里面，allocator會將資源公平的分給每一個Framework，二層在Framework里面，Framework的scheduler將資源按規則分配給Task，其它框架的調度器是直接面對整個集群，Mesos的優勢在于，第一層調度先將整個Node分配給一個Framework，然后Framework的調度器面對的集群規模小很多，然后在里面進行二次調度，而且如果有多個Framework，例如有多個Marathon，則可以并行調度不沖突，

以下面這個調度圖為例子：

• Slave1 向 Master 報告，有4個CPU和4 GB記憶體可用，
• Master 發送一個 Resource Offer 給 Framework1 來描述 Slave1 有多少可用資源，
• FrameWork1 中的 FW Scheduler會答復 Master，我有兩個 Task 需要運行在 Slave1，一個Task 需要<2個cpu，1 gb記憶體="">，另外一個Task需要<1個cpu，2 gb記憶體="">，
• 最后，Master 發送這些 Tasks 給 Slave1，然后，Slave1還有1個CPU和1 GB記憶體沒有使用，所以分配模塊可以把這些資源提供給 Framework2，

K8s概述：幾種集群方案的對比

DC/OS

DC/OS是以Mesos為內核，加上marathon和chronos作為運行和管理任務和應用的框架，它集成了許多大資料處理框架（hadoop、spark等），

K8s概述：幾種集群方案的對比

Mesosphere DCOS除了內核Mesos，還有兩個關鍵組件Marathon和Chronos，其中，Marathon(名分布式的init)是一個用于啟動長時間運行應用程式和服務的框架，Chronos(又名分布式的cron)是一個在Mesos上運行和管理計劃任務的框架，

Mesosphere DCOS在其公有倉庫上已提供了40多種服務組件，比如Hadoop，Spark，Cassandra, Jenkins, Kafka, MemSQL等等，

DC/OS上面的Framework實作也可以使用k8s，

k8s vs mesos

K8s概述：幾種集群方案的對比

DC/OS采用二次調度的機制，使得應用調度與資源調度相分離，這一點與Kubernetes不同，Kubernetes的應用調度與資源調度全部都是通過內部的組件完成的，其自身的資源調度平臺僅能為容器運行提供支撐，不能為其它的Framework提供資源支撐，可以說Kubernetes的容器調度與資源調度是緊耦合的，而在DC/OS平臺下，各應用調度框架與Mesos資源實作了松耦合，Mesos僅負責資源的調度，而上層應用的調度則由各應用的Framework自身完成，Framework自身也可以通過容器的方式運行在平臺之上，

不同集群規模的選擇

K8s概述：幾種集群方案的對比

因為容器和集群編排有學習成本，所以對于小集群，建議是使用Iaas和裸機部署docker，

然后當發展到一定程度，有50+個以上的服務的中等規模集群，建議使用Docker Swarm，Swarm與docker緊密結合，命令與docker相對一致，比較容易上手，

到了百級別的集群，在這個量級上需要有一些定制化作業，swarm調度方面開始有壓力，組件內置又不好debug，這時候會比較多選擇Mararthon+Mesos，雙層調度機制使得集群可以大很多，

到了千級別的集群，kubernetes的模塊劃分的更細，設計思想也更偏向于微服務部署，就是學習成本比較高，

然后是萬級別的節點，這時候Kubernetes的調度和etcd等組件的壓力在萬級別上會達到瓶頸，單個etcd集群和串行調度，controller監聽單佇列會遇到性能的問題，這時候需要定制化K8s組件，比如etcd做多集群，對于多租戶可以實作并行調度，監聽多個佇列，定制事件優先級，比如add優先于delete等等，

在這個級別上也可以使用DC/OS做定制化，天生的雙層調度可以給不同的租戶獨立使用Marathon并行調度，

最后是部署大資料組件，推薦是使用Mesos做調度，因為天生就是從做大資料組件部署起來的，擁有豐富的大資料Framework，