Helmのインストール

KubernetesのパッケージマネージャーであるHelmを使用してSysdigエージェントをインストールします。

Helmをダウンロードして解凍します:

curl -Lo /tmp/helm-linux-amd64.tar.gz https://storage.googleapis.com/kubernetes-helm/helm-v2.13.1-linux-amd64.tar.gz tar zxf /tmp/helm-linux-amd64.tar.gz -C /tmp/

We make the binary executable, and place it in the path:

chmod a+x /tmp/linux-amd64/helm sudo mv /tmp/linux-amd64/helm /usr/local/bin

最後に、Helmを初期化し、Tiller（Helmサーバー側コンポーネント）をインストールして、チャートデータベースが最新であることを確認します:

kubectl create -f helm-account.yaml helm init --service-account tiller helm repo update

次のコマンドを使用して、クラスターの現在のステータスを表示できます kubectl get pod -n kube-system

Sysdigエージェントのインストール

tiller podが実行されると、Sysdigエージェントは簡単なコマンドしか必要ないため、数秒でデプロイできます： helm install --name sysdig --set sysdig.accessKey=YOUR_OWN_ACCESS_KEY,sysdig.settings.tags="cluster:training" sysdiglabs/sysdig

コマンドをコピーした後、マウスの右ボタンを使用してコマンドをターミナルに貼り付けることができます。 自身のアクセスキーを使用する必要があることを忘れないでください。

これにより、Sysdigエージェントポッドが各ノードにデプロイされ、実行中のコンテナを監視できるようになります。

sysdigエージェントがデプロイされていることがわかります:

helm list

コンテナの作成には少し時間がかかる場合があります。すべてのコンテナがRunningの状態であることを確認します

kubectl get pods

この投票アプリは Kubernetes deployments 内のすべてのマイクロサービスをインストールおよび管理する Kubernetes namespaceです.

ホームディレクトリには、kubectlをラップしてアプリケーションを作成、ストレス、スケーリング、破棄するスクリプトが含まれています。

アプリケーションをデプロイするには、実行するだけです:

./create.sh

コンテナイメージがプルされ、すべてのコンテナが作成されるまで、しばらく時間がかかります。すべてのポッドがRunningの状態になったら、完了したことを確認できます：

kubectl get pods -n example-voting-app

これで投票アプリの準備が整いました。example-voting-appnamespaceにはさまざまなデプロイメントが含まれています：

• voterはランダムに投票を発行するHTTPクライアントです。時々、それは犬と猫に投票します。
• voteは、投票を収集して高速のメモリ内データベースに保存するHTTPサーバーです。
• workerは2つのデータベース間でデータを同期します。1つはメモリにデータを保存し、もう1つはディスクの永続性を提供します。
• resultは結果を報告するHTTPサーバーです。
• observerは結果を取得するHTTPクライアントです。
• dbはvoteによって収集された投票を永続化するデータベースです。

Sysdig Monitorにログインすると、Exploreタブが表示されます。このビューは、インフラストラクチャー内のさまざまなリソースまたはエンティティをグループ化できるインベントリの概要を提供します。

デフォルトでは、Sysdigモニターは1時間の時間枠でライブデータを表示します。このワークショップでは、（ウィンドウの下部にある）時間枠ナビゲーションバーを使用して、10秒などの短い時間枠を選択することをお勧めします。

Groupingsはラベルの階層構造であり、ユーザーはインフラストラクチャービューをExploreタブで論理階層に編成できます。これにより、各レベルに適用可能な各インフラストラクチャーオブジェクトの行を含むツリービューになります。各エンティティについて、CPU、メモリ、ネットワーク、I/Oなどのいくつかの基本的なメメトリクスを表に表示できます。

ホスト名やコンテナなどの物理属性、またはKubernetes namespace、デプロイメント、ポッドなどの論理属性を使用してデータを表示できます。

たとえば、グループ化ビューをDeployments and Podsに変更します。

example-voting-app namespaceとそれを構成するすべてのデプロイとポッドを確認できるはずです。

他にもエクササイズしてみましょう！

先に進む前に、いくつかの質問に答えてみましょう：

• クラスターにはいくつのノードがありますか？
• 各ノードで実行されているSysdigエージェントを確認できますか？
• 投票アプリの各マイクロサービスで実行するインスタンスの数を教えてください。
• 各投票アプリマイクロサービスが現在実行されているノードを確認できますか？
• どのマイクロサービスがより多くのCPUを使用しますか？ そしてI/Oは？
• どのノードがメモリ使用量が多いですか？ そしてディスク使用量？

これで、アプリのコンポーネントについてのアイデアが得られました。しかし、これらのマイクロサービスは互いにどのように相互作用するのでしょうか。投票が発生すると、有権者と投票サービスの間のトラフィックが予想されます。結果サーバーは、データベースをチェックして結果を生成します。

Sysdigモニターでは、トポロジマップを使用して、エンティティが相互にどのように相互作用するかを視覚化できます。物理グループを使用すると、さまざまなエンティティが互いに対話しているのがわかりますが、論理グループを使用すると、Kubernetesがオーケストレーションしたサービスがどのように相互作用するかをよりよく理解できます。

Deployments and pods:Namespacesのようなグループを選択します。Namespaces > Deployments > Pods > Containers。ツリーでEntire Infraestructureを選択すると、デフォルトのダッシュボードの1つを選択できるようになります：Topology → Network Traffic。

インフラストラクチャ全体ではなく特定の部分のみを調べたい場合は、Entire Infrastructureから、たとえばexample-voting-app namespaceに変更します。 これをスコープの変更と呼びます。

これらのエンティティーを掘り下げていくと、コンテナの内部をプロセスレベルまでどのように見ることができるかがわかります。これは、Sysdigが提供する深い可視性の本当にクールな例です。

デフォルトのダッシュボードを使用して、エクスプローラから直接、アプリケーションまたはクラスタのいくつかの側面を監視できます。今見たように、アプリケーション、ホストとコンテナ、Kubernetes、ネットワーク、サービス、トポロジで利用できるそれらの集まりがあります。

他にもエクササイズしてみましょう！

デフォルトのダッシュボードを使用して、次のことを確認してください：

• 各投票アプリのマイクロサービスにどのテクノロジーが使用されていますか？（各コンテナ内で実行されている各プロセスを特定します）
• コンテナにコンテナのCPUまたはメモリの制限はありますか？

アプリケーションが期待どおりに動作しているかどうかを確認するために使用できるメトリクスとダッシュボードがいくつかあります。

このアプリケーションではすべてHTTPを使用しているため、Sysdig Monitorですぐに使用できるさまざまなメトリクスとデフォルトのHTTP(s)ダッシュボードを使用して、パフォーマンスを診断および評価できます。

たとえば、開始に適した場所はHTTPダッシュボードです。(Default Dashboards → Applications → HTTP):

このパネルから、いくつかの関連するメトリクスをすばやく確認できます:

• リクエスト数（1秒あたり）:サービスの現在のスループットとサービスされている接続の数を測定します。
• HTTPエラー数（1秒あたり）:HTTP応答コードを調べて、エラー状態を検出します。4XX応答コードはクライアントエラーであり、5XXはサーバーエラーであることに注意してください。
• 平均リクエスト時間（ミリ秒）:サービスのレイテンシを測定します。これにより、クライアントの視点から見たサービスの質を把握できます。

これらのメトリクス（つまり、レイテンシー、トラフィック、エラー、サチュレーション）は、Google SREブックでゴールデンシグナルと呼ばれるものです。これらを使用して、ユーザーの視点から任意のアプリケーションを監視できます。これは、任意のアプリケーションの健全性とパフォーマンスを判断するために調べる最初のメトリクスになるはずです。これは、さまざまなコンポーネントが何らかの種類のAPIリクエスト（HTTP、gRPCなど）を使用して相互に通信するマイクロサービスアプリケーションに特に関連しています。

ここでは、Sysdigが特定のアプリケーションプロトコル（この場合はHTTP）を識別してデコードし、最も要求されたURLまたはエンドポイントであるAPMのようなメトリクス、最も遅いHTTP応答コード、または リクエストタイプ（GET、POSTなど）。

他の監視方法では、代わりにリソース消費を調べます。 たとえば、USEモニタリングは、使用率、サチュレーション、エラーの3つのメトリクスに基づいてリソースのサービスキャパシティを抽象化しようとします。

• utilizationメトリクスには、CPU使用率、メモリ使用率などがあります。
• saturationメトリクスは、メモリページフォールトまたはディスクIO waitである可能性があります。
• errorsは、ファイルを開こうとして失敗した可能性があります。

ダッシュボードのDefault Dashboards → Kubernetes → Resource Usage → Kubernetes Deployment Healthは、Kubernetesメタデータによってメトリクスを集計するUSEスタイルの概要を提供します：

Sysdigは、オーケストレーションの状態も監視できます。これは、Kubernetesが期待どおりにデプロイおよびオーケストレーションを行っているかどうかを知るために重要です。これらのメトリクスは、kube-state-metricsとも呼ばれます。ダッシュボードKubernetes → Kubernetes State → Kubernetes Deployment Stateは、いくつかの洞察を提供します。調査している範囲に応じて、さまざまなリソースについてレポートするさまざまなダッシュボードを使用する必要があります。クラスタースコープの場合、namespaceを確認できます。 namespace内ではデプロイを確認でき、デプロイ内ではポッドを確認できます。

他にもエクササイズしてみましょう！

kube-stateダッシュボードを使用して、以下を確認してください:

• Kubernetesポッドが再起動していますか？
• 各サービスにはインスタンス（ポッド）がいくつありますか？ そして、私たちはいくつである事を期待しますか？
• 必要な（定義された）ポッドは、利用可能なポッドと同じですか？

サンプルの投票アプリケーションは、通常、デプロイされた状態で標準的な条件で適切に動作します。しかし、突然私たちのアプリがより多くのトラフィックを受け取り始めると想像してください。

• この状況でアプリケーションをどのように監視できますか？
• アプリケーションのボトルネックを見つけるにはどうすればよいですか？
• 変更を加えた場合、現在のワークロードでアプリケーションがサービスを適切に提供していることを確認できますか？

トレーニングの目的で、ホームディレクトリ内で次のスクリプトを実行することにより、手動でアプリケーションに負荷をかけることができます：

./stress.sh

これにより、 voterサービスのインスタンスがスケールアップし、アプリケーションの負荷が増加します。

しばらくすると、ゴールデンシグナルの動作の変化が現れます。たとえば、Services → Kubernetes Service Golden Signalsダッシュボードに表示されます。

他にもエクササイズしてみましょう！

• メトリクスの上に表示するようにイベントを設定できますか？
• 現在、voterサービスのインスタンスはいくつありますか？
• 現在、いくつのリクエストを受け取っていますか（合計）？
• アプリケーションの応答時間はどれくらいですか？
• アプリケーションでエラーが発生していますか？

アプリケーションに負荷がかかると、サービスごとの応答時間がどのように増加するかを明確に見ることができます。また、サービスごとのリクエストレートが増加し、同時にアプリケーションがエラーを受け取り始めることもわかります。 これらのメトリクスから、ストレス下ではアプリケーションが劣化していると結論付けることができます。

ゴールデンシグナルを把握して、アプリケーションが正しく動作していないことを確認します。次に、リソースの使用状況を見て、リミットに達していないかどうかを確認します。

他にもエクササイズしてみましょう！

• Kubernetesの観点からすべてがまだ正常かどうかを診断できますか？
• リソース使用量の変化を特定できますか？
• この変更はターゲットのレイテンシーに影響しますか？
• このシナリオに対処するために可能なオプションは何ですか？

Services → Kubernetes Service Golden Signalsダッシュボードを見ると、voterサービスのCPU使用率の増加がわかります：

そして、Hosts & Containers → Container Limitsダッシュボードを使用して少し深く掘り下げると、 voterサービスのCPUが限界に達していることがわかります：

cpu.quota.used.percentは、コンテナが定義された期間に実際に使用したCPUクォータの割合を示すメトリクスです。これは、コンテナが使用できるCPUの量のハードリミットであり、このため、CPUクォータは100％を超えないようにする必要があります。ダッシュボードから、 voteサービスが100％のリミットに達していることがわかります。これは、voteサービスがボトルネックであることを示しています。

増加した負荷を処理するために、voteサービスをスケールアップすることにします。

繰り返しになりますが、ホームディレクトリには、このサービスを拡張するためのスクリプトがあります。

./scale.sh

少し待ってから、Services → Kubernetes Service Golden Signalsダッシュボードをもう一度使用して、アプリケーションが再び制御下にある様子を確認できます。

興味深い点がいくつかあります:

• サービスあたりの応答時間は、ストレスがピークに達する前と同様です。アプリケーションは問題なく応答しています。
• サービスあたりのリクエスト率が増加しました。私たちはより多くのリクエストを受け取り、voteサービスがスケールアップされたときにその要件を満たすことができます。