San Antonio API Security Summit 2025 に参加しよう!
San Antonio API Security Summit 2025 に参加しよう!
San Antonio API Security Summit 2025 に参加しよう!
San Antonio API Security Summit 2025 に参加しよう!
San Antonio API Security Summit 2025 に参加しよう!
San Antonio API Security Summit 2025 に参加しよう!
閉じる
プライバシー設定
ウェブサイト運営に必要なCookieや類似技術を使用しています。追加のCookieは貴社の同意がある場合のみ利用されます。同意は「Agree」をクリックすることでいただけます。どのデータが収集され、どのようにパートナーと共有されているかの詳細は、Cookieポリシープライバシーポリシーをご確認ください。
Cookieは、貴社デバイスの特性や、IPアドレス、閲覧履歴、位置情報、固有識別子などの特定の個人情報を取得、解析、保存するために使用されます。これらのデータは様々な目的で利用されます。分析Cookieによりパフォーマンスを評価し、オンライン体験やキャンペーンの効果向上に役立てます。パーソナライズCookieは、利用状況に応じた情報やサポートを通じ、貴社専用の体験を提供します。広告Cookieは、第三者が貴社のデータをもとにオーディエンスリストを作成し、ソーシャルメディアやネット上でのターゲット広告に使用します。貴社は各ページ下部のリンクから、いつでも同意の許可、拒否、または撤回が可能です。
ご送信ありがとうございます。内容を受け付けました。
申し訳ありません。フォーム送信時にエラーが発生しました。
DevSecOps

Kubernetesモニタリング

Kubernetesが複雑なアーキテクチャに組み込まれる場合、クラスタのオーバーリソースが大きな課題です。K8sを利用する人々はクラスタ管理に手を焼くことが多いですが、難しいからといって放置するのは得策ではありません。K8sのモニタリングは、クラスタを効率的に維持するための有力な方法の一つです。ここでは、この概念を詳しく見ていきます。

Kubernetesモニタリング:概要

K8sのクラスタは扱いが複雑で、この複雑さゆえにK8sユーザーがプラットフォームを十分に活用できずにいます。

しかし、K8s環境を追跡・モニタリングし、クラスタの問題を即時に発見して積極的に運用すれば、DevOpsチームにとってクラスタ管理はそれほど面倒ではなくなります。例えば、クラスタの稼働時間やCPU使用量、ストレージ使用量、複数のクラスタ要素間の通信など、さまざまな要素を把握します。

クラスタを監視する主要コンポーネントは「クラスタオペレーター」です。クラスタオペレーターはクラスタのあらゆる動作を監視し、異常があればシステムに通知を送ります。具体的には、設定の失敗や複数Podの過剰稼働、リソース使用量の閾値超過、Podエラーなどが典型的な異常例です。クラスタオペレーターは多方面を監視できますが、大規模なK8sモニタリングには十分ではありません。

そのため、専門家はクラウドベースのモニタリングツールやアプリによる包括的な監視を推奨しています。

なぜ重要か

K8sで継続的デプロイを行う人たちが取り組む理由は、K8sを活用すると複数のコンピューティング環境間を容易に移行できるからです。デプロイしたアプリは、最小限の労力でコンピューティング環境を切り替えられます。

また、KubernetesデプロイYAMLを使うと、DevOpsチームは単一のシステム上で幅広いアプリコンテナを扱いやすくなります。その結果、K8sで共有クラスタシステムを構築するのも容易です。アプリ同士は完全に分離されているため、基盤のホスト環境と切り離された状態で動作します。この構造により、複数クラウドでのスケーリングも容易になります。

Kubernetesが登場する以前は、アプリの移植性が低かったため、非ポータブルなアプリを使い続けるしかありませんでした。しかしK8sの登場により、アプリの可搬性がサポートされただけでなく、DevOpsチームが単一OS上で複数のアプリを展開できるようになりました。これがK8sが広く普及した理由の一つです。

Kubernetesデプロイの成功例としては、Googleが挙げられます。この大手テック企業は自社開発のプラットフォームを活用し、週あたり数十億ものコンテナを稼働しています。

ただし、Kubernetesのデプロイがいつも成果をもたらすわけではありません。どの技術にもデメリットはあり、K8sの場合、アプリと関連サーバーの一対一のやり取りが存在しない点が課題です。アプリはサーバーを頻繁に切り替えるため、DevOpsチームはサーバーの状態を追跡できず、アプリのヘルスを予測しにくくなります。

K8sにおいてアプリのヘルスはクラスタやコンテナにも大きく依存します。K8sアプリの動作に影響を与えるコンポーネントは1つではなく、複数の要因が絡み合っているのです。

そこでK8sのモニタリングが重要になります。アプリのヘルス監視を複数カテゴリーに分解することで、DevOpsチームがエラーを発見しやすくし、脆弱性を取り除きやすくしてくれます。

CPU使用量やストレージ、ノード容量などのメトリクスを監視せずにいると、K8sアプリは深刻な運用トラブルに見舞われ、期待どおりの動作ができなくなりかねません。

Kubernetes Monitoring

K8sモニタリングにおける主要なメトリクス

前述のように、K8sを注視することはリスクを減らし、アプリのパフォーマンスを向上させる唯一の手段です。ただし、エコシステムを的確に監視しないと望む結果が得られません。

アプリのヘルスや運用に影響を与えるメトリクスを把握することが大切です。モニタリングを行う際は、まずそれらのメトリクスに注力してください。Kubernetesの場合、監視は主に2つのレベルで行われます。

クラスタモニタリング - これはK8sクラスタが正常かどうかを確認するために行います。このレベルでは、対象となるノードが健全に稼働しているか、利用リソースが適正かを追跡するため、多様なメトリクスを確認します。

Podモニタリング - Pod自体の運用やパフォーマンスに関わるメトリクスを扱うレベルです。PodはK8sの基本単位であり、正常に動作しなければアプリが適切に機能することは期待できません。

それでは、各レベルでどのようなメトリクスを見ていくのか確認しましょう:

クラスタレベルのメトリクス

このレベルで追跡するメトリクスは3つのカテゴリーに分類されます。

  • #1 - クラスタノード - ノード数を把握しておくことで、必要なクラウドリソースを見積もることができます。
  • #2 - クラスタPod - 稼働中のPodの数を把握し、失敗したPodを即座に入れ替えるための情報を得られます。Pod数を把握していないと、継続的に円滑なクラスタ運用を行うのは難しいでしょう。
  • #3 - リソース利用率 - ノードが消費しているリソースを監視し、今後のリソース需要を判断するのに役立ちます。リソースの不足や過剰利用を防ぐことが可能です。

Podレベルのメトリクス

こちらのレベルでも、メトリクスは3つのカテゴリーに分かれています:

  • #1 - コンテナメトリクス - CPU、ネットワーク、メモリなどのコンテナ使用状況です。これらを取得するにはMetrics-serverが必要です。
  • #2 - アプリメトリクス - アプリのビジネスロジックに関係するメトリクスです。アプリによって重要視する指標は異なり、ユーザー数を見るアプリもあれば、ユーザー体験を重視するアプリもあります。
  • #3 - K8sの可用性とスケーリングに関するメトリクス - オーケストレーターがPodをどのように扱っているかを把握するための指標です。通常は、ある時点で稼働しているPodの実数と期待数、ネットワークデータ、進行中の実装状況、ヘルスチェックなどを追跡します。

これらの指標を活用すれば、DevOpsチームは包括的かつエンドツーエンドなK8sモニタリングを実施し、アプリのパフォーマンスを向上させやすくなります。

K8sモニタリングの種類

K8sを継続的にデプロイする際は、まずどの監視方式を採用するかを検討する必要があります。一般的には監視対象が多岐にわたるため、多角的に進めることが求められます。

  1. K8sクラスタモニタリング

このタイプの監視はクラスタのヘルスや処理にのみ焦点を当てます。K8sクラスタを円滑に稼働させるには、クラスタ内のノードが正常に動作しているか、各ノードのリソース使用量、稼働しているアプリ数など、さまざまな指標を追跡することが必要です。

クラスタを監視する場合は、ディスク使用量、CPU消費量、ネットワーク帯域、メモリ使用量、クラスタ使用状況、オーバーヘッド、稼働中のPod数などを特に注視します。

  1. K8s Podモニタリング

名前のとおり、Podの監視を行う方式です。PodはK8sの基本実行単位であり、もし元のPodが失敗した場合、K8sは自動的に同じPodを再生成し、運用が止まらないようにします。

アクティブなセッション中は多数のPodが稼働するため、適切に管理しないと混乱します。理想的な方法はプロセス単位でPodを制限し、ヘルス状態を把握しやすくすることです。

kubectlコマンドの「get pod」を使用すれば、Podの現在ステータスを簡単に確認できます。STATUS欄に各Podの詳細が表示されるため、ヘルスチェックや進行中処理、インスタンス数、ネットワークやデータの使用状況などを追跡すると理解が深まります。

実際のKubernetesデプロイや複数のクラスタを手動で監視するのはほぼ不可能ですので、Sumo Logicなどの自動化ツールが非常に役立ちます。

  1. K8sアプリ性能モニタリング

K8s上で動作するアプリが安定して動くよう、常に監視しておくことが大切です。トレース情報やログ詳細、パフォーマンスデータ、K8sのシステムイベントなどを追跡できる複数のツールが存在します。

  1. K8sコスト監視

ワークロードを適切に配置してクラスタのコストを予算内に抑えるためにも、コスト監視が重要です。具体的にはロードバランシングやCPU使用量、ストレージ、クラスタ管理費用、共通サービスのサブスクリプションコストなどをチェックします。

コスト監視を行う際は、ノードやPodのサイズが適切かどうかを検討し、AWSクラウドの割引やスポットインスタンスを利用することで費用を抑えられます。

  1. K8sセキュリティ監視

難易度は高いものの、セキュリティ監視を無視すると大規模なKubernetes導入がすぐに崩壊してしまう恐れがあります。一般に、APIやネットワーク層、コンテナ、ホストOS、コンテナランタイム、kubectlなどはリスクが高い部分です。K8sセキュリティ監視はこれらをすべて対象に含みます。

  1. K8sネットワーク監視

最後に、K8sネットワークを監視することも欠かせません。クラスタ間の通信が監視されないままだと、複雑な不具合が発生しやすくなります。ネットワーク監視では、エンドポイントのトランザクション、レスポンスタイム、エラー率、サービスマップなどをチェックします。

Kubernetesモニタリングツール

K8sを手作業で監視するのは非常に難しく、現実的ではありません。そのため、自動化された豊富な機能を持つK8sモニタリングツールを活用するのがおすすめです。ありがたいことに、多種多様なKubernetesツールがあります。例えば:

  • Kubernetes Dashboard

これはWebベースの強力なインターフェイスが特徴的なK8s監視ツールで、クラスタにデプロイされたコンテナ化アプリの監視やクラスタリソースの管理など多彩な機能があります。

さらにコンテナ化されたアプリのトラブルシューティングや、個別のK8sリソースの作成、クラスタ上で動作中のアプリ概要の把握などにも役立ちます。

  • Grafana

Grafanaはオープンソースの可視化プラットフォームとしておすすめです。ノード、Pod、デプロイメント、クラスタといった4つの主要メトリクスを標準で監視できます。

管理者はこのツールを使って、追跡したい情報を即時にダッシュボード化し、運用に役立てることができます。

SoundCloudが開発し、CNCFに寄贈された高機能なK8sモニタリングツールです。DockerやK8sとの相性が良く、幅広いメトリクスを監視できます。標準では可視化機能がないため、Grafanaと組み合わせて利用されることが多いです。コンテナ化されたアプリやマイクロサービスも監視可能です。

Jaegerはトレーシングシステムとして世界的に評価されています。Uberが開発したオープンソースで、分散トランザクションのトラブルシューティングや即時監視に適しています。ソフトウェアのレイテンシ最適化やコンテキスト伝播などの問題を見つけるのに役立ちます。

  • Kubewatch

Go言語で構築されたKubewatchは、非常に使いやすいオープンソースのK8s監視ツールとして知られています。操作画面がシンプルで、初心者でも問題なく扱えます。コラボレーションツールとクラスタ間の即時連携を可能にします。

Kubernetesモニタリングのベストプラクティス

K8sのモニタリングは非常に重要ですが、正しい方法で実施しないと大きな成果は得られません。以下は、モニタリングを行ううえで押さえておきたいポイントです。

  1. マイクロサービスのAPIゲートウェイを追跡

マイクロサービスの場合、CPUやメモリなどリソース単位の細かいメトリクスをすべて追跡すると複雑になりがちです。より効果的なのは、レイテンシやリクエスト数、エラー率といったAPI関連のメトリクスを追跡することです。

これらのメトリクスを即時で把握できれば、REST APIやNginx、Istioなどに存在する不具合や脆弱性を迅速に検知できます。サービスレベルのメトリクスはすべてのK8sサービスで一定の精度を保ち、監視を一貫化してくれます。

  1. 高いディスク使用率を無視しない

高いディスク使用率を見つけても放置してしまうと、やがて大きな障害につながる恐れがあります。修正が難しい場合でも、できるだけ早く対応することが大切です。アラートの閾値は75〜85%に設定するのがおすすめです。

ディスク消費を正確に把握するため、すべてのディスクボリュームを監視対象に含めるとよいでしょう。ルートファイルシステムも例外ではありません。

  1. エンドユーザーの体験を考慮する

Kubernetesを稼働させる際は、K8s上で動いていない要素であっても、最終的なエンドユーザー体験に注意を払う必要があります。K8sがユーザーにどのような影響を与えるかも重要な監視項目です。

エンドユーザーの体験を判断するには、合成モニタリングやリアルユーザーモニタリングのデータが役立ちます。これらのデータを分析すれば、ユーザーがKubernetesワークロードにどのようにアクセスしているのか、アプリの応答性能や使いやすさはどうかなどを把握できるでしょう。

  1. クラウド環境の特性を考慮する

Kubernetesがクラウド上にデプロイされている場合は、IAMイベントやクラウドAPI、ネットワーク性能、コストなどクラウド特有の要因もモニタリングの対象に含める必要があります。

具体的には、IAMイベント(ログイン失敗や権限変更)やネットワークのパフォーマンスが考慮すべき要素です。Kubernetesの継続的デプロイを行っている場合は特に、クラウド環境に合わせたモニタリング戦略を構築しましょう。

FAQ

最新情報を購読

学習目標
最新情報を
購読
購読する
関連トピック