RSS

Helm 中的 gRPC

Helm 是 Kubernetes 的包管理器。Helm 为用户提供了一种可自定义的机制,用于管理分布式应用程序并控制其部署。

我很幸运能够成为杰出的开源 Kubernetes Helm 社区的成员,并担任核心贡献者。我与 Helm 团队合作的第一天,就在为下一代 Helm 的架构制作原型。在当天结束时,我们获得了初步的 RPC 协议数据模型,该模型用于启用 Helm 与其集群内服务器组件 Tiller 之间的通信。

我们选择使用协议缓冲区(gRPC 用于序列化和空中传输的默认框架)作为我们的数据定义语言。在与 Helm 团队进行黑客马拉松的第一天结束时,gRPC 和协议缓冲区被证明是一个强大的组合。我们已成功使用从 protobuf 和 gRPC 服务定义生成的代码实现了 Helm 客户端和 Tiller 服务器之间的通信。作为个人偏好,我们发现与 Swagger 之类的东西相比,protobuf 文件和生成的 gRPC 代码提供了美观的、几乎是自我记录的开发者体验。

几天之内,Helm 团队就在为我们的用户确定范围和实现功能。通过选择 gRPC/Proto,我们减少了通常用于讨论 API 建模和生成样板服务器代码的时间。如果我们没有从第一天就享受到 gRPC/protobuf 的好处,那么我们将花费更多的时间在堆栈中上下切换,而不是专注于重要的事情:用户及其要求的功能。

除了作为 Helm/Tiller 通信协议之外,我们的协议缓冲区更有趣的应用之一是我们使用它来建模 Kubernetes 术语中所谓的“Chart”。Chart 是 Kubernetes 清单的封装,使您能够定义、安装和升级 Kubernetes 应用程序。对于更复杂的 Kubernetes 应用程序,清单集可能很大。凭借其固有的压缩功能,协议缓冲区和 gRPC 使我们能够减轻传输庞大而杂乱的 Kubernetes 清单的麻烦。

要深入了解

总而言之,protobuf 和 gRPC 为 Helm 提供了

  • 客户端和服务器通信的明确定义的消息和协议语义。
  • 通过减少花费在样板服务器代码/API 建模上的时间来增加功能开发。
  • 通过生成的代码和压缩实现数据的高性能传输。
  • 最大程度地减少了从 0 到客户端/服务器通信所花费的认知周期。