一、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容器內：
- 如果插件有更新，即使服務沒有變化也要重新把鏡像構建部署一遍
- 如果插件存在內存泄露問題，整個容器都會被連累
而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則不具備這樣的功能