一点感想：K8S和Docker的取舍

之前一直用Docker来部署和发布应用，近期因为工作需要，被迫了解和使用K8S，不免有些感慨，吐槽下：

1、无论Docker还是K8S，都可谓很牛逼的DevOps工具！而Docker容器的发明，无疑是软件史上最伟大的发明之一！

回顾下软件编程的历史，可以浓墨重彩地赞颂的几个发明：

- Fortran：首个高级语言，第一次让程序员可以脱离硬件去编程，只考虑算法问题。

- Java虚拟机：首个跨平台语言，通过引入虚拟机机制，可以让程序员不用担心平台的差异，从容在C和S之间OOXX

- Linux：首个开源操作系统，脱袜子(Torvalds)先生一己之力，打造出可媲美大厂才能研发出来的服务器操作系统

- 谷歌搜索：首个分布式海量存储和计算系统，突破了人类处理数据能力的瓶颈，使得人工智能也得以腾飞

- Spring：虽然跟前面几个大牛比起来只能算是小弟，但Rod凭借以一敌万的勇气，开辟了轻量化软件框架的血路，让开源系统的质量和水平上升到新高度，彻底挫败了IBM等大公司想要垄断这一切的企图

- VM：开辟了虚拟机的先河，使得过去高不可攀的分布式开发环境得以平民化，更多的个人开发者可以轻松地完成高复杂系统的开发

- Docker：不仅仅是VM的模仿，而是对VM的颠覆。Docker完美地把业务和平台解耦，配置和软件解耦，使得软件的部署、发布、升级以及运维自动化成为可能。从小处说，可以低成本替代商业化的VM，从大处说，促成了软件工业的高度自动化。

2、如果已经熟用Jenkis，是否仍然选用K8S？不建议！

K8S当然是基于Docker容器技术，构建的一套非常好的运维工具。但是对于小公司来说，资源不是那么紧张的情况下，最好不要赶时髦，强行上K8S。你需要知道，一将功成万骨枯，任何强大都是靠巨大牺牲换来的。这个牺牲是什么？就是工具的复杂度。本来Docker容器一句话的事情，在K8S里需要拆成Pod、RC、Service，甚至Dns好多句话，每句话都是一句菊花。

当然如果你觉得Docker使用也很复杂，Jenkis使用当然更复杂，那么您可以戴上K8S这些菊花。

3、K8S真能弹性可伸缩？健壮性呢？

K8S主打的卖点就是自愈性和可伸缩，这个当然不能去轻易地否定。但是它的自愈性和可伸缩真的那么香吗？还得看看健壮性或者可靠性！K8S的架构也跟其他集群差不多，一个master，若干个node，然后用probe探针来检查所有容器的健康状况，这就有个巨大的隐患！万一这个master阵亡了，你再多的node又如何自愈呢？从架构来说，Redis的集群机制显然要高明很多。

想明白这点，其实K8S的自愈性和弹性伸缩不免让人捏把汗。

4、如果纯朴的Docker和华丽的K8S同时站在你面前，你选择哪一个娶回家？

个人的选择是Docker+Jenkis，而非K8S。原因很简单，Docker部署对各种软件部署的侵入性太小了，集群性配置尤其，同时又满足了轻便性，就是一个镜像可以幻化出无数个并行跑的容器，同时又能用挂载的手段使得各不相同。一旦需要迁移，只需要把业务和配置相关的部分拷贝和转移就可以了，软件部分使用同版本镜像甚至更新版本即可。再配合Jenkis+maven的自动编译和部署，很容易就做到运维自动化。

但K8S就不是那么回事了，你需要写很多编排文件，从POD写到RC，从Deploy写到Service，还要整DNS，而且负载均衡完全系于iptables，同样让人捏把汗。就好比你不过想找个能过日子的女人生活，结果你去娶了个希拉里，这不是摆明了让自己难受吗？

5、结束语

说了这么多，其实最后我们还是用的K8S。不是我们想这样，而是因为我们没得选择。

各位，你现在知道我有多痛苦了吧？！