Helm 中的 gRPC
Helm 是 Kubernetes 的包管理器。它为用户提供了可定制的机制，用于管理分布式应用程序并控制其部署。
我很幸运能成为出色的开源 Kubernetes Helm 社区的一员，担任核心贡献者。我与 Helm 团队合作的第一天，就用于原型化下一代 Helm 的架构。那天结束时，我们已经获得了初步的 RPC 协议数据模型，该模型用于实现 Helm 客户端与其集群内服务器组件 Tiller 之间的通信。
我们选择使用 protocol buffers（gRPC 用于序列化和空中传输的默认框架）作为我们的数据定义语言。在与 Helm 团队合作的第一个工作日结束时，gRPC 和 protocol buffers 被证明是一个强大的组合。我们已经成功地实现了 Helm 客户端和 Tiller 服务器之间的通信，使用的是从 protobuf 和 gRPC 服务定义生成的代码。作为个人偏好，我们发现 protobuf 文件和由此生成的 gRPC 代码提供了一种美观、几乎自文档化的开发体验，相比之下，Swagger 等工具则不然。
几天之内，Helm 团队就开始为我们的用户规划和实现功能。通过选择 gRPC/Proto，我们减少了通常花在“自行其是”（bikeshedding）上的时间，这种现象通常不可避免地源于 API 建模和编写样板服务器代码。如果我们从第一天起就没有享受到 gRPC/protobuf 的好处，我们将在技术栈的上下层之间花费更多时间进行调整，而不是专注于真正重要的事情：用户以及他们请求的功能。
除了作为 Helm/Tiller 通信协议外，我们对 protocol buffers 更有趣的应用程序之一是使用它来建模在 Kubernetes 术语中称为“Chart”的东西。Chart 是 Kubernetes manifests 的封装，使您能够定义、安装和升级 Kubernetes 应用程序。对于更复杂的 Kubernetes 应用程序，manifests 的集合可能很大。凭借其固有的压缩能力，protocol buffers 和 gRPC 使我们能够减轻传输庞大且分散的 Kubernetes manifests 的麻烦。
欲深入了解
- Helm proto，请参阅：https://github.com/kubernetes/helm/tree/master/_proto/hapi
- 其生成的对应部分，请参阅：https://github.com/kubernetes/helm/tree/master/pkg/proto/hapi
- 我们的 Helm 客户端接口，请参阅：https://github.com/kubernetes/helm/tree/master/pkg/helm
总而言之，protobuf 和 gRPC 为 Helm 提供了：
- 客户端和服务器通信清晰定义的消息和协议语义。
- 通过减少样板服务器代码/API 建模上的时间投入，加速了功能开发。
- 通过生成代码和压缩实现高性能数据传输。
- 最大限度地减少了从零开始到实现客户端/服务器通信所需的认知循环。