AKS クラスターのメモリ飽和状態のトラブルシューティング

この記事では、メモリ飽和の問題をトラブルシューティングする方法について説明します。 メモリの飽和は、少なくとも 1 つのアプリケーションまたはプロセスでコンテナー ホストが提供できるメモリよりも多くのメモリが必要な場合、またはホストが使用可能なメモリを使い果たした場合に発生します。

前提条件

• Kubernetes kubectl コマンドライン ツール。 Azure CLI を使用して kubectl をインストールするには、az aks install-cli コマンドを実行します。

現象

次の表は、メモリの飽和の一般的な症状の概要を示しています。

現象	説明
スケジュールできないポッド	ノードが設定されたメモリ制限に近い場合、追加のポッドをスケジュールすることはできません。
ポッドの削除	ノードのメモリが不足している場合、kubelet はポッドを削除できます。 コントロール プレーンは、リソースを持つ他のノードで削除されたポッドのスケジュールを変更しようとしますが、他のノードがこれらのポッドを実行するのに十分なメモリを持っているという保証はありません。
ノードの準備ができていない	メモリの飽和により、 kubelet と containerd が応答しなくなり、最終的にノードの準備の問題が発生する可能性があります。
メモリ不足 (OOM) の強制終了	ポッドの削除がノードの問題を防ぐことができない場合、OOM の問題が発生します。

トラブルシューティングのチェックリスト

メモリの飽和を減らすには、効果的な監視ツールを使用し、ベスト プラクティスを適用します。

手順 1: メモリ飽和状態のノードを特定する

メモリ飽和状態のノードを識別するには、次のいずれかの方法を使用します。

• Web ブラウザーで、Azure portal で AKS の Container Insights 機能を使用します。

• コンソールで、Kubernetes コマンド ライン ツール (kubectl) を使用します。

ブラウザー

Container Insights は、コンテナー ワークロードのパフォーマンスを監視する AKS 内の機能です。 詳細については、「 Azure Kubernetes Service (AKS) クラスターのコンテナー分析情報を有効」を参照してください。

1. Azure ポータルでKubernetes サービス検索して選択。

2. Kubernetes サービスの一覧で、クラスターの名前を選択します。

3. クラスターのナビゲーション ウィンドウで、 Monitoring 見出しを見つけて、 Insights を選択します。

4. 適切な Time Range 値を設定します。

5. Nodes タブを選択します。

6. Metric リストで、Memory ワーキング セット (Allocatable から計算) を選択。

7. パーセンタイル セレクターで、サンプルを Max に設定し、 Max % 列ラベルを 2 回選択します。 このアクションにより、使用されたメモリの最大割合 (最大値から最小値) でテーブル ノードが並べ替えられます。

   

   テーブルには 4 つの行があり、AKS エージェント プール仮想マシン スケール セット内の 4 つのノードを表します。 状態はすべて **Ok** で、使用されるメモリの最大割合は 64 ~ 58% で、使用される最大メモリは 2.6 GB から 2.86 GB、使用されるコンテナーの数は 20 ~ 24、稼働時間は 6 ~ 15 日です。 コントローラーは表示されません。

8. 最初のノードのメモリ使用量が最も多いため、そのノードを選択して、ノードで実行されているポッドのメモリ使用量を調査します。

   

   ノードの下に 9 つのプロセスが一覧表示されます。 状態はすべて **Ok** で、プロセスに使用されるメモリの最大割合は 16 ~ 0.3% で、使用される最大メモリは 0.7 mc から 22 mc、使用されるコンテナーの数は 1 から 3、アップタイムは 3 ~ 4 日です。 ノードとは異なり、すべてのプロセスに対応するコントローラーが一覧表示されます。 このスクリーンショットでは、コントローラー名はプロセス名のプレフィックスであり、ハイパーリンクが設定されています。

   Note

   ポッドの CPU またはメモリ使用量の割合は、コンテナーに指定された CPU 要求に基づいています。 ノードの CPU またはメモリ使用量の割合は表しません。 そのため、ポッドの CPU またはメモリ使用量の割合ではなく、実際の CPU またはメモリ使用量を確認します。

コマンド ライン

この手順では、コンソールで kubectl コマンドを使用します。 ノードの現在の状態のみが表示されます。

1. kubectl top node コマンドを実行して、ノードのメモリ使用量を取得します。

   kubectl top node
   

   このコマンドの出力は、次のテキストのようになります。

   NAME                                 CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
   aks-agentpool-30486455-vmss000003    239m         12%    3148Mi          69%
   aks-agentpool-30486455-vmss000005    326m         17%    2143Mi          46%
   aks-testmemory-30616462-vmss000000   66m          3%     1532Mi          28%
   aks-testmemory-30616462-vmss000001   90m          4%     1689Mi          31%
   aks-testmemory-30616462-vmss000002   74m          3%     1715Mi          31%
   

2. ノードで実行されているポッドとそのメモリ使用量の一覧を取得するには、 kubectl get pods と kubectl top pods コマンドを実行します。

   kubectl get pods --all-namespaces --output wide \
       | grep <node-name> \
       | awk '{print $1" "$2}' \
       | xargs -n2 kubectl top pods --namespace \
       | awk 'NR==1 || NR%2==0' \
       | sort -k3n \
       | column -t
   

   Note

   このコード スニペットでは、 <node-name> を実際のノード名に置き換えます。

   コード スニペットの出力は、次のテキストのようになります。

   NAME                                 CPU(cores)   MEMORY(bytes)
   coredns-autoscaler-5655d66f64-9fp2k  1m           7Mi
   shippingservice-7946db7679-qzplg     6m           15Mi
   azure-ip-masq-agent-tb8xv            1m           16Mi
   cloud-node-manager-wggqd             1m           16Mi
   kube-proxy-c244z                     1m           22Mi
   coredns-59b6bf8b4f-5zg5s             3m           24Mi
   coredns-59b6bf8b4f-5x62d             3m           25Mi
   currencyservice-7977f668dc-rvbwm     12m          32Mi
   csi-azurefile-node-9fcx8             2m           38Mi
   metrics-server-5f8d84558d-frsq4      4m           42Mi
   metrics-server-5f8d84558d-rc5nj      4m           43Mi
   csi-azuredisk-node-9fh7h             2m           46Mi
   adservice-795589cf6f-xs66r           4m           87Mi
   ama-metrics-node-54sfj               16m          249Mi
   ama-logs-rs-6db98d6dff-vj4xw         13m          259Mi
   ama-logs-w5bmd                       12m          403Mi
   

3. kubectl describe node コマンドを実行して、ノード上の各ポッドの要求と制限を確認します。

   kubectl describe node <node-name>
   

   このコマンドの出力は、次のテキストのようになります。

     Namespace    Name                                 CPU Requests  CPU Limits  Memory Requests  Memory Limits  Age
     ---------    ----                                 ------------  ----------  ---------------  -------------  ---
     default      adservice-795589cf6f-dgrx7           200m (10%)    300m (15%)  180Mi (3%)       300Mi (6%)     49m
     default      cartservice-6d994d9676-tcr6m         200m (10%)    300m (15%)  64Mi (1%)        128Mi (2%)     49m
     default      frontend-848d9f9dc9-x712b            100m (5%)     200m (10%)  64Mi (1%)        128Mi (2%)     49m
     default      loadgenerator-5c9656f8d6-7vmjr       300m (15%)    500m (26%)  256Mi (5%)       512Mi (11%)    38m
     default      redis-cart-799c85c644-vzpjl          70m (3%)      125m (6%)   200Mi (4%)       256Mi (5%)     49m
     kube-system  ama-logs-zs4qf                       150m (7%)     1 (52%)     550Mi (12%)      1774Mi (38%)   16h
     kube-system  azure-ip-masq-agent-rqqpn            100m (5%)     500m (26%)  50Mi (1%)        250Mi (5%)     16h
     kube-system  cloud-node-manager-nbnrq             50m (2%)      0 (0%)      50Mi (1%)        512Mi (11%)    16h
     kube-system  coredns-59b6bf8b4f-m2prf             100m (5%)     3 (157%)    70Mi (1%)        500Mi (10%)    16h
     kube-system  csi-azuredisk-node-h445m             30m (1%)      0 (0%)      60Mi (1%)        400Mi (8%)     16h
     kube-system  csi-azurefile-node-489cp             30m (1%)      0 (0%)      60Mi (1%)        600Mi (13%)    16h
     kube-system  konnectivity-agent-665c7dfdb8-25p2f  20m (1%)      1 (52%)     20Mi (1%)        1Gi (22%)      15h
     kube-system  kube-proxy-v9gp4                     100m (5%)     0 (0%)      0 (0%)           0 (0%)         16h
   Allocated resources:
     ...
   

   Note

   ノードの CPU またはメモリ使用量の割合は、実際のノード容量ではなく、ノード上の割り当て可能なリソースに基づいています。

高いメモリを使用しているポッドを特定したので、ポッドで実行されているアプリケーションを識別できます。

手順 2: メモリの飽和を回避するためのベスト プラクティスを確認する

メモリの飽和を回避するためのベスト プラクティスを実装する方法については、次の表を参照してください。

ベスト プラクティス	説明
メモリ 要求と制限を使用する	Kubernetes には、コンテナーの最小メモリ サイズ (request) と最大メモリ サイズ (limit) を指定するオプションが用意されています。 ポッドに制限を構成することで、ノードのメモリ不足を回避できます。 実行されているすべてのポッドの制限の集計が、ノードの使用可能なメモリを超えないようにしてください。 この状況は、 overcommitting と呼ばれます。 Kubernetes スケジューラは、 サービスの品質 (QoS) を通じて、設定された要求と制限に基づいてリソースを割り当てます。 適切な制限がない場合は、スケジューラが 1 つのノードで多数のポッドをスケジュールしすぎる可能性があります。 その場合、最終的にノードがダウンする可能性があります。 さらに、kubelet はポッドを削除する際、メモリ使用量が定義済みの要求を超えているポッドを優先的に削除します。 メモリ要求は、実際の使用量に近い値に設定することをお勧めします。
horizontal ポッド オートスケーラーを有効にする	クラスターをスケーリングすることで、多数のポッド間で要求のバランスを取り、メモリ飽和状態を防ぐことができます。 この手法により、特定のノードのメモリ占有領域を減らすことができます。
anti-affinity タグを使用する	メモリが設計上制限されていないシナリオでは、ノード セレクターとアフィニティ タグまたはアンチアフィニティ タグを使用できます。これにより、ワークロードを特定のノードに分離できます。 アンチアフィニティ タグを使用すると、他のワークロードがそれらのノードでポッドをスケジュールできないようにすることができます。 これにより、メモリ飽和状態の問題が軽減されます。
higher SKU VM を選択する	高いメモリ使用量を処理するには、ランダム アクセス メモリ (RAM) が多い仮想マシン (VM) のほうが適しています。 このオプションを使用するには、新しいノード プールを作成し、ノードを遮断し (それらをスケジュール不可にし)、既存のノード プールをドレインする必要があります。
システムとユーザーのワークロードを分離する	アプリケーションはユーザー ノード プールで実行することをお勧めします。 この構成により、Kubernetes 固有のポッドをシステム ノード プールに分離し、クラスターのパフォーマンスを維持することができます。

詳細

• Azure Kubernetes Service (AKS) のベスト プラクティスの詳細を確認する

• Container insights を使用して Kubernetes クラスターのパフォーマンスを監視する

サードパーティの情報に関する免責事項

この資料に記載されているサードパーティ製品は、マイクロソフトと関連のない他社の製品です。 明示的か黙示的かにかかわらず、これらの製品のパフォーマンスや信頼性についてマイクロソフトはいかなる責任も負わないものとします。

サードパーティのお問い合わせ窓口に関する免責事項

サードパーティのお問い合わせ窓口に関する情報は、ユーザーの便宜のために提供されているものであり、 この連絡先情報は、予告なしに変更される可能性があります。 マイクロソフトは、掲載されている情報に対して、いかなる責任も負わないものとします。

お問い合わせはこちらから

質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティ サポートにお問い合わせください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。