Swarm
Swarm是Docker開發的原生集羣工具,Swarm使用標準的docker API,這意味着容器可以使用Docker客戶端命令啓動,Swarm會選擇合適的主機來運行容器。node
Swarm的基本架構很簡單:每一個主機運行一個Swarm代理,一個主機運行Swarm管理器(在測試的集羣中,這個主機也能夠運行代理),這個管理器負責主機上容器的編排和調度。Swarm能以高可用性模式(etcd、Consul 或ZooKeeper 中任何一個均可以用來將故障轉移給後備管理器處理)運行。當有新主機加入到集羣,有幾種不一樣的方式來發現新加的主機,在Swarm中也就是服務發現。默認狀況下使用的是token,也就是在Docker Hub上會儲存一個主機地址的列表。
Swarm的優點:
swarm API兼容docker API,使得swarm 學習成本低,同時架構簡單,部署運維成本較低。
Swarm的劣勢:
一樣是由於API兼容,沒法提供集羣的更加精細的管理。
在網絡方面,默認docker容器是經過橋接與NAT和主機外網絡通訊,這樣就出現2個問題,一個是由於是NAT,外部主機沒法主動訪問到容器內(除了端口映射),另外默認橋接IP是同樣的,這樣會出現不一樣主機的容器有相同的IP的狀況。這樣兩容器更加不能通訊。同時網絡性能方面,有人測試通過橋接的網絡性能只有主機網絡性能的70%。固然以上問題能夠經過其餘工具解決,好比用 Flannel 或者 OVS網橋。
在容器可靠性方面,相較於K8s的Replication Controllers能夠監控並維持容器的生命,swarm在啓動時刻能夠控制容器啓動,在啓動後,若是容器或者容器主機崩潰,swarm沒有機制來保證容器的運行。docker
Kubernetes
Kubernetes是一個由google基於他們上個世紀容器產品化的經驗而推出的容器編排工具,Kubernetes有些執拗己見對於容器如何組織和網絡強制了一些概念,須要瞭解的主要概念有:
· Pods
Pod是Kubernetes的基本操做單元,把相關的一個或多個容器構成一個Pod,一般Pod裏的容器運行相同的應用。Pod包含的容器運行在同一個node(Host)上,看做一個統一管理單元,共享相同的volumes和network namespace/IP和Port空間。
· Services
Services也是Kubernetes的基本操做單元,是真實應用服務的抽象,每個服務後面都有不少對應的容器來支持,經過Proxy的port和服務selector決定服務請求傳遞給後端提供服務的容器,對外表現爲一個單一訪問接口,外部不須要了解後端如何運行,這給擴展或維護後端帶來很大的好處。
Services能夠對外暴露ip地址, 通常用公網IP地址,執行暴露服務IP地址命令事後,咱們就能夠在公網上訪問了,可是這裏有個問題就是這個IP地址必須是安裝了k8s的機器的IP(實質是須要該IP的主機上的kube-proxy來轉發網絡請求),若是你隨便用一個IP是不能訪問的,這裏也給應用上形成了不便。
· Replication Controllers
Replication Controller確保任什麼時候候Kubernetes集羣中有指定數量的pod副本(replicas)在運行, 若是少於指定數量的pod副本(replicas),Replication Controller會啓動新的Container,反之會殺死多餘的以保證數量不變。Replication Controller使用預先定義的pod模板建立pods,一旦建立成功,pod 模板和建立的pods沒有任何關聯,能夠修改pod 模板而不會對已建立pods有任何影響,也能夠直接更新經過Replication Controller建立的pods。對於利用pod 模板建立的pods,Replication Controller根據labelselector來關聯,經過修改pods的label能夠刪除對應的pods。Replication Controller主要有以下用法:
1) Rescheduling
如上所述,Replication Controller會確保Kubernetes集羣中指定的pod副本(replicas)在運行, 即便在節點出錯時。
2) Scaling
經過修改Replication Controller的副本(replicas)數量來水平擴展或者縮小運行的pods。
3) Rolling updates
Replication Controller的設計原則使得能夠一個一個地替換pods來rolling updates服務。
4) Multiple release tracks
若是須要在系統中運行multiple release的服務,Replication Controller使用labels來區分multiple release tracks。
· Labels
Labels是用於區分Pod、Service、Replication Controller的key/value鍵值對,Pod、Service、 Replication Controller能夠有多個label,可是每一個label的key只能對應一個value。Labels是Service和Replication Controller運行的基礎,爲了將訪問Service的請求轉發給後端提供服務的多個容器,正是經過標識容器的labels來選擇正確的容器。一樣,Replication Controller也使用labels來管理經過pod 模板建立的一組容器,這樣Replication Controller能夠更加容易,方便地管理多個容器,不管有多少容器。後端
第一張圖是舊版本的k8s,第二張圖是最新的架構圖,從圖上或者源代碼能夠看書,新版本的k8s代理程序kuberlet不可再直接watch etcd了,而是輪詢API來獲取pod配置變更信息(不知道什麼緣由)(查了下資料,原來是從安全性方面考慮,etcd只能被一個部件訪問)。安全
在網絡方面,k8s 默認使用Flannel做爲overlay網絡。
Flannel是CoreOS 團隊針對 Kubernetes 設計的一個覆蓋網絡(OverlayNetwork)工具,其目的在於幫助每個使用 Kuberentes 的CoreOS 主機擁有一個完整的子網。
簡單來講,它的功能是讓集羣中的不一樣節點主機建立的Docker容器都具備全集羣惟一的虛擬IP地址。網絡
在Kubernetes的網絡模型中,假設了每一個物理節點應該具有一段「屬於同一個內網IP段內」的「專用的子網IP」。例如:架構
節點A:10.0.15.0/24
節點B:10.0.25.0/24
節點C:10.0.30.0/24運維
上圖是Flannel的示意圖。在使用Flannel的主機,docker容器橋接的再也不是主機網卡,而是Flannel建立的虛擬Flannel網卡,同時各主機虛擬Flannel網卡的IP段不一樣。虛擬Flannel網卡將數據包發往Flanneld服務, Flanneld服務根據配置,以UDP或者vxlan封裝數據包,再從主機網卡發往目標主機。
在默認的Docker配置中,每一個節點上的Docker服務會分別負責所在節點容器的IP分配。這樣致使的一個問題是,不一樣節點上容器可能得到相同的內外IP地址。k8s安裝時,須要修改docker的配置文件,使的docker 網橋的地址錯開,同時再也不直接橋接在物理網卡上,而是Flannel網絡或者OVS網橋上,這使這些容器之間可以之間經過IP地址相互找到,也就是相互ping通。ide
K8s 的優點:
容器的高可用性,集羣的精細管理,複雜的網絡場景。
K8s 的劣勢:
K8s的學習曲線陡峭,同時運維的成本相對高點。工具
總的來講,我的以爲對內使用,看成私有云來使用場景,或者對容器的可靠性要求不高,swarm比較合適;對外服務,或者須要提供高可靠服務的場景,k8s更合適。性能