ブログ

Kubernetesにおけるトレーシング: kubectl capture plugin

Kubernetesにおけるトレーシング: kubectl capture plugin

本文の内容は、2019年4月4日にSysdigのNestor Salcedaが投稿したブログ(https://sysdig.com/blog/tracing-in-kubernetes-kubectl-capture-plugin/)を元に日本語に翻訳・再構成した内容となっております。

KubernetesクラスタでSysdigを使用してキャプチャを1つの簡単なコマンドで実行できるようにするプラグインをリリースしました。 この機能を利用するためにSysdigをクラスタにプレインストールする必要はありません。このプラグインは、皆様のKubernetesにおけるトラブルシューティングをお手伝いするための弊社からの寄与となっております。

コンテナーとそのビヘイビアに関する大量のデータが入ったキャプチャーファイルを作成し、Sysdig Inspectを使用して何らかのパフォーマンス分析やフォレンジック分析、デバッグまたはマイクロサービスはどのように動作しているかなどのポストモータムレポートを作成して学習および知識を向上させましょう。

kubectl pluginのインストール

インストールする前に、このプラグインが使えることを確認します。 以下の前提条件を確認してください:

  • 最新のkubectlバージョン(1.12.0以降)を使用。 v1.8.0リリースでプラグインは正式にアルファ機能として紹介されましたが、kubernetesにおいてプラグインを使用するために1.12.0またはそれ以降のバージョンを推奨します。
  • サポートされしているKubernetesディストリビューションを確認ください。 詳細はSysdigのドキュメントを参照ください。 kubectlプラグインでeBPFプローブビルダーのサポートすべく鋭意対応中です。

すべての前提条件を確認したら、次のステップはプラグインのインストールです。GitHubからリポジトリから取得し、プラグインファイルをPATHに配置します。下記の例では/usr/local/binに配置します。

$ git clone https://github.com/sysdiglabs/kubectl-capture.git
$ cd kubectl-sysdig_capture
$ sudo cp kubectl-capture /usr/local/bin

もしくは、wgetを利用します:

$ sudo wget https://raw.githubusercontent.com/sysdiglabs/kubectl-capture/master/kubectl-capture -O /usr/local/bin/kubectl-capture

$ sudo chmod +x /usr/local/bin/kubectl-capture
$ sudo chmod +x /usr/local/bin/kubectl-captur 

ファイルをPATHに置いたら、次のコマンドでインストールを確認できます。

$ kubectl plugin list   
The following kubectl-compatible plugins are available:


/usr/local/bin/kubectl-capture 

これでkubectlプラグインの準備ができました。

コンテナ化されたアプリケーションのトラブルシューティング

Kubernetes CrashLoopBackOffのトラブルシューティングは、Kubernetesクラスタで最も厄介なことの1つです。 多くの方々は、少なくとも一度は経験されたことでしょう。コンテナー内のトラブルシューティングツールにもアクセスできないので、本当に悪夢です。

コンテナー内のトラブルシューティングツールにアクセスできない他のアプリケーションエラーでも、同様のことが起こります。 Kubernetesクラスタには次のアプリケーションがデプロイされています。

$ kubectl get pod -n ticket-generator    
NAME                            READY   STATUS  RESTARTS   AGE
ticket-balancer-5967c66fb4-qnzj6    1/1         Running   0             6m
ticket-client-68df494585-ntqls  1/1     Running   0             6m
ticket-server-56c75bf88b-nqpcs  1/1     Running   0             6m
ticket-server-56c75bf88b-wjsw2  1/1     Running   0             6m 

デプロイ以降においてアプリケーションのモニタリング中に、お客様に問題を引き起こしているいくつかの502 HTTPエラーについて気付き始めました。

少し掘り下げると、502のエラーがいくつかのログを調べて確認できます。

$ kubectl logs -n ticket-generator ticket-client-68df494585-ntqls
...
100   107       0   107 0       0   7642        0 --:--:-- --:--:-- --:--:--  7642
% Total % Received % Xferd  Average Speed   Time        Time    Time  Current
Dload  Upload   Total   Spent   Left  Speed
<html><body><h1>502 Bad Gateway</h1>
The server returned an invalid or incomplete response.
</body></html> 

確かに502エラーが発生しています。次にロードバランサーのログをチェックして、もう少し深く掘り下げていきましょう:

$ kubectl logs -n ticket-generator ticket-balancer-5967c66fb4-qnzj6

ロードバランサからのログはありませんでした。 これによりトラブルシューティングが難しくなります。 もっと深くみて行きましょう。

$ kubectl logs -n ticket-generator ticket-server-56c75bf88b-wjsw2   
...
10.40.1.6 - - [14/Feb/2019 11:05:29] "GET /getticket HTTP/1.1" 200 -
10.40.1.6 - - [14/Feb/2019 11:05:32] "GET /getticket HTTP/1.1" 200 - 

うーん、これは奇妙です、アプリケーションから200を受け取っています。 ロードバランサ内部ので何が起きているのでしょうか。

状況は部分的にコントロールされています。デプロイメントをロールバックして前のバージョンにしてみることもできますが、ログを見るだけでは根本的な原因を特定するのに十分なデータがありません。なぜこのデプロイメントは失敗してしまうのでしょうか?502エラーのためなのか?しかし、なぜこれらのエラーが起きているのでしょうか。

kubectlプラグインを使ってデータのキャプチャを開始する

アプリケーションをより深く理解し、ロードバランサーのよくわからない部分を明確にしていくために、もっと深く掘り下げていきましょう:

$ kubectl capture ticket-balancer-5967c66fb4-qnzj6 -ns ticket-generator -M 30 --snaplen 256
Sysdig is starting to capture system calls:


Node: gke-sysdig-work-default-pool-0ed2e258-xtwv
Pod: ticket-balancer-5967c66fb4-qnzj6
Duration: 30 seconds
Parameters for Sysdig: -S -M 30 -pk -z -w /capture-ticket-balancer-5967c66fb4-qnzj6-1550246858.scap.gz  --snaplen 256


The capture has been downloaded to your hard disk at:
~/captures/capture-ticket-balancer-5967c66fb4-qnzj6-1550246858.scap.gz 

簡単な1つのコマンドで、ロードバランサに関連するすべてのアクティビティをキャプチャしました。次は、Sysdig Inspectでトラブルシューティングしていきましょう。

トレースデータの量を増やす

興味深いのは、--snaplen 256フラグです。 snaplenは各I / Oバッファの最初のバイトをキャプチャすることを可能にします。 デフォルトでは、最初の80バイトだけがキャプチャされますが、キャプチャのコンテキストがもっと必要になることがあります。 巨大なトレースファイルが生成される可能性があるため、注意して使用してください。 しかし、さらに一歩進めたい場合は、kubectlプラグインがsysdigコマンドラインユーティリティと同じパラメータを受け入れるので、このkubectl プラグインでは、フィルタを含むコマンドラインアプリケーションで使用可能なすべてのオプションを使用できます。

なにがここで起こったのでしょうか?

内部的には、kubectlプラグインは、コマンドラインで指定したポッドと同じホストで新しいポッドを開始するので、そのホストで現在起こっていることすべてを見ることができます。 Sysdigは、コンテナー内で何が起こっているのかを確認するための素晴らしいサポートも提供しています。その機能を利用していきます。

$ kubectl get pod --all-namespaces 

NAMESPACE       NAME                                                            READY   STATUS                  RESTARTS   AGE
default         capture-ticket-balancer-5967c66fb4-qnzj6-1550246858   1/1       Running   0             2m 

キャプチャは30秒の期間を指定し、ポッドが30秒よりも長い時間実行されていることを注意してください。 これは、ポッドがSysdig Kernelモジュールをビルドする必要があり、キャプチャが開始されるまで時間を要するためです。

キャプチャを使用してSysdig Inspectで分析する

Sysdig InspectはSysdigをより便利に使えるようにするオープンソースアプリケーションです。 システムコールに関する膨大な量の情報の整理方法、アクティビティの関連付け方法、およびトラブルシューティングアクティビティを簡素化します。

キャプチャが終了すると、キャプチャファイルをローカルディスクにドロップします。 ダウンロードしたキャプチャをSysdig Inspectで読み込むことができます。

そして、ロードバランサの範囲を狭めるためにコンテナでフィルタリングします。

コンテナを選択したら、I/Oストリームを開き、「Printable ASCII」を使用してやりとりを把握していきます。

これで、ロードバランサコンテナがバックエンドサーバとやり取りしていた完全なHTTPのやりとりがわかります。502エラーについての手がかりがあります。 説明していきましょう!

青い行はメッセージを送信していることを意味します、write syscall、オレンジ色の行は受信したメッセージを表します(read syscall)。 完全なやりとりを確認していくことができます:

  • 1行目: ロードバランサが502エラーを送信
  • 2行目: ロードバランサはバックエンドへのリクエストクエリを読み込みます
  • 3行目: ロードバランサはリクエストクエリをバックエンドに送信します。
  • 4行目, 5行目: ロードバランサはバックエンドからボディレスポンスを受け取ります。

根本的な原因は次のように考えられます。

  • バランサはバックエンドサーバーから応答を受け取ります。 bodyは正しいですが、ヘッダーの形式が正しくありません。 text/plain:Content-typeヘッダーは、Content-type:text/plainにする必要があります。
  • ブラウザによってはこれが無視されるため(デベロッパーのPCでは動作)、HTTPプロキシによってはこの無効なメッセージを許容できる場合がありますが、使用しているHAプロキシはこれを許容せず502 HTTPエラーを返します。
  • クライアントは502 Bad Gateway HTTPエラーを受け取ります。

結論

アプリケーションのデプロイメントで問題が発生した場合は、実際に何が起こったのかをよく理解し、修正を適用するための根本的な原因を突き止める必要があります。 マイクロサービスがどのように動作しているのかを深く理解する必要があります。Sysdigはこの作業を支援します。

キャプチャは、システムで発生したすべてのことを完全に記録し、トラブルシューティング分析のためのオープンソースGUIであるSysdig Inspectと組み合わせることで、イベントと詳細を関連付けた調査を実行して根本的な原因を発見できます。

kubectlプラグインを使用すると、Sysdig Inspectで分析するためにキャプチャを記録してローカルワークステーションにダウンロードするために必要なインフラストラクチャをセットアップするための時間と労力を大幅に節約できます。オープンソースですので、コントリビュータとフィードバックには本当に感謝致します。

ご質問・お問い合わせはこちら

top