Kubernetes, 六岁生快~众大咖分享与它的美好回忆

2020-06-18

这月,Kubernetes项目启动六周年了。八位红帽人分享这六年中让他们记忆犹新的事。

微信图片_20200618153556.jpg

红帽云平台资深副总裁Ashesh Badani

在Kubernetes及其生态系统尚未成熟之前,我们就把宝押在它身上;讲真,我们自己那时都没有想好它的未来。2012年,红帽推出了OpenShift,但我们觉得总缺了点啥。当有机会重新设计标准化的容器运行时、格式和编排时,我们全力以赴。即使当时的OpenShift 3已面世,反响很好,与Amadeus的合作也非常顺利,Amadeus在OpenShift上启动了自己的服务平台。过去五年,我们和各种组织、大型社区携手前进。全球最大的银行、航空公司、酒店、物流公司,甚至政府都认可红帽OpenShift选用Kubernetes的道路,他们将关键任务应用委托给OpenShift。现在,我们看到分析和AI/ML用例激增。五年前,这是无法想象的。但是,我最喜欢回忆OpenShift早期没有使用Kubernetes,如何向企业用户解释我们在进行容器编排方面的工作。我们很高兴看到,几乎所有人,每个人都对这一未来方向表示认可,并承诺迁移到基于Kubernetes的架构。剩下的事情大家都知道了:2000个客户,每个云环境中的OpenShift部署都在增加。

红帽OpenShift和Kubernetes容器应用基础架构架构师Clayton Coleman

早在Kubernetes成为默认的标准事实之前,红帽就在评估容器编排系统。谷歌建议我成为该项目的第一批外部提交者之一。对于我自己、参与该项目的其他红帽人以及整个社区来说,这都是一段美好的时光。谷歌的开源团队完全了解该技术,由于我们在OpenShift和开源方面的背景,还有红帽在平台即服务方面拥有丰富的经验,我们将系统构建得简单又好用。双方一拍即合,我们了解企业对Kubernetes有哪些需求,我们有信心满足他们的需求。这对于一个项目来说是个很好的开始:一群了解企业用户痛点的人,这些人协作构建解决方案。其中所涉及的相互协作体验非常棒——在起初的一年半时间里,这些技术专家是有远见,有使命感和经验的人,他们清楚以前的问题出在哪里。开始并非一帆风顺,但我们构建起一个非常坚实的核心。作为开源社区,我们有责任保持我们的项目正常运转,尤其是随着采用率的提高。这是一段非常疯狂的旅程,我为我们的成就感到骄傲。如果我们成功了,那是因为你可以基于Kubernetes构建——这是未来创新的基础。

红帽资深首席软件工程师David Eads

最令我感到骄傲的是我开发的一些Kubernetes组件,这些开放式的组件,让其他开发人员能够创建我之前未想到的东西。诸如CRD、RBAC、API聚合和admission webhook之类的。它们花费了大量的投资,在整个社区中进行了大量的协调以进行生产。尽管现在看起来理所当然,但当时确实是抱着“先构建看看吧”的心态。

在此基础之上,我们已经看到了整个技术栈的发展。诸如operators、自托管部署、证书管理和新的存储扩展机制之类的东西。查看最近的增强建议,你可以看到有关多集群管理和网络扩展的新活动。我期待看到社区如何扩展已有的组件,以及它们将提供和启用的新功能。

红帽杰出工程师Derek Carr

当我回顾Kubernetes的历史时,我想到了作为一个社区,我们拥有如此强大的技术人员,这些技术人员具有各种技术背景,能够一起工作,并以崭新的视角解决问题,这是多么幸运的事。Kubernetes让我第一次接触到开源,记得在项目早期,我就阅读了pull请求,就跟我观看最喜欢电视节目的新一集一样令人兴奋。随着核心项目超过9万个pull请求,我跟不上所有变更,但我为大家建立社区所做的工作感到非常自豪。我经常回想起该项目的最初阶段,也记得它是如何成功的。作为工程社区,我们正在探索分布式系统的问题空间,但作为一个项目,我们的成功离不开每位工程师的分享与协作。

我对该项目所做的最早贡献之一:引入了Namespace资源。回顾相关的pull请求验证代码时,它可能是项目中的第4个API资源,并且是通过开源社区添加的第一个API。

它要求最初的维护者信任我,我对他们的信任深表感谢。实现Namespace支持需要建立一些概念,例如准入控制、存储api和客户端库模式。在更大的工程师社区帮助下,这些构建基块已演变为自定义资源定义webhooks和client-go,得到了项目几代领导人的支持。这使广泛的生态系统可以建立在Kubernetes之上,以解决更多用户的分布式系统问题,用户数量可比核心项目多多了。

当我回顾有关引入Namespace支持的早期经验时,它强调了Kubernetes项目价值的实际应用——分发胜于集中化,社区胜于产品或公司,自动化胜过流程,包容胜于专有,演进胜于停滞。只要Kuberentes恪守这些价值观,我知道我们将来会持续庆祝它的生日。

红帽核心云平台副总裁兼总经理Joe Fernandes

过去六年,我写了很多有关Kubernetes的文章。从红帽选择Kubernetes的原因,红帽如何基于Kubernetes构建,到最终在2015年红帽全球峰会上启动OpenShift 3,我们已经将其完全重建为Kubernetes原生容器平台。当1.0版本的发布日期在我们的发布日期后面,我们还不得不在Kubernetes .9上启动OpenShift 3。让我印象深刻的是客户对Kubernetes的看法。红帽拥有技术强悍和知识渊博的客户群,他们不仅想了解产品在功能和优点方面的功能,而且还想了解产品运作方式的所有底层细节。

我一直很感激他们,这确实使我们的产品经理和销售团队保持关注。我们准备了演示文稿,描述了Kubernetes从Pod到服务、复制控制器、运行状况检查、部署,调度、入口等的关键功能。首先,即使对于大多数技术用户来说,Kubernetes可能也很难理解。但是最终,你会意识到这些基本功能的强大,以及它们可以为你的应用部署带来自动化。在过去六年的无数次客户交谈中,我见证了客户意识到Kubernetes价值的时刻。不出所料,他们中许多成为OpenShift客户,还将一些最具挑战性的关键任务应用托管在OpenShift平台上。这些让我最感动,也是不断激励我们整个产品团队的动力。

红帽软件工程师Maciej Szulik

Kubernetes,是我对开源作贡献的第一个项目。我以前老为一些产品打补丁,不过它们都是不太重要的产品。我依然记得当我与朋友交谈,告诉他们我做的事情与之前一样,但这一次是开放的,还能获得广泛使用。最重要的是,与以往相比,我可以从更多的开发人员和用户那里收集反馈。我要谈论的贡献是Cron Jobs,它后来被称为Scheduled Jobs,是审计的初始版本。该项目让我在专业和个人方面快速成长。我充分了解了分布式系统,使用Go等编程。在全世界也交了很多朋友,在过去几年观摩了几乎所有的KubeCon大会。我非常开心自己参与了这么激动人心的旅程,也迫不及待想见证未来的模样。

红帽资深首席软件工程师Paul Morie

在添加许多“核心” API资源和功能,例如Secrets,Configmap和Downward API,我有很多美好的回忆。每次看到人们使用它们时,就让我思绪万千。作为开发人员,我也有自己喜欢的变更或重构,以及与之相关我珍视的时刻。其中一个就是看到我写的“keep the space shuttle flying”在社交媒体上受到了广泛的关注。它属于持久卷系统大修的一部分,主要提醒将来的开发人员在尝试简化逻辑时要小心。几年后,有人注意到我的笔记,发现它很有趣,可以分享,社交媒体上对此也进行了有趣的讨论。有人还拍了一张非常可爱的航天飞机照片,当我看到它时,我的脸上露出了微笑。

对我个人来说,另一个非常令人满意的事情是对kubelet的重构。我想我是在追踪Downward API里PodIP的一个bug,这时我意识到,通过kubelet.go文件的5000多行代码走了一条极其复杂的路径,我想要添加一些命令解决这种混乱的局面。逐渐地,我能够将这个巨大的文件重构为更小的、有序排列的文件,从而使事情(我希望)更易于理解和维护。没有疯狂的黑客攻击或其他任何攻击,只是在文件之间移动代码,但它仍保留在我的记忆中。

除了我们在Kubernetes社区所做的有趣的事,我想让大家探索Kubernetes没做过的事,我认为这是其成功的一部分。对我来说,Kubernetes不需要为容器镜像、配置语言、中间件等提供官方的构建引擎这一事实,是一个巨大的胜利,也是为什么它被如此广泛采用的一个原因。这些结果绝不是给定的,我们拥有出色的社区领导能力,为管理项目范围做出了明智的选择(有时是艰难的选择)。

Kubernetes社区没有尝试解决所有阳光下的问题(或者至少在任何特定时间都没有解决的问题),而是进行了明智的投资,使Kubernetes的开放式扩展成为可能。例如,在2016年,在kubernetes或kubernetes项目之外为service-catalog SIG开发API时,我们的选择非常有限,实际上必须编写自己的API服务器。现在,我可以编写一个自定义资源定义(CRD),并在几分钟之内就可以使用功能很简单的API。太不可思议了!Kubernetes社区对这些扩展机制的投资是该项目成功的关键部分。这些不仅让许多不同堆栈可以集成,从而实现了较大的采用范围,而且还促进了全新生态系统的创建。例如,如果没有我们拥有的扩展机制,就不会有Knative项目和Operator生态系统。

红帽OpenShift产品经理Rob Szumski

在Kubernetes旅程中,我花了一些时间回忆项目进行的几个重大转变。首先是巨大的可扩展性改进,这是由etcd 3与切换到gRPC,以便与API服务器通信的Kubernetes社区之间的协作推动。此更改大大降低了1000个节点群集上的调度时间,并扩展了规模测试,以成功应对之前失败的5000个节点群集。在Kubernetes代码库之外产生了巨大的开发成果。

Kubernetes功能的下一个重大转变是,Kubernetes可以“自托管”。自托管意味着使用Kubernetes本身运行Kubernetes控制平面和各种组件。这释放了平台自我管理的能力,这是在CoreOS Tectonic中率先提出并引入OpenShift的能力。易于管理是关键,因为我们看到Kubernetes跨云广泛部署。只能通过平台本身的自动化来使组织中成千上万个集群保持最新状态。最后是与CRD扩展机制结合使用的Operators概念。这为Kubernetes上的分布式系统,和复杂的有状态应用,推开了巨大的工作负载增长之门。集群的这种扩展,以及在Kubernetes可以运行的任何地方运行云服务的经验,对于混合云至关重要。


评论 (0)

加入圈子

校企桥微信公众号
  • 数通交流群 :612647431
  • 存储交流群 :618677698
  • 云计算交流 :615716396
  • WLAN交流 :115887243
  • 安全交流群 :608661181