这段时间学习使用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用户）跑程序，就要注意容器内目录的写入问题了。当然这部分通常是我们程序的临时目录，也通常是创建镜像时ADDCOPY进去的，而问题正来自于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
