复杂性会压垮k8s吗

k8s肯定不会是第一个受制于其规模的开源项目，但是专家有不同看法….

hadoop由于其使用不友好终于耗尽能量，相对于hadoop如今人老珠黄，k8s现在是开源社区新宠。正如Capital One的Bernard Golden所说，k8s“易于操作”，正大步向前。相对这种外交辞令，有些人认为k8s正在忍受类似痔疮一样的痛苦。

k8s会步hadoop的后尘吗？

很可能不会。相对于日益难用的hadoop，k8s变的越来越易用。尽管k8s用起来并不简单，但是其复杂性跟hadoop有本质不同。

Hadoop的不兼容复杂性

首先看看hadoop。当MapReduce概念提出时，Apache Hadoop就是很复杂的。随着更多功能不断加入和完善，复杂性更是不可避免。正如Tom Barber所说，“Hadoop本质是什么？MapReduce被Spark取代又被其它功能取代，等等”，尽管如此，仍然很笨重。

为什么笨重，VMware的Jared Rosoff认为：“Hadoop复杂性来自于其基础架构由太多不相关并且复杂系统沟通，每个系统都有不同生命周期和管理模式”。Flume，Chukwa，Hive，Pig，ZooKeeper等等，听起来名字都很灵气，但是把他们整合在一起工作的确是个噩梦，Hadoop其实是一个复杂解决方案栈，其复杂性来自于用户。

k8s的不同在于其扩展Hadoop的模式。如Rosoff所说，“Hadoop并没有考虑人们会如何扩展系统，因此造成了完全不兼容扩展的生态系统”，相对的，“k8s则选择了完全不同的扩展方式。Operators，CRI/CSI/CNI，确保当更多组件加入时，表现的更加顺畅”。换句话说，不想Hadoop不兼容扩展，“k8s扩展后仍然是个整体”。

k8s可信赖的复杂性

并不是说k8s很简单。Joe Beda of Heptio，作为k8s创始人，声明，“k8s是个复杂系统”，但是这种复杂性是必须的，因为“k8s做了很多抽象工作”。每个人都需要这种抽象吗？不，“大部分人更希望一个简易的功能”

但是对于需要使用k8s的用户来说，Beda强调，相对于已经熟悉的“老旧兼容性复杂性”，他们更需要一种全新的复杂性系统。

作为工程师，我们更愿意体验自己产生的复杂性，而不是需要去学习复杂性。随着开发工作采用Jenkis,Bash,Puppet/Chef/Salt/Ansible，AWS，Terraform等，我们造就了独特但是熟悉的复杂性，这种复杂性是内生的因此并不会感到很复杂。

当时让新人加入这种系统就会比较困难，他们可能对工具很熟，但是对系统独特性并不熟悉，这就是k8s有价值的地方。k8s提供一系列抽象层解决问题。尽管还会需要一些学习，但是这种模式会大大提高生产效率，而且可以在不同项目和开发环境下进行切换。

懂了吗？与某些具有锁定开发系统环境复杂性不同，k8s复杂性带来的好处是不会被捆绑在某种开发环境上。因此，k8s所获得的知识是可以迁移的。换句话说，“一次学习，终身受益。”

相关视频

这个90秒视频中，跟Heptio创始人兼CTO，Joe Beda一起学习k8s。

【视频】

学习一次，终身受益

k8s的学习过程也比Hadoop更容易，Gareth Rushgrove说，“在本地可以很容易运行k8s，相比于其他复杂系统，降低运行门槛非常重要”。另外，如CNCF基金的Chris Aniszczyk所说，“分布式系统内生具有复杂性，k8s帮助云提供商提供一种随需扩展的实现方式”，尽管如此，我们应该这么问这个问题：“k8s相对于它要解决的问题来说复杂吗？”，回答应该是“不”。

因此对于“k8s会步hadoop后尘吗？”，答案也是同样的。k8s已经走过了艰难时刻，尽管k8s的编排工具很复杂，不适合所有场景，但是所有的工具都需要学习，使用和理解。几个小时不够，因为这个工具是为了解决复杂问题的。复杂性分为可控的和意外的两种，hadoop属于后者，而k8s则是前者。

因此，k8s扔将会是容器编排领域的业界标准。