本文发布已超过一年。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已不正确。
观星、解决方案和居家度假：Kubernetes 1.24 版本发布访谈
Kubernetes 项目有来自世界各地的参与者。有些人是朋友，有些人是同事，有些人是陌生人。唯一将他们团结在一起的是，无论他们的差异如何，他们都有一个有趣的故事。我很荣幸成为每周 Google Kubernetes 播客中 Kubernetes 社区故事的记录者。每次发布新的 Kubernetes 版本，都会采访发布团队负责人，讲述该版本的故事，以及他们自己的个人故事。
随着 1.25 版本的临近，这一传统得以延续，回顾了 1.24 版本的故事。该版本由 Jetstack 的 James Laverack 领导。 James 在 5 月份参加了播客，虽然您可以在下面阅读他的故事，但如果可以，请听听他自己的声音。
请务必订阅您获取播客的任何平台，以便收听我们来自云原生社区的所有故事，包括下周的 1.25 版本的故事。
此文本经过了轻微编辑和压缩，以使其更清晰。
CRAIG BOX：您进入 Kubernetes 的旅程经历了金融科技 (fintech) 行业。请告诉我一点关于您是如何接触到软件的？
JAMES LAVERACK：我走了一条相当传统的软件工程道路。我完成了学业，然后在布里斯托大学获得了计算机科学学位，然后我从那里找到了一份软件工程师的工作。有些偶然，我最终做了金融科技的工作，这很有趣，很有吸引力。
但在我加入 Jetstack 之前的最近一份金融科技工作中，我最终参与了一个软件项目。我们需要 Kubernetes 来解决一个技术问题。因此我们实施了 Kubernetes，而且经常发生的情况是，我最终成为团队中唯一一个了解基础设施的人，而其他所有人都在进行应用程序开发。
我最终非常喜欢基础设施方面，以至于我决定转而全职从事该方面的工作。所以我四处寻找，找到了 Jetstack，他们的办公室就在马路对面。我可以在我们办公室的窗户看到他们。所以我决定直接走到马路对面加入他们，更多地做这些 Kubernetes 的事情。
CRAIG BOX：布里斯托的技术环境如何？您去那里上学，然后就再也没离开过？
JAMES LAVERACK：差不多是这样。我认识的很多人和我的很多朋友都发生过这种情况，你去某个地方上大学，然后就相当于永远被困在那里了。就英国的那个地区而言，它一直以技术热点而闻名。它有很多科技公司，显然，我之前工作过的一家公司是一家金融科技公司。我认为一些大公司在那里设有办事处。对于“非伦敦”来说，我认为情况还不错。
CRAIG BOX：但您说技术热点指的是科技行业，而不是天气，我猜是这样。
JAMES LAVERACK：是的，天气和英国通常一样。有点阴天和多雨，我很喜欢。我非常喜欢这样。
CRAIG BOX：公共交通好吗？
JAMES LAVERACK：公交车还可以。我们最近安装了一条新的公交线路，在建造期间每个人都很讨厌它。现在它完成了，每个人都喜欢。所以我认为这是标准配置。
CRAIG BOX：就是这样。作为一个在伦敦生活了很久的人，我很自然地说“伦敦有点像新加坡。它有自己的小城市国家。”但是，每当我们去到世界的那部分地区时，尤其是巴斯，那是一个非常可爱的小镇。
JAMES LAVERACK：哦，巴斯很可爱。我去过几次。
CRAIG BOX：您去过 Box 吗？
JAMES LAVERACK：去哪里，抱歉？
CRAIG BOX：在巴斯郊外有一个叫 Box 的小镇。我在所有建筑物外面都拍了照片。我宣布自己是市长。
JAMES LAVERACK：哦，不，我想我没有去过。
CRAIG BOX：好吧，如果你在这个地区，大家可以去看看。让我们回到 Jetstack。他们在马路对面。很棒的公司，那里的两位 Matt，是那里的联合创始人。您的面试过程是怎样的？
JAMES LAVERACK：面试过程很轻松。一个午餐时间，我只是沿着马路走到一家咖啡店，和 Matt 聊了聊，我们进行了愉快的交谈，谈论了我的背景和 Jetstack，以及我希望在新职位上实现的目标等等。我申请的是软件工程师。然后他们在最后的时候，他看着我，说，“那么，当解决方案工程师怎么样？” 我说，那是什么？
他说，“好吧，你知道，它实际上是当一名软件顾问。你去帮助公司实施 Kubernetes，告诉用户所有你喜欢的东西。但你是全职做这个。” 我说，“好吧，也许。” 最后他说服了我。我最终以解决方案工程师的身份加入，并且抱着如果我不喜欢它，我可以转回去当软件工程师的想法。
将近三年过去了，我从未接受他们的邀请。我一直当解决方案工程师。
CRAIG BOX：在您工作的公司，我猜您实际上是编写软件的人员和 Kubernetes 中部署人员之间的顾问。那么您转到 Jetstack 后继续担任该角色是否更有意义？
JAMES LAVERACK：我认为是这样。我认为这是我喜欢的事情。并不是说我不喜欢编写软件应用程序。我一直很喜欢它，我们有一个非常有趣的产品和一个非常有趣的团队。但我只是觉得它更有趣。而且当我们有应用程序要编写时，越来越难以证明花时间在它上面是合理的。
这完全没问题，这对当时团队的需求是有意义的。但这并不是我想做的事情。
CRAIG BOX：您认为这是否说明了 Kubernetes 是面向开发人员还是面向运营商的？您认为是否始终需要有一组不同的人员来维护运行的基础设施，而不是编写在其上运行的代码的人员？
JAMES LAVERACK：我认为在某种程度上是的，不管它是一个单独的平台团队，还是因为运行它的人员是某种顾问。或者，它是否以一些更全功能版本的 Kubernetes 中抽象出来——尤其是某些云托管版本，在某种程度上消除了这种需求。因此，我认为绝对没有必要聘用一个平台团队。但我认为需要有人来做，或者你需要以某种方式隐式或显式地为有人做这件事付费。
CRAIG BOX：在您加入 Jetstack 的三年里，您为客户所做的工作有多大的不同？这只是学习一件事并将其推广给多个人的情况，还是你遇到的每个人都始终面临不同的挑战？
JAMES LAVERACK：我认为总会有不同的挑战。我的角色变化很大。例如，很久以前，我做了一个 Istio 安装。但这是一个相对复杂、单一网格、多集群的安装。而且那是在多集群支持像现在这样容易获得之前。相反，我曾为特定客户的用例构建基于 Kubernetes 的自定义编排平台。
情况各异，而且每次与客户的互动都不同。这正是我喜欢这份工作的一个要素，事情的方式和进展都存在着多样性。
CRAIG BOX：当平台赶上进度，并能够更容易地管理多集群环境时，您会回到客户那里，让他们了解最新的方法吗？
JAMES LAVERACK：这取决于情况。我们的大多数合作都是为了解决特定的问题。一旦我们解决了那个问题，他们可能会再次找我们。但通常来说，在我的工作领域，这不是一个持续的合作。Jetstack内部有一些人会做这种持续合作，但在我的团队中并不多。
CRAIG BOX：您的个人简介暗示您曾被称为“任何公司政策演变的原因”。这里面有什么故事吗？
JAMES LAVERACK：[轻笑] 我想我只是不能让事情顺其自然。我当时和Jetstack的运营总监谈话，他曾经对我说，每当他考虑新的公司政策时，他都会问它是否能通过James Laverack测试。也就是说，我会不会去研究它并发现一些可怕的漏洞？
例如，当我刚加入公司时，我查看了我们关于公司设备的可接受使用政策。它规定您不允许在笔记本电脑上拥有受版权保护的材料。当然，这很有道理，因为您不希望人们进行软件盗版之类的活动。但按照字面意思，这意味着您不允许在您的机器上拥有任何受任何人版权保护的东西。
CRAIG BOX：比如可能安装在上面的操作系统？
JAMES LAVERACK：比如可能安装在上面的操作系统，或任何东西。你知道，这显然没有任何意义。所以他调整了这一点，而且从那以后，我就一直在摆弄类似的政策。
CRAIG BOX：发布团队通常被认为是一个行政角色，而不是一个纯粹的编码角色。这是否说明您以前是软件开发人员，现在更像一个顾问，职业生涯发生了某种变化？或者还有其他原因吸引您参与社区的这个特定部分？
JAMES LAVERACK：我并不认为它技术含量较低。我的意思是，是的，您做的编码工作少得多。当我告诉我的朋友和一些同事关于我的角色的更多细节时，他们总是感到惊讶。实际上，我的工作中几乎不涉及任何编码。
我不认为我的角色已经改变为减少了编码。事实上，我在Jetstack最近的一个项目，一个客户项目，涉及大量的编码。但我认为真正吸引我加入Kubernetes这个角色的是社区。我发现参与SIG Release并与发布团队互动真的很有意义。所以我一直都很喜欢做这件事，尽管正如您所说，其中并没有那么多编码工作。
CRAIG BOX：的确，您的妻子对您说，“我认为你的工作不再是编码了。你整天都在和人说话。” 这让您有什么感觉？
JAMES LAVERACK：啊，很恼火，因为她是对的。这是几个月前的事了，当时我正忙于所有的Kubernetes会议。而且，我当时的客户项目也涉及大量的技术讨论。我每天都要开三四个小时的电话会议。我不介意这样。但我会出来，部分原因当然是因为你在家工作，所以她总能看到我。所以我出来后，会去拿杯咖啡，然后说，“哦，我有个会议，我得走了。”她会说，“你还写代码吗？” 我想事实上就在圣诞节之后，她问我，“你上次写代码是什么时候？”我不得不思考一下。然后我意识到，也许那里有问题。好吧，不是问题，但我意识到我可能不像以前那样写代码了。
CRAIG BOX：您是那种会拿起一个业余项目来尝试解决这个问题的人吗？
JAMES LAVERACK：当然。我最近开始为我的Minecraft服务器编写一个Kubernetes operator。这可能说明了我目前的状态。
CRAIG BOX：如果它里面有Kubernetes，那听起来不像是业余爱好。
JAMES LAVERACK：[笑] 您不认为Kubernetes是一种业余爱好吗？
CRAIG BOX：这取决于情况。
JAMES LAVERACK：我想我确实认为它是。
CRAIG BOX：我想现在是了。
JAMES LAVERACK：在某种程度上是的。
CRAIG BOX：您提到在决定参与之前观察了发布团队的工作过程。那是作为与客户合作的一部分，并想看看某个特定功能是否会被纳入发布，还是有其他原因让您看到了Kubernetes社区的这种运作方式？
JAMES LAVERACK：我加入Jetstack后不久，就有机会去参加KubeCon圣地亚哥会议。我想我们实际上在那里见过面。
CRAIG BOX：是的。
JAMES LAVERACK：我们还一起吃了晚饭，对吧？我去的时候，在Jetstack只待了几个月。我真的没有以任何认真的方式参与社区。结果，我只是跟着我当时的同事James Munnelly到处走。James很可爱。而且，你知道，我只是跟着他走来走去，因为他认识每个人。
我最终和一群Kubernetes的人在一家酒店酒吧里，包括SIG Release的联合主席，以及社区内其他一些职位的持有者Stephen Augustus。我碰巧问他，我想参与进来。如果我以前从未参与过，有什么好方法可以参与Kubernetes社区？他说，哦，你应该加入发布团队。
CRAIG BOX：所以这完全取决于你最终在酒吧里和谁在一起。
JAMES LAVERACK：是的，差不多是这样。
CRAIG BOX：如果我早点找到你，你可能已经在Istio上工作了。
JAMES LAVERACK：是的，我可能已经在Istio上工作了，我可能最终在某个其他的SIG中做一些事情。我只是碰巧在和Stephen说话。Stephen提出了建议，我就试了一下。然后我就在这里待了三年。
CRAIG BOX：我想我记得当时您正在做一个etcd operator？
JAMES LAVERACK：是的，没错。那是一个客户项目的一部分，他们很庆幸地让我们开源了它。这是一个用于etcd的operator，他们需要在Kubernetes中运行它，这当然与您通常想要运行它的方式相反。
CRAIG BOX：我记得当时我曾问过您，我非常确定这些东西已经存在了，并且问过为什么需要有不同的东西。
JAMES LAVERACK：这是因为他们需要一些非常具体的东西。已经存在的那些都是为了运行无法关闭的集群而设计的。只要有一个副本保持运行，您就可以继续运行etcd。但他们需要能够暂停并重新启动整个集群，这意味着它需要磁盘持久性支持，而事实证明这相当复杂。
CRAIG BOX：如果你直接把所有的数据都扔掉就容易多了。
JAMES LAVERACK：把所有的数据都扔掉要容易得多。我们需要小心管理它。我们考虑过fork并修改现有的一个。但我们意识到，从头开始可能同样容易，所以我们这样做了。
CRAIG BOX：从那以后，自从2020年的Kubernetes 1.18开始，您一直是每个发布团队的成员，担任各种各样的角色。您都经历过哪些角色？
JAMES LAVERACK：我最初是发布说明的影子，并且在1.18和1.19这两个版本中都担任这个角色。在1.20中，我是发布说明的负责人。然后在1.21中，我再次作为增强功能的影子，在1.22中成为增强功能负责人，但在1.23中又成为了发布负责人影子，最后在1.24中成为了完整的发布负责人。
CRAIG BOX：在发布团队中待了相当长的时间。很明显，在这个版本之后您将转入荣誉退休的角色。您认为自己还会继续参与其中吗？这是您显然非常热衷的事情吗？
JAMES LAVERACK：我想只要人们需要我，我就会一直在SIG Release中。我发现这是社区中一个非常有趣的部分。而且我发现这里的人都非常有趣，而且非常热情好客。
CRAIG BOX：那么我们来谈谈Kubernetes 1.24。首先，像往常一样，祝贺您发布成功。
JAMES LAVERACK：谢谢。
CRAIG BOX：这个版本包含46项增强功能。14项已升级为稳定版，15项已升级为测试版，13项处于alpha版。2项已弃用，2项已删除。与最近的其他版本相比如何？这是一个平均数吗？尤其是稳定版的增强功能似乎很多。
JAMES LAVERACK：我认为它非常相似。最近的大多数版本在增强功能的数量以及类别方面都非常相似。例如，在1.23上一个版本中，有47个。我想之前的1.22有53个，所以略多一些。但它大约是这个数字。
CRAIG BOX：您不想偷偷多加两个，这样您就可以说您比上一个版本多一个吗？
JAMES LAVERACK：不，我不这么认为。我想我们已经有足够多的事情要做了。
CRAIG BOX：发布团队显然要受SIG正在开发的功能及其计划的约束。发布过程和SIG之间是否曾经进行过任何协调，比如，这个版本将是一个追赶版本，就像macOS的旧Snow Leopard版本一样，我们说我们不想要那么多新功能，但我们真的想要更多的稳定性，你们能否专注于这些类型的事情？
詹姆斯·拉弗拉克：其实不是。Kubernetes 组织的核心是 SIG 本身，也就是构成该组织的特别兴趣小组。他们想做什么，完全取决于他们自己。我们不会对应该实现的风格进行任何特定的协调。许多 SIG 都有多个版本的路线图，试图实现他们认为重要的功能。
克雷格·博克斯：我们来谈谈 1.24 中的一些新功能。我们已经听了很多版本关于即将到来的末日，也就是 Dockershim 的移除。它在 1.24 中被移除了。我们应该担心吗？
詹姆斯·拉弗拉克：我不认为我们应该担心。这是社区长期以来一直在准备的事情。我们发布了大量文档关于如何处理这件事。说实话，大多数用户，大多数 Kubernetes 中的应用程序开发人员，根本不会注意到任何差异或需要担心它。
只有真正管理 Kubernetes 集群的平台团队和在非常特殊的情况下直接使用 Docker（而不是通过 Kubernetes API）的人，才会遇到任何问题。
克雷格·博克斯：而且我看到 Mirantis 和 Docker 已经为 Docker 开发了一个 CRI 插件，所以你可以直接切换到它，一切都会继续。
詹姆斯·拉弗拉克：是的，当然，或者你可以使用许多其他 CRI 实现之一。CNCF 中有两个，containerd 和 CRI-O。
克雷格·博克斯：在经历了几个版本来沟通这个变化的过程之后，团队在未来如何沟通类似的消息方面学到了什么？
詹姆斯·拉弗拉克：我认为从这个角度来看，这是非常有趣的，因为这是 Kubernetes 项目迄今为止最大的移除。我们之前删除过功能。事实上，我们在这个版本中也删除了另一个功能。但这是我们做出的最用户可见的改变之一。
我认为这样做有很好的理由。但我认为我们学到了很多关于如何以及何时进行沟通的知识，以及拥有迁移指南的重要性，以及拥有真正阐明事情的官方文档的重要性。我认为这是 Kubernetes 项目自从我加入团队以来成熟很多的领域。
克雷格·博克斯：被移除的另一个功能是什么？
詹姆斯·拉弗拉克：我们正在移除的另一个功能是动态 Kubelet 配置。这是一个已经处于 beta 阶段一段时间的功能。但我认为我们决定它没有被充分使用到足以保留它的程度。所以我们正在移除它。我们在 1.22 中将其弃用，并且在这个版本中将其移除。
克雷格·博克斯：在几个版本前，有一项政策变化谈到不允许功能永远保持在 beta 阶段。有没有因为缺乏维护而面临被移除风险的功能，或者现在所有的 SIG 在保持其功能正常运行方面都做得很好？
詹姆斯·拉弗拉克：我认为 SIG 们在这方面做得越来越好。我们曾经有一段时间，许多功能都长期处于 beta 阶段。正如你记得的那样，Ingress 长期处于 beta 阶段。
克雷格·博克斯：我选择相信它仍然是。
詹姆斯·拉弗拉克：[笑声]我认为我们朝着 Kubernetes 等事物的稳定性方法迈进是非常好的。我认为这是一个非常积极的变化。
克雷格·博克斯：Ingress 处于 beta 阶段如此之久，以及诸如主要工作负载控制器之类的东西，导致人们相信 beta API 是稳定且可用于生产环境的，并且应该被使用。这个版本中正在发生变化的是，beta API 将默认关闭。为什么有这个变化？
詹姆斯·拉弗拉克：这实际上是为了鼓励使用稳定的 API。正如你所说，人们普遍认为 beta API 实际上是稳定的。因为它们可以被非常迅速地移除，我们经常最终处于这样的状态：我们想遵循政策并移除一个 beta API，但却无法做到，因为它根据社区的说法是事实上的稳定。这意味着集群运营商和用户在进行升级时会遇到许多本可以避免的重大更改。这实际上只是为了在未来进行更多升级时帮助保持稳定性。
克雷格·博克斯：我理解这现在只适用于新的 API。目前处于 beta 阶段的功能将继续可用。因此，不会再次发生重大更改，对吗？
詹姆斯·拉弗拉克：是的，没错。除了我们在此版本中记录的更改之外，beta API 中不会有重大更改。这只适用于新的功能。
克雷格·博克斯：现在在这个版本中，工件使用 Cosign 签名进行签名，并且对这些签名的验证有实验性支持。为了使该过程成为可能，需要发生什么？
詹姆斯·拉弗拉克：这是 SIG Release 另一半的一个巨大过程。SIG Release 有发布团队，但它也有处理实际推送发布的机制的发布工程团队。他们花了很多时间，我的一个朋友 Adolfo 在那里，花了很多时间试图使我们符合 SLSA 标准。我相信我们现在正在考虑达到 Level 3 标准。
SLSA 是一个描述软件供应链安全的框架。当然，这是我们目前行业中一个非常大的问题。很高兴看到该项目采用这方面的最佳实践。
克雷格·博克斯：我回顾了我与 Rey Lejano 关于 1.23 版本的对话，我们基本上接近 Level 2。我们现在显然正在升级到 Level 3。我想我当时问 Rey，说 SLSA 的灵感来自于像 Kubernetes 这样的大型项目是否公平，并且理论上，这些项目应该很容易勾选框以达到该级别，因为 SLSA 框架是在考虑到像 Kubernetes 这样的项目的情况下编写的？
詹姆斯·拉弗拉克：我认为是这样。我认为这有点困难，仅仅因为它做是一回事，但证明你在做这件事是另一回事，这就是这些框架的全部意义所在 — 断言，证明。
克雷格·博克斯：作为 Kubernetes 的最终用户，无论是我自己安装它，还是我从像 GKE 这样的服务中获取它，那么这种来源将让我证明什么？如果我们回想一下我们最近与圣地亚哥谈论的橙汁例子，我如何判断我的软件可以安全运行？
詹姆斯·拉弗拉克：如果你自己下载并运行 Kubernetes，你可以使用验证镜像签名功能来验证你下载并运行的东西实际上是 Kubernetes 项目发布的东西，并且它是从 Kubernetes GitHub 存储库中的实际源代码构建的。这可以让你对你正在运行的东西充满信心，特别是如果你在某种高度安全或受监管的环境中运行。
作为最终用户，这并不一定会直接影响你。但这意味着提供托管 Kubernetes 选项的服务提供商，例如 Google 和 GKE，可以为他们运行的服务提供更高的安全性和安全性。
克雷格·博克斯：很多人只是通过被授予一个 API 端点来访问他们的 Kubernetes 服务器，然后他们开始针对它运行 kubectl。他们实际上并没有安装自己的 Kubernetes。他们有一个提供商或一个平台团队为他们做这件事。你认为是否有可能进入这样一个世界：当你在部署工作负载时，你可以运行一些东西来查询 API 服务器，例如，并访问相同的来源数据？
詹姆斯·拉弗拉克：我认为以这种方式做会非常困难，仅仅因为这种来源和断言数据意味着你实际上可以访问底层的可执行文件，通常，当你在托管平台上运行时，你无法访问。如果你有 Kubernetes 提供给你，我认为你仍然必须信任提供给你的平台团队或组织。
克雷格·博克斯：就像你去酒店的早餐吧时，你必须相信他们对他们的橙汁是很好的。
詹姆斯·拉弗拉克：是的，我认为橙汁的例子很棒。如果你自己制作，那么你可以使用断言。如果你没有，如果你只是被给予了一杯，那么你将不得不相信是谁在倒它。
克雷格·博克斯：继续探索新的稳定功能，存储容量跟踪和卷扩展已经普遍可用。这些功能使我能够做什么？
詹姆斯·拉弗拉克：这是一组来自 SIG Storage 的非常出色的稳定功能。存储容量跟踪允许 Kubernetes 上的应用程序使用 Kubernetes API 来了解有多少存储可用，这可以驱动应用程序的决策。使用卷扩展，这又允许应用程序使用 Kubernetes API 来请求额外的存储，这可以使应用程序做出各种操作决策。
克雷格·博克斯：SIG Storage 也在努力通过一个项目将其所有树内存储插件迁移到 CSI 插件。他们这个过程进展如何？
詹姆斯·拉弗拉克：在 1.24 中，我们有两个插件已经迁移出去。Azure Disk 和 OpenStack Cinder 插件都已迁移。他们正在维护原始的 API，但实际的实现现在发生在那些 CSI 插件中。
克雷格·博克斯：他们还有很长的路要走，还是只是每次发布砍掉几个？
詹姆斯·拉维拉克：据我所见，他们每次发布只是砍掉几个。还有几个需要处理。这实际上是 Kubernetes 中一个更大的主题的一部分，即将特定于应用程序的东西推到接口后面，例如容器存储接口和容器运行时接口。
克雷格·博克斯：这显然建立了一种局面，即你拥有一个稳定的接口，并且可以在 Kubernetes 之外拥有该接口的 beta 实现，从而绕开我们之前讨论的无法运行 beta 版本的问题。
詹姆斯·拉维拉克：是的，没错。它也使 Kubernetes 更容易扩展。例如，你无需尝试将代码放入树内即可实现新的存储引擎。
克雷格·博克斯：gRPC 探测已在 1.24 版本中升级到 beta 版。该功能提供了什么？
詹姆斯·拉维拉克：我认为，这是 Kubernetes 中应用程序开发人员最能感受到的变化之一。到目前为止，Kubernetes 具有对容器进行就绪性和活跃性检查的能力，并能够根据这些检查做出智能的路由和 Pod 重启决策。但是这些检查必须是 HTTP REST 端点。
在 Kubernetes 1.24 中，我们启用了一项 beta 功能，允许他们使用 gRPC。这意味着，如果你正在构建一个主要基于 gRPC 的应用程序（就像许多微服务应用程序一样），你现在可以使用相同的技术来实现你的探测，而无需捆绑 HTTP 服务器。
克雷格·博克斯：是否还有其他特别值得注意的增强功能，或者可能与你一直在做的工作相关的增强功能？
詹姆斯·拉维拉克：SIG Network 有一个非常有趣的功能，它是关于避免服务 IP 地址分配冲突。在现有版本的 Kubernetes 中，你可以分配一个服务使用特定的内部集群 IP，或者你可以将其留空，它将生成自己的 IP。
在 Kubernetes 1.24 中，有一个可选功能，允许你指定一个用于动态生成 IP 的池。这意味着你可以静态地将 IP 分配给服务，并且知道该 IP 不会被意外地动态分配。这实际上是我在本地 Kubernetes 集群中遇到的一个问题，我使用静态 IP 地址来处理大量端口转发规则。我一直担心在服务器启动期间，它们会被动态分配给其他服务之一。现在，有了 1.24 和此功能，我不再需要担心这个问题了。
克雷格·博克斯：这就像在你的 DHCP 服务器中分配 IP，而不是仅仅在你的本地计算机上静态声明 IP 吗？
詹姆斯·拉维拉克：差不多是这样。这意味着你不会意外地双重分配某些东西。
克雷格·博克斯：为什么我们不都直接使用 IPv6 呢？
詹姆斯·拉维拉克：这是一个非常深刻的问题，我认为我们没有时间讨论。
克雷格·博克斯：即使我们有时间，这个播客的篇幅也无法容纳它。
詹姆斯·拉维拉克：[笑]
克雷格·博克斯：Kubernetes 1.24 的主题是 Stargazer（观星者）。你们是如何选择这个主题的？
詹姆斯·拉维拉克：每个发布负责人都可以选择自己的主题，基本上是自己选择。当我开始时，我问了上一任发布负责人 Rey，他是如何选择他的主题的，因为他选择了 Kubernetes 1.23 的“下一个前沿”。他告诉我，他实际上是在发布甚至开始之前就选择了主题，这意味着在发布的前几周和几个月里，我真的很担心，因为我还没有选择主题，也不知道该选择什么。
后来，我又与另一位前发布负责人交谈，他们告诉我他们是在发布前两周才选择主题的。看来情况确实各不相同。大约在发布的中途，我有一些想法。我想也许我们可以谈谈 - 我住在英国一个叫布里斯托的城市，那里有一座非常著名的桥梁 - 我想，哦，我们可以谈谈桥梁和建筑，以及社区弥合差距之类的隐喻。我有点喜欢这个想法，但它并没有真正吸引我。
我的一件事是，我是一个严重的夜猫子。我早上无法有效地工作。我一直很喜欢夜晚。这让我开始思考天文学和星星。我想有一天晚上，我正试图入睡，因为我睡不着，我正在看 PBS Space Time，这是一个非常棒的 YouTube 频道，谈论物理学。我不是物理学家。我不懂任何数学。但我发现它作为一个话题真的很有趣。
我只是想，嗯，我为什么不做一个关于星星的主题呢。在许多版本中，Kubernetes 经常有太空主题。正如您所知，它的原始名称是基于《星际迷航》的。之前的版本有一个基于《星际迷航》的主题。我想，好吧，让我们这样做。所以我提出了“观星者”的想法。
克雷格·博克斯：一旦你有了主题，你就需要一个发布标志。我听说你家里有一位艺术家？
詹姆斯·拉维拉克：[笑] 我不认为她会喜欢被这样称呼，但是，是的。我的妻子是一位艺术家，尤其是一位数字艺术家。我与 SIG Release 的人谈了一下，看看他们是否愿意让我的妻子来做，他们说他们完全没问题。
我问她是否愿意花一些时间为我们创建一个标志。谢天谢地，她愿意。她为我们制作了这个 - 嗯，我有点不得不说 - 她为我们制作了一个漂亮的标志，你可以在我们的发布博客和社交媒体上看到它。它是一个设置在星空下的望远镜，我非常喜欢它。
克雷格·博克斯：它客观上非常漂亮。它显然有七颗星，或者说是昴星团的七姐妹。颜色有什么特别的含义吗？
詹姆斯·拉维拉克：颜色基于 Kubernetes 的蓝色。如果你看背景，那片薄雾实际上是原始 Kubernetes 标志中的 Kubernetes 轮子的形状。
克雷格·博克斯：你必须以正确的方式眯着眼睛看它。非常抽象。就像艺术的风格一样。
詹姆斯·拉维拉克：就像艺术的风格一样。
克雷格·博克斯：你之前提到了 Rey Lejano，1.23 版本的发布负责人。我们每次采访都会问，这个人从上一任负责人那里学到了什么，以及他们将为下一任负责人放在信封里什么。当时，Rey 说他会鼓励你在发布团队会议中使用可教学的时刻。你做到这一点了吗？
詹姆斯·拉维拉克：没有我想象的那么多。我认为我真正从 Rey 那里学到的是更多地沟通。我这次努力尽可能多地公开沟通。我实际上担心我会过多地在 SIG Release Slack 频道上发送垃圾邮件。我问了我们的 SIG Release 主席 Stephen 和 Sasha。他们说，不用担心。随便发多少垃圾邮件都可以。
因此，我认为过去几个月在 SIG Release Slack 中的大部分对话都是我发的。[笑] 看起来效果还不错。
克雷格·博克斯：这就是它的用途。
詹姆斯·拉维拉克：这就是它的用途。但当然，SIG Release 不仅仅做单个发布过程。它也是发布工程。
克雷格·博克斯：我相信他们会对正在发生的事情感兴趣？
詹姆斯·拉维拉克：是的，确实如此。我认为能够以这种方式与大家交流真的很好。
克雷格·博克斯：我们之前谈到了你在 KubeCon 上初次接触 Kubernetes，并与人面对面交流。几乎完全以虚拟方式运行发布是什么感觉？
詹姆斯·拉维拉克：还不错。发布团队一直都是地理分布的，这在某种程度上是设计好的。它一直都是非常虚拟的参与，所以我不认为它受到疫情和旅行限制的影响太大。当然，我期待着在 KubeCon Valencia 再次见到大家。但我认为发布团队在目前的情况下处理得非常出色。
克雷格·博克斯：你将传递给下一任发布负责人的建议是什么？已经宣布下一任负责人是来自 Google 的 Cici Huang。
詹姆斯·拉维拉克：我会对 Cici 说，公开沟通非常重要。我养成了每周在 SIG Release 中发布一次发生的事情总结的习惯。我非常高兴我这样做了，如果她愿意，我会鼓励她也这样做。
克雷格·博克斯：这个版本原定于两周前发布，但被推迟了。发生了什么事？
詹姆斯·拉维拉克：延迟的原因是一个发布阻塞的 bug —— 一个绝对的致命问题。这是在底层 Go 实现的 TLS 证书验证中。这意味着许多客户端根本无法连接到集群或其他任何东西。因此，我们做出了一个决定，我们不能发布这样一个大的 bug。因此，它被称为发布阻塞。
这个修复必须合并到上游的 Go 1.18.1 中，然后我们当然必须重建和发布候选版本。考虑到我们希望在进行大量此类更改后让事情保持稳定一段时间，我们认为将发布推迟几周比冒险发布一个有问题的点零版本更为谨慎。
克雷格·博克斯：Go 1.18 本身也很新。该项目如何决定升级其底层编程语言的速度？
詹姆斯·拉维拉克：其中很大一部分是由支持要求驱动的。我们为每个版本提供三个版本的支持。因此，Kubernetes 1.24 很可能会在明年这个时候，即 2023 年之前获得支持，因为我们每年发布三个版本。这意味着，直到 2023 年 5 月，我们可能会发布 Kubernetes 1.24 的更新，这意味着我们使用的 Go 版本和其他依赖项也必须受到支持。我的理解是，旧版本的 Go，Go 1.17，不会被支持足够长的时间。
任何即将到来的底层关键 bug 修复程序，都不会被向后移植到 Go 1.17，因此我们可能无法充分支持 Kubernetes 1.24。
克雷格·博克斯：不幸的延迟的一个副作用是不幸的假期情况，你原本预定在发布后的一周休假，但最终你却在发布前的一周休假了。在这种情况下，你真的能休假并放松吗？
詹姆斯·拉维拉克：好吧，我哪儿也没去，如果你是问这个的话。
克雷格·博克斯：谁都没去。这就是疫情的状况，居家度假。
詹姆斯·拉维拉克：是的，居家度假。这很有趣。一方面，我在这段时间做了很多 Kubernetes 的工作。所以你可以说这不算真正的假期。另一方面，我那些烦人的朋友让我开始玩一款 MMO，所以我花了很多时间玩那个。
克雷格·博克斯：我还听说你买了一台新的吸尘器？
詹姆斯·拉弗拉克：[笑] 你一直在关注我的推特。是的，我找不到旧吸尘器的充电线了。所以我决定买一个新的。我终于决定买一个好牌子的吸尘器。它确实更好用。
克雷格·博克斯：这不是 BBC。如果你想说出它的名字，可以的。
詹姆斯·拉弗拉克：是的，我们去买了一个不错的戴森吸尘器，这是我第一次买这么贵的吸尘器。一方面，我觉得花这么多钱买吸尘器有点不好意思。另一方面，它确实方便多了。
克雷格·博克斯：是那种手持式的吗，像一个带长腿的巨型吸尘器？
詹姆斯·拉弗拉克：不，我买的是插电式的落地吸尘器，因为问题是，我上次把充电器弄丢了，所以我不想再次发生这种情况。所以我买了一个插墙式的。
克雷格·博克斯：我必须说，从标准的 Henry Hoover 到——我们现在住的地方有一个我称之为仿戴森的便携式吸尘器——有一个你可以拿起随身携带，而不必担心电线的吸尘器，确实能鼓励我保持住所的整洁。
詹姆斯·拉弗拉克：真的吗？我觉得我们上一个也是插电式的，但它并没有鼓励我们多用它，因为它太没用了。
詹姆斯·拉弗拉克是 Jetstack 的一名高级解决方案工程师，也是 Kubernetes 1.24 版本的发布团队负责人。
您可以在 Twitter 上通过 @KubernetesPod 找到 Google 的 Kubernetes 播客，并且可以订阅，这样您就不会错过任何一期节目。