爲何有了Compose和Swarm，還會有Kubernetes的出現？

1、k8s設計思想更先進

k8s的主要設置思想，是從更宏觀的角度，以統一的方式來定義任務之間的各類關係

1.k8s的核心功能圖

2.k8s的全局架構圖

把微服務比喻爲人，服務治理解決的是人的溝通，人太多了就須要生存空間和溝通方式的優化，這就須要集羣和編排。 compose和swarm能夠解決少數人之間的關係，好比把手機號給你，你就能夠方便的找到我，可是若是手機號變動的時候就會麻煩，人多了也會麻煩。 而k8s是站在上帝視角的高度抽象，看到了

1. 整體有哪些組織，不一樣組織有什麼樣的特色（Job、CronJob、Autoscaler、StatefulSet、DaemonSet...）
2. 不一樣組織之間交流可能須要什麼（ConfigMap，Secret...），這樣比較緊密的人在相同的pod中，經過Service-不會變動的手機號，來和不一樣的組織進行溝通，
3. 幫助人們快速構建組織(Deployment、RC)。

k8s就是把組織協調這項管理學落實到了計算機工程上

2、功能對比

1. swarm偏重的是容器的部署，而k8s偏重應用的部署

swarm中最小單元是容器，而k8s是pod，pod能夠由多個容器組成，在pod內共享volume和namespace，同一pod內的通訊更爲高效 pod有什麼好處？ 例若有一個web容器，爲了收集web日誌，須要安裝一個日誌插件，若是把插件安裝在web容器內：

1. 若是插件有更新，即便服務沒有變化也要從新把鏡像構建部署一遍
2. 若是插件存在內存泄露問題，整個容器都會被連累

而pod能夠爲日誌插件和web應用各自建立一個容器，二者共享volume，web應用只須要日誌保存到volume，兩個容器各自有本身的鏡像，更新互不影響

2. k8s比swarm有更多的調度策略，更適合大規模容器的的管理

swarm只有三種調度策略：spread、binpack、random，而k8s策略數更多多，還有端口衝突策略、容器掛載卷衝突策略、指定特定宿主機策略等。 Composer中，經過link將容器關聯起來，如DB的的鏈接寫入環境變量供進程使用，若是DB發生變化（如鏡像） 集羣中的節點，只要在同一network內，服務之間

3. k8s的負載均衡機制比swarm更靈活

swarm採用的是nginx+consul。 consul保存了各個docker中應用的網絡信息，nginx在compose時，在dockerfile中指定consul的地址，配置到nginx配置中，從而實現負載均衡，這樣有個缺點，就是新添加的容器IP和網絡須要手動添加到nginx文件中 而k8s負載均衡經過service實現，沒有容器IP變動問題，只要有相同的label的pod均可以經過service訪問，新添加的容器IP和網絡不會影響負載均衡器

4.k8s支持彈性伸縮

k8s能夠根據Pod的CPU、內存自動的調整Pod的個數，保障服務的可用性，swarm則不具有這樣的功能

原文出處：https://www.cnblogs.com/chenqionghe/p/11474486.html