现状核实 : Kubernetes真实开发体验一瞥

【编者的话】这是为期三个月的系列文章中的第一篇文章，系列文章探讨了2020年Kubernetes的挑战。在1月份，我们将研究Kubernetes开发人员的体验。

尽管Kubernetes的使用量急速增加，但在开发人员体验方面，尤其是在企业环境中，仍然存在诸多难题需要克服，这已不是秘密。 服务提供商 New Relic 的产品经理 JF Joly 解释说：“通常情况下，新技术可以非常有效地解决一些问题并且对开发人员提供有效的帮助，因此开发人员会迅速使用它，但是当后续面对扩展时就会出现诸多弊端。

对于刚接触Kubernetes的开发人员来说，在笔记本电脑上建立单个群集似乎很简单。 Canonical 产品经理Ammar Naqvi解释说：“当进入公有云面向数千个节点和数千个群集时，实施的难度将成倍增加。”

一方面，开发人员发现系统集成Kubernetes后简化了复杂应用程序的供应和管理， 但是这也可能很快会让开发人员陷入另一种配置困境。尽管这可能不是Kubernetes本身的错，但是由于不同的IT团队努力将其签入现有系统运营，这样可能就导致了整个架构的混乱。

那么开发人员使用Kubernetes到底有什么体验呢？

不同类型的开发人员

开发人员并非单一的群体，整体描述其对于 Kubernetes 体验是一个非常大的挑战。 Java开发人员的日常工作流程与 Python 开发人员的日常工作流程不同。“我们更愿意认为，没有单一的开发人员经验，” Red Hat 的产品战略高级总监 Brian Gracely 解释说。“我们发现的第二件事是：一些开发人员只想编写软件，他们根本不关心集容器或Kubernetes。” 在大型组织中，此类开发人员可能确实不需要关心容器和平台。 根据Joly的说法，当New Relic迁移到Kubernetes时，开发人员受到很小的影响。这是因为只有平台团队负责直接管理Kubernetes。 他说：“有很多人正在开发与Kubernetes不直接相关的功能，对于他们来说，Mesos和Kubernetes之间的变化并不重要。” Joly说，在New Relic的许多客户中这种模式的例子比比皆是。在大型、技术精湛且具有高度专业化的组织中这些场景也是如此。 在The New Stack的 播客采访中 ，分析师 Janakiram MSV 解释说，开发人员在使用Kubernetes时面临的挑战之一是其缺乏像“平台”这样的高内聚界面。 相比之下，以另一种基础架构技术虚拟机（VM）为例，它通过一系列复杂的技术为最终用户提供有价值的服务，所有这些技术都可以提供无缝切换且一致的体验。 Kubernetes虽然也可以提供了自身的价值，但它还没有一个使开发人员可以轻松理解“内聚抽象”平台。 他说：“ Kubernetes几乎仍然只是一个基础架构。“

“没有为Kubernetes的消费者提供开发者体验或用户体验。” Kubernetes最初是为集群管理员设计的。 但是今天，它已经从基础架构 工具 转变为用于管理工作负载平台。 “但是Kubernetes缺少基础架构之上的关键层支持。”Janakiram MSV 补充说。

入门

当然，有许多开发人员希望并且需要精通在生产环境中使用Kubernetes。 学习并使用Kubernetes不一定很容易。 Kubernetes培训公司 Magic Sandbox 的首席技术官 Mislav Stipetic 说：“现有的大多数文档都在'hello world'级别上。” “当您处理具有状态、高级网络、安全性问题的应用程序时，唯一的学习方法就是在Medium 上浏览大量的技术文章。” 与此同时，这方面的专家并不多。Stipetic说:“我们在网站上做了一项调查，让人们对Kubernetes的知识打分，从1分到10分。”“Kubernetes的一位创始人填写了这张表，他只给自己的知识打了七八分。” “挑战从未停止，”Naqvi 表示赞同。“如果你独自学习vanilla Kubernetes，学习曲线是恒定的，至少这是我自己的经验，” 当开发人员开始使用Kubernetes时，他们需要学习一套全新的术语，而且在人们开始使用时，理解所有东西是如何相互关联的常常是一个挑战。 Platform9 的首席技术官 Roopak Parikh 解释说:“我们看到的另一个挑战是理解不可变的基础架构，这意味着你不能在以后修改配置文件。”

配置文件

在使用Vanilla Kubernetes时，一个常见的开发人员经验问题是管理配置。Naqvi解释说:“即使您是一位经验丰富的开发人员，要正确配置也很有挑战性。”“很难让所有东西都与你现有的技术栈配合得很好。”

您的基础设施中包含的关联越多(Kubernetes部署的规模越大)，管理配置的难度就越大。Naqvi说:“如果你想在Kubernetes部署中做一些有用的事情，你需要更多的基础设施组件。”把它没有bug地运行起来，这是很有挑战的。

在vanilla Kubernetes中，许多新用户不了解如何将Kubernetes与CI / CD系统集成。 这是大多数托管服务所提供的东西，据Joly称，这对New Relic的许多客户来说都是巨大的收益。 他说：“对于诸如GKE或EKS之类的托管服务，我们的客户确实具有巨大的吸引力，这确实降低了壁垒。”

在某些方面，Kubernetes的挑战源于公司快速在生产环境使用。Joly见过许多公司在没有花时间让架构师制定政策、没有为组织定制规范化的Kubernetes蓝图的情况下使用Kubernetes，最终因Kubernetes的多个“rogue”部署被胡乱拼凑在一起从而导致混乱。对于新开发人员来说，在没有清楚地了解Kubernetes运行的基本构建块的情况下，仓促进入也是很有诱惑力的。Kubernetes中的所有抽象层对于大规模的操作都是非常重要的，但是对于只想快速测试的开发人员来说，这些抽象层似乎会分散他们的注意力。

另一个常见的痛点是对系统的可见性。或者说是在更基础的层次上如何将所有系统组合在一起。我们还没有面向客户在内部使用Kubernetes的时候就发现了这一点，” Joly说。“了解所有系统之间的关联非常困难，如果某一个节点上有问题，那么它会影响应用程序的哪个实例？”

体制问题

另一方面，采用Kubernetes的另一个难题可能是组织结构。如果公司没有建立一个新的平台团队来管理Kubernetes，而只是简单地利用现有的基础设施团队，让它负责这个新的基础设施，那么这就违背了团队迄今为止所衡量的一切——稳定性和高可用性，这意味着很少有变化。“我们通常看到成功的公司以使用Kubernetes构建更快更新的应用，这和我们的目标是一致的，”Gracely说。“因此，我们应该围绕环境将频繁变更这一理念进行设计。”

对于某些开发人员来说，这也可能是一种费力不讨好的工作。Stipetic说:“你甚至不会因为这种转变而获取奖励，这是一种看不见的工作。”“人员和知识孤岛的困境必须改变，要付出更多的汗水才能取得成果。”

回报

事实上Kubernetes已经被如此大规模迅速使用，开发人员体验后得出一致结论：值得。 Stipetic表示：“ Kubernetes可能使简单的事情变得越来越复杂"， 但是，一旦开发人员熟悉Kubernetes，使用特殊的功能就可以是工作变得异常轻松。 它还为整个组织创建了处理容器编排的标准方法，这使得加入新团队成员更加容易。

Joly说：“就编排和更好地利用资源以及缩短企业上市时间而言，Kubernetes确实提供了您从未有过的价值。”

原文链接： reality-check-a-peek-at-the-developer-experience-with-kubernetes 翻译： ylzhang