Kubernetes应用交付兴趣小组主席有关开发者体验的问答


【编者的话】这篇文章是一个为期三个月的系列文章的一部分,该系列研究了2020年Kubernetes面临的挑战。这一篇,让我们来研究Kubernetes开发者的体验。

系列文章列表:


我们已经知道Kubernetes的开发者体验并非那么顺畅,这无疑也会阻碍Kubernetes的发展,但对于许多提供Kubernetes托管服务或专有发行版的公司来说,却是一个机会。那么,如何才能让开发人员在生产环境中更简单地使用Kubernetes呢?

所以,在今天这个关于Kubernetes和开发者体验的第二篇文章中,我们与云原生计算基金会的应用交付特别兴趣小组(Cloud Native Computing Foundation’s Application Delivery Special Interest Group - SIG)主席、Dynatrace的首席技术战略师Alois Reitbauer、阿里巴巴工程师张磊和VMware的高级工程师Bryan Liles进行了交谈。我们讨论了一些迫在眉睫的项目;CNCF和其他社区在改善开发者体验做了哪些项目,以及其他一些同时在进行的项目。下面就是我们谈话的摘要。

我们为什么要关心Kubernetes的开发者体验?

Reitbauer:很多公司为了向云原生架构迈进,都在加大投资。我们当然是希望他们成功,而不是让项目失败,尽管有些时候,他们还没有意识到事情有多么复杂。进而,这也意味着我们需要满足拥有各种技能且涵盖各个领域的开发人员,同时还包括那些习惯使用传统企业应用的开发人员。


“对编写软件的人来说,命名一直都是一个很头疼的问题。”——Bryan Liles,VMware公司
Liles:在这过去的六年里,Kubernetes变得越来越容易上手。刚开始的时候,构建起一个集群是相当困难的。现在你可以使用集群API并将对象放到集群中来创建一个全新的集群。我们之前只提供Pod,现在我们还提供deployments和replica sets。但是,开发人员并不会从这个角度去看,因此,我们觉得需要考虑开发人员关心的事情——应用程序和配置。

在改善开发者体验方面,CNCF具体都在做些什么?

Liles:在应用交付特别兴趣小组(App Delivery SIG)中,我们已经编写了一套指南,解释了应用程序的各个部件,并列出了各个部件对应的名称。对于编写软件的人来说,命名一直都是一个很头疼的问题。

Reitbauer:我们正在定义一种通用的语言,并先从概念上达成一致。我最喜欢的一个例子是,云原生空间中的每个人都喜欢谈论蓝绿部署和渐进式交付。但是如果你随便问三个人,这到底是什么意思,以及一些实现蓝绿部署的细节,你很可能会得到三个不同的答案。

如果假设这个概念是标准的,作为应用程序交付中的一个角色,那么它实际上意味着什么呢?它是如何工作的呢?


“使用Kubernetes应该更像是开一辆车,而不是造一辆车。”——阿里巴巴张磊
张磊:SIG正在积极地思考一些Kubernetes社区所缺少的东西。我们知道所有的开发人员都在抱怨Kubernetes的复杂性,但事实上,我们认为Kubernetes本身就应该是复杂的。它是一个管理基础架构层的平台。但这并不意味着每个开发人员或运维人员都应该与Kubernetes直接交互。所以在SIG,我们所考虑的是在整个架构层,Kubernetes到底应该处在哪一层。

当然,我们知道一定会有很多缺失的部分,例如,如何能让那些开发人员可以不必了解所有的底层技术,还能更容易地使用Kubernetes。就像,当你开车时,你只需要知道怎么使用方向盘和刹车,而不需要知道如何制造引擎或变速箱。所以说,使用Kubernetes应该更像是开车,而不是造车。

在比较大的社区中看到过哪些针对开发者体验的活动?

Liles:首先,最新版本的OpenShift在界面上的改进是一件大事,它关注于工作负载和管道,而不仅仅是Kubernetes中的对象。我还在一个叫做Octant的项目中,目标是为Kubernetes创建一个更专注于以开发人员为中心的UI。就是说,假如你有一个工作负载,它将不再专注于replica sets和pods。Kubernetes的很多知识点对新手来说都是看不见的。我们需要更多的人从事这样的项目,重新思考这些接口应该如何工作。

对未来有什么期望?

Liles:CNCF做的这些网络研讨会,通常他们都非常焦距在项目上。例如,如何通过Argo实现持续集成(CI)。说到未来的期望,举个例子,我希望看到CNCF能在这些网络研讨会上先停下来回头看一下,更多地谈谈为什么。通过持续集成你到底想要实现什么?持续集成为什么很重要?

再具体到未来的Kubernetes,人们很清楚下一步该做什么。到那时,持续集成(CI)和持续交付(CD)应该会很容易实现。正如现在,尽管我们也在取得进展,但在未来,想要得到高效的Kubernetes肯定要比现在还要更加简单。

Reitbauer:我认为坚持一条路走下去,固然是好的,但也有一定的风险,因为你必须在标准化的思维和避免单就某个项目的妥协之间取得平衡,尽管我们常说,标准化有助于提高生产效率。继续延伸一下汽车的比喻,我们都同意一点:是汽车就都会有方向盘和转向灯,这些我们选不了,但是我们可以选择我们最喜欢的汽车品牌。Kubernetes的情况也应该如此。目前在Kubernetes中唯一达成一致的是:它处在基本构建块的位置。

张磊:CNCF是代表标准的最佳选择,而且并不只针对某一个项目。“标准”可以只是指标准化的词汇,就像Bryan之前提到的那样。比方说,什么是应用程序?它是一个容器、Pod还是部署?这当然应该都是CNCF带头建立起来的标准。


“我们需要满足拥有各种技能且涵盖各个领域的开发人员,同时还包括那些习惯使用传统企业应用的开发人员。”——Alois Reitbauer,Dynatrace
让广大Kubernetes社区的人们感到困惑的原因之一是,Kubernetes在整个技术栈中,是从下到上构建的,且专注于基础设施层。然而,基础设施的概念和开发/应用层的概念之间一直存在巨大的隔阂。我想,对于我们来说,现在已经到了需要将一定的重心转移到应用层的时候了。

这三位SIG主席一致认为,改善开发者体验不仅是社区现阶段关注的重点,而且也必将是未来一两年的工作重心。举一个即将实现的例子,Liles提到了Kubeflow,它极大地简化了数据科学家在机器学习项目中使用Kubernetes的体验。“我们得把从这些项目中学到的经验,应用到编写web services的人身上,”他说。

原文链接:Q&A: CNCF App Delivery SIG Chairs Talk Developer Experience and Kubernetes(翻译:伊海峰)

0 个评论

要回复文章请先登录注册