本文の内容は、2023年2月16日にVICTOR HERNANDO が投稿したブログ（https://sysdig.com/blog/how-to-monitor-kubernetes-control-plane)を元に日本語に翻訳・再構成した内容となっております。 以前の記事ですでに説明したように、Kubernetesのコントロールプレーンは、さまざまな役割を果たすいくつかの重要なコンポーネントで構成されています。それらは、Kubernetesとアプリケーションの両方が機能し、適切に動作することを保証するために必要なものです。 Kubernetesの複雑さと、クラウド環境の急速な導入により、多くの組織がまだクラウドネイティブの導入の途上にあります。これらの組織のほとんどは、複雑な問題に定期的に対処しなければならず、タイムリーに対応することは必ずしも容易ではありません。アプリケーションの監視とトラブルシューティングは、適切に処理されないと大きな頭痛の種になってしまいますが、Kubernetesコントロールプレーンの監視も、Kubernetesやクラウドインフラクチャーにおける問題の監視とトラブルシューティングの際に大きな痛手となる可能性があります。良いニュースは、Sysdig Monitorがそのような大変な作業を手助けしてくれることです! Sysdig MonitorがKubernetesのコントロールプレーン監視にどのように役立つのか、読み進めてみてください。
Kubernetesのコントロールプレーン監視
Kubernetesのコントロールプレーンは、Kubernetesクラスター内のエンジンルームです。前述したように、そのコンポーネントを適切に監視することが重要です。さもなければ、アプリケーションで深刻な問題に直面することになり、サービスの停止にさえつながるかもしれません。 ご自身のPrometheusセルフマネージドインスタンスを使ってKubernetesコントロールプレーンを監視する方法にご興味がある方は、以下の記事をご覧ください。 一方、Sysdig Monitorでは、Prometheusのマネージドサービスを提供しています。お客様はPrometheusのスケーラビリティ、パフォーマンス、長期保存のいずれにも気を配る必要はなく、これらの重要なポイントはSysdigがカバーします。メトリクスやKubernetesのデータを引き出すために、Sysdigが水面下で行っていることを一言で言うと、以下の通りです。- Sysdig Agentをクラスター内のすべてのノードにデプロイすることが最初のステップです。
- エージェントは、コンテナやノードからeBPFでメトリクスや低レベルの情報収集を開始します。
- Kubernetes、インフラストラクチャーのメタデータ、およびアプリケーションのコンテキストは、メトリクスを充実させるために使用されます。これらのメトリクス、ネットワークデータ、プロセス情報、リソース使用率、システムコール、その他多くの情報がSysdig Monitorによって収集され、取り込まれます。
- Kubernetes APIサーバー、スケジューラー、kube-controller-manager、CoreDNS、etcdといったKubernetesコントロールプレーンコンポーネントは自動的にスクレイピングされます。
- Kubeletのメトリクスも cAdvisorのデータを含め、Sysdig Agentによって収集されます。
- remote-writeを使用して独自のカスタムメトリクスをSysdig Prometheusマネージドサービスにプッシュするか、Sysdig Agentが任意のカスタムエンドポイントを検出し、そこからメトリクスを収集し始めるように設定することが可能です。
- すべてのデータは、Sysdig Monitorポータルで数秒後に自動的に利用できるようになります。
Sysdigエージェントの設定方法
Sysdig Monitorのポータルに初めてログインすると、自動的にオンボーディングセクションにリダイレクトされます。ここには、数ステップで簡単にエージェントをデプロイするための手順が記載されています。その他、Sysdigドキュメントポータルには、この最初のタスクを完了するために必要なすべての情報が記載されています。
それでは、Sysdigエージェントのインストールを始めましょう。このシナリオでは、Helm チャートが使用されます。
# kubectl create ns sysdig-agent namespace/sysdig-agent created # helm repo add sysdig https://charts.sysdig.com "sysdig" has been added to your repositories # helm repo update Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "sysdig" chart repository ...Successfully got an update from the "prometheus-community" chart repository Update Complete. ⎈Happy Helming!⎈ # helm install sysdig sysdig/sysdig-deploy \ > --namespace sysdig-agent \ > --set global.sysdig.accessKey=abcdefgh-ijkl-mnop-qrst-uvwxyz012345 \ > --set global.sysdig.region=eu1 \ > --set nodeAnalyzer.enabled=false \ > --set global.clusterConfig.name=k8s-lab NAME: sysdig LAST DEPLOYED: Wed Jan 18 09:58:46 2023 NAMESPACE: sysdig-agent STATUS: deployed REVISION: 1 NOTES: The agent for Sysdig Secure DevOps Platform is spinning up on each node in your cluster. After a few seconds, you should see your hosts appearing in the Sysdig Agent Health & Status Dashboard. Links for your deployment: * Sysdig Monitor: https://eu1.app.sysdig.com/#/dashboard-template/view.sysdig.agents?last=10 * Sysdig Secure: https://eu1.app.sysdig.com/secure/#/data-sources/agents数分待って、Podが既に稼働しているかどうか確認します。
# kubectl get pods -n sysdig-agent NAME READY STATUS RESTARTS AGE sysdig-agent-9hk84 1/1 Running 0 4m1s sysdig-agent-smtm6 1/1 Running 0 4m1s sysdig-agent-vpcbn 1/1 Running 0 4m1sこの時点で、Kubernetesクラスター全体の監視とトラブルシューティングを開始する準備が整いました。 Kubernetesのコントロールプレーンメトリクスの取り込みはオートマジック（自動的かつ魔法のような）です。Sysdig Agentの初回デプロイ後、コントロールプレーンのダッシュボードやメトリクスが表示されない場合は、サポートのお客様担当者に連絡し、アクティベーションを依頼してください。
Kubernetes環境におけるSysdig Monitorのメリット
Sysdig Monitorのポータルにログインし、Sysdig Agentをデプロイするとすぐに、Sysdig Monitorのサービスが実に幅広く、様々なユースケースをカバーしていることに気づかれることでしょう。- Kubernetesの監視とトラブルシューティング：クラスターのキャパシティと可用性を監視し、問題を最大10倍速くトラブルシューティングし、リソースの消費量と実際のリミット値やリクエスト値を効果的に測定します。
- Prometheusの監視、Prometheusのマネージドサービスと長期的な時系列保存のための長期ストレージを提供します。
- カスタムメトリクス、Sysdig Agentにより、お客様独自のカスタムメトリクスを収集したり、リモートライトによりプッシュすることができます。PromQLエクスプローラーを使用して、お客様のカスタムメトリクスデータを調査・分析できます。
- クラウド監視：クラウドプロバイダーのサービスを積極的に監視し、メトリクスやアラートに対するメタデータのリッチ化からベネフィットを得ることができます。
- コスト最適化では、ワークロードを効率的に観察し最適化することで、無駄な支出を平均40％削減することが可能になります。
- アウトオブボックスで提供される膨大な数のダッシュボード：アプリケーションもKubernetes内部のコンポーネントも、Sysdigのダッシュボードのおかげで、最初から観察することができます。
- Sysdig Advisorは、Kubernetes環境における複雑な問題のトラブルシューティングを支援します。
- 最近リリースされたSysdig Cost Advisorは、コストをかけすぎている箇所を特定し、40%のコスト削減を開始するための改善策を提供します。
- Sysdig Inspectは、データキャプチャーからシステムコールやその他の内部を分析するためのインターフェースを提供します。
- メトリクスエクスプローラーは、素晴らしい機能の一つです。これは、すべてのメトリクスからデータを探索し、引き出すことができます。
- 事前定義されたアラートのセットは、あなた自身や他のサードパーティのアプリケーションで利用可能です。
- その他にも
Kubernetesコントロールプレーン監視のためのアウトオブボックスのダッシュボード
エージェントがKubernetesノードとKubernetesコントロールプレーンからのデータ収集を開始するとすぐに、多くのダッシュボードが自動的に表示され、Kubernetesアプリケーションとサービスを監視するために必要なすべての情報を提供していることに気づくでしょう。Sysdig Agentをデプロイするために必要なステップに従いましたか？もしそうなら、Kubernetesインフラクチャー全体で何が起こっているのかを観察し始める準備が整ったことになります！
Sysdig Monitorは、Kubernetesインフラストラクチャーにあるサードパーティのワークロードを検出することができます。これらのワークロードの中には、自動的に有効化され、追加のステップなしに監視できるものがあります。Istioは良い例です。Sysdig Monitorプラットフォームにログインするだけで、メトリクスをコンシュームし始めることができます。CNI や CoreDNS のような、より高いレベルの他の多くのコンポーネントも同じように Sysdig Monitor に統合されています。これらの統合はSysdigによって管理されているため、バージョンアップ後の監視システムの調整について心配する必要はありません。サードパーティアプリケーションの統合の詳細については、Sysdigの公式ドキュメントを参照してください。
これは本当に良いことですが、Kubernetesの問題のトラブルシューティングについてはどうでしょうか？
それについては、次のセクションで説明しましょう。読み進めて、Kubernetesのコントロールプレーンの問題をトラブルシューティングする方法について学んでください。
Sysdig MonitorでKubernetesのコントロールプレーンの問題をトラブルシュートする
Sysdig Advisorのおかげで、ユーザーはKubernetesインフラの問題を一目で簡単に発見することができます。コントロールプレーンレベルで出てくるような複雑で隠れた問題も、従来のトラブルシューティングに比べて最大で10倍速くトラブルシューティングすることが可能です。 次の例では、Kubernetes APIサーバーで非常に奇妙なことが起こり始めていることに気づきます。アウトオブボックスのKubernetes APIサーバーのダッシュボードでは、異常な動作が確認できます。4xx httpレスポンスコード、APIサーバーのリクエスト期間操作の突然の増加、などです。何が起こっているのか、どのように把握すればいいのか見てみましょう。
Sysdig Advisorを使えば、インフラストラクチャー全体を簡単にチェックすることができます。今回のケースでは、CPUとメモリの急激な増加が検出されました。
クラスターで利用できるネームスペースを掘り下げ、kube-systemを選択すると、control-plane Podsが見つかります。Kubernetes APIサーバーやetcdのパフォーマンスに大きく影響し、何か異常が起きていることが確認できます。
次に、念のためKubernetes APIサーバーのPodログをいくつか確認し、有用な情報を入手してみましょう。以下の画像にあるように、kube-apiserverのPodは、これらのいくつかのメッセージを継続的に報告しています。nginx-deploymentに何らかの問題があるようで、APIがPodの削除やetcdエントリの作成に恒常的に追われているようです。
Sysdig AdvisorのEventsセクションで確認できます。そのデプロイに何らかの問題があるようです。Kubernetesクラスターは、多くのnginx-deploymentオブジェクト関連のイベントを報告しています。これらの Pod をホストするために利用できるノードがありません。
このデプロイは、デフォルトのネームスペース内に配置することができます。まず確認してみましょう。約63%のPodが利用可能で、0%のnginx-deploymentのPodが利用可能です。
デフォルトのネームスペースにあるnginx-deploymentを選択してみましょう。nginx-deploymentが固まり、Kubernetes APIやetcdに過剰な負荷がかかっていることがわかります。