RSS

HelmにおけるgRPC

Brian Hardock (DEIS のソフトウェアエンジニア、DEIS、Helm プロジェクトに取り組んでいる) | ゲスト投稿

Helm は Kubernetes のパッケージマネージャーです。Helm は、ユーザーに分散アプリケーションの管理とデプロイメントの制御のためのカスタマイズ可能なメカニズムを提供します。

私は、コアコントリビューターとして、素晴らしいオープンソースの Kubernetes Helm コミュニティの一員であるという幸運に恵まれています。Helm チームで働き始めた最初の日、私たちは次世代 Helm のアーキテクチャのプロトタイピングに費やしました。その日の終わりまでには、Helm とそのクラスター内サーバーコンポーネントである Tiller との間の通信を可能にするために使用される、初期の RPC プロトコルデータモデルを調達しました。

私たちは、gRPC がデフォルトで使用するシリアライゼーションおよび無線送信のためのフレームワークであるプロトコルバッファを、データ定義言語として選択しました。Helm チームとの最初のハッキングの日の終わりまでには、gRPC とプロトコルバッファは強力な組み合わせであることが証明されました。protobuf ファイルと生成された gRPC コードから、Helm クライアントと Tiller サーバー間の通信を正常に達成することができました。個人的な好みとして、protobuf ファイルと生成された gRPC コードは、Swagger のようなものと比較して、美的でほぼ自己文書化される開発者体験を提供することがわかりました。

数日以内に、Helm チームはユーザー向けの機能をスコープし、実装していました。gRPC/Proto を選択することで、API モデリングと定型的なサーバーコードの作成から必然的に生じる、典型的な時間のかかる議論を減らすことができました。もし初日から gRPC/protobuf の利点を享受していなければ、ユーザーや彼らが要求した機能に焦点を当てるのではなく、スタックの上下をピボットするのにかなりの時間を費やしたでしょう。

Helm/Tiller 通信プロトコルとしての機能に加えて、プロトコルバッファの興味深い応用例の1つは、Kubernetes 用語で「Chart」と呼ばれるものをモデル化するために使用していることです。Chart は、Kubernetes マニフェストのカプセル化であり、Kubernetes アプリケーションを定義、インストール、およびアップグレードできるようにします。より複雑な Kubernetes アプリケーションの場合、マニフェストのセットは大きくなる可能性があります。その固有の圧縮機能により、プロトコルバッファと gRPC は、かさばって散らばった Kubernetes マニフェストの送信という面倒を軽減することを可能にしました。

詳細については、

要約すると、protobuf と gRPC は Helm に以下を提供しました。

  • クライアントとサーバーの通信のための、明確に定義されたメッセージとプロトコルのセマンティクス。
  • 定型的なサーバーコード/API モデリングに費やす時間を削減することによる、機能開発の増加。
  • 生成されたコードと圧縮による、データ的高速伝送。
  • クライアント/サーバー通信のゼロから開始するまでの認知サイクルを最小限に抑えました。
ページのソースを表示 このページを編集 子ページを作成 ドキュメントの課題を作成 プロジェクトの課題を作成