GKE 上で gRPC サーバーのヘルスチェックを実施
Google Cloud Japan Team
※この投稿は米国時間 2020 年 11 月 12 日に、Google Cloud blog に投稿されたものの抄訳です。
gRPC は Cloud Native Computing Foundation がホストする高性能なオープンソース RPC フレームワークです。GKE のお客様には、多くの場合マイクロサービスの作成に好んで使用されています。gRPC で構築したサービスでは、クライアントとサーバー側の実装言語を問わない効率的な相互通信が可能なためです。
ただし、Kubernetes はネイティブでは gRPC のヘルスチェックをサポートしないため、grpc-health-probe という名前のオープンソース プロジェクトを開発、リリースいたしました。gRPC サーバーのヘルスチェックを行うコマンドライン ツールであるこのプロジェクトは、これまで 180 万回ダウンロードされています。
この記事では、Kubernetes クラスタ（Kubernetes Engine など）上で動作する gRPC サーバーをヘルスチェックするためにカスタム開発されたツールの必要性についてご説明します。
Kubernetes 上の gRPC ヘルスチェックのケース
Kubernetes はマイクロサービスを実行し、gRPC はマイクロサービスの通信によく使用されるため（また、gRPC と Kubernetes が両方とも CNCF のプロジェクトであるため）、Kubernetes はネイティブにヘルスチェック用の gRPC プロトコルをサポートすると思われがちですが、実はそうではありません。
Kubernetes は、Pod の readiness や liveness を表明するために、以下のヘルスチェック用メソッドをネイティブにサポートします。
TCP ソケット オープン
HTTP GET リクエスト
コンテナ内でのバイナリ実行
gRPC のトランスポート層には主に HTTP/2 スタックが使用されますが、Kubernetes の「httpGet」プローブを使用して gRPC リクエストを作成することができません。そのため、Kubernetes に gRPC ヘルスチェックを追加するという提案もありました。しかしながら現在、他の RPC フレームワーク（Apache Thrift など）に対しても同等のスタンスを維持し、Kubernetes ヘルスチェックでどれかひとつをネイティブにサポートしない立場を取っているため、
当面の間 Kubernetes で gRPC ヘルスチェックがネイティブにサポートされることはありません。カスタム開発されたツールをお使いいただくか、独自開発が必要です。
gRPC サーバーの「健全性」の意味とは
通常 Google のすべてのマイクロサービスは z-pages（/healthz など）という一連のよく知られたエンドポイントに接続しています。これは、特にフリート全体のヘルスチェックの標準化に役立ちます。ただし、gRPC サーバーにヘルスチェック用のエンドポイントが付属しているわけではないため、
gRPC コアが、gRPC のすべての言語実装で配布する形でヘルスチェック プロトコルを提供しています。このプロトコルを実装するには、こちらのヘルスサービスをご利用のサーバーに登録して、rpc Check(HealthCheckRequest) returns (HealthCheckResponse) メソッドを実装し、サービスのステータスを反映させてください。
プロトコルが gRPC サービスに実装されると、/grpc.health.v1.Health/Check パスが追加され、外部ツール（または Kubernetes 自身）が、サーバーが健全かどうかを診断するためのクエリを実行できるようになります。
grpc_health_probe のご紹介
上記の問題に対処するために、Google は grpc_health_probe というオープンソースの小規模なコマンドライン ユーティリティをリリースしました。これは、gRPC ヘルスチェック プロトコルを使用して、サービスの健全性に関するクエリを実行し、ステータスを出力後、診断結果を示す成功またはエラーコードを表示して終了するものです。
grpc_health_probe はすでに 180 万回以上ダウンロードされており、gRPC をスタックの一部に使用する多くの企業の本番環境で使用されています。これには Google も含まれます。
このコマンドライン プローブツールを健全なサーバーで使用するとステータスが表示され、以下の成功を示すゼロのステータス コードが返されます。
ただし、フリーズ状態など動作に問題のあるサーバーの場合はレスポンスが異なり、以下のようなゼロ以外の終了コードを表示して終了する場合があります。
grpc_health_probe は、Kubernetes で使用するために設計されています。ヘルスチェックに統合するには、コンテナの Linux 名前空間で定期的にバイナリを実行する exec プローブを使用します。つまり、このプローブはループバック インターフェース（localhost）上で動作する gRPC サーバーにクエリを実行できるということです。
結果として、grpc_health_probe を Kubernetes マニフェストに統合するには、gRPC サーバーのコンテナ イメージでバイナリをバンドルし、マニフェストで以下のような「exec」プローブを構成する必要があります。
まとめ
Kubernetes は gRPC サーバーのヘルスチェックをネイティブにサポートしませんが、標準のプローブツールをコンテナ イメージにバンドルして exec プローブ経由で呼び出すことで、ヘルスチェックを簡単に行えます。
また当然のことながら、この方法を Kubernetes を基盤とした Knative や Cloud Run for Anthos などの他のコンピューティング環境のヘルスチェックにも活用できます。
プローブ バイナリを実行する代わりに、同じサーバー プロセス内で Vanilla HTTP を使用して独自の /healthz エンドポイントを実装できます。また、Kubernetes httpGet プローブを使用することも可能です。これをさらに簡単に行える Go などの言語もありますが、他の言語の場合は、Vanilla HTTP サーバーを実行するサイドカー コンテナを作成して、同じ Pod 内の gRPC サーバーにクエリを実行できます。また、httpGet プローブの併用も可能です。
grpc-health-probe プロジェクトの作成に至った理由の詳細は、以下の記事リンクをご覧ください。また、ご質問などございましたら、お気軽に Twitter でお声がけください。
関連情報:
-シニア デベロッパー アドボケイト Ahmet Alp Balkan
