docker 集羣：K8S& swarm對比

Swarm
Swarm是Docker開發的原生集羣工具，Swarm使用標準的docker API，這意味着容器可以使用Docker客戶端命令啓動，Swarm會選擇合適的主機來運行容器。

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沒有機制來保證容器的運行。

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通。

K8s 的優點：
容器的高可用性，集羣的精細管理，複雜的網絡場景。
K8s 的劣勢：
K8s的學習曲線陡峭，同時運維的成本相對高點。

總的來講，我的以爲對內使用，看成私有云來使用場景，或者對容器的可靠性要求不高，swarm比較合適；對外服務，或者須要提供高可靠服務的場景，k8s更合適。