Kubernetes是否存在“杀敌一千,自损八百”的问题?


【编者的话】本文主要探讨为何多数中小企业并不倾向使用Kubernetes,同时介绍了Kubernetes的部分特性,包括可扩展性及复杂性等。另外,本文亦将阐述Kubernetes相对于ECS、Swarm的关键性比较优势。

【烧脑式Kubernetes实战训练营】本次培训理论结合实践,主要包括:Kubernetes架构和资源调度原理、Kubernetes DNS与服务发现、基于Kubernetes和Jenkins的持续部署方案 、Kubernetes网络部署实践、监控、日志、Kubernetes与云原生应用、在CentOS中部署Kubernetes集群、Kubernetes中的容器设计模式、开发Kubernetes原生应用步骤介绍等。

Kubernetes是否存在“杀敌一千,自损八百”的问题?

很多朋友可能都思考过这个问题,特别是考虑到大部分中型SaaS、网络及电子商务企业早晚要放弃HeroKu(一款支持多种编程语言的云平台),(每个人最终都将放弃Heroku。)而最终决定到底该选择AWS、Docker Swarm或者是其它更为“简单”的解决方案——当然,也包括直接投向Kubernetes的怀抱。

由Heroku迁移至AWS、Docker Swarm或者是其它自主开发型解决方案的作法,往往会给我们带来一些自寻麻烦且本可避免的常见陷阱。这是因为上述解决方案初看起来似乎比Kubernetes更为简单,但从长远的角度讲却常会带来更严重的局限性、更难以解决的挑战以及更为可观的开销。由于单纯逃离Heroku并不足以帮助我们摆脱这些恐怖的噩梦,因此目前很多公司开始在犹豫当中选择Kubernetes。下面,我们将对原因作出具体阐述。

Kubernetes:一切源自可扩展性

中小型企业之所以拒绝选择Kubernetes,一个很普遍的原因就是其可扩展性。CTO可能会说,“我只拥有一款Rails程序,一套简单的传统EC2虚拟机就足以解决问题。Kubernetes处处都在考虑扩展——而我不需要这么夸张的可扩展能力。”

但这正是问题所在:并非所有的基础架构都需要进行由数十到数千的大规模节点扩展(但是,大家至少需要两个节点,从而尽可能降低宕机事故的可能性)。千万别被扩展性所误导——Kubernetes的优势绝不仅限于扩展性。

对于新手来讲,如果你的Rails应用内存不足并引发宕机,则运行在普通EC2的实例上的此类应用程序将不会自动重启; 这意味着运维人员需要随时待命以解决问题。另外,Kubernetes拥有自动运行状态检查机制,因此如果你的应用程序因某种原因而无法响应——包括运行时内存不足或者遭遇锁死,Kubernetes都会自动进行重启。Kubernetes还能够轻松基于分支环境进行开发,这一点在EC2实例当中同样几乎无法实现。

思考一下——您打算如何运用更高可用性、自动扩展性以及更为丰富的功能等重要优势?

意外复杂性与必要复杂性

中小型公司拒绝Kubernetes的另一个原因在于复杂性。

事实上,Kubernetes确实相当复杂。不可否认,Kubernetes的启动与运行皆难于上手。但这种复杂性也从另一个侧面反映出Kubernetes的倾向性。

早在1960年代,弗雷德·布鲁克斯(Fred Brooks)立足计算机科学领域撰写了一本名为《人月神话》的开创性著作。在书中,他讨论了他的团队在构建IBM大型机OS/360系统时的所见所感。他提到了两种系统性复杂因素:意外复杂性与必要复杂性。意外复杂性属于一类随机介入的因素(属于负面类型),而必要复杂性则属于完成工作所必需的因素(正面类型)。

ECS与Docker Swarm表面上看起来更简单,但却皆具有更多的意外复杂性,并会将这些复杂性直接传递给用户。这种复杂性在初始阶段往往并不明显。那么这种意外复杂性到底有何表现?首先,大家需要弥补系统在能力方面的缺失。比如:ECS要求用户编写大量代码以实现可用性(有时需要成百上千行代码)。这些工具的使用还受到架构层面的限制,同时带来陡峭的学习曲线。

在另一方面,Kubernetes的意外复杂性很低而必要复杂性很高(实现用户实际想要实现的目标所需要的复杂性)。Kubernetes之所以如此强大,是因为它已经是谷歌的第三代容器管理技术——而Swarm与ECS还只是第一代。

Kubernetes的“税收”

部分企业并不担心Kubernetes的复杂性,而是担心这种复杂性无法带来应有的回报。他们担心技术团队在Kubernetes上付出很高的“税收”,但最终却没能因此获得足够的价值。

为了避免这种“税收”,他们会雇佣一支技术水平高超的运维团队并希望其能带来理想结果。毫无疑问,如果给予他们充分的发挥空间,他们一定会选择自行构建一套基于Kubernetes的平台。但如果权限不足,他们会尝试从零开始构建起类似于Kubernetes的解决方案(我们将其称为‘伪Kubernetes’),而这显然会给公司带来技术债务。(因为在自行构建时,大家最终得到的一定只是是一套错误且成本更为高昂的Heroku变种。这一点已经在云基础架构的第十条法则中进行过充分论证。)

当你的目标是构建产品时,为什么要将有限的资源浪费在运营任务身上呢?如果你不需要或者至少不必从零开始构建自己的Heroku,为什么要雇佣那么多运维工程师呢?我们将在本系列的下一篇文章中就这一话题展开探讨,即:你的开发人员是如何变“坏”的。

内容展望?

运维咨询:利用我们数十年的运维专业知识帮助您完成云端迁移,让你的架构拥有自动化能力并将你的SaaS与Web应用提升至新的水平。

运维服务:与专家合作维护你的运维平台,同时负责各类日常运营问题——这意味着您不再需要招聘全职运维人员进行产品开发与交付。

原文链接:Is Kubernetes Overkill?(翻译:康良)

0 个评论

要回复文章请先登录注册