我们最近有机会采访了 VMware 首席工程师 Joe Beda，他是 Kubernetes 和 Google Compute Engine 的创造者之一。Joe 是一位经验丰富的软件工程师，曾在 Microsoft 和 Google 工作过。 他也是云原生领导者 Heptio创立者之一，该公司现在是 VMware 的一部分。下面是整个采访记录，希望你喜欢它！
Evrone：你好。很高兴见到你！现在让我们开始此次的访谈吧。如今，应用程序可以通过虚拟化技术的帮助从硬件中抽象出来。使用容器意味着从操作系统和巨大的系统资源经济中抽象出来。Kubernetes 等平台让我们无需手动控制，这意味着我们不必关心应用程序怎样以及在哪运行方。这是否意味着我们正在失去控制，客户的故障排除变得更加困难？

Joe：嘿，非常感谢邀请我过来！我认为它不一定要把你从操作系统中抽象出来。我的意思是，当你在容器中运行某些东西时，你仍然知道你是在 Linux 上运行的。我认为它所做的一些事情确实有助于我们尝试创造神奇的结果：“只需获取我的代码并运行它。我不在乎它在哪里运行，只要让它正常运转就行。”首先，大家对容器与虚拟化结合使用存在效率方面的争论。你可以在相同的硬件上打包更多的东西，你可以做得更小，你可以有更细粒度的过度使用和事物之间的权衡。

但更重要的是，借助容器的能力，你可以拥有一个更好的一键部署以及隔离性的部署单元。所以我们最终会得到这样的一个预期，至少在服务器端，我们可以在笔记本电脑上，一个云中，另一个云中运行一个程序。几乎可以说是完全相同的程序。相同的制品可以在没有改变的情况下运行在不同的环境中。拥有这样的部署单元能够更好的提高我们的工作效率。

运行 CPU 进程很棒，但一般来说，如果没有网络功能，程序就没有多大用处。这就是真正复杂的地方。就拿容器来说，通过二进制打包机制可以让它在不同的主机上运行，但是只有让它能够网络连通，才能变得有用，你需要让这些容器之间能够互相通信，在正确的时间正确的地方拥有正确的功能——这些最终会成为复杂问题因素的一部分。

Evrone：您提到我们可以假设容器运行在某个 Linux 内核之上，但微软目前正在为 Linux 进行 Windows 子系统的密集开发。您认为这会是 Windows 容器集成时代的一个良好开端吗？

Joe：我对 Linux 的 Windows 子系统方面不是很了解。我曾经在微软共事过的一些人正在努力的做这块事情。但我的理解是，Linux 的 Windows 子系统的第二个版本实际上是一个在虚拟机中运行的 Linux 内核，它与 Windows 文件系统和网络之间有一些细粒度的交互。

我用过它，我对这项有趣的技术印象非常深刻。有了它，你可以直接运行容器引擎，例如 Docker，并能够获得在你的桌面电脑上拥有 Linux 的体验。你会拥有一个真正的 Linux 内核，只不过与更传统的 Linux 系统相比它仅仅多了一个 UI 界面。我认为重要的是要认识到这是一种与原生 Windows 容器完全不同的机制。原生 Windows 容器正在面临许多挑战性，因为 Windows 不是按照容器期望的方式驱动构建的。Windows 使用全局注册表和全局资源管理器，所以创建一种方式来隔离所有这些东西是一项艰巨的任务。

我的理解是，就成熟度和使用而言，原生 Windows 容器在开发方面仍处于早期阶段。如果你是正在 Windows 平台使用 C++ 或更底层语言开发的程序员，你会很容易了解到这一点。不管你是针对 Windows 使用 Win32 还是 Linux 之类的东西，你都会看到它们之间很大的差异。就对应的模型而言，它们的差异相当大。

但是一旦你开始使用更高级语言，我们会发现它们之间没有很大的差异。随着微软的视角转向 .NET 核心——它可以很好的处理差异之间的转换，我们可以看到那些更高级别环境的编程模型与底层操作系统的分离。话虽如此，仍然有相当多的 .NET 标准待完善。并且对 native Windows DLL 仍有相当多的依赖，尤其是在媒体编码之类的事情上。而且还有很多地方需要运行 Windows 工作负载。这就是为什么我认为围绕 Windows 容器的工作仍在进行中。但是随着许多这样的事情，比如支持 Linux 的 .NET 核心，Windows 原生容器化也没有你想象的那么重要。

Evrone：您提到了您在微软的职业生涯并为 Internet Explorer 浏览器工作。您觉得您从中学到的最有用的经验是什么？

Joe：随着职业发展，你肯定可以从多个不同的方面学习东西。如果我们从技术的角度来说，有一个比我更高级的工程师实现了一个内存分析系统，基本上在 Internet Explorer 以及在主渲染引擎中的每个被尝试分配操作，我们会放置一个标签，然后创建层次结构并且能够实时可视化内存的使用位置。这是一种基于内存的调试模式。当系统变得足够复杂，以至于你都不真正了解系统怎样运行的，如果你能够多做出一些探索，你会很惊讶感受到你做的事情带来的效果，这是我学到的有用经验之一。这也是我在职业生涯中一次又一次体会到的事情。你一开始提出理论假设，然后根据程序中代码实际发生的情况来验证这些假设，最后发现你总是错的。

所以你真正需要的是看看。我的意思是，有这些理论假设很好，但你真正需要的是去验证这些东西。直到你验证了你正在优化的事情是瓶颈所在，然后再真正的去优化，真实性才是最重要的问题。

在专业开发方面……大概在 Internet Explorer 5 或 Internet Explorer 6 开发早期。我开始承担一点领导角色。当时的 Internet Explorer 除了 NT 之外，还针对 Win9x。IE4 的原始版本在 48 或 64 兆字节的机器上运行，相当低的内存，低功耗的机器。所以这是一个与我们今天完全不同的环境。

当时我实际的工作主要是在帮助改进 Internet Explorer 引擎（渲染引擎）的性能，这是与我们当时的主要竞争对手 Netscape 等公司的关键竞争胜利。我从这些横向角色中学到了很多。绩效表现不仅仅是一个团队的事情，它实际上可能会受到其它任何事情的影响。所以我学到的最重要的一课是：你如何通过影响力来领导？当你不能够直接控制他们在做什么时，你如何能够让人们很好的做事？早期我也犯了一些错误。我当时想，“我们必须这样做，我们必须那样做”并尝试使用一些权威（我可能没有）来尝试让事情发生。是的，这并没有那么好。

所以这也是很重要的一课，关于：你如何真正理解人们的动机是什么？他们的目标是什么？以及如何为他们创造双赢局面，以便在你不使用权威的情况下让别人能够与你保持一致？这只是你在整个职业生涯中不断培养的一项技能。同时这说明软件开发是一项团队运动。你真正需要的是要让别人能够很好的一起工作。这与核心技术以及编写大量出色的代码一样重要。

Evrone：哇，很美好的经历。那段时间你更喜欢 Internet Explorer 还是 Netscape Navigator？

Joe：关于过去发生的事情有很多话要说。当我从微软过渡到谷歌时，对我来说最大的变化之一是谷歌非常专注于“让我们为客户做得更好”而不是“让我们去扼杀竞争”。而且我现在还继续坚守着关注用户而不是关注竞争的态度。我不知道谷歌是否仍然这样做。

后来，我内化了“让我们专注于为用户做正确的事情”。但在我职业生涯的早期，微软在很大程度上是一种“让我们出去杀死竞争对手”的东西。我回头看，我认为就 IE 在市场上的定位而言，这不是一种健康的态度。话虽如此，在技术方面，IE4 在当时还是比 Navigator 好得多。我会给你一个例子。我们有一个页面的内存模型，你可以对其进行编程。你在浏览器中获得的 DOM 模型实际上真正始于 IE4。正是这个团队真正推动了对齐（align）编程模型和标记（markup）的想法，无论你在标记内容中做了什么，你都可以通过使用 JavaScript 来调整运行。当时 Navigator 还没有那种内存模型。

如果你使用 Navigator 窗口并调整它的大小，它实际上会重新解析页面的原始文本来重新渲染它，因为它没有对应的内存模型能够离线渲染它。有时，当你调整窗口大小时，它实际上会重新下载一些东西。当时，Navigator 支持的动态特性意味着他们会将多个网页交替的绘制在一起，同时你可以替换其中的一些内容。这就是 Navigator 层做的事情。

在我看来，当时的 IE4 是真正建立了我们现在所认为的现代网络浏览器。它做了很多改进；完成了很多很棒的事情。当时的标准（standard）正在不断演进。通常，IE 技术都会领先于标准，随着标准发生变化。你需要在兼容性与标准之间进行权衡，这是一项非常困难的事情。我们不一定总是拥有能够处理这些情况的工具或技术。但当时我真的更喜欢 IE，因为我认为我们在建立现代网络浏览器方面做了一些非常有趣的事情。我们当时称它为 HTML Dynamic、DHTML，但本质上，现代 DOM 是我们当时所做的事情。

Evrone：是的，我们清楚地记得这一点。在您的一次演讲中，您提到 Kubernetes 是平台的平台。在您看来，最火爆的基于 Kubernetes 的平台是什么？

Joe：老实说，我认为我们仍在学习，Kubernetes 成功的原因之一是我们不一定需要在 Kubernetes 之上构建一个单一的单体平台。让我们来做一下对比说明。如果你看一下 Mesos 之类的可扩展性模型，Mesos 本质上是一个工具包内核，然后你可以在它之上构建诸如 Marathon、Aurora 或 Chronos 之类的东西，这些系统将使用核心调度程序来做事情。但是你发现 Aurora 和 Marathon 和 Chronos 都有自己的 API。他们有自己的用户系统。他们有自己的世界建模方式。这些东西最终成为孤立的孤岛。

我们用 Kubernetes 做的一件事是我们为一组通用模型创建了一个通用 API，所有这些都是围绕 CRUD 的。我们发现，当人们扩展 Kubernetes 时，他们以一种通常可以与 Kubernetes 的其他扩展互操作的方式进行操作。这意味着人们在它之上构建的东西不是在孤岛中运行，而是能够通过生态系统的其他部分来让其真正丰富起来。我认为这是 Kubernetes 的一个很大的不同点。你会发现我们有一些通用的组件还在不断的演进中。例如，单例模式的 cert-manager。这是每个人都使用的一个 Kubernetes 扩展。

实际上没有很多人自己去创建证书管理系统。但是在 Kubernetes 中我们有一个发展非常好的 ingress 生态系统，不管是基于 envoy 的、Nginx、HAProxy 还是原生云，它们都会使用证书管理这个扩展。这些都可以按照某种相同的方式来协同工作。我认为我们并不是做出了一个让别人在 Kubernetes 之上构建应用的平台，而是一系列组建（blocks），别人可以将它们组合在一起来创建真正满足他们需求的平台。

话虽如此，但我觉得还有很多想象空间，比如 VMware Tanzu 项目正在做的一些事情，它能够包含用户的所有选择，这对于早期用户来说往往是压倒性的，归结一句话就是，“嘿，如果你以这种方式将这些东西组合在一起，你将获得很好的体验。”而且，随着你更好地了解自己的需求，更好地了解这个系统和生态系统，你就可以开始利用这些东西，然后根据自己独特的需求来进行定制化。没有唯一不变的平台，通过组合不同的组件，我们可以为个人和组织带来更好的使用体验。

Evrone：大多数专家说到Kubernetes都会提到它的高准入门槛。这对平台来说是好还是坏？对于新手来说，是不是可以降低准入门槛？

Joe：我认为这是一个非常复杂的话题。用我喜欢的术语来描述就是偶发复杂性（accidental complexity）和本质复杂性（essential complexity）。通常情况下，如果你尝试使用一个系统并将其过度简化，你会发现它会变得很死板，并且能够应对的使用场景会变的相对狭窄。我们在许多早期的平台即服务的产品中能够看到这一点。开始觉得很棒，后面就觉得不合适。你可以把许多事情都提前做好，但是，最终，你会碰到各种各样的阻碍。而且没有太多可解决的办法。在你必须接受你的程序不能改变的情况下，你不得不或者在某种程度上使用不同的环境来解决问题。我认为这都是太过于简化导致的。

过度简化的另一个缺点是，在开始的时候你觉得事情很简单，但在其下面隐藏着很深的复杂性。通常，如果事情发生的过于“神奇”，那么理解它怎样运作的就会变得更加困难。我认为，从根本上说，利用各种其他外部服务（如负载均衡器和动态存储）的机器池（pool of machines）部署水平可扩展的分布式应用程序，这是一个比较难的事情，并且存在很多复杂性。即使通过 Kubernetes 提供的灵活性，也很难进一步简化它。在 Kubernetes 中肯定有一些地方存在一些偶发复杂性，可能比实际需要还要复杂，我认为这在任何现实世界的系统中都是不可避免的。

我认为这确实是一个难题，并且需要相对复杂的解决方案。我认为我们对这些事情视而不见。我的意思是，考虑向刚接触计算机的人介绍，比如说，编程和使用 Linux 之类的东西。这是一个很大的复杂性，但是他们又不得不面对它，只有这样他们才能达到真正精通这件事的水平。同样，看看任何主要的云，比如 AWS。这绝非简单。那里有很多复杂性，但是你会看到它是一个可以以多种不同方式使用的工具包，因此复杂性是合理的。

我认为其中一些也适用于 Kubernetes。复杂性是合理的。问题是 Kubernetes 仍然很新。随着这些东西变得成熟，随着它进入某种共享格式塔，变成一个行业所拥有的共同理解，复杂性往往会逐渐消失。但是新用户仍然必须接触它。当我们有新的开发人员进入我们的行业时，我们就会看到这一点。有很多东西需要学习。你知道，目前还没有和 Kubernetes 相同的产品。所以我们没有办法比较Kubernetes是否是容易还是简单。但我们知道的是，一旦我们掌握了它，我们就会突然忘记那种痛苦。我认为 Kubernetes 也有类似的动态。

Evrone：两周前，我们的团队参加了我们最大的技术活动之一。会议上的热门话题之一是：开发人员应该关注学习 Kubernetes 基础知识，还是专注编写好的代码，然后把其他交给系统管理员或 DevOps 专家？

Joe：我认为这取决于你所说的开发人员。通常，我们将开发人员作为一个统一的群体，这样更方便我们互相交谈，但是我们发现确实有很多不同类型的开发人员，他们有不同的关注点和需要学习许多不同的事情。让我们以游戏引擎为例。我有一个高中的朋友，他通过微优化（micro-optimization）处理 AAA 游戏。这与我现在从事的工作截然不同。问题是，如果你正在开发一款游戏，你是否应该只使用虚幻引擎之类的东西，而不用关心底层的渲染技术？或者你需要关注 GPU 相关的事情吗？答案是，两者都有，取决于你是哪种类型的开发人员。

我认为我们将有更多的开发人员嵌入到我们已有的运行时部署系统中并且需要了解 Kubernetes，他们也将成为开发这些平台的人。通常，他们也会慢慢融入 DevOps 角色中，他们就是应用程序和应用程序运行环境之间的连接器。仍然会有一些开发人员从不编写业务逻辑，他们不想考虑这些事情。

我认为这两件事都有改进空间，围绕“云原生”这个术语的关键之一（或者这些术语中的任何一个，“DevOps”，“云原生”，它们很难定义）是没有权威可以告诉我们“真正的云原生”是什么意思。但在我看来，云原生本质上是能够充分利用类云（cloud-like）平台的优势，其中类云平台是 API 驱动、自助服务和弹性的，而 Kubernetes 确实是一个类云平台。我们使用云原生获得的优势是，你有一组开发人员不断创造和丰富平台，然后其他开发人员在这些平台之上构建应用。

对于这两件事，对应着运维和开发角色。对于那些开发和定制化平台的人，他们需要非常了解 Kubernetes。对于那些在它之上构建应用的人来说，取决于他们做什么。如果他们正在做简单的 3 层 Web 应用程序，他们不需要非常了解 Kubernetes，因为这些模式很容易理解并且可以被很好的处理。

如果你正在做的事情类似于涉及机器学习的超高动态分布式系统，你可能需要更深入地了解对应的运行环境，因为这更可能是一个定制化的架构，你必须要深入了解。再次与游戏引擎的类比，如果你正在做一个简单的游戏，你不需要了解它。但是对那些正在做更高级的事情人来说，他们必须对他们的游戏引擎做 C++ 扩展。“开发人员”不是一个单一的概念，它要依赖你做的事情来定义。

Evrone：有一个玩笑说云原生是你无法在笔记本电脑上运行或调试的东西。

Joe：哈哈，对于这个问题，你需要有一定信任程度的供应商。同时存在一些地方你无法调试实际发生的事情，而且这两者都是需要授权的，幸运的是这些都是别人的事情。话说回来，对于喜欢深入研究的开发人员，想要了解“执行某个操作，数据包是怎么样流转的？”，云原生提供了一些障碍让你无法调试通过，这有时会让那些习惯于能够深入了解他们所做的事情的人感到不安。

Evrone：最近，我们注意到存在一种转向微服务架构的趋势。从您的专业角度来看，容器编排是微服务演进的唯一途径吗？

Joe：我觉得并不是。有很多人在没有容器的情况下做微服务。许多细粒度的、面向服务的工作和基础设施即代码是 Netflix 早期完成的，他们很有发言权。你知道，很多东西都是使用 AMI 等在 EC2 上完成的。所以这里的很多技术都可以在没有容器的情况下工作。我认为你可以在没有微服务的情况下使用容器，但人们看到的是这两个东西可以很好地协同工作。在所有这些事情中，没有正确的答案。只有一组工具、技术和模式可供你选择，然后利用它们做事情。这些只是一些可以很好地协同工作的工具和模式。

Evrone：我们经常谈论容器编排系统的优点，尤其是在会议上，但是它有什么缺点吗，有什么你不喜欢或想要改变的地方吗？

Joe：我认为，很重要的一点是它需要承担更多的事情。如果你做一些简单的事情，Kubernetes 可能不适合你，容器可能更不适合你。我的意思是在某些场景下，你正在做一些非常简单的事情，你启动一​​个虚拟机并安装 Docker，然后运行一个容器，最后才开始真正的处理事情，对许多的用例来说，它们能工作的很好。Kubernetes 和容器不是万能的。话虽如此，我认为管理 Kubernetes 集群的工作越多，它就会变得更有用、更容易。

就我想要改变的事情而言——目前还没有。我想我可能太亲近它了，所以无法真正说出什么要改变的。肯定有一些事情我们正在努力的改进。生命周期管理，Kubernetes 的运维方面，怎样管理集群？这比我们在项目早期认识到的要困难得多。我们在上游做了大量工作来让 Kubernetes 控制器模式来管理 Kubernetes 集群本身。这就是现在集群 API 工作的那样。

我认为我们管理和处理 YAML 以及安装软件的方式仍然非常分散，并且比它实际需要的更难。令我惊讶的是，在 Kubernetes 的旅程中，我们仍然有人直接处理 YAML。我已经发表了一个名为“我对 YAML 感到抱歉”的演讲，其中我已经讨论了一些相关的细节。我认为这些都是可以解决的问题。我不知道在我们做事的方式上，我是否会改变任何基本的东西。我认为随着时间的推移我们可以解决所有这些问题，而我们要做的事情就是倾听和迭代，最终让事情变得更好。

Evrone：还有关于工作与生活平衡的问题。你的生活一定充满了很多高负荷的项目。您对其他开发人员保持高效工作和更好生活方面的建议是什么？

Joe：对我来说，有不同的方法可以提高效率。这实际上取决于你想成为哪种类型的开发人员以及你想要将你的技能和激情放在哪里。我不相信 10 倍的开发人员。正如我之前在采访中所说，这实际上是一项团队运动。有句老话，要想走得快，就一个人走；想走远，就一起走。很多时候我们有 10 倍的开发人员，他们做事效率很快。但是，通常情况下，最终会以带来大量长期债务的短期胜利而结束。所以我认为真正的 10 倍开发者是那些让周围的人变得更好并帮助他人更有效率的人。

如果你有一个 10 人的团队，并且你让每个人的效率提高了 20%，那么这就是一个巨大的乘数，尤其是他们还能够他们周围的人变得更有效的话。

我的工作与生活平衡建议是：找到一种方法来提升和信任他人，这样你就不会独自承担所有这些。当人们感到自己的责任远远超出了他们的能力时，他们真的会陷入困境。这是我对那些感到精疲力竭的人总结出来的公式，比如当你觉得有责任做某事时，而你没有工具去做，无论是组织上还是一天中的几个小时。然后你最终会感到筋疲力尽，因为你一天结束后的感觉就像有很多事情没有完成，它只会侵入你后面的生活。

但是，如果你可以确保你要解决的问题在你拥有工具的处理范围内，并且你开发了这些工具，以便通过与其他人合作并提升影响别人，那么我认为这在避免倦怠方面可以让事情更加长期可持续。

Evrone：谢谢！感谢我们所有社区的 Kubernetes。我们希望通过这次采访，我们能够让我们的开发人员变得更好，让我们的世界变得更美好。
我们很高兴有机会采访 Joe，并能够从他作为软件工程师工作的宝贵经验和多年专业知识中学习到很多东西。在为客户开发产品时，我们经常使用 Kubernetes，没有比与它的创建者交谈更深入地了解该工具的方法了。

我们还要感谢来自 Selectel 的朋友 Nikolai Rubanov 为本次采访提供的帮助。

在 Evrone，我们提供定制的 DevOps & Kubernetes 解决方案，旨在满足客户的特定需求。如果您有需要帮助的项目或想法，或者您想了解有关我们服务的更多信息，请给我们发送消息，我们会尽快与您联系，了解我们如何提供帮助。

原文链接：Kubernetes Co-founder Joe Beda: "Software development is a team sport"（翻译：王欢）