すべてのプロダクト
Search
ドキュメントセンター

Container Service for Kubernetes:SysOMを使用したコンテナーメモリの問題の特定

最終更新日:Dec 12, 2024

コンテナエンジン層はユーザーに透過的ではないため、コンテナサービス障害のトラブルシューティングは困難です。 この問題に対処するために、Container Service for Kubernetes (ACK) はOSカーネルレベルのコンテナーモニタリング機能を提供し、コンテナーエンジン層の信頼性と透過性を高めます。 これにより、コンテナ化されたアプリケーションを効率的に移行できます。 このトピックでは、System Observer Monitoring (SysOM) を使用してコンテナーメモリの問題を特定する方法について説明します。

前提条件

ack-sysom-monitorの請求

ack-sysom-monitorコンポーネントを有効にすると、関連コンポーネントは自動的にManaged Service for Prometheusにモニタリングメトリックを送信します。 これらのメトリックはカスタムメトリックと見なされます。 カスタム指標には料金がかかります。

この機能を有効にする前に、課金の概要を読んで、カスタムメトリクスの課金ルールを理解することをお勧めします。 料金は、クラスターサイズとアプリケーション数によって異なります。 リソース使用量の表示の手順に従って、リソース使用量を監視および管理できます。

シナリオ

多くの企業はコンテナ化を使用してITアーキテクチャを構築し、コストを削減し、効率を高め、柔軟性とスケーラビリティを向上させています。

しかしながら、コンテナ化は、コンテナエンジン層の透明性を損ない、メモリ不足 (OOM) の問題などの問題を引き起こす。 Kubernetesのポッドが過剰なメモリを占有し、メモリ使用量が上限を超えると、OOMの問題が発生します。

この問題を解決するために、Container Service for Kubernetes (ACK) チームは、Alibaba CloudのGuestOSチームと協力して、OSカーネルレベルのコンテナモニタリング機能を提供します。 これらの機能は、コンテナーのメモリ使用量をより適切に管理および最適化し、メモリ不足によるOOMの問題を回避するのに役立ちます。

コンテナメモリ

コンテナのメモリは、アプリケーションメモリ、カーネルメモリ、空きメモリで構成されます。

メモリカテゴリ

メモリタイプ

説明

アプリケーションメモリ

アプリケーションメモリは、次のタイプで構成されます。

  • anon: ファイルに関連付けられていない匿名メモリ。 たとえば、プロセス内のヒープ、スタック、およびデータセグメントには匿名メモリが使用されます。 ヒープメモリは、brkおよびmmapによって割り当てられる。

  • filecache: ディスクから読み取られ、ディスクに書き込まれたファイルデータをキャッシュするために使用されるメモリ。 頻繁に使用されるキャッシュはアクティブファイルキャッシュと呼ばれ、通常はシステムによって再利用されません。

  • buffer: ブロックデバイスとファイルシステムのメタデータを格納するために使用されるメモリ。

  • hugetlb: ファイルシステム内の巨大なページによって占有されるメモリ。

実行中のアプリケーションが占有するメモリ。

カーネルメモリ

カーネルメモリは、次のタイプで構成されます。

  • スラブ: カーネルオブジェクトのメモリ割り当てを管理するために使用されるキャッシュメモリアロケータ。

  • Vmalloc: 仮想メモリ空間に大きなメモリ領域を割り当てるために使用されるカーネルメカニズム。

  • allocpage: ローカルメモリを割り当てるために使用されるメカニズム。

  • その他: KernelStack、PageTables、およびReserve。

OSカーネルが使用するメモリ。

フリーメモリ

なし。

使用されていないメモリ。

仕組み

Kubernetesは、メモリワーキングセットを使用して、コンテナーが占有するメモリを監視および管理します。 コンテナによって占有されるメモリが指定されたメモリ上限を超えた場合、またはノードで使用可能なメモリが不足した場合、Kubernetesは、メモリワーキングセットに基づいてコンテナを削除するか強制終了するかを決定します。 SysOMを使用すると、メモリワーキングセットが大きいポッドを特定し、包括的かつきめ細かい方法でメモリ使用量を監視および分析できます。 このようにして、O&Mエンジニアと開発者は、メモリワーキングセットが大きいポッドをすばやく見つけて修正し、コンテナのパフォーマンスと安定性を向上させることができます。

コンテナのメモリワーキングセットは、ある期間内にコンテナによって占有されるメモリの量を指す。 メモリは、期待どおりに実行するためにコンテナに必要です。 メモリワーキングセット=InactiveAnon + ActiveAnon + ActiveFile。 アプリケーションの匿名メモリの総量は、InactiveAnonとActiveAnonの合計に等しくなります。 ActiveFileは、アプリケーションのアクティブファイルキャッシュのサイズに等しい。

SysOM機能の使用

SysOMのOSカーネルレベルのダッシュボードを使用すると、ポッドやノードのメモリ、ネットワーク、ストレージメトリクスなどのシステムメトリクスをリアルタイムで表示できます。 SysOMメトリックの詳細については、「SysOMに基づくカーネルレベルのコンテナーモニタリング」をご参照ください。

  1. ACKコンソールにログインします。 左側のナビゲーションウィンドウで、[クラスター] をクリックします。

  2. [クラスター] ページで、管理するクラスターの名前をクリックします。 左側のウィンドウで、[操作] > [Prometheusモニタリング] を選択します。

  3. [Prometheusモニタリング] ページで、[その他] タブをクリックし、[ACK Sysom Pod Kernel Resource Monitor] タブをクリックして、ポッドのメモリ分布をダッシュボードに表示します。

    次の式を使用して、不足しているメモリ問題を見つけます。メモリワーキングセット=InactiveAnon + ActiveAnon + ActiveFile。

    1. SysOMが提供するダッシュボードのPodメモリ分布の円グラフには、OSカーネルレベルのポッドメモリ分布が表示されます。 円グラフのinactive_anonactive_anon、およびactive_fileのメモリタイプのサイズを比較し、最大の割合を占めるメモリタイプを見つけます。

      次の図に示すように、inactive_anonメモリタイプが最大の割合を占めます。

      image.png

    2. [ポッドリソース分析] セクションで、トップコマンドを使用して、クラスター内で最もInactiveAnonメモリを占有しているポッドを見つけます。

      次の図に示すように、arms-promポッドは最も非アクティブなAnonメモリを占有します。

      image.png

    3. [ポッドメモリの詳細] セクションでは、ポッドのメモリ使用量の詳細を表示できます。 ポッドキャッシュ、InactiveFile、InactiveAnon、Dirty memoryなど、ダッシュボードに表示されるポッドのメモリメトリクスに基づいて、ポッド内の一般的なメモリ不足の問題を特定できます。

      image.png

  4. [ポッドファイルキャッシュ] セクションで、大容量のキャッシュメモリの原因を特定します。

    ポッドが大量のメモリを占有すると、ポッドのメモリワーキングセットが実際の使用中のメモリサイズを超える可能性があります。 メモリ不足の問題は、ポッドが属するアプリケーションのパフォーマンスに悪影響を及ぼします。

    image.png

  5. メモリ不足の問題を修正します。

    ACKが提供するきめ細かいスケジューリング機能を使用して、メモリ不足の問題を修正できます。 詳細については、「コンテナーのメモリQoS」をご参照ください。

関連ドキュメント