Kubernetes是否存在“杀敌一千，自损八百”的问题？-云栖社区-阿里云

本文讲的是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?（翻译：康良）

原文发布时间为：2017-08-30

本文作者：kl2422

本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。

原文标题：Kubernetes是否存在“杀敌一千，自损八百”的问题？