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