做容器云的最佳用户


【编者的话】给用户看的容器云的科普和展望。

前言

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

我很讨厌这些电线杆小广告的宣传方式:可以实现弹性伸缩、自动化运维、持续交付、微服务、秒级部署、高强度容灾、多版本控制等功能,从而改善和解决复杂的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分太清楚,但这是给客户看的,不是内部考核用的,请大家脑补时往好处想。


原文链接:https://mp.weixin.qq.com/s/Ze7IB2nCBST8FTcPjMmTFA

0 个评论

要回复文章请先登录注册