我从14年开始关注容器技术，15年开始使用容器技术，这些年看到了容器技术爆发式发展、版本的快速迭代，记得当时Docker版本还是0.7，Kubernetes版本是1.0，到现在Docker CE 18，Kubernetes 11。
一门新技术的产生必定是为解决某些问题而存在的，同样也会带来一定的问题，容器技术是一项颠覆性技术，改变了企业的CI/CD（持续集成/持续交付，部署）环节的方式，开启了一场革命，我们一起看看这场革命怎么实行的！
Docker是什么？
2013年初，Docker横空出世，一个怀揣着改变应用程序部署的革命技术，目前看来，显然它做到了！
Docker是一个开源的应用容器引擎，对应用进程进行封装隔离，并且独立于宿主机与其他进程。Docker理念是将应用及依赖包打包到一个可移植的镜像中，可以运行到任意Docker引擎上。具有快速部署、可移植性、环境隔离等特点。
Kubernetes是什么？
Kubernetes（K8S）是Google开源的容器集群管理系统，其设计源于Google在容器编排方面积累的丰富经验，并结合社区创新的最佳实践。
K8S在Docker容器技术的基础之上，大大地提高了容器化部署应用简单高效。并且具备了完整的集群管理能力，例如服务发现、资源配额、缩容扩容、动态更新、持久化存储、监控、日志等，涵盖项目周期的各个环节。
经过这几年的快速发展，K8S已经成为建设容器云平台的首选方案。
Docker与Kubernetes有什么联系？
说到这里，就涉及到容器云平台核心组成了。
Docker是一个容器引擎，用于运行容器，Kubernetes是一个容器编排系统，不具备容器引擎功能，相比Docker是一个更高级封装，而他们在一起堪称珠联璧合，一起搞大事！如图：
聊聊日常运维中的工作痛点
1. 多开发语言，多运行环境
公司发展迅速，业务量蹭蹭的往上涨，同时也会开展其他业务线，打造自己的生态圈。多业务线维护给运维也带来一定挑战，例如多项目、多开发语言，例如开发语言有Java、Go、Python、还有PHP，这就意味着运行环境可能非常复杂，还要要维护多个版本，写N个脚本、长期积累还会导致环境臃肿、杂乱、故障率高、不易维护等问题，当迁移业务时，这个不敢动，哪个不敢动！
A：根据不同环境构建不同的镜像，例如：
- 基础镜像：基本的运行环境，例如Java、PHP
- 项目镜像：包含项目，可直接部署
镜像在镜像仓库中管理及维护，通过版本管理应用环境镜像。
2. 环境不一致引发的争议
开发人员通常在Mac、Windows系统上开发项目，功能上线，合并代码到版本仓库，随后通知测试部门测试，测试通过后发布到生产环境，目前大多数互联网公司都是这种流程。
那么问题来了，项目可能在测试环境或生产环境就运行不起来…，为什么呢？操作系统、软件版本、少依赖包、配置忘记修改了等等？从而出现这些神秘的Bug，神秘的配置。有同学可能说：写一个参考文档。通常还会有遗漏，而且这依赖于文档编写能力和理解能力。
A：容器消除了线上线下的环境差异，保证了应用生命周期的环境一致性和标准化。开发人员使用镜像实现标准开发环境的构建，开发完成后封装项目及依赖环境，测试和运维人员可以直接用这个镜像在任何Docker Engine创建容器进行测试和发布，大大简化了持续集成、测试和发布的过程。Docker的可移植性，保持运行状态一致性，可想而知，是否更容易解决问题呢？
3. 微服务架构带来的问题
微服务架构是当下最流行的一种业务架构开发模式，目的是让臃肿的业务系统拆分成多个微服务，一个微服务完成某个特定的功能，如电商的购物车、支付、用户后台、消息等等。每一个微服务都是微型六角形应用，都有自己的业务逻辑和适配器，微服务部署在多台服务器上，每次项目升级都要java -jar启动服务，维护几十台这样的服务器，简直苦不堪言，感觉要吐血了。
A：
微服务特点：组件化、松耦合、去中心、灵活独立。
容器特点：沙箱机制、隔离性、可移植性、快速部署。
是不是恰到好处呢？容器的特点在微服务下能更好发挥优势，是部署的理想选择。
4. 项目上线周期长
马上就618、双11了，到时业务访问量会很大，得扩容服务器了。
新项目/扩容大致流程：申请资源 -> 资源审批 -> 虚拟机创建 -> 环境部署 -> 代码测试 -> 上线。
多部门协作，这个流程起码得一周吧！流程化提高一定生产力也可能带来一定局限：增加事项落实时间；那如何才能做到业务快速扩展并发能力和缩短上线周期呢？难道这个流程真的不能再优化了嘛？
A：说到弹性伸缩，在云计算领域数AWS做的好了 - AWS Auto Scaling。AWS Auto Scaling 可以监控您的应用程序并自动调整容量，以便以尽可能低的成本来保持稳定、可预测的性能。使用 AWS Auto Scaling，您可以在几分钟内为多项服务中的多个资源轻松设置应用程序扩展，例如EC2（云主机）。
当使用容器技术后，这种弹性伸缩的单元就是物理机/云主机之上的容器了。由于Docker容器快速启动的特性，可以在秒级部署几十个、上百个容器来提供服务，成倍提高并发能力，缩短上线周期。当业务高峰期下去了，动态销毁一部分容器，释放资源，让业务低成本稳定运行。
上述问题你有遇到过吗？在容器技术未出现之前可能很难解决这些问题，但容器技术的出现针对这些痛点交出一份满意的答卷，能帮助企业IT基础架构解决或者改善现状！
如何高效学习Docker/Kubernetes？
学习容器技术最大障碍不是网上资源太少，而是网上资源太多。大多数缺章少节的，很难按照教程跑通，并且Kubernetes具备丰富的功能，相对比较复杂，学习成本自然是有的；再说了，很简单的技术在网上随便找资料就能学会，也就没什么价值了。因此，决定写Docker和Kubernetes技术文章专栏，目的是让学习Kubernetes的朋友少走些弯路，在企业落地容器云平台提供一些企业实践性指导，希望自己所学所思的东西能够帮助到大家，能够有所启发。
此专栏以最佳实践为讲解导向，确保实用性、实战性。
专栏地址： 基于Kubernetes企业容器云平台落地与实践
若你在容器运维中，遇到Kubernetes方面的问题，请给我留言。同样，若发现有任何纰漏，还请随时指正，相互学习，共同进步！
记得点进去看看哦。
总结
- 首先，我们要明确企业上容器云的目的，容器是为业务服务的，任何技术都是为了更好的服务业务，这是我们的出发点。其次，看看业务特点是不是适合容器化，业务是不是具有版本迭代快、访问波动大、业务量增长快等特点。
- 容器平台目的是能为应用带来部署灵活、弹性伸缩、节省资源等优势。这些要求最好具备微服务架构、无状态化等特点，这些优势能更好的发挥。但不适合容器化的应用也不能勉强，否则建设后，不能带来预期的价值，不仅浪费了大量企业投入，还使得容器平台的价值得不到认可，这都不愿意看到的结果。
- 企业是一个大团队，要想体现个人价值，管好自己的一亩三分地是不行的，我们需要从一个全局角度看事情，发现其中的痛点去解决它；并且大家要建立一个统一的目标，共同围绕这个方向使劲，向自己的客户或用户交付最大化价值及最高质量的成果；团队以项目为导向，而不是职责！
这种文化也是DevOps所倡导的，频发的交付带来更迅速的反馈，更高效的CI/CD流程可间接带来效益。
