您好,登錄后才能下訂單哦!
如何進行docker容器集群管理平臺的比較,很多新手對此不是很清楚,為了幫助大家解決這個難題,下面小編將為大家詳細講解,有這方面需求的人可以來學習下,希望你能有所收獲。
容器化和微服務是當前最熱話題,不久之前,筆者(據說因為現在都不用筆了,“筆者”的稱謂已經不合適了,因為輸入用鍵盤,叫“鍵人”更為合適)參加QCon上海一個微服務監控的Session,場面爆棚,我不得不在擁擠的過道聽完了整個session。隨著要管理的容器越來越多,容器的集群管理平臺成為了剛需!
Swarm是Docker公司在2014年12月初新發布的容器集群管理工具。它可以把多個主機變成一個虛擬的Docker主機來管理。Swarm使用Go語言開發,并且開源,在github上可以找到它的全部source code。Swarm使用標準的Docker API,給Docker用戶帶來無縫的集群使用體驗。2016年7月, Swarm已經被整合進入Docker Engine。
Docker Swarm提供API 和CLI來在管理運行Docker的集群,它的功能和使用本地的Docker并沒有本質的區別。但是可以通過增加Node帶來和好的擴展性。理論上,你可以通過增加節點(Node)的方式擁有一個無限大的Docker主機。
Swarm并不提供UI,需要UI的話,可以安裝UCP,不過很不幸,這個UCP是收費的。
Swarm的架構并不復雜,可以說非常簡單。Manager負責容器的調度,Node負責容器的運行,Node運行Docker Daemon和Manager之間通過HTTP來通信。Docker Client通過Manager上暴露的標準Docker API來使用Docker的功能。
Swarm的集群協調和業務發現可以支持不同的第三方組件,包括:
Consul
Etcd
ZooKeeper
Docker Hub
如果對集群協調的概念不熟悉,可以參考我的另一篇博客《使用Python進行分布式系統協調 (ZooKeeper,Consul, etcd )》
Swarm的基本容器調度策略有三種:
spread 容器盡可能分布在不同的節點上
binpack 容器盡可能分布在同一個節點上
random 容器分布在隨機的節點上
Swarm集群的高可用配置很容易,以下圖為例:
manager配置在不同的AWS AZ中,通過領導選舉選出Primary manager。
多個節點分布在不同的AZ中,同時Consul/etcd/ZooKeeper也需要配成冗余的。
Docker Swarm的特點是配置和架構都很簡單,使用Docker原生的API,可以很好的融合Docker的生態系統。
Kubernetes是Google開發的一套開源的容器應用管理系統,用于管理應用的部署,維護和擴張。利用Kubernetes能方便地管理跨機器運行容器化的應用。Kubernetes也是用Go語言開發的,在github上可以找到源代碼。
Kubernetes 源于谷歌公司的內部容器管理系統Borg,經過了多年的生產環境的歷煉,所以功能非常強大。
Kubernetes主要提供一下的功能:
使用Docker對應用程序包裝(package)、實例化(instantiate)、運行(run)。
以集群的方式運行、管理跨機器的容器。
解決Docker跨機器容器之間的通訊問題。
Kubernetes的自我修復機制使得容器集群總是運行在用戶期望的狀態。
應用的高可用和靠擴展
支持應用的在線升級(Rolling Update)
支持跨云平臺(IaaS)的部署
為了支持這些功能,Kubernetes做了做了很多的抽象概念,所以,剛開始使用Kubernetes,需要學習不少的新概念,包括:
Pod
Pod是Kubernetes的基本操作單元,把相關的一個或多個容器構成一個Pod,通常Pod里的容器運行相同的應用,或者是相關的應用。Pod包含的容器運行在同一個Minion(Host)上,看作一個統一管理單元,共享相同的volumes和network namespace/IP和Port空間。
Job
Job是一個生命周期比較短的應用,一般只會在出錯的情況下重啟,可以通過配置Job的并發和運行次數來擴展Job
Service
Service是一個生命周期比較長的應用,會在任何退出時重啟,可以通過配置Service的復制(Replica)來達到高擴展和高可用
Recplica Controller
Replication Controller確保任何時候Kubernetes集群中有指定數量的pod副本(replicas)在運行, 如果少于指定數量的pod副本(replicas),Replication Controller會啟動新的Container,反之會殺死多余的以保證數量不變。Replication Controller使用預先定義的pod模板創建pods,一旦創建成功,pod 模板和創建的pods沒有任何關聯,可以修改pod 模板而不會對已創建pods有任何影響,也可以直接更新通過Replication Controller創建的pods
以上是一些核心概念,除了這些,Kubernetes還提供其它一些概念,來支持應用程序的運維,包括:
Label
對系統中的對象通過Label的方式來管理
Namespace
對對象,資源分組,可以用于支持多租戶
Config Map
提供全局的配置數據存儲
總之,功能強大,系統概念繁多,比較復雜。
Kubernetes支持安裝UI的addon,來管理整個系統:
下圖是Kubernetes的基本架構:
Master
Master定義了Kubernetes 集群Master/API Server的主要聲明,Client(Kubectl)調用Kubernetes API,管理Kubernetes主要構件Pods、Services、Minions、容器的入口。Master由API Server、Scheduler以及Registry等組成。
Scheduler收集和分析當前Kubernetes集群中所有Minion節點的資源(內存、CPU)負載情況,然后依此分發新建的Pod到Kubernetes集群中可用的節點。由于一旦Minion節點的資源被分配給Pod,那這些資源就不能再分配給其他Pod, 除非這些Pod被刪除或者退出, 因此,Kubernetes需要分析集群中所有Minion的資源使用情況,保證分發的工作負載不會超出當前該Minion節點的可用資源范圍
Minion
Minion負責運行Pod,Service,Jobs, Minion通過Kubelet和Master通信。Proxy解決了外部網絡能夠訪問跨機器集群中容器提供的應用服務。
etcd
負責集群的協調和服務發現
Kubernetes提供了很多應用級別的管理能力,包括高可用可高擴展,當然為了支持這些功能,它的架構和概念都比較復雜,當然我覺得為了獲得這些功能,值!
Mesos是為軟件定義數據中心而生的操作系統,跨數據中心的資源在這個系統中被統一管理。Mesos的初衷并非管理容器,只是隨著容器的發展,Mesos加入了容器的功能。Mesos可以把不同機器的計算資源統一管理,就像同一個操作系統,用于運行分布式應用程序。
Mesos的起源于Google的數據中心資源管理系統Borg。你可以從WIRED雜志的這篇文章中了解更多關于Borg起源的信息及它對Mesos影響。
Mesos的主要功能包括:
高度的可擴展和高可用
可自定義的兩級調度
提供API進行應用的擴展
跨平臺
下圖是Mesos的管理界面:
Mesos的基本架構如下
Master
Master負責資源的統一協調和Slave的管理。 Master協調全部的Slave,并確定每個節點的可用資源,聚合計算跨節點的所有可用資源的報告,然后向注冊到Master的Framework(作為Master的客戶端)發出資源邀約。Mesos實現了兩級調度架構,它可以管理多種類型的應用程序。第一級調度是Master的守護進程,管理Mesos集群中所有節點上運行的Slave守護進程。集群由物理服務器或虛擬服務器組成,用于運行應用程序的任務,比如Hadoop和MPI作業。第二級調度由被稱作Framework的“組件”組成。
Slave
Salve運行執行器(Executor)進程來運行任務。
Framework
Framework包括調度器(Scheduler)和執行器(Executor)進程,其中每個節點上都會運行執行器。Mesos能和不同類型的Framework通信,每種Framework由相應的應用集群管理。
Framework可以根據應用程序的需求,選擇接受或拒絕來自master的資源邀約。一旦接受邀約,Master即協調Framework和Slave,調度參與節點上任務,并在容器中執行,以使多種類型的任務
ZooKeeper
Zookeeper負責集群的協調,Master的領導選舉等
Mesos相比Kubernetes和Swarm更為成熟,但是Mesos主要要解決的是操作系統級別的抽象,并非為了容器專門設計,如果用戶出了容器之外,還要集成其它的應用,例如Hadoop,Spark,Kafka等,Mesos更為合適。Mesos是一個更重量級的集群管理平臺,功能更豐富,當然很多功能要基于各種Framework。
Mesos的擴展性非常好,最大支持50000節點,如果對擴展性要求非常高的話么,Mesos是最佳選擇。
ECS (Amazon EC2 Container Service )是亞馬遜開發出的高度可擴展的高性能容器集群服務。在托管的 Amazon EC2 實例集群上輕松運行容器應用和服務。他最大的好處就是在云上,不需要自己管理數據中心的機器和網絡。
ECS繼承了AWS服務的高擴展和高可用性,安全也可以得到保證。
在基本容器管理的基礎上,ECS使用Task和Service的概念來管理應用。
Task類似Docker Compose,使用一個JSON描述要運行的應用。Service是更高一層的抽象,包含多個task的運行實例,通過修改task實例的數量,可以控制服務的伸縮。同時Service可以保證指定數量的Task在運行,當出現錯誤的時候,重啟失敗的Task
下圖是ECS的架構圖:
使用EC2,ELB,安全組等大家熟悉的AWS的概念,AWS用戶可以輕松管理你的容器集群。并且不需要付初基本資源以外的費用。
通過ECS agent可以是Container連接到ECS集群。ECS Agent使用Go開發,已開源。
我們并不清楚ECS的調度策略,但是AWS提供了一個例子,如果繼承第三方的調度策略。
通過Cloud Watch Log,我們可以很方便的對整個集群進行監控。
如果你是一個AWS的重度用戶,ECS是個不錯的選擇,因為你可以是把你的容器集群運行在AWS的云上,管理起來非常方便。
這里對幾個平臺做一個簡單的比較:
Swarm | Kubernetes | Mesos | ECS | |
基本功能 | Docker原生的集群管理工具 | 開源的容器集群工具,提供應用級別的部署,維護和擴張功能 | 基于數據中心的操作系統 | 基于云的高可用,高擴展容器集群 |
高層次抽象 | 無 | Pod | 無 | Task Service |
應用擴展性 | 無 | 支持 | Framework 支持 | 支持 |
應用高可用性 | 無 | 支持 | Framework 支持 | 支持 |
集群協調和服務發現 | etcd | etcd | ZooKeeper | / |
調度策略(Schedule) | 內置,可擴展 | 內置 | 兩級別,可擴展 | 可擴展 |
監控 | Logging Driver | Heapter,ELK Addon | 內置 | CloudWatch |
用戶界面 | CLI | CLI API UI | API UI | CLI |
開發語言 | Go | Go | Java | NA |
開源 | 是 | 是 | 是 | 否 |
最大支持管理節點數 | 官方1000 | 官方1000 | 10000 | / |
四個平臺,Swarm是最輕量級的,功能也最簡單,適于有大量Docker實例環境的用戶。Kubernetes增加了很多應用級別的功能,適用于快速應用的部署和維護。Mesos最重,適用于已經有了相當的應用和容器混合的環境。ECS則推薦給AWS的用戶或者不希望自己管理數據中心的云用戶。
看完上述內容是否對您有幫助呢?如果還想對相關知識有進一步的了解或閱讀更多相關文章,請關注億速云行業資訊頻道,感謝您對億速云的支持。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。