现状调查：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解释说，“我们发现的第二件事是，一些开发人员根本不关心Container或Kubernetes，他们只想编写程序。因为，在较大的组织中，他们的开发人员可能真的不需要关心它。”根据Joly的说法，当New Relic迁移到Kubernetes时，开发人员受到的影响很小，因为负责管理Kubernetes的是另一个平台团队。他说：“有很多正在进行功能开发的人，他们与Kubernetes并没有直接的联系，对他们来说Mesos和Kubernetes之间看不出有什么变化。”这种情况是他在New Relic的许多客户身上看到的，特别是那些大型的、技术复杂的、高度专业化的组织。
分析师Janakiram MSV在接受The New Stack的播客采访中说到，Kubernetes所面临的诸多挑战之一是，缺乏一个统一界面的“平台”。相比之下，另一种基础设施技术——虚拟机（Virtual Machine）技术，VM通过一组复杂的技术为最终用户提供了有价值的服务，使最终用户得到无缝、清晰的体验。Kubernetes虽然也能够提供价值，但依然没有出现一个能让开发人员可以轻松理解，且足够清晰的抽象概念。“Kubernetes的所处的位置，更倾向于基础设施层，”他表示，“Kubernetes并没有向它的消费者（consumer）提供任何开发者体验或用户体验。”因为，Kubernetes最初是为集群管理员设计的。但是今天，它已经从一个基础设施工具变成了用来管理工作负载的一整套平台。“但基础设施之上关键的一层缺失了。”

入门
当然，有许多开发人员希望并且需要在生产环境中熟练使用Kubernetes。学习使用Kubernetes并不一定容易。Kubernetes培训公司Magic Sandbox的首席技术官Mislav Stipetic表示：“大多数文档都是‘hello world’级别的。当你在处理一个有状态、有高级网络、有安全需求的应用程序时，唯一的学习途径是从大量媒体文章中深挖探究。”
与此同时，这方面的专家现在并不多。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运行所需的基本模块还没有清晰了解的情况下，就仓促进入从而导致各种混乱。Kubernetes中，所有的抽象概念层对于规模部署都是非常重要的，但是对于那些只想快速测试某些模块的开发人员来说，这些抽象层似乎会分散他们的注意力。
另一个常见的痛点是对系统的可见性，或者更简单一点说，如何将所有的东西组合在一起。Joly表示：“我们内部在开始与Kubernetes合作时就发现了这一点，在没有客户的情况下也是如此。理解事物之间如何进行联系是一个巨大的挑战。所以说，如果一个节点有问题，那么我的应用中的哪个实例会受到影响呢？“

体制问题
另一方面，企业想引入Kubernetes，最大的学习曲线之一很可能是来自组织结构方面的。如果公司不是去建立一个新的平台团队去管理Kubernetes，而只是使用现有的基础设施团队，并让他们负责这个新的基础设施。这会违背了这个团队迄今一直在被考核的标准——稳定性和高可用性。要知道，稳定性和高可用性通常意味着尽量不要改变。Gracely说：“我们通常看到那些在Kubernetes取得成功的公司，他们一般会把Kubernetes与那些需要频繁迁移的新应用一起挂钩。所以我们在设计时应该考虑到环境是会经常变化的。”
对于某些开发人员来说，这可能也是一个费力不讨好的工作。Stipetic说：“你甚至都不会因为这种转变而获得奖励，因为这是一种看不见的工作。人员和知识的储备方面必须要做出改变，通常来讲，任何事在看到结果之前都需要付出相当多的努力。”

回报
Kubernetes能被如此迅速地采用的事实表明，反复地讨论开发人员体验，肯定会是值得的。“Kubernetes让简单的事情更简单，让困难的事情成为可能，”Stipetic如是说。开发人员一旦熟悉了Kubernetes，那些高级的机制就会使工作变得更容易。Kubernetes还为整个组织创建了处理容器编排的标准方法，这使团队里的新成员会更容易上手。Joly说：“Kubernetes在编排、资源高效利用和快速市场化方面提供了前所未有的价值。”

图片由Pixabay的skeeze提供。

原文链接： https://thenewstack.io/reality … etes/