這段時間學習使用k8s，繼而學習使用Docker、swarm，swarm可以理解為Docker的擴展，下面我來比較一下使用k8s和swarm搭建服務器群的差別
1. 資源占用。k8s要比較多。在阿里雲上租的2核4G用k8s有點撐不住，什么都不干主節點和工作節點都要10%的CPU，50%的內存，就那么一直占着，難怪阿里的k8s最低的節點都是4核8G。
2. 上容器的過渡性。從實體服務器到容器可能有一個過渡期，象我在嘗試應用Docker時，現在系統有不適合的地方需要考慮很多手段如何在不增加費用的情況下平滑過渡。這時swarm勝出。因其貼近原始的Docker，如redis、rabbitmq，使用Docker的端口配置可以臨時將服務搬到Docker而不需改動其他服務的配置，因端口可以原封的對應，但k8s的service只能使用主機30000開始的端口。
3. 費用比。k8s需要多一些。一是因為其資源占用比較高，二是k8s默認master節點不安裝pod，按高可用性要求3個master再加上worker的機器，這個費用就有點高了。我利用swarm搭建的環境只使用三台服務器，三台都作為master使用，因swarm默認master也會安裝container，默認我就省了worker的費用。
以下就平滑過渡需要注意的事項說說
1. 必須控制容器最大CPU。我的情況下，后端服務啟動過程長，占用CPU高。在人工維護時這不是問題，因后端一個個來的。但在容器就要注意了，有可能兩個或更多的后端一起跑起來，相互搶占資源，服務器很可能會死機。如何限制網上查一下很多說明。一般的書上也會說。這里不展開。
2. 用戶問題。我的情況是有一台服務器支撐起整個過渡期間的服務，Docker會與該服務器並行一段時間，它們之間會共用一次文件，所以它們需共用使用tomcat用戶來使用這部分資源。如果容器里用tomcat(非root用戶）跑程序，就要注意容器內目錄的寫入問題了。當然這部分通常是我們程序的臨時目錄，也通常是創建鏡像時ADD\COPY進去的，而問題正來自於ADD和COPY到鏡像都是使用root用戶，而不管你主機當前該目錄是什么用戶權限。大家可以考慮這個文章
https://yeasy.gitbooks.io/docker_practice/image/dockerfile/copy.html
在ADD、COPY指令的時候還可以加上 --chown=<user>:<group> 選項來改變文件的所屬用戶及所屬組。
COPY --chown=55:mygroup files* /mydir/ COPY --chown=bin files* /mydir/ COPY --chown=1 files* /mydir/ COPY --chown=10:11 files* /mydir/
3. volume問題。我們總想將
4. 查錯。如果容器起來了，我們程序跑起來，分析程序的日志來查相關配置問題，可以在主節點上執行
$docker service ls $docker service logs <上面列表其中一個的name>
但如果容器沒跑起來，使用以下命令可以看到截斷后的錯誤信息
可以使用不截斷的方式顯示錯誤信息，我們再指定一下要顯示的列，如下
$docker service ps wcsc_site-t --format "{{.Name}}: {{.Error}}" --no-trunc
wcsc_site-t是我自己的其中一個service，下圖是顯示結果
如果容器成功起動，想進入容器里看看，可以使用ps指令查出ID，再使用exec bash命令。以下還是以我的名為wcsc_site-t的服務為例
先要找到service所在的節點
$ docker service ps wcsc_site-t
再到相關節點的主機上運行
$docker ps -a|grep wcsc_site-t
$docker exec -it <上面查詢的ID> bash
