docker|Docker痛失C位，运维人该何去何从（）
开源社区和云厂商之间存在着与生俱来的巨大矛盾，这种矛盾，好比前人栽树，后人乘凉，还不给树浇水。开源社区花费大量的心血，打造出一款款领先的技术，云厂商却白嫖这些技术谋取暴利，这种利益分配方式，对开源社区来说，极其不公。
Docker曾经依靠对技术人员友好简洁的技术，取代了Cloud Foundry，而后，又为了自己的利益，走上了商业化的旅途，从此与K8s社区产生了利益冲突，k8s社区也渐渐地走上了去docker的历程。有观点说，k8s作为云原生时代的C位，完全没有必要为企业版的docker背书。那么是不是意味着运维人也应该放弃docker?
首先，docker免费的对象是同时满足雇员在250人以下，年收入小于1000万美元的公司，个人或者非盈利性组织，那意味着，如果是在这种小型的公司做运维，那就不用放弃docker。
其次，如果是对于中型或者大型公司，docker的能力是否满足公司的需要，公司在技术选型的规划中，是否决定放弃docker?如果公司的技术架构上以然需要docker，那么技术人员也不需要放弃docker。
再次，即使目前k8s已经计划去docker，这项决定，是一个不计代价的商业行为，还是k8s已经找到了比docker更加好用的商业替代品？有说法说，k8s降维打击docker，因为，docker做到了容器技术优化，而k8s只管容器编排，却不管是什么容器。我觉得这种说法存在一定的问题，容器编排和容器本身，做的是两个事情，k8s与docker，在这个方面并不存在竞争关系，而是只有合作关系，无非是这种合作，目前破裂了。k8s做的不是降维打击，而是利用它的话语权选择了其他的容器当小弟，如果k8s体系内，没有一个比docker好用的替代品，那么k8s弃用docker将会给它自身带来一定的研发成本。同样，docker离开了k8s，那意味着它在容器编排方面也会有了新的负担。但对用户来说，具体是弃用docker还是弃用k8s，还是得看企业的技术架构的考虑。
【docker|Docker痛失C位，运维人该何去何从（）】最后，总结一下我的个人观点，Docker失去C位，和K8s分手，这件事情其本质上是两家的商业利益的关系，是容器相关技术的角逐。而对企业级用户来说，选则背谁的书，选谁支撑自己的架构，得结合自己的业务来决定。对技术人员来说，放不放弃docker，也得看看自己的技术主管是个什么意思，多和技术主管沟通，更可能规避自己被离职的风险。对找工作的学生来说，技多不压身，现在也有很多docker相关的工作，也未必就一定摒弃docker，找机会了解cgroup,namespace这些技术，或许，还有机会成为容器领域的大神。
推荐阅读
- Docker应用:容器间通信与Mariadb数据库主从复制
- docker镜像探索----dive工具
- 02|02|简单使用Docker命令
- Docker-Dockerfile
- Docker|Docker exec 出现 ＂fork/exec /proc/self/exe: no such file or directory＂ 问题
- 菜鸟的docker技术入门之路
- Scrapy定时爬虫总结&Docker/K8s部署
- 制作jdk8|制作jdk8 Dockerfile
- Go|Docker后端部署详解（Go+Nginx）
- docker|Docker