现状调查:Kubernetes开发人员体验一瞥


【编者的话】这篇文章是一个为期三个月的系列文章的第一部分,该系列将研究2020年Kubernetes面临的一些挑战。这一篇,让我们来研究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在编排、资源高效利用和快速市场化方面提供了前所未有的价值。”

原文链接:Reality Check: A Peek at the Developer Experience with Kubernetes(翻译:伊海峰)

0 个评论

要回复文章请先登录注册