Kubernetes 真的很复杂吗？
作者 | jason moiron
译者 | 弯月
责编 | 郭芮
出品 | CSDN（ID：CSDNnews）
近日，VMware首席工程师、Kubernetes项目创始人之一Joe Beda发表了一篇有关Kubernetes复杂性的精彩推文（https://twitter.com/jbeda/status/993978918196531200）。我建议你们看看这篇推文，里面有一些在我个人感觉特别引人深思的几句话：
首先，Kubernetes是一个复杂的系统。它提供了很多功能，同时也带来了新的抽象。但是，这些抽象并不能解决所有的问题，但是我敢肯定本来应该使用更简单的方式就可以解决的问题，很多人却选择用Kubernetes来解决。
计算就是建立抽象，一些最初感觉很尴尬的事情最后也变成了新的常态。高层抽象的目的不是简化，而是让自己更适合不同的任务。
还有下面的摘录：
话虽这么说，我认为，作为工程师，我们更加希望平衡我们需要创造的复杂性与我们需要研究的复杂性。
上述引用语句的顺序似乎有点乱，因为我想特别强调最后一个，我认为这是工程中认知偏差的重要来源。
在现实世界中，这些偏见被放大了，因为“我们自己建造的东西”实际上是“我们已经知道的东西”，而且这包括“我们已经学到的东西”。我认为程序员大量涌入管理层的一个重要原因是人们认为反复做几乎完全相同的工作所得到的回报会越来越小，而我们缺乏这方面的全面再教育。
我一直在“学习”Kubernetes，因为我们正在工作中尝试使用它。我发现Kubernetes很难，它本身很大，而且以我有限的知识很难知道我的观点是多么无知。我原本打算只写简单性与认知偏差，但随后Kris Nova发布了如下推文：
你可以在一条推文中描述你和你的团队切换到Kubernetes后带来的技术优势吗？
我真的很喜欢这条推文，因为如果从怀疑主义或者寻求确认的角度来看这个问题，那么这句话看似很有道理。而问题的答案也因人而异。对我来说，他们重点强调了我反复发现的Kubernetes的一个特殊问题，而且距离我成功完成一篇博文以来已经一年多了，但我可以再写一遍：
有关Kubernetes的说辞纯属胡扯。
通过实际使用我看见了很多Kubernetes带来的好处，聪明的技术人都能理解其带来的价值，但是很难用语言表述。你可以说它很难，因为Twitter上看不见它的身影。
想在#AzureStack上建立#Kubernetes集群吗？这可以帮助你利用Azure Stack的基础设施即服务（Infrastructure as a Service，简称IaaS）功能运行微服务和基于容器的工作负载。
昨天，欧洲核子研究委员会（Conseil Europeen pour la Recherche Nucleaire，简称CERN）团队在#KubeCon上播放“公共云宾果”（bingo），想看看有多少公共云可以连接到他们的Kubernetes联合会。
#KubiCon上的每个人都想知道@IstioMesh。@DanCiruli解释了它与#Kubernetes生态系统的差异。
那么Kubernetes究竟有什么用？我可以用它做哪些我做不了的事情？也许我们可以看看新的功能列表呀（http://kubernetesstatus.com/）。不错，貌似我们可以实现日志轮换，只不过1994年我就实现了。
市面上并没有这项技术的报道。此刻又不是在写简历，所以我一点不在乎我根本不了解云原生。根据我有限的经验，你可以利用Kubernetes实现：
- 库存管理和可见性；
- 构建与此相关的工具的通用平台（API）；
- 配置和部署的良好抽象；
- 服务发现和配置管理。
Kubernetes网站（https://kubernetes.io/）上有上述部分内容的介绍，但都非常抽象，并且很多都是需求金字塔上层的需求。在构建大型系统的时候，你需要大部分的功能，但是大型系统已经存在了，所以很明显Kubernetes并不是构建大型系统的唯一方法。不幸的是，如果你的部署已然非常大，那么你可能需要多个集群。
然而，当你进一步考虑这些功能时，你会发现有现成的东西还是很方便的。作为参与编写过两个自定义数据库的人，能够雇佣到非常了解你的工具的人是一件很棒的事情。书写良好的公开文档也非常棒。
Kubernetes的结构可以让我们在迅速发展的基础设置层面上，真正利用开源的东西构建一切——这是一个被低估的好处。我们所有人都可以合作与分享满载各种食谱的夜市或路边摊的承诺已被证明是不可行的。Helm和Istio都是Kubernetes复杂性的先驱，并且证明了作为平台，Kubernetes的工作方式不同于上一代不成熟的开发工具。
当然，它们不是免费提供的，即使从表面看来也有很多难以回答的问题，或有争议的答案：
- yaml是什么？该如何使用？
- 我想运行另一个流程……等一下，不行，除非我通过yaml详细描述它与父环境的每个关系。
- 我想运行一个数据库，而且我不希望你在没有任何数据的情况下在计算机上更改运行的日期计划。
- 怎么会出错呢？出错又会怎么样呢？
第一个问题只是开玩笑，但是也不完全是。对于每个可观察的系统来说，第二个问题都是非常讨厌的，而且对于云原生管理系统来说，不方便观察是非常糟糕的第一印象。
Alan Perlis曾说，如果编程语言需要关注无关紧要的事物，那就说明这个语言很低级。问题在于，如果你对方程式一无所知，那么你就很难掌握与之相关的事物，而且往往我们都很无知。
如果你有开发和部署大型分布式系统的经验，那么你知道我的上述列表是非常有说服力的，在这些事情上我们能达成统一意见是非常重要的。对于那些没有这些经验的人来说，上述列表强调了很多在你初次涉足这方面工作时会遇到的重要事项，这是带给社区的重大贡献。
但是如果你已然做出了决定，那么情况可能会很复杂。
让我们以服务发现为例。在使用服务发现的时候，我们也会使用运行状况检查和自我诊断，这是为了在服务中断或者性能下降时可以做一些很有趣的事情（http://ucare.cs.uchicago.edu/pdf/socc13-limplock.pdf）。这些都是难题，很多时候我们都会用非常粗略的方法解决这些问题，但是这些解决方案仍然可以为我们带来久经考验且非常必要的系统稳定性。
不幸的是，我们的方法与Kubernetes的集中式方法略有出入。通常如果你的需求太过复杂就会出现这种情况，但是这时为了处理适当的复杂度，Kubernetes的方法也会显得很复杂。这是一种经过深思熟虑且成熟的方法，但其结构与我们的完全不同。因此它的复杂带来了不兼容，这对双方都没有好处。
Kubernetes的配置管理更糟糕，因为它不仅复杂而且还不健全。有一些做应用程序的公司已经在尝试解决这个问题了，他们是否能够成功，我们只有拭目以待。
这种“复杂但不兼容”的模式已经反复出现很多次了。通常人们对待陈述这个问题的态度让我不禁联想：人们还会存储数据吗？也许这正是我所缺少的。
这一切都让我很担心，获利最多的人也会遇到使用Kubernetes时的很多问题，虽然这很自然（大型系统往往都很复杂），但是确实有损Kubernetes的形象。“实际上Kubernetes并没有扩展性”之类的传言越来越多，而且经验越多，就越会加重这句话的分量。
对于我们这个特定的项目来说，我认为如果考虑到整体寿命，那么我们仍然会选用Kubernetes。尽管如此，我仍然怀疑将现有的架构整个移动到Kubernetes上是个坏主意。如果你没有在Kubernetes特有的限制中一点点发展起来，那么就会遇到无穷无尽的麻烦，即使有很多其他形式的好处。也许这不仅限于Kubernetes，放在任何情况下都是如此，可能Kubernetes确实提供了痛苦最少的方法，虽然没有狂风暴雨的肆虐，但是也足以扼杀温室中的花朵。
考虑到Kubernetes的临界质量，时间也难以准确评估其复杂性。它是否能够优雅地适应它自身带来的各种提升？
与许多其他表面上已经脱离Google的技术一样，Kubernetes复杂性的主要来源之一也是：95％的人不需要也不想要Kubernetes。我没有去寻找http/2的自定义实现，虽然很多人都在做这方面的努力，希望有人能成功。
Kubernetes提供了许多抽象，但并没有提供解决方案，由此带来的许多问题将随着人们对于实现方式产生的共识而逐渐消失。群集管理系统的纷繁芜杂的状态将逐渐消失，因为按照惯例，人们将对这个目前正在广泛实验的问题达成共识。必要的复杂性似乎可以归结为过度工程化，就好似单页面时代的MVC框架中插入式的服务器端模板，系统却像应用一样与JSON端点通信。
那么，Kubernetes太过于复杂吗？可能吧。但是，我们需要经历一代技术，才能让Kubernetes简化后的核心提高自己的知名度，而且最终我们可能会很喜欢它。
原文链接：http://jmoiron.net/blog/is-k8s-too-complicated/
本文为 CSDN 翻译，如需转载，请注明来源出处。