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

开源 云计算 Kubernetes

摘要

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

正文

在德克萨斯州奥斯汀市举行的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