本文の内容は、2020年9月10日にAaron Newcombが投稿したブログ(https://sysdig.com/blog/kubernetes-monitoring-best-practices/)を元に日本語に翻訳・再構成した内容となっております。
Kubernetes監視ソリューションを評価する際には、これらのKubernetes監視のベストプラクティスに注目してください。ツールがKubernetesネイティブであれば、これらを理解するのは簡単です。
現実を直視しましょう。Kubernetesでコンテナを実行することは、自動化、セグメンテーション、効率性の面で多くの利点をもたらします。しかし、Kubernetesのように常に変化し続けるインフラストラクチャーでパフォーマンスと可用性を監視する能力は、課題になることがあります。これに早期に対処する方法として、Secure DevOpsワークフローを採用することが挙げられます。
DevSecOpsとしても知られるSecure DevOpsは、開発から本番までのアプリケーションライフサイクル全体にセキュリティと監視をもたらします。これにより、安全で安定した高性能なアプリケーションを提供できるようになります。このワークフローは、既存のツールチェーンにプラグインして、DevOps、開発者、セキュリティチーム全体に単一の真実のソースを提供し、効率を最大化し、トラブルシューティングと最適化のための可視性を提供します。
このパズルの中で、Kubernetesとコンテナの監視は欠かせません。先に述べたように、Kubernetesの監視は困難であり、クラウドネイティブアプリケーション環境で何が起こっているのかを理解する能力を複雑にしています。ひいては、トラブルシューティングも複雑になります。幸いなことに、適切なツールとKubernetesモニタリングのベストプラクティスに従うことで成功することができます。
Kubernetesの監視はどう違うのでしょうか？
誰かがサーバの列を歩いて物理的に検査する時代は終わりました。仮想マシンはトラブルシューティングをより複雑にします。現在、コンテナはさらに一歩進んでいます。
コンテナは、使用需要に合わせてデプロイと再デプロイが行われるため、一度に数分間しか稼働しないことがあります。長い時間が経過してしまったものをどのようにトラブルシューティングすることができるでしょうか？
コンテナはブラックボックスでもあります。互いに隔離されたサンドボックス内で動作しているため、プロセスにアタッチしてメトリクスを収集することは容易ではありません。
さらに、コンテナはウサギのように増殖します。従来のシナリオよりも100倍、あるいは1,000倍以上のエンティティを監視することになるかもしれません。さらに悪いことに、コンテナは複数のホストに分散しています。適切なコンテキストがなければ、失敗したプロセスをどのようにして適切なアプリケーションやチームに関連付けることができるでしょうか？
そう考えると、インフラを取り巻く霧は今まで以上に濃くなっているように思えます。
しかし、心配する必要はありません。Kubernetesとコンテナは十分に成熟しており、この課題に対応できる監視ソリューションが用意されています。以下は、Kubernetesの監視を成功させるための7つのKubernetes監視のベストプラクティスのリストです。また、監視ソリューションがこれらのベストプラクティスに従うことができ、実用的な洞察を提供することができるかどうかを知るためのヒントをいくつか挙げました。
1. 表面に留まらず、深いシステムの可視性を追求する
コンテナは、最低限のバイナリ、ライブラリ、その他の要素を含む最小限のオペレーティング・システムだけを含めることが必要です。これは、移植性が高いという利点がありますが、監視がより困難になります。
これはサンドボックス化と相まって、ベアメタルサーバやVMに比べて抽象度が増し、コンテナがブラックボックスとして機能するようになります。
ホスト全体で何が起こっているかを知るために、Kubernetesの監視のベストプラクティスは、深い可視性を探すことです。これは、CPU、メモリ、ネットワーク、ストレージなどのリソースに関する情報を収集するだけでなく、実行中のプロセス、それらがシステムとどのように相互作用しているか（ファイルアクセス、ポートのオープンやクローズなど）、実世界との関係を記述したメタデータに関するカーネルレベルの粒度の高いデータを収集することを意味します。
システムレベルでの深い可視性の必要性の例としては、CrashLoopBackOffステータスのトラブルシューティングを試みることが挙げられます。多くのツールはコンテナをCrashLoopBackOffステータスでレポートできますが、この問題の根源は、コンテナが起動したときに何をしようとしているかの詳細を見ることで発見されることが多いです。システムコールの可視性を高めてこそ、根本的な原因を特定し、是正措置をとることができます。
2. インストルメント戦略の評価
システムからメトリクスやイベントを収集するためには、いくつかの計装戦略があります。モニタリングソリューションにコミットする前に、どれがシステムにとって適切なものなのかを評価することは、Kubernetesのモニタリングのベストプラクティスと考えられています。
最も一般的な戦略の1つは、インストルメンテーションライブラリでコンテナをラップしたり注入したり、サイドカーでエージェントを実行したりすることです。理論的には、これはアプリケーションの変更やエージェントのインストールを必要とせず（エージェントはライブラリやサイドカーにあります）、クラスタノードのホストにアクセスできないサーバーレスのシナリオで便利です。
しかし、Kubernetes環境では、この戦略はいくつかの問題を導入します。これらのライブラリは、実行中のコンテナごとに一度だけロードされることになり、RAM使用量が大幅に増加する可能性があります。ノードあたりのコンテナの密度が高くなると、これが積み重なって大きな問題になることがあります。
これらのライブラリはコンテナのようなユーザ空間上で実行されるため、収集できるデータ量はコンテナが見ることができるものに制限されます。また、これらのライブラリはアプリとシステムの間に配置されているため、エッジケースによってはデバッグが困難な動作を引き起こす可能性があります。
上記のすべての問題のために、より多くのモニタリングソリューションがeBPFプローブに移行しています。eBPFプローブは、Linuxカーネルのモジュールとして実行されるプログラムで、システムコールをすべてリッスンすることができます。これにより、トラブルシューティング、根本原因の分析、およびKubernetes環境でのパフォーマンスを確保するために必要なすべての情報を取得することができます。
その後、ユーザースペース上で実行されている別のプロセスが、プローブ情報を他のソース（プロメテウスのメトリクス、JMX、ログなど）と組み合わせて、モニタリングのバックエンドに報告することができます。
適切にコード化されていれば、eBPFプローブはRAMをあまり使用せず、CPUへの影響はわずかです。また、単なるオブザーバーであるため、プロセスに干渉することはありません。
3. システムの履歴データを取得することで、メトリクスを超えることができます
従来のシステムアーキテクチャとコンテナアーキテクチャの最大の違いの一つは、コンテナが刹那的であるということです。ほとんどが静的なままのベアメタルや VM アーキテクチャーとは異なり、コンテナはさまざまな場所にデプロイでき、変更が必要なときや新機能のロールアウトの準備ができたときに簡単に再デプロイすることができます。
これは、競争力を維持するために迅速に動く必要があるクラウドネイティブ環境にとって大きな利点です。しかし、これは問題が発生したときの大きな課題でもあります。コンテナが5分しか持たなかったり、クラスタ内の別のノードに移動したりした場合、何が問題になったのかをどうやって知ることができるでしょうか？
このような場合、メトリクスやログデータが役に立つのは限られており、このような動的な環境ではパフォーマンスの問題は簡単に隠れてしまいます。そのため、イベント周辺のすべてのホストアクティビティをキャプチャすることは、Kubernetesモニタリングのベストプラクティスとなっています。
50秒のような短い時間でも、重要なイベントがあったことがわかれば、豊富な情報を得ることができます。プロセス、ネットワーク、ファイル、ログ、CPU、メモリ、コンテナのアクティビティをキャプチャーして保存し、トレンド分析のためにコンテナがなくなった後に表示することで、根本的な原因を特定するのに役立ちます。
4. Kubernetesのコントロールプレーンを検査する
Kubernetesコントロールプレーンは、Kubernetesクラスタの頭脳です。これは、クラスターリソースのすべてを管理し、新しいポッドをスケジュールし、クラスターに保存されているすべての秘密を読み取ることができます。Kubernetesコントロールプレーンを監視していないのは、車のエンジンに気づかないのと同じです。ガソリンを入れたり、バッテリーを充電したり、オイルを交換したりするタイミングを知る必要があります。
Kubernetesコントロールプレーンは、あなたの環境にとって同様の重要な機能を提供しています。
コントロールプレーンの主なコンポーネントは以下の通りです。
- The API Server
- Kubelet
- The controller manager
- etcd
- kube-proxy
- kube-dns
Kubernetesコントロールプレーンを監視することで、レイテンシーやクラスターエラーを検出してトラブルシューティングしたり、サービスパフォーマンスを検証したりすることができます。車にダッシュボードがあるのと同じように、Kubernetesコントロールプレーンの要素についてもダッシュボードを用意する必要があります。
例えば、Kubernetes APIサーバを監視することで、クラスターコンポーネント間のすべての通信を可視化することができます。
Kubernetesコントロールプレーンの監視については、Kubernetesモニタリングガイドに詳細が記載されています。
5. メトリクスとイベントを相関させてコンテキストを埋め込む
インフラストラクチャ、サービス、アプリケーションを監視する際に収集される時系列データには、メトリクスとイベントの2種類があります。
メトリクスは、時間的に均等に分散して採取されたサンプルで、予測や平均化のためだけでなく、システムの状態を監視するためにも使用できます。
一方のイベントは、何か注目すべきことが起きた時限的な記録であり、そのため予測できません。
環境内のエンティティの数は、より多くのコンテナを使用するようになるにつれて増加し、時系列のメトリクスとイベントの数も増加します。
問題をトラブルシューティングする際に、何百万ものメトリクスとイベントがあると、問題をピンポイントで特定することは、干し草の山の中から針を見つけるようなものです。モニタリング・ツールがメトリクスとイベントを相関させることができれば、ノイズから信号を分離し、正しい方向を示すのに大いに役立ちます。
例えば、あるメトリクスはクラスターノードが割り当てを超えてメモリを使用していることを示すことができます。このような情報があれば、コンテナの調査を開始して、異常なメモリ使用量がないかどうかを調べることができます。この作業は、そのクラスターノードで実行されているコンテナの数にもよりますが、時間がかかる場合があります。
同時に、コンテナがKillされたイベントがあったとしましょう。この追加情報により、調査範囲を絞り込むことができます。最も可能性が高いのは、そのコンテナのリミットとリクエストが誤って設定されていることです。一見すると、根本的な問題の理論はすでにわかっています。
しかし、その時点に到達するためには、これら二つの情報を並べて見る必要があります。文脈と情報の組み合わせこそが、点と点を結びつけ、是正措置を講じ、MTTR を下げるために必要なものなのです。これが、メトリクスとイベントを相関させることがKubernetesモニタリングのベストプラクティスである理由です。
ダッシュボードのメトリクスの上にイベントをオーバーレイするモニタリングソリューションを探してください。
6. すぐに使えるダッシュボードとアラートを探す
最近では、ほとんどすべてのモニタリングツールに何らかのダッシュボード機能が搭載されています。ダッシュボードはデータを可視化するための素晴らしい方法ですが、何を見るべきかのアイデアがある場合に限ります。
KubernetesやPrometheusに慣れていない人にとって、ダッシュボードやアラートの学習曲線は険しいものになるかもしれません。"知らないものは知らないということを知らない"という古い格言がここでは最もよく当てはまります。ダッシュボードを監視製品の機能として持つだけでなく、簡単に始められるようにいくつかのダッシュボードを用意しておくことが、Kubernetesの監視のベストプラクティスである理由です。
アラートはまた、新しいツールを学習する際に、頭の中を整理するのが難しい場合があります。閾値の低いアラートを設定すると、サポートチームは「アラート疲労」を起こしてしまいます。逆に、アラートが適切なタイミングでトリガーされない場合、エンドユーザーに影響を与えている可能性のある状態についての重要な情報を見逃してしまう可能性があります。
選択したモニタリングツールに優れた例が組み込まれていると、セットアップとチューニングのプロセスで時間を節約することができます。また、良い学習ツールにもなり、今まで考えもしなかった監視すべきことを発見するのに役立ちます。
モニタリングツールを補完するモニタリング統合、ダッシュボード、アラートのオンラインリポジトリがあります。時間を無駄にしないように、PromCatのように、これらのリソースがテストされ、メンテナンスされていることを確認してください。
モニタリングソリューションには、ダッシュボードとアラートの追加機能があります。例えば、以下のようなものです。
- ダッシュボード上のメトリクスの説明が含まれています
- ダッシュボードをカスタマイズできること
- テスト環境からのアラートの嵐を避けながら、本番イベントを通知するために、アラートで適切なスコープを設定できること
7. SaaSベースの監視ソリューションを選択する
オンプレミスのソリューションよりもSaaSベースのスキャンサービスを選択すると、多くのメリットがあります。
オンデマンドでスケーラブルなリソース：最初は少数の時系列で始め、コンテナ・アプリケーションの規模に応じて成長させることができ、バックエンドのデータ管理を気にする必要はありません。
迅速な実装：インストールやセットアップに時間がかかるオンプレミスのアプリケーションとは異なり、エージェントをインストールして数分でモニタリングを開始することができます。
簡単なアップグレードとメンテナンス：SaaS プロバイダがパッチを処理し、新機能のアップデートをデプロイするため、手動でアップグレードする必要がありません。
インフラストラクチャーやスタッフのコストが不要：永続的な所有権を持つ社内のハードウェアやソフトウェアのライセンス費用を支払う必要がありません。また、アプリケーションのメンテナンスやサポートのためにオンサイトで作業する必要もありません。
まとめ
Kubernetes とコンテナは監視のパラダイムを変え、従来の監視戦略を無意味なものにしました。コンテナは短命で不透明な上に、監視すべきエンティティの数が増えます。
しかし、Kubernetesモニタリングのベストプラクティスに従うことで、システムの可用性とパフォーマンスを確実にするための深い可視性を得ることができ、インシデントの迅速なトラブルシューティングに役立つ適切なコンテキストを得ることができます。
適切なツールの選択が鍵となります。SysdigはこれらのKubernetesモニタリングのベストプラクティスに従うことを可能にし、ガイド付きのオンボーディングで5分以内に設定を完了させることができます。コンテナ、サービス、アプリケーションのメタデータの可視性と相関性をすぐに利用できるSysdigは、環境のパフォーマンスと可用性を向上させながら、MTTRを下げるのに役立ちます。今すぐお試しください。
Kubernetesとコンテナモニタリングのワークフローを実際に見るには、ウェビナー「The Five Kubernetes Monitoring Must-Haves」をご覧ください。