為什麼有了Compose和Swarm，還會有Kubernetes的出現？
一、k8s設計思想更先進
k8s的主要設定思想，是從更巨集觀的角度，以統一的方式來定義任務之間的各種關係
1.k8s的核心功能圖
2.k8s的全域性架構圖
把微服務比喻為人，服務治理解決的是人的溝通，人太多了就需要生存空間和溝通方式的優化，這就需要叢集和編排。
compose和swarm可以解決少數人之間的關係，比如把手機號給你，你就可以方便的找到我，但是如果手機號變更的時候就會麻煩，人多了也會麻煩。
而k8s是站在上帝視角的高度抽象，看到了
- 總體有哪些組織，不同組織有什麼樣的特點（Job、CronJob、Autoscaler、StatefulSet、DaemonSet...）
- 不同組織之間交流可能需要什麼（ConfigMap，Secret...），這樣比較緊密的人在相同的pod中，通過Service-不會變更的手機號，來和不同的組織進行溝通，
- 幫助人們快速構建組織(Deployment、RC)。
k8s就是把組織協調這項管理學落實到了計算機工程上
二、功能對比
1. swarm偏重的是容器的部署，而k8s偏重應用的部署
swarm中最小單元是容器，而k8s是pod，pod可以由多個容器組成，在pod內共享volume和namespace，同一pod內的通訊更為高效
pod有什麼好處？
例如有一個web容器，為了收集web日誌，需要安裝一個日誌外掛，如果把外掛安裝在web容器內：
1.如果外掛有更新，即使服務沒有變化也要重新把映象構建部署一遍
- 如果外掛存在記憶體洩露問題，整個容器都會被連累
而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則不具備這樣的功