Google Cloudとコンテナの継続的なセキュリティ
本文の内容は、2019年4月4日にSysdigのNestor Salcedaが投稿したブログ(https://sysdig.com/blog/tracing-in-kubernetes-kubectl-capture-plugin/)を元に日本語に翻訳・再構成した内容となっております。
KubernetesクラスタでSysdigを使用してキャプチャを1つの簡単なコマンドで実行できるようにするプラグインをリリースしました。 この機能を利用するためにSysdigをクラスタにプレインストールする必要はありません。このプラグインは、皆様のKubernetesにおけるトラブルシューティングをお手伝いするための弊社からの寄与となっております。
コンテナーとそのビヘイビアに関する大量のデータが入ったキャプチャーファイルを作成し、Sysdig Inspectを使用して何らかのパフォーマンス分析やフォレンジック分析、デバッグまたはマイクロサービスはどのように動作しているかなどのポストモータムレポートを作成して学習および知識を向上させましょう。
インストールする前に、このプラグインが使えることを確認します。 以下の前提条件を確認してください：
すべての前提条件を確認したら、次のステップはプラグインのインストールです。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 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
簡単な１つのコマンドで、ロードバランサに関連するすべてのアクティビティをキャプチャしました。次は、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をより便利に使えるようにするオープンソースアプリケーションです。 システムコールに関する膨大な量の情報の整理方法、アクティビティの関連付け方法、およびトラブルシューティングアクティビティを簡素化します。
キャプチャが終了すると、キャプチャファイルをローカルディスクにドロップします。 ダウンロードしたキャプチャをSysdig Inspectで読み込むことができます。
そして、ロードバランサの範囲を狭めるためにコンテナでフィルタリングします。
コンテナを選択したら、I/Oストリームを開き、「Printable ASCII」を使用してやりとりを把握していきます。
これで、ロードバランサコンテナがバックエンドサーバとやり取りしていた完全なHTTPのやりとりがわかります。502エラーについての手がかりがあります。 説明していきましょう！
青い行はメッセージを送信していることを意味します、write syscall、オレンジ色の行は受信したメッセージを表します（read syscall）。 完全なやりとりを確認していくことができます：
根本的な原因は次のように考えられます。
アプリケーションのデプロイメントで問題が発生した場合は、実際に何が起こったのかをよく理解し、修正を適用するための根本的な原因を突き止める必要があります。 マイクロサービスがどのように動作しているのかを深く理解する必要があります。Sysdigはこの作業を支援します。
キャプチャは、システムで発生したすべてのことを完全に記録し、トラブルシューティング分析のためのオープンソースGUIであるSysdig Inspectと組み合わせることで、イベントと詳細を関連付けた調査を実行して根本的な原因を発見できます。
kubectlプラグインを使用すると、Sysdig Inspectで分析するためにキャプチャを記録してローカルワークステーションにダウンロードするために必要なインフラストラクチャをセットアップするための時間と労力を大幅に節約できます。オープンソースですので、コントリビュータとフィードバックには本当に感謝致します。