Kubernetes 创始人 Craig McLuckie 谈多云和开源现状

看新闻很累？看技术新闻更累？试试下载 InfoQ 手机客户端，每天上下班路上听新闻，有趣还有料！

在德克萨斯州奥斯汀市举行的 Kubecon 大会吸引了超过 4000 名工程师，Craig McLuckie 做了有关 Kubernetes 之旅的主题演讲。

InfoQ 对 Kubernetes 项目创始人兼 Heptio 首席执行官 Craig McLuckie 的采访。

InfoQ：让我们直入主题。您谈了技术公司的三大重要事项以及 Kubernetes 的重大影响。让我们聊一下开发效率以及可恢复性如何优于弹性。Kubernetes 对此提供了什么特别的帮助以及它对开发效率的总体影响？

McLuckie：Kubernetes 在以下两个方面确实提供了帮助。

首先，可以把操作者从大量常见情况中解放出来。使用传统的技术，业务人员可能会发现有东西不正常了，就打电话给随时待命的工程师。通常，他们需要重启一个进程，让事情恢复正常。这是一个人为的过程，占用人的时间。Kubernetes 可以自动化这个过程，它引入了控制循环，可以管理组件的健康状况。有些事情，机器做得比人好，这就是其中之一。这不是说 Kubernetes 取代了操作者的角色，我们通常将其视为简化操作的“操作者赋能工具”，可以大幅缓解运行 App 的辛苦。

第二个考量因素是，Kubernetes 是一个非常健壮的真正的分布式系统。按照设计，它消除了系统中的单点故障。对于一个恰当配置的集群（配置了高可用及恰当的基础设施），你可以在数据中心里转转，拔掉节点，Kubernetes 会把工作负载调整到运行中的节点，把一切恢复到正常状态。许多用户在首次看到这个效果时都非常吃惊。我记得有人将其称为“猎枪证明系统（ shotgun proof system ）”。其稳定性令人吃惊。

我还要指出一点，公司应该考虑下可用性的真正含义——简单来说是应用程序正常运行时间的比例。这受两个因素影响——停机需要花多少时间？停机后恢复需要多少时间？

人们往往忽视了，让应用程序重新运行的时间左右了整体可用性。你可能会花大量的时间确保有些东西永远不会宕掉（弹性），但是，如果最终没有抓住重点，在特殊情况下，它宕了，那就需要花费大量的时间才能恢复（也就是说，没怎么考虑可恢复性）。

还有一件人们会忽视的事，就是运行中断的情况千差万别。对于某些类型的应用程序，每 1000 秒宕机一秒不会对业务产生明显的影响。如果只需要 0.1% 的时间重新加载，那么用户可能都没注意到，也就不会放在心上。有些业务，如果在高峰期遇到了一整天的运行中断，可能就会非常的挣扎。运行中断的情况千差万别。

InfoQ：您说，Kubernetes 促成了多云，不管怎样，您所说的事情正在发生，企业不是更喜欢标准化到单一供应商吗？混合云似乎限制在本地和云供应商之间，而不是不同的云供应商。这种说法是否准确？

McLuckie：对某些用户来说，是这样的，但我见过的比较大的公司都不是这样做的。大多数规模较大的企业都担心和云提供商建立单一的供应商关系。过去的六个里，在金融、零售业、制造业、医疗卫生等领域 CIO 层面的对话中，没有一个人不在某个时候提到谷歌和微软。相比之下，几年前，当我还在谷歌工作时，有许多人都只使用了 Amazon 的服务。

企业希望同第二家云提供商建立关系。对他们而言，理想状态时，云提供商提供“效用计算”、令人讨厌的电力供应（110 伏 50HZ），而他们希望获得尽可能优惠的价格。他们非常担心锁定，那会让他们丧失议价能力。

这不是说单个应用程序要运行在多个云上。有些情况下是这样的（例如，互联网规模的应用程序，或者跨不同地区运行的 App），但是，对于许多人而言，问题是在哪里构建下一代应用程序。对他们来说，关键是不要让他们的开发人员在另一个环境里构建应用程序。Kubernetes 处于“适居带”：不是特别底层，不会让你受困于特定环境的细节，也不是特别高级（与大多数 PaaS 解决方案相比），并不能让你想运行什么就运行什么。我们开始时就是这样设计的。

澄清一下，这不是因为 Amazon 的工作做得糟糕，完全不是，但是，谷歌和微软在去年一年左右的时间里都经历了跨越式的发展，是这个市场中非常强大的存在。

InfoQ：最后，您在演讲中提到，企业很复杂。这我们都知道，但这是说 Kubernetes 是银弹吗？

McLuckie：不，当然不是。这就像，随着世界从大型机转向客户端 - 服务器架构，标准化的操作系统在商用机器上运行也不是管理企业复杂度的银弹。企业总是需要应对独特的操作要求和条件，把所有应用程序迁移到 Kubernetes 上运行当真需要花相当长的时间。

现如今，如果你在涉及核心业务的体系结构上花足够的时间，对依赖链进行足够的追踪，你通常会找不到一个大型主机。实际上，据我所知，大型机销售额近十年来达到了顶峰。还需要很长时间人们才能删除数据中心里的虚拟机。

然而，Kubernetes 提供了帮助，它对应用程序开发的颠覆性就像以前从大型机向客户端 - 服务器迁移一样。我们很快将看到大量已有的应用程序迁移到 Kubernetes，但是，许多传统的应用程序可能要花些时间才能迁移。当前正在运行的东西需要组织克服巨大的惯性。不只是技术上的，还有文化上的。变革很缓慢。

InfoQ：让我们换个话题，聊下你们最近的创业之旅。你们公司 Heptio 经常提到 Kubernetes undistribution 。您能详细地说下这到底是什么意思吗？它如何帮助企业呢？

McLuckie：在过去几年中，我们看到，在企业和推动他们发展的开源社区之间，有一个相当显著的变化。

首先，他们会将开源看作是减轻锁定威胁的一种好方法。Kubernetes 为运行 App 创建了一个一致的环境，把他们从赖以运行的基础设施上分离出来。已经说过，只要云提供商和上游保持一致，企业就没有什么理由不想使用 Kubernetes 的托管版本（谷歌 Kubernetes 引擎、Azure Kubernetes 服务和 Amazon Kubernetes 服务）。对于许多情况而言，这些都是不错的选择。不过，在许多情况下，他们无法使用其中的任何一种服务。那些服务不在本地运行，或者那些平台并不是天生就能满足他们独特的需求。

其次，企业和开源社区之间的关系正在发生变化。精明的企业意识到，通过努力让上游社区接受某个东西，可以让他们处于有利位置，因为他们就无需自己维护那个东西。自然地，他们会寻找一个合作伙伴，帮助他们使用上游友好的解决方案填补生态系统中的空白，这些解决方案在基于云提供商的环境里也有效。

Heptio Kubernetes Subscription 提供了传统分发的许多积极属性。一个负责任的供应商提供的严格定义的参考架构，一个稳定的安装框架、24x7x365 技术支持等。但是，它同时还带来了传统分发不具备的几个好处：

• 我们承诺密切关注“上游”，这意味着，从应用程序的角度来说，你从来都不用考虑 Kubernetes 终于何处、始于何处。对用户而言，这意味着在运行应用程序时有很大的灵活度（在 HKS 上，或者是云提供商的托管服务上）。
• 我们承诺借助类似 Sonobuoy 这样的工具和更先进的机制不断改进我们的支持模型，使客户的集群达标，并维护客户的集群。我们认为，大部分企业环境都是“雪花”，我们认识到，归根结底，可观测的一致性比控制集群构建过程更重要。稍后我们会更详细地介绍。
• 我们承诺弥补将新的工作负载类型带到 Kubernetes 时存在的不足，并且是用一种对上游来说很友好的方式。关于这一点，您通过我们资助的项目就可以看到，每个项目背后都有一个客户故事。

InfoQ： Ark 和 Sonobouy 解决了企业管理 Kubernetes 集群时的部分常见问题。关于这些产品及其路线图，其他作为 Kubernetes 项目补充的产品，您能从技术上更详细地介绍下吗？

McLuckie： Ark 的出现是因为我们其中一个最早的客户苦于对有状态 Kubernetes 工作负载的备份和还原。他们得到的建议是复制底层的状态存储（etcd），那对他们无效。随着我们开始研究解决方案，我们发现，Ark 的价值远不止备份还原。它提供了一种相当可靠的方法在环境之间迁移工作负载。在我们所从事的每个垂直领域，这都是一项挑战。客户看中复制生产环境用于测试的能力，有时候，他们需要能够把工作负载从非托管的 Kubernetes 解决方案（本地或云上）迁移到云提供商创建的托管解决方案。

我们将继续在这两款产品上进行投入，促进工作负载的整体可用性，改善 Ark 的特性，让它可以适用于有更高要求的工作负载，我们还将引入新功能，增加选择——让它成为一款有效的迁移工具。不仅让用户可以灵活地在环境间迁移工作负载，最终还要让他们能够维护其他环境里的工作负载副本，那样，比如说，如果出现严重的云提供商中断，他们就可以在不同的云提供商那里快速启动。

Sonobuoy 开始时是作为一款降低支持复杂度的工具。很显然，它是始于生产环境里经常出现的“配置漂移”，我们发现，自己在提供电话支持时做了大量相同的工作。而且，这类工作通常表现为令人痛苦的“电话游戏”，大量高延迟的来来回回。我们就问自己，判断集群是否“正常”的最佳方法是什么，并且发现，上游的 Kubernetes 一致性测试会是个很好的起点。这可以帮助我们的用户确保他们的集群看上去和符合特定版本标准的集群一样。该工具后来成为原生云计算基金会下 Kubernetes 认证项目中供应商认证的底层框架。

将来，我们希望更进一步，不只是运行一致性测试，还能帮助用户处理安全和优化问题。一个很棒的例子是最近的 Tesla 安全问题，密码窃取者攻入了生产环境集群。我们已经创建了一个 Sonobuoy 扩展，让我们的 HKS 订阅用户可以了解我们对良好集群的看法。这让他们可以深入了解如何针对特定的工作负载和可用性需求优化集群。Tesla 的例子就是我们希望帮助用户避免的事情。仅仅交付二进制文件（就分发来说）是不够的。我们的目标是提供源于代码的专业知识和见解。但是，我们使用的方法必须符合我们避免引入专有运行时组件的价值观；我们不能夺走客户对于其环境的控制权。

除 Ark 和 Sonobuoy 之外，我们已经开始了 Contour 项目的工作，这是一种处理 Kubernetes 集群负载均衡的现代化方法，还有 ksonnet 提供了一种更简单的方法，创建 Kubernetes 配置供现实世界应用。将来会有更多那样的工具。

InfoQ：接下来的这个问题我问过 Brendan Burns 。Kubecon 大会上的许多演讲都是要让开发变得更乏味（确实有用）。我们的社区目前的发展情况怎么样？如果让您大胆地设想一下，那么与现在相比，我们的社区五年后会是什么样子？

McLuckie：这个问题很好，是的，开发仍然太有趣。我希望，在接下来的五年中，我们对 Kubernetes 的讨论不比对 Linux 内核的讨论多。它真得应该消失在后台。如果我们做了正确的工作，我认为，有些事情就会成真。

大多数开源和 ISV（软件供应商）的安装指令都是始于“选择一个经过认证的 Kubernetes 集群”。第 2 步将是“运行这个 kubectl 命令”。Kubernetes 将解锁第三方软件随处运行的能力，让那些供应商更容易提供云提供商托管服务之外的方案。在许多情况下，你可能会选择使用一项云服务，但是，你应该能够从你可以自己控制的基础设施上而不是云提供商那里获得类似的体验。

我相信，对于开发流程，我们将从封闭的 PaaS 服务转向一个企业可以使用一流组件组装类似 PaaS 功能的地方。其中，有些可能是领域专属的，只在一个特定的行业里应用。企业能够快速组装一个完整的解决方案，提供了一条从代码到有着强大防护的生产环境的简单路径，也提供了在需要时“打破玻璃”运行自定义功能的能力。

如果我们做了正确的工作，我们将会看到，需要人类操作员执行大量功能的工单驱动的基础设施管理将转向 API 驱动的管理，大量企业都需要的东西由专门从事那项功能的外部团队提供。我们将看到 SRE（网站可靠性管理）规则的出现，因为企业赞助了专门的团队来向更广泛的组织提供服务，实现深度操作专业化。

感兴趣的读者可以在大会网站上观看完整视频，了解主题演讲会议的更多细节。

查看英文原文： Kubernetes Founder Craig McLuckie on Going Multi-Cloud and Open Source