做容器云的最佳用户

给用户看的容器云的科普和展望。

前言

我一直瞧不上容器厂商的企宣话述，连带着看轻了容器技术；但容器技术是有价值的，容器编排技术更是一片大好的发展方向。

我很讨厌这些电线杆小广告的宣传方式：可以实现弹性伸缩、自动化运维、持续交付、微服务、秒级部署、高强度容灾、多版本控制等功能，从而改善和解决复杂的IT应用场景。事实上是使用者自己设计维护可以弹性伸缩、自动运维、容灾冗余的程序，无论是用物理机、虚拟机还是容器（进程），本来能弹性的服务还是能弹性，没容灾的服务还是在赌命。

合格的架构和运维都瞧不上这些废话，因为十年前我们用裸机就能实现这些功能了。但世上没有那么多合格的架构师，云计算要解决的就是缺人的问题。最早的云主机也是类似夸张无赖的宣传，我第一眼看云主机也觉得是个噱头，这些遗毒至今还在误导客户。本文是为说清容器的能力特性，我们该如何用好容器编排系统。

容器的基础特性

容器和虚拟机都属于IaaS云的范畴，按申请资源量付费，不关注客户业务逻辑和访问频率。容器只是隔离出一个进程，而虚拟机是模拟了一整套操作系统，这是双方的本质区别。

进程的创建就是申请内存、端口等系统资源，但应用的初始化仍然需要时间，所以容器启动到服务可用仍然需要几秒甚至更久。容器的快速部署优势在于CI/CD环境里，快速部署不只是说程序启动的快慢，而是决策的快、操作的简单。

容器是一个进程，本地文件系统是容器最大短板。文件和设备的所与者都是“用户/OS/虚拟机ID”这类长效标识，不可能是“进程ID/容器ID”这类临时状态。假设我在一个虚拟机上开了多个容器分别读写多个文件夹，现在我重新启动这些容器，新启动的容器根本不知道自己“上辈子是哪个容器”，该接管哪个文件夹。Kubernetes的StatefulSet已经在尝试将磁盘等资源绑定到一个Pod内，但这个功能还不够成熟，且需要外部存储系统的支持，所以容器使用本地文件存储仍然是一种冒险行为。

我们该引导客户放弃本地文件存储的习惯，本地只读写重启就失效的缓存和socket文件，让容器用户将持久化文件都放到对象存储和数据库。这是个必然的技术趋势，即使不用容器用物理机，本地文件都是无法被统一读取的，集中存储在OSS和RDS的数据，才能称之为数据资产。

少谈做容器能省资源

容器因为虚拟化程度低，肯定比虚拟机要节省资源，但面对这种诡辩我会三联问：

• “您的职场生涯中关注过消耗服务器资源吗？”

• “拿省下的钱给你们团队发工资好不好？”

• “为了资源效率，我们直接用裸机行吗？”

容器公司见到客户就谈价格谈省钱，又说不清楚省了多少钱，实际上砍了IT项目才是最省钱的，能解决问题客户可以多花钱。

在云平台运营过程中，容器技术确实能节省成本，但这是靠容器资源的更小调度粒度决定的。假设一台物理机有180G内存可用，客户买了5台32G内存的虚拟机用了160G，剩余20G内存就是卖不出去了。但如果拿这20G内存给一堆只用500M到2G的容器进程用，还是整机都跑小容器不跑大虚机，资源利用率一下就高很多了。那闲置的20G内存成本早晚也要把摊到客户身上，但这和客户直接可视的资源售价没关系。

这个理由最蠢的地方就是，它把容器云的客户限定成了对成本敏感的运维人员，而使用和更新容器、使用容器编排系统，都是要研发人员一起努力才能发掘出来。

容器编排系统的核心优势

很多人都说容器云是“私有云谁用谁爽，公有云谁用谁丧”，其实原因就是：容器云需要开发人员配合才能用好，而容器编排系统比容器自身更重要。Kubernetes与其说是Docker的竞争者，不如说是容器行业的庇护者。有了Kubernetes这个容器编排系统，虽然Docker技术不那么醒目了，但其可用性更高更接地气了。

单纯用Dokcer的容器，更像是个封装的比较彻底，做足了资源隔离的JVM。研发人员只在程序出错时才会关注Runtime，而运维人员没感觉到这有什么酷的，但确实容器云已经有存在的价值了。比如说OpenStack、PaddlePaddle这类新兴软件和开发框架的部署环境没那么简单，用Docker包一层就变的非常友好了。

对于持续集成和交付场景来说，以前我们是硬压着研发和测试，务必保持版本一致、务必保证文件打好包，从不盲信回滚预案，必须后半夜上线，就这样还天天出故障；现在自动上线的压力确实小多了，大家都可以放心测试生产环境一致、保证文件不漏传、可以和Git无缝集成，可以扔给研发和测试半自助上线了。这就是我前文所说的，容器快速部署的优势在于决策的快、操作的简单。

而Kubernetes的兴起它把容器从改良工具变成了革新武器。以前有过很多架构师做培训和文档，讲解服务发现、注册、编排、路由，资源监控和统计，研发就是说听不懂。可是一套来自大厂的开源方案出来了，研发就主动去拥抱了。有了Kubernetes以后，即使研发人员做不了架构和运维，只要肯适应Kubernetes的设计逻辑，都可以取代这两类人的工作。他们通过配合了Kubernetes或类似组件的容器云，老老实实改变研发流程，让代码和架构，让架构和资源耦合到一起。

现在我们能说清楚过去为什么没有公有容器云成功案例，因为客户的执行层是脑臀分离的——运维推动研发把程序改造到可以上容器，以完成运维的业绩，猫让狗帮忙抓条鱼给猫吃，这事能搞定才怪。而成功的私有云案例，其原始推动力都是客户的技术决策层和架构师，他们不依赖Kubernetes也能搞定架构问题，这不是容器技术和容器厂商的成功，而是客户技术团队的成功案例。

现在是个有趣的节点了，Kubernetes在逐渐被大家接受，研发拥抱Kubernetes就可能设计出符合架构美学的服务。相信很快就会出现容器云的真正成功案例——客户技术足够普通但上云后架构足够合理。

文末总结

以前我看到虚拟机套单容器的事情，因为不信任他们老套的宣传话述，狠狠的嘲笑了这些容器云从业者。

但我和一个值得信任的高手聊天时，他反问我，这种架构除了看起来不够优雅，有没有什么逻辑上的致命问题？

如果有一些服务就是要业务进程包在容器里，但数据文件就是要落在硬盘上，这时候用容器加云主机可以说是一种取长补短的嫁接，总好过拿Pod本地存储做冒险。

我也是因为这次会面而想写本文，开始更正态度看容器的，有问题的人用过的工具一样可以是好工具。

想想自己曾经也对云计算不屑一顾，人生的循环真是有趣。

备注

1. 本文中的运维指的是业务服务运维，不是资源支撑运维。

2. 很多人会跟我说容器比虚拟机启动的快，但容器应该跟虚拟机里的进程比重启速度啊，虚拟机重启进程也不用重启系统啊。

3. 我一般说Docker纯粹指的是它的容器部分，不包括Swarm等部分。

4. 在我看来容器对系统运行环境的封装就是像个JVM，我知道容器封装的更多更彻底，但这只是五十步和一百步的区别。

5. 我知道文中没把Docker和Kubernetes分太清楚，但这是给客户看的，不是内部考核用的，请大家脑补时往好处想。

文章转载自公众号：云算计， 点击查看原文。

基于Kubernetes的DevOps实践培训

本次培训包含：Kubernetes核心概念；Kubernetes集群的安装配置、运维管理、架构规划；Kubernetes组件、监控、网络；针对于Kubernetes API接口的二次开发；DevOps基本理念；微服务架构；微服务的容器化等，点击识别下方二维码加微信好友了解具体培训内容。

点击阅读原文链接即可报名。