本文已超过一年。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已不正确。
猫衬衫和土拨鼠日：Kubernetes 1.14 版本访谈
上周，我们庆祝了 谷歌 Kubernetes 播客一周年。在这个每周节目中，我的联合主持人 Adam Glick 和我专注于 Kubernetes 和云原生领域中发生的所有美好事物。从每周的新闻到对社区人士的采访，我们帮助您及时了解 Kubernetes 的一切。
每隔几个周期，我们都会检查 Kubernetes 本身的发布过程。去年，我们采访了 Kubernetes 1.11 的发布经理，并在 Kubernetes 博客上分享了该记录。我们收到了很好的反馈，因此我们想分享我们最近与 Kubernetes 1.14 发布经理 Aaron Crickenberger 的对话记录。
一如既往，可以通过收听播客版本来享受规范版本。如果您喜欢您听到的内容，我们鼓励您订阅！
CRAIG BOX：我们喜欢从让我们的嘉宾深入了解他们的背景开始。Kubernetes 是由来自许多不同公司的贡献者构建的。在加入谷歌之前，您曾在三星 SDS 从事 Kubernetes 的工作。当您更换公司时，您在社区中的地位和您所做的工作会发生变化吗？
AARON CRICKENBERGER：基本上没有。我认为当前公司的食物更好一点！但总的来说，我基本上一直与同样的人做着同样的事情。在我加入谷歌之前，我首先关心的是社区，其次才是谷歌，而且我基本上仍然以这种方式运作，因为我相信谷歌的成功取决于社区的成功，其他依赖 Kubernetes 的人也是如此。一个良好和健康的上游造就一个良好和健康的下游。
因此，这很大程度上就是为什么三星首先让我从事 Kubernetes 工作的原因，是因为我们认为这项技术是合法的。但我们需要确保社区和整个项目也是合法的。因此，这就是为什么您看到我在整个 Kubernetes 任期内继续倡导透明度和社区赋权。
ADAM GLICK：您共同创立了 测试 SIG。您是如何决定需要它的？以及在过程的哪个阶段您得出了这个结论？
AARON CRICKENBERGER：这在 Kubernetes 项目的早期就发生了。我实际上有点模糊地记得它具体发生的时间。但当时，我的老板 Bob Wise 与谷歌内部的一些人合作共同创立了可扩展性 SIG。
如果您还记得很久以前 Kubernetes 刚开始时，人们担心 Kubernetes 的性能是否足够。例如，我相信它正式支持大约 100 个节点。有些人认为，这很愚蠢。我的意思是，拜托，谷歌可以做更多的事情。而且谁会真正使用只支持 100 个节点的容器编排器？
当然，问题是我们非常保守。我们正在努力迭代、尽早且频繁地发布。因此，我们帮助推动了界限，以确保 Kubernetes 能够证明它可以正常工作到一千个节点，甚至在它被正式支持之前，就说，看，它已经可以做到这一点了，我们只是想确保我们把所有的螺丝都拧紧了。
好的，太棒了。我们决定我们需要首先创建一个称为 SIG 的东西来讨论这些事情并确保我们朝着正确的方向前进。然后，我将个人注意力转向了测试，我认为这是下一个需要 SIG 的东西。所以我相信测试是为 Kubernetes 创建的第二个 SIG。它最初是与 Ike McCreary 共同创立的，当时我相信他是谷歌的 SRE，然后最终将其移交给谷歌工程生产力部门的一些人，我认为这与测试的利益非常一致。
就像“我不知道你们这些人在这里尝试用 Kubernetes 写什么，但我希望帮助你们写得更好、更快、更强大”。因此，我希望确保我们作为一个社区和一个项目，能够让您更容易编写测试，更容易运行测试，最重要的是，更容易根据这些测试结果采取行动。
这归结为，让我们确保 Kubernetes 不仅在 Google Cloud 上进行测试。这对我来说非常重要，因为我不是在 Google Cloud 中而是在其他云中运行的。我认为它确实有助于推销这个故事，并建立对 Kubernetes 的信心，使其在多个云上有效运行。我还认为，看到社区中 SIG 测试的倡导将我们带到现在可以使用测试网格的世界真的很有帮助，以便每个人都可以看到同一组测试结果，以了解哪些内容被允许阻止 Kubernetes 出门。
这个过程基本上只是说，让我们去做吧。这个过程是找到那些有动力的人，并建议我们定期开会，我们尝试围绕一套共同的工作团结起来。这在 SIG 管理成为正式事物之前就发生了。在大约一年后，我认为，我们逐渐确定了大多数 SIG 遵循的模式，即您尝试确保您有会议议程、您有 Slack 频道、您有邮件列表，您公开讨论所有内容，您尝试使用一套一致的里程碑并向前推进。
CRAIG BOX：我想问一些关于您在 Kubernetes 之前的经历。为什么运输集装箱中有一个黑鹰飞行模拟器？
AARON CRICKENBERGER：正如您可能想象的那样，黑鹰直升机在世界各地的各种地方飞行，而不仅仅是在碰巧旁边有一个停车场的建筑物旁边。因此，为了让您的飞行员保持状态，您可能希望确保他们有良好的训练时间和飞行时间，而无需花费燃料来飞行真正的直升机。
我参与了制作所谓的运行模拟器，使用黑鹰直升机中部署的完全相同的硬件，包括可以摇晃以模拟运动的运动座椅和全保真视觉系统来训练飞行员完成一系列程序。所有这些都打包在两个运输集装箱中，以便可以在需要的地方部署模拟器。
在一次会议之前，我在空军基地的一个领域使用这个模拟器工作时，绝对有一次非常有趣的经历，我能够体验到 F-16 进行起飞演习，这太棒了。他们会离开跑道，然后直接将加力燃烧室开到最大，然后直接升入空中。而且我必须处理图形模拟错误。这真的很酷。
CRAIG BOX：对于很多人来说，当您单击他们 GitHub 链接中列出的网页时，您会得到他们的简历，或者您会得到他们参与的开源项目列表。在您的情况下，有一个 SoundCloud 页面。人们在该页面上会发现什么？
AARON CRICKENBERGER：他们会看到我生活中的一切。我发现音乐是我生活中非常重要的一部分。这是我随着时间的推移发展出来的一种非语言的声音。我需要一些地方来托管它。然后，它在 SoundCloud 和 Bandcamp 之间产生了选择，SoundCloud 是托管我的录音的更容易的地方。
因此，您会听到我大约五年前拿起吉他并随意演奏的结果。您会听到我通过 Ableton Live 乱搞所学到的东西。您会听到我做的一些环境音乐混音。我有一段时间没有在那里发布任何内容了，因为我正在努力把我的鼓录音做到恰到好处。
因此，如果您转到我的 YouTube 频道，您主要会看到我参与的各种 SIG 会议的录像。但如果您回顾一下更早的版本，您会看到我实际上是在打鼓。我正尝试将它们融入我的下一首歌曲中。
CRAIG BOX：您知道 Hugh Padgham 是谁吗？
AARON CRICKENBERGER：我不知道。
CRAIG BOX：Hugh Padgham 是录音工程师，他做出了 80 年代基本上定义了 Phil Collins 的门限混响鼓声。我认为如果您在鼓声方面遇到问题，您应该给他打电话。
AARON CRICKENBERGER：太棒了。
ADAM GLICK：您提到您还可以找到您使用 SIG 所做工作的视频。您是如何成为 1.14 的发布经理的？
AARON CRICKENBERGER：我从 1.4 时代就开始参与 Kubernetes 的发布过程。我最初是尝试帮助找出，你如何为这个东西编写发行说明？你如何处理这一团糟，并尝试以一种对最终用户和开发人员来说有意义的理智方式来描述它？而且随着时间的推移，我逐渐参与了发布的其他方面。
我帮助处理了 CI 信号。我帮助处理了问题分类。当我帮助处理 CI 信号时，我编写了第一个剧本来描述我在这里所做的事情。自此以后，其余的发布团队都使用了该模型，其中每个角色都在剧本中描述了他们所做的事情，该剧本不仅用于他们自己的利益，还用于帮助他们培训其他人。
我正式成为发布负责人的方式是我在 1.13 中担任了发布影子。当发布负责人想找出谁将领导下一次发布时，他们会回头看看他们的影子，因为这些人是他们一直在帮助和培训的人。
CRAIG BOX：如果他们没有影子，他们是否必须再等三个月才能再次发布？
AARON CRICKENBERGER：他们不必。它的工作方式是发布负责人可以查看他们的影子，然后他们会查看其余的发布团队负责人，以了解是否有足够的经验。如果没有，他们会咨询 SIG 发布的负责人。
例如，对于 Kubernetes v1.15，我最终陷入了一种不幸的境地，我的影子都没有人可以站出来成为 1.15 的负责人。我咨询了 Claire Lawrence，她是我的 1.14 增强功能负责人，并且在两个季度都加入了发布团队，因此满足了成为发布负责人的要求。因此，她将成为 v1.15 的发布负责人。
克雷格·博克斯：对于一个随口抛出的土拨鼠日玩笑，这真是一个绝妙的回答。我很感谢。
艾伦·克里克伯格：[笑声]
亚当·格里克：你可以再问一遍，看看答案是什么，然后再问一次，看看它如何随着时间推移而演变。
艾伦·克里克伯格：我关于土拨鼠日的段子不多了。我之后会再回到这个话题。
亚当·格里克：作为发布负责人，你的职责是什么？
艾伦·克里克伯格：不要慌张。我的意思是，本质上，发布负责人的工作是做最后决定，然后通过做最后决定来坚守底线。所以，作为发布负责人，你不应该尝试深入并修复所有问题，或者做所有事情，或者对其他人的工作进行事后诸葛亮。你的主要职责是倾听其他所有人的建议，并帮助他们做出最佳决策。只有在没有明确共识的情况下，你才会介入并自己做出决定。
我觉得在这个发布周期中，我得到了一个非常能干的团队的帮助。这非常有帮助。但是，作为一个背负着我喜欢称之为“成就猴”的人，我很难抗拒直接参与并提供帮助的冲动，因为我之前也做过这些。我有实地经验。
发布负责人的工作不是冲锋陷阵，而是帮助确保每个冲锋陷阵的人都实际在做他们需要做的事情，并且在做他们需要做的事情时不会受阻。它还包括唱歌跳舞和制作有趣的图片。所以我认为它更像是关于有效的沟通。而唱歌跳舞、制作有趣的图片和表情包是我实现这一目标的一种方式。
所以，我认为每周在 Kubernetes 社区会议上发布更新时，为了帮助人们关注这些更新，我每周都会穿一件不同的猫咪 T 恤。在人们嘲笑和调侃我的第一件猫咪 T 恤时，我说我真的需要咖啡“喵”，有人问我是否从“猫咪咖啡机”里得到的咖啡，我决定加大力度。
而且我听说人们会期待那些猫咪 T 恤。他们想知道最新的是哪一件。我甚至专门买了一件猫咪 T 恤来表示代码冻结即将到来。
我们还决定，与其强加一个涉及很多里程碑和标签的疯狂流程，这会给机器增加额外的摩擦，不如我在 Twitter 上发布大量关于代码冻结即将到来的表情包。而且这似乎效果很好。总的来说，发布负责人的工作是沟通、解除阻塞，然后尽可能地什么都不做。
这真的有点困难和可怕，因为你总是有这种感觉，你可能错过了一些东西，或者你只是没有看到那里的一些东西。所以，我处于这个位置，发布非常稳定，我花了很多时间思考，好吧，我错过了什么？这看起来太好了。这太安静了。通常会有一些东西爆炸。来吧，是什么，是什么，是什么？这是一个把所有这些都放在心里，直到发布结束才与大家分享的过程。
亚当·格里克：他也穿着猫咪 T 恤在这里。
当一位新任美国总统上任时，通常情况下，即将卸任的总统会给他们留下一张带有建议的便条。除了影子团队之外，Kubernetes 发布管理方面是否存在类似的东西？
艾伦·克里克伯格：是的，我想说，这有一种非常特别的——我不知道我在这里寻找的词是什么——纽带、关系，或者其他什么，过去担任过发布负责人的人对那些担任发布负责人角色的人非常理解和支持。
你知道，我谈到了发布负责人有很多不确定性和自我怀疑，而在表面上你必须假装一切都好。得到那些经历过这些的人的支持是非常有帮助的。
所以我能够联系到一位之前的发布负责人。不是像玩那种游戏——是什么，像两个信封？第一个信封，你指责即将卸任的总统。第二个信封，你写两封信。不是那样的。
我很乐意为我们对发布流程所做的所有不顺利的更改承担责任，但我也很乐意帮助支持我的继任者。我觉得我作为发布负责人的工作是，第一，确保发布顺利完成，第二，确保我为我的继任者成功做好准备。
所以我已经和克莱尔会面，描述我作为介绍步骤会做什么。我计划在整个发布过程中继续与克莱尔协商，以确保一切进展顺利。
克雷格·博克斯：如果你想听听之前一些发布负责人的观点，请查看第 10 集，我们在那里采访了乔什·伯克斯和蒂姆·佩珀。
亚当·格里克：你计划在那份给克莱尔的便条里写些什么？
艾伦·克里克伯格：这是一个很好的问题。我会告诉克莱尔首先信任她的团队，其次信任她的直觉。就像我说的那样，我认为与你的团队建立信任非常重要，因为发布是这种超人的努力，涉及吸收、处理或引导数百名贡献者的工作。
而你的团队至少由 13 个人组成。如果包括所有正在接受培训的人，你可以达到 40 或 50 人。那里有很多工作要做。这比任何一个人能处理的工作都要多得多。
老实说，这与我将告诉 Kubernetes 的新贡献者是一样的，那就是你不可能理解所有这些。你不会理解 Kubernetes 的形态。你永远不会成为真正知道所有事情的专家，这没关系。重要的是要确保当你不知道答案时，你知道该向谁寻求答案。如果你的团队是那些人，那真的很有帮助。
克雷格·博克斯：你一直在处理的特定版本以及刚刚发布的版本是 Kubernetes 1.14。这个版本有哪些新功能？
艾伦·克里克伯格：这个版本的 Kubernetes 包含比以往任何其他版本的 Kubernetes 都更稳定的增强功能。我对此感到非常自豪。我知道在过去，你可能听过其他发布负责人谈论，例如，这是稳定性版本，或者这次我们真的要让事情更加成熟一点。但我觉得这次我可以很有信心地说出来。
例如，我站在一个房间里，那是 2017 年的一个领导力峰会，我认为，我们说，看，我们真的要努力让 Kubernetes 更稳定。我们将专注于加强 Kubernetes 的核心并定义 Kubernetes 的核心是什么。我们不会接受一大堆新功能。然后我们又去接受了一大堆新功能。那是很久以前的事了。今天我们在这里。
但我认为我们终于开始看到当时开始的工作的结果。Windows Server 容器支持可能是最大的一个。你可以听迈克尔·迈克尔讲述关于 SIG Windows 大约三年前如何启动的故事。而今天，他们终于可以宣布 Windows Server 容器已经 GA 了。这是一个巨大的成就。
我相信，这其中很多繁重的工作都是在最后完成的。它始于 Kubernetes 1.13 中的一次对话，并在这次发布中真正结束，我们定义了 Windows Server 容器到底是什么？它们与 Docker 容器或其他在 Linux 上运行的容器运行时有何不同？
因为今天，人们对 Kubernetes 提供的功能所做的很多假设也与基于 Linux 的容器提供的功能有关。因此，我们希望使人们能够使用他们一直喜爱的 Kubernetes 编排功能，但也要使用它来编排一些仅在 Windows 上可用的应用程序或功能。
因此，我们汇总了一个所谓的 Kubernetes 增强提案流程，或简称 KEP。我们说，我们将使用这些 KEP 来准确描述将某个东西称为 alpha、beta 或稳定的标准。因此，Windows 功能允许我们使用 KEP——或者在将 Windows 引入此处时，我们使用 KEP 来描述 Windows Server 容器的所有工作和不工作的内容。这非常重要。而且我认为这确实帮助我们更好地理解或定义了 Kubernetes 在这种背景下的含义。
好吧，我花了大部分时间用一个单一的稳定功能回答你的问题。
克雷格·博克斯：好吧，让我们深入了解一下 KEP 流程，因为这是第一个有新规则的版本。它说，此版本的所有提议的增强功能都必须有相关的 KEP。所以这是一个 Kubernetes 增强提案，一份描述它的一页文档。 A、让工程师接受使用它，然后 B、基于这些文档构建东西的过程是怎样的？
艾伦·克里克伯格：这是一个持续改进的过程。所以它绝不是完成的，但它确实需要大量的谈论，以及一遍又一遍地对同一个人或不同的人说同样的事情，当涉及到涉及沟通和流程变更的事情时，情况通常如此。但总的来说，大家几乎都赞成这一点。
但是，对于门槛会设置得有多高，以及我们将如何严格或死板地执行这些标准，存在一些困惑。我觉得我们还有改进的空间。但我们已经一致同意，是的，我们确实喜欢在一个地方拥有关于特定增强的所有信息。对吧？
以前的世界是如何运作的，我们会抛出 Google 文档，这些是设计提案，然后我们会对这些文档进行大量评论。然后，最终，这些文档被转换为 markdown 文件。这些文件最终会出现在社区存储库中，
然后我们会有很多相关的议题谈论这些。然后可能有人会打开另一个他们称之为伞形议题的议题。然后会在这里放上一堆评论。然后在 PR 中会进行很多讨论。我刚刚列出了七件不同的事情。
所以 KEP 的目的是将所有关于增强功能的设计、实施和推理的讨论集中在一个地方。而且我认为，我们在这一点上完全赞同。我们有改进的空间吗？当然。人类参与其中，这是一个混乱的过程。我们绝对可以找到更好地自动化、更好地构建它的地方。我期待看到这些改进的发生。
你知道，我认为另一件大事是，很多这些 KEP 都分散在三个不同的 SIG 中。有 SIG 架构，他们对这些有技术愿景。有 SIG PM——你知道，选择你喜欢的 P——产品、项目、流程、程序、更好地引导事物前进的人，然后是 SIG 发布，他们只想弄清楚，什么会登陆发布版本，为什么，如何，为什么它很重要？因此，将所有这三个 SIG 的职责放在正确的位置，即 SIG PM，我认为这将真正帮助我们正确地迭代，并向前发展。
克雷格·博克斯：此版本中的另一个变化是没有代码冻结前的缓冲期了。什么是代码缓冲期，为什么我们不再有它了？
艾伦·克里克伯格：这确实是个好问题。在过去的几个月、几个季度甚至几年里，我被10个不同的人问过这个问题。随便你选哪个时间段。所以我最终决定，如果没人知道什么是代码缓冲期，我们为什么还要有它？
克雷格·博克斯：这就像解冻的冰冻，但可能加了糖？
艾伦·克里克伯格：[笑] 代码缓冲期是关于——我们希望在代码冻结之前减缓变更的速度。比如，我们把代码冻结视为一个重大截止日期，在此之后不会再有任何事情发生。
虽然我真的很想假设并渴望生活在一个开发人员超级高效的世界里，他们很早就开始进行变更，并在完成时就提交变更。但今天，我恰好生活在一个开发人员被截止日期驱动的世界里。他们会分心，还有其他事情要做。然后突然，他们意识到代码冻结就在眼前。
他们过去两个月一直在考虑实现的这个精彩功能，现在他们必须在两周内完成。所以突然之间，各种代码开始以超快的速度飞进来。好吧，这很棒。我喜欢授权人们提高生产力。
但我们不希望发生的是，有人决定提交一些大规模的功能或增强功能，彻底改变一切。或者他们可能决定要重构整个世界。如果他们这样做，他们就会因为合并冲突和变基而使其他人的生活变得非常困难。或者，我们已经习惯并适应的所有测试信号可能会完全改变。
所以，代码缓冲期的目的是提醒人们，嘿，别当混蛋。要有点责任感。请尽量不要在最后一分钟提交任何超大的东西。但我们强制执行这一点的方式是，确保你的PR有一个里程碑。并确保它具有“优先级：关键/紧急”的标签。过去，我们会说，确保有一个名为“状态：已批准，里程碑”的标签。
我们想知道，所有这些东西到底意味着什么？人们变得痴迷于所有标签、里程碑和流程。他们从来没有真正关注我们为什么要求人们注意代码冻结即将到来的事实。
亚当·格里克：为了流程而流程，它们可能会开始相互叠加。你提到这个版本中还有很多其他内容。你想谈谈其中一些其他部分吗？
艾伦·克里克伯格：当然。我认为其他两个人会觉得兴奋的另外两个稳定功能是 就绪门控 和 Pod优先级和抢占。今天，Pod有活跃性和就绪性的概念。一个活跃的Pod中运行着一个应用程序，但它可能还没有准备好做任何事情。因此，当Pod就绪时，这意味着它已准备好接收流量。
因此，如果你正在考虑一些大规模扩展的应用程序，你希望确保你的Pod仅在其完全准备好时才处理流量。但在1.14之前，你唯一可以验证的方法是使用TCP探针、HTTP探针或exec探针。要么确保容器内部的端口已打开，要么在容器内部运行命令并查看命令的输出。
然后，你肯定可以在那里自定义相当多的内容，但这要求你将所有这些信息都放在Pod内部。对于某些集群运营商来说，在Pod准备就绪之前，他们可能需要表示一些更重要的考虑因素。例如，确保Pod已在某些其他系统中注册，以确保它被授权提供流量，或类似的事情。Pod就绪门控允许发生这种功能——透明地扩展你用来确定Pod是否准备好接收流量的条件。我们相信，这将为那些试图管理其应用程序和服务的用户提供更复杂的编排和部署机制。
我觉得，对于那些喜欢过度订阅Kubernetes集群的消费者来说，Pod优先级和抢占会很有趣。现在你可以说，某些Pod比其他Pod更重要，而不是假设所有Pod的大小和优先级都相同，并且先来的Pod赢。它们会在其他Pod之前被调度，甚至可能会将其他Pod踢出去，以便为真正重要的Pod腾出空间。
你可以将其理解为，如果你有任何必须在你的集群上运行的超级重要代理或守护进程。它们应该始终存在。现在，你可以将它们描述为高优先级，以确保它们始终存在，并且始终在其他任何事物之前被调度。
亚当·格里克：你是否关注任何其他处于Alpha或Beta阶段的新功能？
艾伦·克里克伯格：是的。我觉得，在Beta方面，我感兴趣的很多东西——如果我回到我的成熟度、稳定性和定义Kubernetes核心的主题，我认为存储SIG一直在做着令人惊叹的工作。他们继续每个季度、每个季度地发布新的、渐进式的存储增强功能——主要是通过CSI，容器存储接口项目，这太棒了。它允许你插入任意的存储功能。
他们有许多与此相关的内容，这次处于Beta阶段，例如拓扑支持。因此，你将能够更准确地表达你的CSI卷需要相对于你的应用程序如何以及在何处存在。块存储支持是我听很多人要求的，以及定义 持久本地卷 的能力。
假设你在节点上运行一个Pod，并且你希望确保它直接写入节点的本地卷。这样，它就可以具有超高的性能。酷。给它一个emptydir。一切都会好的。
但是，如果你销毁了Pod，那么你将丢失Pod写入的所有数据。因此，我再次回到这样的例子，也许它是一个代理，它正在将大量有用的、有状态的信息写入磁盘。你希望该代理能够消失并被某些东西替换，并且能够从磁盘上获取所有这些信息。本地持久卷允许你执行此操作。而且你可以以你习惯的方式来指定云提供商给你的持久卷或永久卷。
由于我共同创立了SIG测试，我认为我必须提一下我喜欢的一个测试功能。它非常小巧和愚蠢，但一直困扰我的是，当你尝试下载测试时，你会下载一个超过1GB大小的东西。在过去，Kubernetes的客户端和服务器也是这样工作的。此后，我们将它分解成——你只需要下载适合你平台的二进制文件。
例如，我在我的MacBook上开发Kubernetes。我可能不需要下载Linux测试二进制文件、Windows测试二进制文件、ARM64测试二进制文件或s390x测试二进制文件。我有没有说过Kubernetes支持很多不同的架构？
克雷格·博克斯：直到现在我才注意到s390是一个受支持的平台。
艾伦·克里克伯格：我们肯定会为它构建二进制文件。我不确定我们是否真的看到过在s390上运行的经过认证的符合性Kubernetes，但这绝对是我们构建Kubernetes的目标之一。
不必下载超过1GB的二进制文件就可以运行一些测试，这真是太棒了。我喜欢生活在这样一个世界里：我不必从头开始构建测试。我是否可以运行一个包含所有测试的程序？也许我可以使用它来对我的集群进行浸泡测试或健全性测试，以确保一切正常。而且只下载我需要的东西真是太棒了。
克雷格·博克斯：你正在谈论Kubernetes拥有核心的概念以及发布和稳定性的概念。如果你回想一下甚至10年前的Linux发行版，我们不再那么关心内核的版本号发布，但我们关心Red Hat发布版中的新功能。你认为我们目前正在达到Kubernetes的那个阶段吗？
艾伦·克里克伯格：我认为这是人们真正希望看到Kubernetes朝着的方向发展的一种模式。我不确定这是否是我们将要采取的模式，但我认为这是一个正在进行的讨论。所以你知道，我们创建了一个名为 WG LTS 的工作组。我喜欢用它的更长的名字来称呼它——WG“要LTS，还是不要LTS”。LTS到底是什么意思？我们试图发布和支持什么？
因为我认为，当人们想到发行版时，他们自然会倾向于某些发行版具有更高的发布速度，而另一些发行版具有较慢的发布速度。对于那些希望生活在永不改变的软件中的人们来说，这很酷也很棒。但是，我们这些大规模运行软件的人发现，你实际上无法阻止变化发生。你的基础设施、环境或软件中总会有一些不受你控制的部分。
因此，我们可以采取任何措施来实现我喜欢称之为动态稳定性的东西，这对所有相关人员来说可能更好。尽可能降低更改的成本。尽可能降低更改和升级的痛苦，并接受一切都在不断变化。
所以是的。也许这就是Linux所在的位置，内核总是在变化。你可以关心它，也可以不关心它。而且你可以选择一个与Linux内核超级同步的发行版，或者可能具有稍长的升级节奏。但我认为关键是要启用这两种选项。因为我认为，如果我们试图生活在一个只有发行版而没有其他东西的世界里，这实际上会在长期内伤害所有人，并可能使我们远离我们所拥有的所有云原生理想，试图接受变化是一个常数。
亚当·格里克：在不谈论胡须的情况下，我们不能让你离开。什么是SIG胡须，它在你成为1.14版本经理的过程中有多重要？
艾伦·克里克伯格：我觉得，成为SIG胡须成员是所有版本负责人的新要求。SIG胡须的出现是因为，有一天，我意识到我变得懒惰了，我留下了这非常巨大而壮丽的胡须。在西雅图KubeCon大会上，布兰登·伯恩斯在数千人面前称赞我的胡须，这真是太让人受宠若惊了。我无法告诉你那是什么感觉。
但认真地说，就像，好吧，我是个男人。我有胡子。很多在科技行业工作的人都是男人，而且很多男人都有胡子。这绝不是一种排斥的方式，也不是在指责什么，或者其他任何类似的事情。只是注意到当我在镜头前时，有时胡子看起来比脸还多。这是怎么回事呢？
后来公司里有人开始叫我“胡子”。结果发现他们读过尼尔·斯蒂芬森的《编码宝典》，如果你熟悉这本书的话。
亚当·格里克：这是一本很棒的书。
艾伦·克里肯伯格：是的。它讲到了胡子和西装。西装是负责所有演讲的人，而胡子是负责所有行动的人。我想我因为到处走动，出现在很多地方而有了名声。所以我决定接受这个称呼。
我第一天到谷歌上班时，我在找显示我的办公桌位置的铭牌，而我的铭牌上写着“SIG 胡子”。我不知道是谁做的，但我想，好吧，我就用这个称呼了。所以从那时起我就称自己为“SIG 胡子的艾伦”。
所以对我来说，胡子不仅仅是脸上的胡子，而是一种内心的状态——热情好客，充满乐趣，拥抱这个社区所有的美好，并鼓励其他人也这样做。在这方面，我希望看到更多人成为“SIG 胡子”的成员。我正在想办法实现这一点。是的，这很棒。
艾伦·克里肯伯格是谷歌云的高级测试工程师。他共同创立了 Kubernetes 测试 SIG，参与了自 1.4 版本以来的每个 Kubernetes 版本发布，自 2017 年成立以来一直担任 Kubernetes 指导委员会的成员，最近担任了 Kubernetes 1.14 版本的发布负责人。
你可以在 Twitter 上通过 @kubernetespod 找到谷歌 Kubernetes 播客，你也可以订阅，这样你就不会错过任何一集。请来 KubeCon EU 向我们问好！