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アプリは深刻な運用トラブルに見舞われ、期待どおりの動作ができなくなりかねません。
前述のように、K8sを注視することはリスクを減らし、アプリのパフォーマンスを向上させる唯一の手段です。ただし、エコシステムを的確に監視しないと望む結果が得られません。
アプリのヘルスや運用に影響を与えるメトリクスを把握することが大切です。モニタリングを行う際は、まずそれらのメトリクスに注力してください。Kubernetesの場合、監視は主に2つのレベルで行われます。
クラスタモニタリング - これはK8sクラスタが正常かどうかを確認するために行います。このレベルでは、対象となるノードが健全に稼働しているか、利用リソースが適正かを追跡するため、多様なメトリクスを確認します。
Podモニタリング - Pod自体の運用やパフォーマンスに関わるメトリクスを扱うレベルです。PodはK8sの基本単位であり、正常に動作しなければアプリが適切に機能することは期待できません。
それでは、各レベルでどのようなメトリクスを見ていくのか確認しましょう:
このレベルで追跡するメトリクスは3つのカテゴリーに分類されます。
こちらのレベルでも、メトリクスは3つのカテゴリーに分かれています:
これらの指標を活用すれば、DevOpsチームは包括的かつエンドツーエンドなK8sモニタリングを実施し、アプリのパフォーマンスを向上させやすくなります。
K8sを継続的にデプロイする際は、まずどの監視方式を採用するかを検討する必要があります。一般的には監視対象が多岐にわたるため、多角的に進めることが求められます。
このタイプの監視はクラスタのヘルスや処理にのみ焦点を当てます。K8sクラスタを円滑に稼働させるには、クラスタ内のノードが正常に動作しているか、各ノードのリソース使用量、稼働しているアプリ数など、さまざまな指標を追跡することが必要です。
クラスタを監視する場合は、ディスク使用量、CPU消費量、ネットワーク帯域、メモリ使用量、クラスタ使用状況、オーバーヘッド、稼働中のPod数などを特に注視します。
名前のとおり、Podの監視を行う方式です。PodはK8sの基本実行単位であり、もし元のPodが失敗した場合、K8sは自動的に同じPodを再生成し、運用が止まらないようにします。
アクティブなセッション中は多数のPodが稼働するため、適切に管理しないと混乱します。理想的な方法はプロセス単位でPodを制限し、ヘルス状態を把握しやすくすることです。
kubectlコマンドの「get pod」を使用すれば、Podの現在ステータスを簡単に確認できます。STATUS欄に各Podの詳細が表示されるため、ヘルスチェックや進行中処理、インスタンス数、ネットワークやデータの使用状況などを追跡すると理解が深まります。
実際のKubernetesデプロイや複数のクラスタを手動で監視するのはほぼ不可能ですので、Sumo Logicなどの自動化ツールが非常に役立ちます。
K8s上で動作するアプリが安定して動くよう、常に監視しておくことが大切です。トレース情報やログ詳細、パフォーマンスデータ、K8sのシステムイベントなどを追跡できる複数のツールが存在します。
ワークロードを適切に配置してクラスタのコストを予算内に抑えるためにも、コスト監視が重要です。具体的にはロードバランシングやCPU使用量、ストレージ、クラスタ管理費用、共通サービスのサブスクリプションコストなどをチェックします。
コスト監視を行う際は、ノードやPodのサイズが適切かどうかを検討し、AWSクラウドの割引やスポットインスタンスを利用することで費用を抑えられます。
難易度は高いものの、セキュリティ監視を無視すると大規模なKubernetes導入がすぐに崩壊してしまう恐れがあります。一般に、APIやネットワーク層、コンテナ、ホストOS、コンテナランタイム、kubectlなどはリスクが高い部分です。K8sセキュリティ監視はこれらをすべて対象に含みます。
最後に、K8sネットワークを監視することも欠かせません。クラスタ間の通信が監視されないままだと、複雑な不具合が発生しやすくなります。ネットワーク監視では、エンドポイントのトランザクション、レスポンスタイム、エラー率、サービスマップなどをチェックします。
K8sを手作業で監視するのは非常に難しく、現実的ではありません。そのため、自動化された豊富な機能を持つK8sモニタリングツールを活用するのがおすすめです。ありがたいことに、多種多様なKubernetesツールがあります。例えば:
これはWebベースの強力なインターフェイスが特徴的なK8s監視ツールで、クラスタにデプロイされたコンテナ化アプリの監視やクラスタリソースの管理など多彩な機能があります。
さらにコンテナ化されたアプリのトラブルシューティングや、個別のK8sリソースの作成、クラスタ上で動作中のアプリ概要の把握などにも役立ちます。
Grafanaはオープンソースの可視化プラットフォームとしておすすめです。ノード、Pod、デプロイメント、クラスタといった4つの主要メトリクスを標準で監視できます。
管理者はこのツールを使って、追跡したい情報を即時にダッシュボード化し、運用に役立てることができます。
SoundCloudが開発し、CNCFに寄贈された高機能なK8sモニタリングツールです。DockerやK8sとの相性が良く、幅広いメトリクスを監視できます。標準では可視化機能がないため、Grafanaと組み合わせて利用されることが多いです。コンテナ化されたアプリやマイクロサービスも監視可能です。
Jaegerはトレーシングシステムとして世界的に評価されています。Uberが開発したオープンソースで、分散トランザクションのトラブルシューティングや即時監視に適しています。ソフトウェアのレイテンシ最適化やコンテキスト伝播などの問題を見つけるのに役立ちます。
Go言語で構築されたKubewatchは、非常に使いやすいオープンソースのK8s監視ツールとして知られています。操作画面がシンプルで、初心者でも問題なく扱えます。コラボレーションツールとクラスタ間の即時連携を可能にします。
K8sのモニタリングは非常に重要ですが、正しい方法で実施しないと大きな成果は得られません。以下は、モニタリングを行ううえで押さえておきたいポイントです。
マイクロサービスの場合、CPUやメモリなどリソース単位の細かいメトリクスをすべて追跡すると複雑になりがちです。より効果的なのは、レイテンシやリクエスト数、エラー率といったAPI関連のメトリクスを追跡することです。
これらのメトリクスを即時で把握できれば、REST APIやNginx、Istioなどに存在する不具合や脆弱性を迅速に検知できます。サービスレベルのメトリクスはすべてのK8sサービスで一定の精度を保ち、監視を一貫化してくれます。
高いディスク使用率を見つけても放置してしまうと、やがて大きな障害につながる恐れがあります。修正が難しい場合でも、できるだけ早く対応することが大切です。アラートの閾値は75〜85%に設定するのがおすすめです。
ディスク消費を正確に把握するため、すべてのディスクボリュームを監視対象に含めるとよいでしょう。ルートファイルシステムも例外ではありません。
Kubernetesを稼働させる際は、K8s上で動いていない要素であっても、最終的なエンドユーザー体験に注意を払う必要があります。K8sがユーザーにどのような影響を与えるかも重要な監視項目です。
エンドユーザーの体験を判断するには、合成モニタリングやリアルユーザーモニタリングのデータが役立ちます。これらのデータを分析すれば、ユーザーがKubernetesワークロードにどのようにアクセスしているのか、アプリの応答性能や使いやすさはどうかなどを把握できるでしょう。
Kubernetesがクラウド上にデプロイされている場合は、IAMイベントやクラウドAPI、ネットワーク性能、コストなどクラウド特有の要因もモニタリングの対象に含める必要があります。
具体的には、IAMイベント(ログイン失敗や権限変更)やネットワークのパフォーマンスが考慮すべき要素です。Kubernetesの継続的デプロイを行っている場合は特に、クラウド環境に合わせたモニタリング戦略を構築しましょう。
最新情報を購読