Google Kubernetes Engine 環境でのサービスのトラブルシューティング例

※この投稿は米国時間 2021 年 2 月 27 日に、Google Cloud blog に投稿されたものの抄訳です。

アプリケーションの失敗やコンテナの障害は避けられません。SRE チームや DevOps チームのメンバーは、この事実を十分に理解しています。このような面倒な問題をうまく切り抜けることができるように、過去のブログでは Google Kubernetes Engine（GKE）環境で動作しているアプリケーションをデバッグする方法を説明しました。GKE ダッシュボードが更新され、新しく使いやすいトラブルシューティング フローも追加されました。今回はさらに一歩進んで、これらのフローを活用してアプリケーションやインフラストラクチャの問題をすばやく見つけて解決する方法をご説明します。

このブログでは、サンプルアプリをクラスタにデプロイし、コンテナの再起動が確認された場合に通知を出すアラート ポリシーを設定する手順について解説していきます。そこから、アラートをトリガーし、新しい GKE ダッシュボードで問題を簡単に特定して、問題を引き起こしたと思われるワークロードやインフラストラクチャで何が起きているのかを正確に特定する方法を探ります。

設定

アプリをデプロイする

この例では、2 つのエンドポイントを公開するデモアプリを使用します。1 つは / のエンドポイントで、これは単なる「hello world」です。もう 1 つは /crashme エンドポイントで、Go の os.Exit(1) を使用してプロセスを終了します。クラスタにアプリをデプロイするには、Cloud Build を使ってコンテナ イメージを作成し、GKE にデプロイします。次に、ロードバランサを使用してサービスを公開します。

サービスをデプロイしたら、実行中の Pod を確認します。

RESTARTS は各 Pod で最初はゼロであることにご注意ください。ブラウザまたは curl などのコマンドライン ツールを利用して /crashme エンドポイントにアクセスします。この時点で、次のように再起動が表示されます。

このエンドポイントに対する各リクエストによって、再起動が発生します。ただし、この操作は 30 秒ごとに 1 回よりも多く行わないでください。それよりも多く行った場合、コンテナが CrashLoopBackOff になり、サーバーが再び利用可能になるまで時間がかかります。再起動は必要に応じて、この簡単なシェル スクリプトを使ってトリガーできます。

$IP_ADDRESS は、作成したロードバランサの IP アドレスです。

では、なぜコンテナの再起動が問題になるのでしょうか。Kubernetes 環境でのコンテナの一般的なライフサイクルにおいて、ある程度の再起動は想定されます。ただし、コンテナの再起動が多すぎるとサービスの可用性に影響します。とりわけ、特定の Pod のレプリカの増大に伴って再起動が増える場合などです。過剰な再起動は、該当するサービスの質を低下させるだけでなく、そのサービスを使用して依存関係にある他のダウンストリーム サービスにも影響するというリスクがあります。

実際のところ、再起動の回数が多くなる原因として、liveness プローブの設計上の問題、アプリケーション自体におけるデッドロックなどの問題、メモリ リクエストの構成の誤りによる OOMkilled エラーなどが考えられます。そのため、コンテナの再起動に関するアラートを事前に出すことで、複数のサービスに広がる可能性のあるパフォーマンス低下を未然に防ぐことが大切です。

アラートを設定する

これで、再起動が検知された場合に通知を出すアラートを設定する準備ができました。ここでは、アラート ポリシーを設定する方法をご説明します。

kubernetes.io/container/restart_count 指標を使うと、deployment yaml ファイルで指定された特定のコンテナ名でフィルタリングできます。いずれかの時系列がゼロを超えた場合、つまりいずれかのコンテナの再起動が確認された場合に、トリガーするアラートを設定します。

設定が完了したら、テストして結果を確かめましょう。

アラートをテストする

準備ができたら、ループ スクリプトを開始して、45 秒ごとに /crashme エンドポイントにアクセスします。restart_count 指標は 60 秒ごとにサンプリングされるため、アラートがダッシュボードに表示されるまでに、それほど時間はかかりません。

インシデントにカーソルを合わせると詳細を表示できます。

次に、[インシデントを表示] をクリックします。インシデントの詳細の画面が開き、ここでインシデントをトリガーした特定のリソースを確認できます。この場合は、コンテナが原因でインシデントが生成されたことがわかります。

次に、[ログを表示] をクリックし、新しいログビューアでログを確認すると、コンテナが再起動したことでアラートがトリガーされたことが一目でわかります。

すべての関連性が非常にわかりやすく、インシデント発生時のトラブルシューティングがより簡単になります。

まとめ

最新の GKE ダッシュボードでは、これまでの反復処理に関して多くの改善が導入されました。新しいアラートのタイムラインは直感的です。明示的にマークされたインシデントを操作して、発生したインシデントの具体的な内容から、実際の問題を示すコンテナログに至るまで、あらゆる情報を得ることができます。

GKE で稼働しているサービスを担当する SRE や DevOps のエンジニアは、GKE ダッシュボードによりインシデントに対応しやすくなります。インシデントの特定からデバッグログまで、あらゆる対応を迅速かつ容易に行えるようになり、短い時間でインシデントをトリアージして軽減できるようになりました。GKE 環境でサービスのトラブルシューティングを行う方法の概要は、次の動画でご覧いただけます。