虚拟座谈会：Kubernetes 和 Multi-Cloud 的挑战

本文要点

Kubernetes 正在经历显著的增长，因为它解决了应用程序可移植性和部署方面的特定痛点。

• Kubernetes 已经消除了供应商锁定，并能够通过在不同的云上选择供应商的产品来实现云的可移植性。

• 以多云的方式来阐述应用程序和分布式系统模式，其中包括一些样例和案例研究。

• Kubernetes 社区如何团结起来应对多云相关的挑战。

最近在西雅图举行的 Kubecon+CloudNativeCon 2018 大会上，约有 8500 名与会者出席，可以说一票难求，从主题 演讲 到许多技术演讲都在讨论主流的云厂商所提供的各种 Kubernetes 服务。

尽管各种云供应商都有 Kubernetes 产品，每个云都试图在互补的服务中体现它们产品的差异，但 Kubernetes 社区的目标是跨 Kubernetes 产品的应用程序可移植性。然而，在在现实中，单个应用程序或解决方案能够跨多个云吗? 或者，多云（multi-cloud ）仅仅意味着组织能够处理多个云厂商吗?

InfoQ 在西雅图遇到 Kubecon 2018 大会上该领域的专家： Dr. Lew Tucker ——前思科云计算 CTO， Dr. Sheng Liang ——Rancher Labs 的首席执行官， Marco Palladino ——Kong 公司 CTO 以及 Janet Kuo ——Kubecon+CloudNativeCon 2018 联合主席和谷歌软件工程师，共同讨论 Kubernetes 和多云方面的挑战。

座谈会的参与者首先讨论了 Kubernetes 社区的增长，以及它如何支持云中的应用程序的开发和部署。他们讨论了多云的含义以及与 Kubernetes 平台和社区的协同作用。

另外，他们还讨论了一些适合于多云的分布式系统模式，包括一些 Kubernetes 相关的现有项目和案例研究。

最后，座谈会的参与者认为 Kubernetes 社区要使多云成为现实还需要解决的一些挑战，包括在项目中要解决这些挑战可能的路线图。

InfoQ：让我们从总体上谈谈 Kubernetes 社区，特别是最近结束的 Kubecon 2018。作为从一开始就参与社区和会议的成员，你们认为这种增长的原因是什么? 它将如何影响开发人员和架构师?

Lew Tucker: 是的，Kubernetes 见证了开发者和用户社区的惊人增长和扩张。作为一个开源的容器编排系统，Kubernetes 使开发人员更容易地构建和部署具有弹性和可伸缩性的应用程序，同时提供跨多个云平台的可移植性。作为第一个从云原生计算基金会（Cloud Native Computing Foundation）毕业的项目，它正迅速成为云原生应用程序的事实标准平台。
Sheng Liang：Kubernetes 之所以流行，是因为它很好地解决了一个重要的问题：如何可靠地运行应用程序。它是最好的容器编排器、集群管理器和调度器。最好的技术与运行良好的开源社区相结合，使得 Kubernetes 势不可挡。
Marco Palladino：如果不考虑颠覆性的行业趋势，即微服务和容器的兴起，就无法解释 Kubernetes 的发展。这些趋势改变了我们构建和扩展软件的方式。随着企业的不断创新，要找到扩展应用程序和团队的新方法，他们发现，让软件和组织同时实现解耦和分布式将提供一个更好的框架，最终使他们的业务也能随着时间成倍增长。因此，大型团队和大型单体应用程序被解耦并分布到较小的组件中。虽然一些公司 (Amazon、Netflix 等) 很久以前就率先进行了这种转型，并成功构建了自己的工具，但其他所有大型企业组织都缺乏实现类似转型的意愿、知识和研发能力。随着主流采用容器 (Docker，2013 年) 技术以及像 Kubernetes 这样的平台的出现 (2014 年)，世界上每个企业现在都可以通过一个新的、易于使用的自服务生态系统来实现向微服务的过渡。因此，Kubernetes 不仅推动了运行和部署软件的特定方式，而且成为了现代化架构的推动者，组织以前由于缺少 工具 而很谨慎地采用这些架构方式，现在任何组织都可以使用这些工具。不可忽视的是，Docker 和 Kubernetes，以及围绕这些平台的大多数生态系统，都是开源的——为了理解 Kubernetes 的采用，我们还必须理解企业软件的决策转变，从自上而下 (如 SOA，由供应商驱动) 到自下而上 (由开发人员驱动)。作为这些行业趋势的结果，这些趋势反过来又进一步推动了 Kubernetes 的采用，开发人员和架构师现在可以利用大型的自服务开源技术生态系统，这在五年前是前所未有的。
Janet Kuo：一个关键的原因是 Kubernetes 有一个非常强大的社区——它由一组不同的最终用户、贡献者和服务提供者组成。最终用户选择 Kubernetes 并不是因为他们喜欢容器技术或 Kubernetes，他们选择 Kubernetes 是因为它解决了他们的问题并允许他们更快地行动。Kubernetes 也是最大、最活跃的开源项目之一，有来自世界各地的贡献者。这是因为在 Kubernetes 中没有权力的集中，这就鼓励了协作和创新，而不管是否有人将 Kubernetes 作为工作的一部分或爱好。最后，世界上大多数主要的云提供商和 IT 服务提供商都采用了 Kubernetes 作为其容器编排的默认解决方案。这种网络效应使得 Kubernetes 呈指数级增长。

InfoQ：我们可以回顾一下 Java 消除供应商锁定的日子。Kubernetes 有一个类似的任务，供应商似乎在标准上合作，在实现上竞争。总体而言，消除供应商锁定可能是件好事。然而，云可移植性或多云意味着什么? 它甚至会影响到客户（不包括 Kubernetes）吗?

Tucker：抽象层通常用来隐藏底层的复杂性，随着它们成为平台，它们还提供了一定程度的系统之间的可移植性。

在早期的 Java 时代，我们谈到了“编写一次，在任何地方运行”的承诺，它减少或消除了与 Unix 或 Windows 相关的传统操作系统锁定。这一点能够实现到什么程度通常需要仔细编码，但其价值是明确的。现在，面对相互竞争的公共云供应商，我们面临着类似的情况。底层云平台是不同的，但是 Docker 容器和 Kubernetes 提供了一层抽象和跨云的高度可移植性。在某种程度上，这迫使云提供商在提供的服务上展开竞争。然后，用户可以决定他们要与该供应商锁定到什么程度，以便利用该供应商特定的服务。随着我们越来越多地转向基于服务的体系结构，预计这种正常的供应商锁定将成为常态。

Liang：虽然消除云锁定对一些客户来说可能很重要，但我不认为单纯的云可移植性产品能够成功。许多其他因素，包括敏捷性、可靠性、可伸缩性和安全性，通常更为重要。这些正是 Kubernetes 提供的一些功能。我相信 Kubernetes 最终将成为一个有效的云可移植性层，它实现云可移植性几乎是一个副作用，有点像浏览器实现设备可移植性的方式。

Palladino：作为长期战略和路线图的一部分，我们经常从组织有意识的自上而下决策的角度来看待多云。然而，现实要实际得多。大型企业组织实际上是各种团队、议程、策略和产品的集合，这些团队、议程、策略和产品恰好是同一个复杂的“多细胞”有机体的一部分。组织内的多云必然会发生，因为每个不同的团队 / 产品不可避免地会对如何构建他们的软件做出不同的决策，尤其是在软件开发的时代，开发人员自底向上领导所有主要的技术决策和试验。那些与最终用户和业务非常接近的团队将采用任何更好的技术 (和云) 来实现他们的目标并最终扩展业务。传统的中心化 IT——远离最终用户和业务，但更接近团队——将需要适应一个新的混合现实（hybrid reality），正如我们所说的，这种混合现实正在他们的底层开发。随着时间的推移，企业对已经使用不同云的产品和团队的收购也将导致更加分布式和解耦的多云组织。云计算的出现并不一定是因为组织想要这样做，而是因为它必须这样做。因此，容器和 Kubernetes(由于非常便携) 是这些实用需求的一个很好的技术解决方案。它们提供了一种在不同的云供应商 (和裸机) 之间使用半标准化的打包和部署流运行软件的方法，从而减少了运维碎片化。

Kuo：云可移植性和多云使用户可以根据业务需求为不同的应用程序选择最适合的解决方案。多云还支持更多级别的冗余。通过增加冗余，用户可以获得使用最佳技术进行构建的更大灵活性，还可以帮助他们优化操作并保持竞争力。

InfoQ: Kubernetes 在不同云上的发行版和产品将试图区分它们各自的产品，这似乎是“合作竞争”的自然过程。根据您过去在类似社区的经验，Kubernetes 社区应该避免哪些陷阱?

Tucker：为了在市场上竞争，不同的供应商自然会希望自己的产品与众不同。对于 Kubernetes 社区来说，最重要的事情是保持开源原则，并将基于供应商或基础设施的差异置于标准接口之后，以防止平台分裂成专有的变体。公共接口，如设备插件框架 (例如 GPUs) 和 CNI(容器网络接口)，将基础设施的特定差异隔离在公共 API 之后，允许供应商在提供公共层的同时进行竞争。今天的供应商在如何提供托管的 Kubernetes 方面也有所不同。这是在平台之外的，保留了完整的 Kubernetes API，这仍然需要让用户决定是否在部署模型中采用供应商管理框架。
Liang：用户社区应该避免应用程序只能与特定的 Kubernetes 一起工作的特性。现在很容易从各种提供商中建立 Kubernetes 集群。在创建 YAML 文件或 Helm chart 以将应用程序部署到您选择的发行版上之后，您还应该在 GKE 或 EKS 集群上尝试相同的 YAML 文件或 Helm chart。
Palladino：社区应该警惕任何云供应商暗示的“拥抱、扩展、消灭”策略，长期来看，这种策略将分裂 Kubernetes 和社区，并为“统治所有人”的新平台铺平道路。
Kuo：分裂是 Kubernetes 社区应该共同努力避免的。否则，最终用户就无法在不同的平台上获得一致的行为，从而失去了可移植性和选择的自由——这正是 Kubernetes 最初吸引他们的地方。为了满足谷歌首先确定的这一需求，Kubernetes 社区在一致性方面投入了大量资金，以确保每个服务提供者的 Kubernetes 版本都支持所需的 API，并为最终用户提供一致的行为。

InfoQ：你能不能介绍一些显而易见的分布式系统或应用程序模式，使其适合于多云的 Kubernetes？它是微服务吗?

Tucker：基于微服务的架构非常适合 Kubernetes。但是，当把单体的应用程序分解成一组单独的服务时，我们现在引入了依赖于各部分之间通信的分布式系统的复杂性。这并不是每个应用程序开发人员已经准备好的。服务网格，如 Istio，似乎是 Kubernetes 的自然补充。它们承载了许多网络和流量管理功能，使应用程序开发人员不必担心服务认证、加密、密钥交换、流量管理等问题，同时提供统一的监视和可见性。
Liang：虽然微服务显然适合多云 Kubernetes，但是遗留部署架构也适合。例如，我们的一些客户部署了用于灾难恢复的多云 Kubernetes。一个云中应用程序的失败不会影响另一个云中相同应用程序的功能。另一个用例是地理复制。为了地理上的接近，我们的一些客户将相同的应用程序部署在多个云中的许多不同区域。
Palladino：微服务是一种模式，它为我们的体系结构需求增加了很大的额外价值，因为它导致了更多的可移动部件和更多的网络操作——管理一个整体是一个 O(1) 问题，而管理微服务是一个 O(n) 问题。Kubernetes 一直是管理微服务的非常成功的平台，因为它提供了有用的原语，可以利用这些原语来自动化大量的操作，从而能够从权衡中移除一些 (如果不是大部分)“微服务的额外代价”。API 平台的出现与 Kubernetes 原语 (如 sidecar 和 ingress 代理) 紧密集成，也使得构建网络密集型、解耦和分布式架构变得更加容易。也就是说，任何应用程序都可以从运行在 Kubernetes(包括单体应用) 上获益。通过让 Kubernetes 作为多个云供应商之上的底层抽象层运行，团队现在可以全面地整合操作关注点——比如分发和部署应用程序——而不必担心每个云供应商的细节。
Kuo：微服务是最著名的模式之一。Sidecar 模式将现代应用程序的日志、监视和网络等功能集成到应用程序中也非常重要。代理模式对于简化应用程序开发人员的生活也很有用，这样编写和测试他们的应用程序就容易得多，而不需要处理微服务之间的网络通信，这是服务网格解决方案 (如 Istio) 经常使用的方法。

InfoQ：新兴的服务网格模式是如何实现多云平台的呢（如果有的话）?

Tucker：我相信随着技术的成熟，基于 kubernets 的微服务和服务网格架构的应用将会越来越流行。下一步自然是服务网格连接运行在不同云上的多个 kubernetes 集群。多云服务网格将使开发人员更容易将来自不同提供者的最佳组件和服务组合到单个应用程序或服务中。
Liang：新兴的服务网格模式为多云 Kubernetes 的部署增加了很多价值。当我们在多个云中部署多个 Kubernetes 集群时，同一个 Istio 服务网格可以跨越这些集群，为应用程序提供统一的可见性和控制。
Palladino：向微服务的过渡意味着在我们试图连接的服务之间更频繁地使用网络。我们都知道，即使在私有组织的网络中，网络也会被认为不可靠和不可信任。服务网格是一种模式，它试图通过提供一些功能 (通常部署在与我们的服务一起运行的 sidecar 代理中) 来使我们原有的不可靠的网络再次变得可靠，这些功能支持可靠的服务到服务通信 (如路由、断路器、健康检查等)。根据我在大型企业组织的工作经验，实现跨产品的服务网格，通过帮助跨不同的区域和数据中心路由工作负载，以及在跨不同的云和区域强制服务之间进行安全通信，该模式可以帮助实现多云。
Kuo：容器编排对于运行分布式应用程序来说是不够的。用户需要工具来管理这些微服务及其策略，他们希望这些策略与服务分离，以便能够独立于服务更新策略。这就是服务网格技术发挥作用的地方。服务网格模式是平台独立的，因此可以在云之间和跨混合基础设施构建服务网格。目前已经有几个开源的服务网格解决方案可用。Istio 是最流行的开源服务网格解决方案之一。Istio 为分布式服务提供了可见性和安全性，并确保开发和操作之间的解耦。与 Kubernetes 一样，用户可以在任何合适的地方运行 Isio。

InfoQ：供应商和客户通常会跟踪资金流向。您能具体谈谈 Kubernetes/ 云计算所涉及的客户成功案例或案例研究吗?

Liang：Rancher 2.0 之所以获得巨大的市场成功，正是因为它能够跨多个云管理多个 Kubernetes 集群。一家跨国媒体公司，使用 Rancher 2.0 来管理 AWS、Azure 和内部 vSphere 集群中的 Kubernetes 集群。他们的 IT 部门能够根据需求控制将应用程序部署在哪个云上。在另一个案例中，全球第三大风力涡轮机制造商金风公司 (Goldwind) 使用 Rancher 2.0 在中央数据中心和安装风力涡轮机的数百个边缘位置管理多个 Kubernetes 集群。

Palladino：我有幸与大型企业组织密切合作，看到这些组织正在努力克服实用性的挑战。特别是 Kong 的一个大型企业客户，由于过去几年公司进行了大量的收购，决定在 Kubernetes 之上迁移到多云。每一次收购都将使新的团队、产品和体系结构处于上级组织的管理之下，随着时间的推移，您可以想象在组织中使用如此多的碎片来发展现有的团队是多么困难。因此，组织决定标准化应用程序的打包 (使用 Docker) 和执行 (使用 Kubernetes) 方式，以简化所有团队的操作。尽管有时非常相似，但不同的云供应商实际上提供了一组不同的服务，具有不同的质量和支持，而且事实证明，某些云在某些场景下比其他云更好。因此，组织中运行的许多应用程序也运行在不同的云上，这取决于它们实现的服务，在决定采用 Kubernetes 时，公司已经是一个多云的现实。为了降低应用程序和这些产品从每个云供应商实现的特定服务之间的延迟，他们还决定启动一个多云 Kubernetes 集群。这绝不是一项简单的任务，但保持事物碎片化的成本要高于将其架构现代化以更好地进行长期扩展的成本。在大型企业中，这完全是跟可扩展性相关的——不仅仅是技术上的，还有组织和操作上的。

Kuo： Kubernetes 的案例研究 涵盖了各种各样的客户成功案例。实际上，我最喜欢的是最古老的游戏之一，它讲述的是《口袋妖怪 Go》(Pokemon Go，一款在发布后就迅速走红的手机游戏) 是如何 在 Kubernetes 之上运行 的。Kubernetes 允许游戏开发者在为全球数百万玩家提供服务的同时部署实时更改。看到大规模生产 Kubernetes 集群的真实用例，人们感到惊讶和兴奋。今天，我们已经了解了更多的 Kubernetes 客户成功故事——比如我们刚刚在 KubeCon 大会主题演讲上从 Uber 和 Airbnb 上听到的故事。多样化和令人兴奋的用例现在是社区中的规范。

InfoQ：从单个项目或解决方案的角度来看，不同的组件或服务驻留在多个云中是否可行? 在 Kubernetes 真正成为多云之前，需要解决的主要技术挑战 (如果有的话) 是什么?

Tucker：是的。除了 Kubernetes API 之外，关于专用联邦 API 的工作已经在进行中 (参见 Kubernetes 和 GitHub )。这种方法并不局限于驻留在同一云提供商上的集群。但是，它仍然处于非常早期的阶段，除了明显的问题 (如延迟增加和不同的云服务 API) 之外，许多实用的问题仍在讨论中。

Liang：是的。许多 Rancher 客户实现了这个部署模型。我们正在 Rancher 中开发一些新特性，以改善多云体验。1) 协调部署在多个云中的多个集群中的应用程序的机制。2) 整合全局负载均衡器和 DNS 服务器，实现流量重定向。3) 不同集群 pod 之间的通道网络流量机制。4) 跨多个集群复制存储的机制。

Palladino：跨多个 Kubernetes 集群的联合，这是一个控制平面 API，可以帮助运行多个集群和安全性 (用户和策略)。跨多个集群同步资源也是一个挑战，同时还要具有全面的可观察性。其中一些问题可以通过采用第三方集成和解决方案来解决，但是如果 Kubernetes 在这个方向上提供更多开箱即用的支持就好了。实验性的 Kubernetes 联邦 API 已经有了一个 alpha 版本，但遗憾的是，它还不够成熟，不能用于生产 (存在已知 问题 )。

多云 Kubernetes 类似于同时管理独立的 Kubernetes 集群。整个发布生命周期 (打包、分发、测试等等) 需要应用到所有集群应用并且要进行同步 (或基于可配置条件的少数集群)，同时还有一个中心化的平面来监控整个系统的运维状态。跨多个集群的应用程序和用户安全性也变得更具挑战性。在运行时，我们可能希望在一个集群和另一个集群之间强制执行多区域路由 (用于故障转移)，这也意味着引入更多的技术 (和数据平面开销) 来管理这些用例。我们通常在单个集群中使用的所有功能，如 CI/CD、安全性、审计、应用程序监视和警报，都必须在多集群、多云环境中重新考虑——不仅在运维方面上，在组织上同样如此。

Kuo: Kubernetes 已经很好地抽象了底层基础设施层，因此云提供商服务 (如网络和存储) 只是 Kubernetes 中的资源。然而，在多云环境下运行 Kubernetes 时，用户仍然面临很多冲突。需要解决的技术挑战包括不同区域和云之间的连接、灾难发现、日志记录和监视。我们需要提供更好的工具来实现无缝的用户体验，社区致力于提供这些资源。

InfoQ：您能不能简要地谈一谈一些尚未成为主流的产品或技术，这些产品或技术可能有助于解决我们到目前为止一直在讨论的一些问题，从而简化在多云上的开发和部署?

Liang：我们的旗舰产品 Rancher 是专门为管理横跨多个云的多个 Kubernetes 集群而设计的。

Palladino：像 Kong 这样的开源产品可以通过提供一个可以与不同平台和体系结构集成的混合控制平面，并且使大型遗留应用程序能够从一开始就被解耦和分发，从而帮助我们跨多云部署的服务在安全性、可观察性和流量控制方面得到强化。像 CNCF 这样的开源生态系统还提供了各种各样的工具，帮助开发人员和架构师应对企业不可避免地要处理的多云和混合架构的新挑战 (单体、SOA、微服务和无服务器)。随着系统规模的增加，通过利用现有技术而不是重新发明轮子来避免关键功能 (如安全性) 的碎片化是非常重要的。开源再次引领了这一趋势，它提高了开发人员的生产力，同时为整个组织创造了商业价值。

Kuo：我看到的一个常见模式是使用 Kubernetes API 管理所有东西。为此，您很可能需要定制 Kubernetes API，例如使用 Kubernetes CustomResourceDefinition 。许多围绕 Kubernetes 构建的技术，如 Istio，都严重依赖于这个特性。Kubernetes 开发人员正在改进自定义 Kubernetes API 特性，以便更容易地构建用于多云开发和部署的新工具。

InfoQ：最后一个问题。总结一下，您认为 Kubernetes 社区的发展方向是什么? 在定义路线图时，多云有多重要? 关于 Kubernetes 和 Kubecon，还有其他开发人员和架构师应该关心的想法吗?

Tucker：大多数用户调查显示，公司不止使用一个云供应商，通常包括公共云和私有云。所以多云是一个既成的事实。因此，Kubernetes 为跨云的应用程序可移植性提供了一个重要的公共平台。然而，计算机发展的历史表明，我们在不断地构建抽象层。因此，当我们考虑多云时，可能我们真正要达到的是其他的“平台”，比如无服务器的，或者构建在 kubernetes 之上的纯基于服务的架构。
Liang：多云一开始是 Kubernetes 的一个很好的优点。我相信当人们计划部署 Kubernetes 时，多云是一个核心需求。该社区正在许多领域改进对多云的支持：Kubernetes 一致性、SIG 多集群和联邦。我对这些努力的方向感到非常兴奋。如果您对 Kubernetes 的多云支持感兴趣，我鼓励您查看这些项目。
Palladino: Kubernetes 和容器使整个组织能够对其架构进行现代化，并扩展其业务。因此，Kubernetes 很适合成为任何现代工作负载的未来基础设施。随着越来越多的开发人员和组织将 Kubernetes 部署到生产环境中，该平台将变得越来越成熟，能够处理以不同配置 (包括多云) 运行的大量工作负载。随着具有非常独特的需求和环境的产品和团队数量的不断增长，要想继续取得成功，每个组织都应该为多云这一真实和实用的主题进行规划。就像多细胞生物一样，现代企业将不得不适应多云世界，以便不断构建可伸缩和高效的应用程序，最终向最终用户交付业务价值。
Kuo: Kubernetes 社区为云提供商带来了一个特殊的利益团体，确保 Kubernetes 生态系统以一种对所有云提供商都中立的方式发展。我已经看到许多 Kubernetes 用户选择 Kubernetes 是为了使用云计算。我认为，出于同样的原因，更多的企业用户将加入 Kubernetes 社区。

结论

座谈会成员讨论了他们自己与 Kubernetes 社区的个人经验，以及它如何支持云开发和部署。所有小组成员的结论都是，Kubernetes 已经消除了供应商锁定，并通过不同云上的产品选择实现云可移植性。然而，他们也认识到，多云并不仅仅意味着多云上的公共平台。

座谈会成员讨论了 Kubernetes 社区的实用方法，以真正的开源方式和社区方式解决与应用程序开发和部署相关的特定痛点。这种社区方法不太可能陷入“拥抱和扩展”的危险中，这在过去是许多项目的祸根。

最后，在 Kubernetes 及其路线图如何发展为真正的多云的背景下，座谈会成员讨论了应用程序模式，如服务网格、Istio 等。

座谈会成员简介

Lew Tucker，思科系统前副总裁 / 首席技术官，曾担任云原生计算、OpenStack 和 Cloud Foundry 基金会的董事会成员。他在高科技行业有超过 30 年的经验，从分布式系统和人工智能到软件开发和并行系统架构。在思科之前，Tucker 是 Sun Microsystems 的云计算副总裁 / 首席技术官，负责 Sun 云平台的开发。他也是 JavaSoft 执行团队的一员，创建了 Java .sun.com，并帮助将 Java 引入开发人员的生态系统。Tucker 在康奈尔大学医学院 (Cornell University Medical school) 从事神经生物学工作后进入科技行业，并获得了计算机科学博士学位。

Marco Palladino是旧金山的一位发明家、软件开发者和互联网企业家。作为 Kong 的首席技术官和联合创始人，他是 Kong 的合著者，负责公司产品的设计和交付，同时在 Kong 和外部软件社区内提供 API 和微服务方面的技术思想领导。在此之前，Marco 于 2010 年与他人共同创立了 Mashape，成为全球最大的 API 市场，并于 2017 年被 RapidAPI 收购。

Janet Kuo是谷歌 Cloud 的软件工程师。自 2015 年以来，她一直担任 Kubernetes 项目维护者。她目前担任 KubeCon + CloudNativeCon 联合主席。

Sheng Liang是 Rancher Labs 的联合创始人兼首席执行官。Rancher 开发了一个帮助组织采用 Kubernetes 的容器管理平台。此前，Sheng Liang 是 Citrix 平台的首席技术官， 也是 Cloud.com （被 Citrix 收购）的首席执行官和创始人