Alibaba Cloud Container Service for Kubernetes (ACK) は、カーネルレベルのモニタリングデータを提供することでコンテナメモリ問題の可視性を向上させるツールである SysOM を提供します。これにより、コンテナエンジンレイヤーでの問題診断の透明性が高まり、コンテナ移行プロセスを効率化できます。本記事では、SysOM を使用してコンテナメモリ問題を診断する方法について説明します。
前提条件
-
2021年10月以降に作成された ACK マネージドクラスター または ACK サーバーレスクラスター を作成済みであること。クラスターバージョンは 1.18.8 以降である必要があります。クラスターをアップグレードする方法については、「クラスターの手動アップグレード」をご参照ください。
-
Prometheus Service for Alibaba Cloud を有効化済みであること。
-
ack-sysom-monitor 機能が有効化されている必要があります。詳細については、「ack-sysom-monitor 機能の有効化」をご参照ください。
課金
ack-sysom-monitor 機能を有効にすると、コンポーネントは自動的に監視メトリクスを Prometheus Service for Alibaba Cloud に送信します。これらのメトリクスは カスタムメトリクス として課金され、追加料金が発生します。
予期しない料金が発生しないように、この機能を有効にする前に Prometheus Service for Alibaba Cloud の課金の概要 を確認し、カスタムメトリクスの料金体系を理解してください。料金は、クラスターのサイズやアプリケーションの数などの要因によって変動する場合があります。リソース消費 機能を使用して、リソースの使用状況を監視および管理できます。
背景情報
コンテナ化は、コスト削減、効率向上、柔軟性、スケーラビリティの観点から、エンタープライズ IT アーキテクチャのベストプラクティスとなっています。
しかし、コンテナ化はコンテナエンジンレイヤーの不透明性ももたらし、メモリ使用量が過剰になり、制限を超えて Out of Memory (OOM) 問題を引き起こす可能性があります。
Alibaba Cloud Container Service for Kubernetes (ACK) チームは、Alibaba Cloud GuestOS チームと協力し、オペレーティングシステムカーネルレベルのコンテナ監視機能を使用して、メモリ使用量を正確に制御し、OOM 問題を防ぎます。
コンテナメモリのコンポーネント
コンテナのメモリは、アプリケーションメモリ、カーネルメモリ、空きメモリで構成されます。
|
メモリのカテゴリ |
メモリのサブカテゴリ |
説明 |
|
アプリケーションメモリ |
アプリケーションメモリは、以下のコンポーネントで構成されます。
|
実行中のアプリケーションが使用するメモリ。 |
|
カーネルメモリ |
カーネルメモリは、以下のコンポーネントで構成されます。
|
オペレーティングシステムカーネルが使用するメモリ。 |
|
空きメモリ |
N/A |
未使用で使用可能なメモリ。 |
仕組み
Kubernetes はワーキングセットを使用して、コンテナのメモリ使用量を監視および管理します。コンテナのメモリ消費量が設定された制限を超えたり、ノードがメモリプレッシャーに直面したりすると、Kubernetes はワーキングセットを使用してコンテナをエビクトするか終了するかを決定します。SysOM で Pod のワーキングセットを監視することで、より包括的で正確なメモリ分析が可能になります。これにより、運用チームはワーキングセットの使用率が高い問題に迅速に対処し、コンテナのパフォーマンスと安定性を向上させることができます。
ワーキングセットとは、コンテナが特定の時間枠内でアクティブに使用しているメモリの部分、つまり現在の操作に必要なメモリを指します。これは、次の数式を使用して計算されます：ワーキングセット = inactive_anon + active_anon + active_file。この数式では、inactive_anon と active_anon はアプリケーションの匿名メモリの合計サイズを表し、active_file はアプリケーションのアクティブなファイルキャッシュのサイズを表します。このレベルの分析は、運用チームがリソースをより効果的に管理し、アプリケーションの安定性を確保するのに役立ちます。
SysOM 機能の使用
SysOM は、Pod とノードに対して OS カーネルレベルのモニタリングダッシュボードを提供し、メモリ、ネットワーク、ストレージのシステムレベルのメトリクスをリアルタイムで監視できます。SysOM で利用可能なメトリクスの詳細については、「SysOM カーネルレベルのコンテナ監視」をご参照ください。
ACK コンソールにログインします。左側のナビゲーションウィンドウで、クラスターリスト をクリックします。
クラスターリスト ページで、対象のクラスター名をクリックします。左側のナビゲーションウィンドウで、 をクリックします。
-
Prometheus 監視 ページで、SysOM システムオブザーバビリティ タブをクリックし、次に SysOM コンテナシステムの監視 - ポッドディメンション タブをクリックして、ダッシュボードで Pod のメモリデータを表示します。
以下の数式は、メモリブラックホール問題の診断に役立ちます。
Pod の合計メモリ = 常駐セットサイズ (RSS) + Cache ≈ inactive_anon + active_anon + inactive_file + active_file
ワーキングセット = inactive_anon + active_anon + active_file
-
[Pod Memory Monitor] セクションで、Pod の合計メモリの数式を使用して、Pod のメモリをキャッシュと RSS に分解できます。次に、キャッシュ (
active_file、inactive_file、shmem(共有メモリ) で構成) と RSS (active_anon、inactive_anonで構成) の構成比率を表示できます。次の図に示すように、inactive_anon メモリが最も大きな割合を占めています。
-
[Pod Resource Analysis] セクションで、top ツールを使用して、クラスター内で最も多くの InactiveAnon メモリを消費している Pod をすばやく見つけます。
次の図に示すように、arms-prom Pod のメモリ消費量が最も高くなっています。
-
[Pod Memory Details] セクションで、Pod の詳細なメモリ構成を表示します。ダッシュボードには、Pod Cache、InactiveFile (非アクティブなファイルキャッシュ使用量)、InactiveAnon (非アクティブな匿名メモリ使用量)、ダーティメモリ (システムのダーティメモリ使用量) など、さまざまなメモリコンポーネントが表示されます。これにより、一般的な Pod のメモリブラックホール問題を特定できます。
-
-
[Pod File Cache] セクションで、キャッシュメモリ使用量が高い原因を特定します。
Pod のメモリキャッシュが大きい場合、そのワーキングセットの使用量が増加する可能性があります。このキャッシュされたメモリは、Pod のワーキングセット内でメモリブラックホールとなり、アプリケーションのパフォーマンスに悪影響を与える可能性があります。
-
メモリブラックホール問題を修正します。
コンテナのメモリブラックホール問題を特定した後、ACK のきめ細かなスケジューリング機能を使用して解決できます。詳細については、「コンテナメモリ QoS の有効化」をご参照ください。
関連ドキュメント
-
SysOM で利用可能なメトリクスの詳細については、「SysOM カーネルレベルのコンテナ監視」をご参照ください。
-
ACK コンテナメモリ QoS によって有効化されるカーネル機能の詳細については、「カーネル機能とインターフェイスの概要」をご参照ください。