Thomas Graf 是Isovalent的联合创始人兼首席技术官，也是流行的开源（和云原生）网络技术Cilium的创建者。 Cilium 构建在称为eBPF的内核级 Linux 技术之上。
在这次采访中，Graf 讨论了 Cilium 和 eBPF 在不断发展的云原生网络生态系统中所扮演的角色，以及围绕 Kubernetes 采用和演变的一些更广泛的趋势。他解释了谁在大型企业中使用和购买 Kubernetes，云原生基础设施仍需要改进，以及对标准化的渴望如何推动创新。
未来：我们应该如何看待 eBPF 和 Cilium 在计算和网络的背景下，一般来说，然后是在云原生生态系统的背景下？
THOMAS GRAF：总的来说，eBPF 是一种技术，而且它的水平极低。它是为内核开发人员设计的，我的背景是内核开发。 eBPF 之于内核、操作系统之于 JavaScript 之于浏览器。它使操作系统可编程，就像 JavaScript 使浏览器可编程一样。过去，我们必须升级浏览器版本才能实际使用某些网站。然后 JavaScript 出现了，突然之间，应用程序团队和开发人员可以构建大规模的应用程序——以至于最流行的文字处理应用程序被浏览器内的应用程序所取代。它引发了巨大的创新浪潮。
eBPF 也是如此，尽管是在操作系统级别，因为突然之间我们可以在内核或操作系统级别上做事，我们可以看到一切并控制一切——这对安全性非常重要——而无需更改内核源代码。我们基本上可以将程序加载到内核中以扩展其功能并为其带来新功能。这也开启了大规模的创新浪潮。 Facebook、Google 和 Netflix 等超大规模厂商正在自己的内核团队中直接使用它。
Cilium 带来的是它使用低级 eBPF 技术从本质上提供新一波软件基础架构，特别是对于云原生浪潮。这就像软件定义的网络，以及后来成为 VMware NSX 的 Nicira 为虚拟化行业所做的事情。我们对云原生做同样的事情，它混合了云提供商或公共云基础设施，以及本地基础设施。我们正在基础设施层解决网络、安全和可观察性用例。
而刚刚发布的 Cilium Service Mesh 就是这些能力的演进？
从大约一年前开始，目前正在发生的事情是这两个空间正在发生碰撞。迄今为止，Cilium 所做的主要集中在网络、虚拟化网络，然后是云原生网络——但仍然是网络。但是，从上到下，Twitter 和 Google 的应用程序团队在做服务网格的东西——首先是在应用程序中，然后是基于 sidecar 的模型，基于代理的模型，这就是Istio等项目所提供的。现在这两层越来越近了，因为传统企业正在进入云原生世界，他们有企业网络需求，但他们的应用程序团队也想要一个服务网格。
Gartner 将这个新层称为“服务连接”——我们将看看这个术语是否流行——但它本质上是一个包含企业网络部分和来自应用程序团队的服务网格部分的层。而且因为这是客户的要求，我们已将这些功能添加到 Cilium 本身中。因此，从本质上讲，Cilium 正在从企业网络端向上发展，而服务网格正在向下进入更多的网络端。
服务网格
为什么如此关注 Kubernetes 堆栈的网络和服务网格级别？
由于希望在多个云中运行并将应用程序拆分为容器，因此连接层已成为中心。过去可能是进程间通信和中间件现在是网络，因此网络对于应用程序相互通信和数据流动变得绝对必要。
特别是在云原生领域，多云变得绝对必要。所有云提供商都有自己的网络层，但当然是针对自己的云量身定制的。他们确实有本地产品，但它们并不是真正的多云。 Cilium 和 eBPF 带来了多云、不可知的层。它在本地的行为与在公共云中的行为完全相同。一些公共云提供商在后台使用 Cilium 来提供托管的 Kubernetes 产品，而电信公司则将其用于本地 5G 基础设施。这是关于说两种语言并将这些世界连接在一起。
这就是为什么如此关注这一点：因为云提供商锁定客户的最简单方法之一就是拥有该连接层。我认为从战略基础架构的角度来看，就像虚拟化层是关键一样，现在连接和网络层绝对是关键。
[未来] 创新的源泉将是开源的，推动需求的客户和用户将是比超大规模企业低一级的公司——规模已经很大但仍具有高度颠覆性的公司。
Kubernetes 在这一点上被广泛接受和采用，但在某些圈子里仍然有人说它是矫枉过正的。您认为 Kubernetes 以及整个云原生生态系统是为谁服务的？
它适用于现代应用程序团队。我认为，如果你想吸引现代应用程序团队，并能够快速进入市场，你需要为他们提供云原生基础设施。我们经常在 Lambda 之类的无服务器上看到原型设计——初始、前 MVP，甚至证明概念或内部销售。然后在 Kubernetes 上，因为应用程序团队可以直接拥有基础设施。然后，当它投入生产时，它们会进入企业、本地 Kubernetes 发行版。但这实际上只是整个基础设施的一小部分，可能是个位数或低两位数的百分比。
不过，这显然将成为新标准。就像虚拟化最初的采用速度很慢，人们说它有点矫枉过正——但随着时间的推移，当然，它开始取代大多数东西——我们会在这里看到同样的情况。或者就像现代语言一样。人们说 Java 太过分了，对于很多应用程序来说可能仍然如此，但曾经有一段时间，在 Java 之外进行任何应用程序开发变得非常困难，因为大多数应用程序开发人员都可以使用 Java 编写。同样会对于现代应用程序团队来说也是如此：他们希望拥有 Kubernetes，以便开发更敏捷的产品并将产品快速推向市场。
在基础架构方面，这可能有点矫枉过正，但如果替代方案是将应用程序从无服务器重写为本地，那将是一项艰巨的任务。所以 Kubernetes 是中间地带，非常有吸引力。
Kubernetes 仍然需要更好的开发人员体验的想法呢？
如果我们看看最初的 OpenShift，在它重新基于 Kubernetes 之前，就是这样。它更接近应用程序团队，并且是更好的应用程序开发人员体验。你可以推送到 Git，它会自动部署。 Heroku 也尝试过这个，但基于 SaaS。
Kubernetes 退后一步说：“我们需要保留一些操作方面的内容，并使其更接近系统管理员的期望。我们不能只针对应用量身定制。”这是中间立场：它需要对应用程序团队具有足够的吸引力，但它仍然需要能够在特定环境之外运行该应用程序，并由应用程序开发人员以外的人管理。
我想说 Docker 和 Kubernetes 之间最大的一步是 Docker 是关于开发人员体验的。它解决了那部分，但没有解决公共云生态系统部分。
我们是怎么走到这一步的？这是平台即服务 (PaaS) 和应用程序容器的自然演变吗？
它是 Docker 映像和 Docker 的打包方面。老派是如何部署到虚拟机中，围绕着它有各种各样的自动化。然后是 Facebook 对 Tupperware 所做的事情——非常定制并且规模非常大。然后 Docker 出现，基本上提供了这个容器镜像，每个人都可以把它当作一个微型 VM。我现在可以分发我的应用程序，而不是 600MB 的虚拟映像，它现在是一个 10MB 的容器。但是你可以同样对待它，它拥有它需要的一切。
这释放了引入像 Kubernetes 这样的编排器的能力，它仍然允许您将应用程序视为迷你虚拟机，但随后也更进一步，实际上将它们视为微服务。它允许您两者兼得。
我想说 Docker 和 Kubernetes 之间最大的一步是 Docker 是关于开发人员体验的。它解决了那部分，但没有解决公共云生态系统部分。它没有，也不一定想要与云提供商紧密集成。 Kubernetes 解决了这个问题。
你认为谁在公司内部运行 Kubernetes？是个人应用程序团队吗？
云原生发生了一个有趣的转变，那就是我们有了“平台团队”的崛起，我称之为。他们不是应用工程师。他们有一点网络操作知识，也有相当多的安全知识。他们拥有 SRE 知识，并且知道如何进行云自动化。他们为应用程序团队提供平台，并将这些应用程序团队视为他们的客户。
平台团队是购买 Kubernetes 和相关技术的人，他们使用这些技术是因为他们的任务是提供下一代基础设施，让现代应用程序团队满意。
我认为无服务器肯定有空间，特别是对于非常快速的应用程序开发。但在企业中，我们将云原生视为虚拟化之上的新层
那是一个全新的买家还是一个全新的团队？还是平台团队就像存在于 Google 或 Facebook 这样的地方并且现在正在成为主流的东西？
他们大多是一个新团队。我认为他们在某种程度上就像谷歌和 Facebook 的 SRE 团队。但是，应用程序团队可能在企业中拥有更多的应用程序部署，因为企业没有像谷歌和 Facebook 这样的软件工程师和 SRE 之间非常明确的区别。我想说这种演变非常类似于您拥有虚拟化团队的方式，然后许多网络操作从关于网络硬件的迁移或演变或升级到关于网络虚拟化。例如，这些团队开始运营 VMware NSX。同样的事情也发生在这里。
虽然，这不一定是新预算。我们看到预算从安全和网络转移到这个平台团队，例如，随着云支出的增加和网络硬件的支出减少。他们经常与安全团队和网络运营团队合作以获得支持，但他们实际上拥有相当可观的预算。
您如何看待云原生计算基金会的发展，Kubernetes 是否将始终处于其中心——或者整个云原生运动的中心？
Kubernetes 激发了 CNCF，在最初的几年里，一切都是关于 Kubernetes 和公共云的。大约一年前我们看到的是，它现在不再只是关于 Kubernetes，它实际上更多的是关于云原生原则。这实际上意味着它也不一定是云，甚至不是私有云。它通常甚至是传统的企业网络、无聊的本地基础设施、裸机服务器等等，但内置了云原生原则。
新规范现在是混合的，包括多个公共云提供商以及本地基础设施。公司希望为应用程序开发人员提供相同的敏捷性，或使用现代云原生工具提供可观察性，或使用现代云原生工具确保安全——例如，身份验证，而不仅仅是分段或基于身份的强制执行——所有这些新的云原生概念现有的基础设施。
我们看到仍然连接到旧世界并谈论 MPLS、VLAN、sFlow 和 NetFlow 的非常强烈的需求——整个现有的企业需求集。他们都没有离开。
大约十年后，云原生空间似乎并没有成为一种时尚。它还有多大的发展空间？
肯定有一段时间，“哦，Kubernetes 可能是短暂的，无服务器将成为下一层。”或者，“Kubernetes 类似于 OpenStack。或者，“它将消失，它将成为一个实施细节。”而这并没有发生。
我认为无服务器肯定有空间，特别是对于非常快速的应用程序开发。但在企业中，我们将云原生视为虚拟化之上的新层，我们相信它的保质期与虚拟化相似。这意味着我们正处于云原生迁移的初期。
基础设施层面还有哪些大问题需要解决？
我们看到企业突然之间，无论他们是否愿意，他们都需要多云战略。因为他们还拥有本地基础设施，所以他们现在需要一个混合云战略。他们需要弄清楚如何在这个基础设施中通用地执行安全性和其他功能，而不会将自己锁定在特定的公共云中。
所以这是下一个重大挑战：谁将成为多云和云原生的不可知层，就像 VMware 一样？谁将成为云原生的 VMware？
我认为，如果你想吸引现代应用程序团队，并能够快速进入市场，你需要为他们提供云原生基础设施。
尽管对于早期采用云原生的现代网络公司来说，采用云原生可能相对容易，但从您的角度来看，挑战在于构建新技术来弥合这个现代世界与现有企业工具和系统之间的差距？
困难的部分是现代应用程序团队习惯于让基础设施层与他们一样快地发展。这迫使基础设施层更加可编程，更加可调。这就是为什么我们实际上在云网络层之上看到了网络层和安全层。但现在我们有企业进来，我们看到仍然连接到旧世界并谈论 MPLS、VLAN、sFlow 和 NetFlow 的非常强烈的需求——整个现有的企业需求集。它们都没有消失，所有的合规规则仍然相同。甚至一些现代 SaaS 公司现在也面临着这些挑战，因为它们变得越来越大，并且他们关心合规性等等。
从技术的角度来看，它是关于如何将新的云原生世界与现有的企业需求联系起来。因为很多这些问题都被公共云提供商隐藏了。公共云提供商解决了合规性问题，但他们没有开源或发布任何内容；他们自己解决了这个问题。它是云价值的一部分。如果企业不想将自己锁定在公共云产品中，他们现在需要重建并购买它。
您认为下一波云原生创新来自哪里？它仍然来自像谷歌这样的公司，还是有一种新型的公司引领潮流？
这很有趣。我会说它可能不是来自谷歌和 Facebook。创新的源泉将是开源的，推动需求的客户和用户将是比超大规模企业低一级的公司——已经相当大的公司仍然具有高度的颠覆性，如 Adobe、Shopify 或 GitHub。但也有可能被技术颠覆的公司，如金融服务、保险提供商和电信公司。这些公司都对使用可重复的开发和基础架构模型标准化基础架构有着共同的兴趣。
Kubernetes、网络和寻找云原生的 VMware 的帖子首先出现在Future上。
原文： https://future.com/kubernetes-networking-and-finding-the-vmware-of-cloud-native/