（译）开发和 Kubernetes 之间的鸿沟

（译）开发和 Kubernetes 之间的鸿沟

我用 Kubernetes 谋生，多数时间里，我都在为 Kubernetes 开发开源软件平台、中间件以及工具。我经常会问我自己以及我的同事：“我们要解决的问题是什么？”以及“我们要为谁解决问题？”。这种提问让我们能够保持对目标的专注，明确产品的价值。我也会把类似的问题抛给前同事们以及本地 Meetup 的参与者——他们各自的公司都在 “Kubernetes 之旅”的途中。如果他们正在构建或准备采用的是一个新的 Kubernetes 的相关工具，我通常会询问要解决的问题以及为谁解决问题。更多情况下，我会询问他们在采用 Kubernetes 的过程中遇到的问题。

不管采用 Kubernetes 的进度如何，两个回应是最常见的。第一个是“Kubernetes 太难了”，另一个是“Kubernetes 的抽象是错的”。第二个问题经常会用设问的方式提出：“Kubernetes 的抽象对么？”。

这种陈述缺乏了重要的上下文。其中没有澄清 Kubernetes 对谁来说太难了？对谁来说抽象有问题？在进一步的探求中，我得到的答案基本上来说是一致的：“开发者”。那么前面的陈述就可以修正为：Kubernetes 对开发者来说太难了，对开发者来说，Kubernetes 的抽象是不对的。

对此，我的观点是，Kubernetes 不是为开发者而生的。很多人会同意我的观点，但是令人惊奇的是，很多人压根没想过这个问题。

更少就是更多？对开发者来说，正确的抽象就是完全不抽象？毕竟在 Kubernetes 甚至是 Docker 诞生之前的几十年里，开发者一直使用自己惯用的技术栈进行开发和测试，所谓的应用抽象（或者 Kubernetes）的缺失，并不会让这些工作无法进行。我对开发者的建议是，开发者可以不关注 Kubernetes。

Kubernetes 是谁的？

在 Kubernetes 之前，组织中会存在一个角色，可以称其为部署专家，这个角色的职责是构建并部署应用和服务。他们需要对平台或相应的技术堆栈有着相当详细的认识，还可能需要一些复杂的、深奥的知识背景，有些自制的部署工具，以及大量的脚本。其工作可能是：部署 Ruby 应用、Python 应用、Tomcat 上的 Java 应用、WebSphere 应用等等不同的任务。这些人才是 Kubernetes 的目标用户——他们熟知应用部署的知识。Kubernetes 为这些用户提提供了能描述所有（容器化）应用的一致的部署模型，能够很好地提高其生产力并降低其学习成本。

经常有一个对 Kubernetes 的误解就是平台（“平台即服务”中的平台），其实它不是。即使是清楚这一点的人也往往对此视而不见，这样就会忽视掉部署专家这一角色的存在。潜意识中，对开发人员产生了一种不切实际的期望：他们应该能够自己使用 Kubernetes，从而可以取代部署专家这一角色。

知道了这些，也就成功了一半了。Kubernetes 并非为开发人员而生，更进一步思考，有三个可能的办法。

我认为最好将开发专家的角色重新加入组织。要完成这一过程，部署专家必须融入到开发团队中，或至少与开发团队紧密合作——和过去一样。我倾向于这种方法的原因是一个称职的部署专家能够优化部署并完成复杂的场景，其他方法难于做到这一点。不幸的是，这种办法可能最难落地。这种方式要对组织进行改进而非技术，从而弥合开发者和 Kubernetes 之间的鸿沟，但是大多数组织缺乏这样的自觉和进取心。可能你是一个初创企业，只有五个开发者，没人想再承担一个部署专家的角色；又可能你是一个有几千开发者的企业，无法将部署专家的角色扩展到支持整个开发团队，资源限制之下，第一个办法无法实施。这种情况下，就只能靠工具或者平台之类的技术手段来拉近开发者和 Kubernetes 了。坦率的说，这就是我和很多人的饭碗。然而不要低估识别和构建合适方案的成本（自建平台正在大行其道），其所需成本可能轻松地超越第一种方法。另外也不应忽视的一点是，平台和工具也都有自己的侧重点，可能会让用户陷入新的困境。用两个新问题解决一个旧问题可能不是个好办法。最后一点，可能你的组织还没有准备好采用 Kubernetes——甚至可能并不需要它。如果一个 Heroku 这样的 PaaS 甚至一个非 Kubernetes 的自建平台能够满足组织的需求，为什么还要给 Kubernetes 缴税？这种情况下，消灭开发人员和 Kubernetes 之间鸿沟的最好方法就是——不要使用 Kubernetes。再次提醒：准备好受到限制，并清楚认识未来走向。

结论

Kubernetes 并非为开发者而生，不要太快的认为，技术是唯一填补这一鸿沟的方法。强烈建议考虑，首先在组织层面做出改变。