我从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是一个更高级封装,而他们在一起堪称珠联璧合,一起搞大事!如图:
Alt text

聊聊日常运维中的工作痛点

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具备丰富的功能,相对比较复杂,学习成本自然是有的;再说了,很简单的技术在网上随便找资料就能学会,也就没什么价值了。因此,决定写DockerKubernetes技术文章专栏,目的是让学习Kubernetes的朋友少走些弯路,在企业落地容器云平台提供一些企业实践性指导,希望自己所学所思的东西能够帮助到大家,能够有所启发。

此专栏以最佳实践为讲解导向,确保实用性、实战性。

这是一项颠覆性技术 - 容器

专栏地址:基于Kubernetes企业容器云平台落地与实践

若你在容器运维中,遇到Kubernetes方面的问题,请给我留言。同样,若发现有任何纰漏,还请随时指正,相互学习,共同进步!

记得点进去看看哦。

总结

  1. 首先,我们要明确企业上容器云的目的,容器是为业务服务的,任何技术都是为了更好的服务业务,这是我们的出发点。其次,看看业务特点是不是适合容器化,业务是不是具有版本迭代快、访问波动大、业务量增长快等特点。
  2. 容器平台目的是能为应用带来部署灵活、弹性伸缩、节省资源等优势。这些要求最好具备微服务架构、无状态化等特点,这些优势能更好的发挥。但不适合容器化的应用也不能勉强,否则建设后,不能带来预期的价值,不仅浪费了大量企业投入,还使得容器平台的价值得不到认可,这都不愿意看到的结果。
  3. 企业是一个大团队,要想体现个人价值,管好自己的一亩三分地是不行的,我们需要从一个全局角度看事情,发现其中的痛点去解决它;并且大家要建立一个统一的目标,共同围绕这个方向使劲,向自己的客户或用户交付最大化价值及最高质量的成果;团队以项目为导向,而不是职责!
    这种文化也是DevOps所倡导的,频发的交付带来更迅速的反馈,更高效的CI/CD流程可间接带来效益。