AKSノード上でのOOMKillの挙動と調査方法

Last Update: feedback 共有

この記事はMicrosoft Azure Tech Advent Calendar 2023 の 17 日目の記事になります。

こんにちは、 Azure テクニカル サポート チームの高田です。
AKS(に限らず、Kubernetes全般)を利用する際に難しいことの一つとして、メモリの割り当てや制限の管理があります。
ノードやその上のメモリ(を確保するための予算)にも限りがあるので
必要十分で済ませようとしたものの、思わぬときにOOMKillでワークロードに
影響が発生した、という経験をされた方も多いかと思います。

この記事では、OOMKillが発生したときにせめて速やかに対処できるよう、
OOMKillの際の挙動やこれに基づく原因調査方法について
いくつかのトピックを紹介させて頂きます。

扱うトピック、扱わないトピック

本記事では、AKSノード上に配置されたPodのメモリ利用に起因してOOMKillが発生した場合の
挙動や、原因の調査方法を紹介します。

そもそもノードのリソース不足でPodがスケジューリングされない(Pendingのままとなる)場合につきましては
スコープ外とさせて頂きますのでご了承下さい。

2種類のメモリ利用制限

AKSノード上でPodがメモリを確保・利用する際、Pod・コンテナーレベル、
ノードレベルの2つの観点にて利用量が制限されます。OOMKillは各レベルで発生し得ます。

Pod・コンテナーレベルでの制限・OOMKill

Pod内のコンテナーが確保・利用可能なメモリの上限は、Podのmanifest(YAML)中の
spec.containers[].resources.limits.memoryにて指定できます。
コンテナーがこの制限を超えてメモリを確保・利用しようとした場合に、OOMKillが発生します。

(設定方法や考え方については下記のドキュメント等をご参照下さい)

Azure Kubernetes Service (AKS) でリソースを管理するアプリケーション開発者のベスト プラクティス

コンテナおよびPodへのメモリーリソースの割り当て

コンテナのリソース管理

ノードレベルでの制限・OOMKill

Podがノードにスケジュールされる際、ノードが提供可能なメモリが
Pod・コンテナーに対して十分か否かの判定は、spec.containers[].resources.limits.memory
(制限)ではなく、spec.containers[].resources.requests.memory(要求)に基づいて
行われます。このため、あるノード上にスケジュールされたPod・コンテナーの
制限値の合計が、実際にそのノード上で利用可能なメモリ量よりはるかに多い、ということが
起こり得ます。

この場合、まず、 Pod・コンテナーによるメモリ使用量の合計が割り当て可能(Allocatable)な
メモリ量を超えた時点で、evict(退去)によるメモリ逼迫の解消が試みられます。
ただ、evict(退去)が間に合わず、メモリ使用量が割り当て可能なメモリ量 + eviction-threshold
の値を超過した場合に、ノードレベルでのOOMKillが発生します。

割り当て可能なメモリ量は、ノードに搭載されている(=VMサイズにて提供される)
メモリ量から、 kube-reserved, system-reserved, 前述のeviction-thresholdの値を
引いた値となっています。

Reserve Compute Resources for System Daemons: Node Allocatable

AKS(Kubernetes バージョン1.28以下)の場合、eviction-thresholdは750MiB、kube-reservedは
ノードに搭載されているメモリ量に基づき一定の法則にて算出された値の量となります。
(system-reservedは定義されていません)

Azure Kubernetes Services (AKS) における Kubernetes の中心概念:
メモリ

ノードに搭載されているメモリ量、割り当て可能な量は各々、kubectl describe nodeコマンドの出力中の
Capacityの項、Allocatableの項などにて確認できます。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
$ kubectl describe node <ノード名>
(略)
Capacity:
  cpu:                2
  ephemeral-storage:  129886128Ki
  hugepages-1Gi:      0
  hugepages-2Mi:      0
  memory:             4007948Ki
  pods:               110
Allocatable:
  cpu:                1900m
  ephemeral-storage:  119703055367
  hugepages-1Gi:      0
  hugepages-2Mi:      0
  memory:             2191372Ki
  pods:               110
(略)

Pod・コンテナーの情報でわかること、わからないこと

あるコンテナーに関してOOMKillによるコンテナーの再起動が発生した場合、
コンテナーの過去の状態としてそのことが記録されます。

1
2
3
4
5
6
7
8
$ kubectl describe pod <Pod名>
(略)
  <コンテナー名>:
    Last State:     Terminated
      Reason:       OOMKilled
      Exit Code:    0
      Started:      Wed, 13 Dec 2023 06:23:20 +0000
      Finished:     Wed, 13 Dec 2023 06:23:21 +0000

ただ、これのみでは、OOMKillが発生した原因
(Pod・コンテナーレベルかノードレベルか)はわかりません。
また、コンテナー内の子プロセスが大量にメモリを使用していた場合、
その子プロセスがOOMkillの対象となることがありますが、
このとき他のプロセスが動作を継続していた場合は、
そもそもコンテナーの再起動とならず、kubectl describe podコマンドなどでは
確認できません。
(このときの挙動については後述します)

ノードの情報にてわかること、わからないこと

ノードレベルでメモリの逼迫が発生していた場合、
ノードの情報(kubectl describe node)やイベントとして、
NodeHasInsufficientMemory を確認できます。

1
2
3
4
5
$ kubectl describe node <ノード名>
Events:
  Type     Reason                     Age                   From            Message
  ----     ------                     ----                  ----            -------
  Normal   NodeHasInsufficientMemory  9m33s (x2 over 18m)   kubelet         Node <ノード名> status is now: NodeHasInsufficientMemory
1
2
3
4
5
$ kubectl get events
LAST SEEN   TYPE      REASON                      OBJECT               MESSAGE
(略)
8m21s       Warning   EvictionThresholdMet        node/<ノード名>       Attempting to reclaim memory
10m         Normal    NodeHasInsufficientMemory   node/<ノード名>       Node <ノード名> status is now: NodeHasInsufficientMemory

これらの情報は、あくまでもこのタイミングでメモリの逼迫が発生していた、ということを示すものであり、
同時期にOOMKillが発生していた場合にも、それがPod・コンテナーレベルのものである可能性は
否定できません。ただ、いずれにせよメモリの逼迫が発生していたことには違いないので、
要求(requests)の見直しや、これとあわせてのノードの増強などを検討すべき、という
判断は可能です。

ノードのログからわかること

とはいえ、関係者への説明のためなど、確実に原因を特定したい場合もあるかと思います。
そのような場合は、ノードのログを見ることでPod・コンテナーレベルか
ノードレベルか確認・判断することができます。

OOMKillはLinuxカーネルの機能により実行されるため、OOMKillが発生した際には
ノードのログ(/var/log/syslog, /var/log/kern.log など)にメッセージが出力されます。
下記の例のように、OOMKillが発生した際には<プロセス名>　invoked oom-killer
から始まり、ハードウェア情報、発生時のスタック情報、メモリ利用状況など、
様々な情報が出力されます。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.036951] stress-ng-vm invoked oom-killer: gfp_mask=0xcc0(GFP_KERNEL), order=0, oom_score_adj=1000
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.036958] CPU: 1 PID: 716580 Comm: stress-ng-vm Not tainted 5.15.0-1051-azure #59-Ubuntu
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.036961] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090008  12/07/2018
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.036962] Call Trace:
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.036964]  <TASK>
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.036967]  show_stack+0x52/0x5c
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.036973]  dump_stack_lvl+0x38/0x4d
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.036978]  dump_stack+0x10/0x16
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.036980]  dump_header+0x53/0x228
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.036984]  oom_kill_process.cold+0xb/0x10
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.036986]  out_of_memory+0x106/0x2e0
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.036989]  mem_cgroup_out_of_memory+0x13f/0x160
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.036992]  try_charge_memcg+0x6cd/0x790
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.036995]  charge_memcg+0x45/0xa0
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.036997]  __mem_cgroup_charge+0x2d/0x90
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037000]  do_anonymous_page+0x104/0x4c0
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037003]  handle_pte_fault+0x21b/0x260
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037006]  __handle_mm_fault+0x409/0x760
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037009]  ? sched_clock+0x9/0x10
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037014]  handle_mm_fault+0xc8/0x2a0
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037017]  do_user_addr_fault+0x1bc/0x660
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037020]  exc_page_fault+0x71/0x160
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037024]  asm_exc_page_fault+0x27/0x30
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037027] RIP: 0033:0x55fbbb223b65
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037031] Code: 98 00 41 54 49 89 fa 55 48 89 cd 48 01 fa 53 4c 8b 59 10 4c 39 ca 0f 83 01 01 00 00 31 c9 0f 1f 80 00 00 00 00 89 cf 83 c1 01 <40> 88 3a 48 8b 3d 99 f7 98 00 48 01 fa 4c 39 ca 72 e9 48 89 f0 31
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037033] RSP: 002b:00007ffd1b287520 EFLAGS: 00010206
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037035] RAX: 0000000000000010 RBX: 00007f1d90825000 RCX: 0000000000734f41
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037036] RDX: 00007f1dad562000 RSI: 0000000040000000 RDI: 0000000000734f40
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037038] RBP: 00007f1dd2c1e398 R08: 0000000000000000 R09: 00007f1dd0825000
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037039] R10: 00007f1d90825000 R11: 0000000000000000 R12: 0000000040000000
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037040] R13: 0000000000000000 R14: 00007ffd1b287670 R15: 000055fbbb2224b0
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037044]  </TASK>
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037045] memory: usage 512000kB, limit 512000kB, failcnt 37
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037046] swap: usage 0kB, limit 9007199254740988kB, failcnt 0
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037047] Memory cgroup stats for /kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod479f327f_a27b_4eda_8523_90bdabcf0a27.slice:
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037069] anon 484630528
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037069] file 37752832
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037069] kernel_stack 65536
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037069] pagetables 1212416
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037069] percpu 11752
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037069] sock 0
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037069] shmem 37720064
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037069] file_mapped 37720064
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037069] file_dirty 0
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037069] file_writeback 0
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037069] swapcached 0
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037069] anon_thp 0
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037069] file_thp 0
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037069] shmem_thp 0
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037069] inactive_anon 522346496
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037069] active_anon 4096
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037069] inactive_file 16384
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037069] active_file 16384
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037069] unevictable 0
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037069] slab_reclaimable 303008
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037069] slab_unreclaimable 210008
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037069] slab 513016
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037069] workingset_refault_anon 0
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037069] workingset_refault_file 0
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037069] workingset_activate_anon 0
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037069] workingset_activate_file 0
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037069] workingset_restore_anon 0
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037069] workingset_restore_file 0
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037071] Tasks state (memory values in pages):
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037072] [  pid  ]   uid  tgid total_vm      rss pgtables_bytes swapents oom_score_adj name
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037073] [ 716518] 65535 716518      243        1    28672        0          -998 pause
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037077] [ 716566]     0 716566    13966    10178   139264        0           975 stress-ng
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037079] [ 716579]     0 716579    13967      424    73728        0          1000 stress-ng-vm
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037082] [ 716580]     0 716580   276111   118439  1015808        0          1000 stress-ng-vm
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037084] oom-kill:constraint=CONSTRAINT_MEMCG,nodemask=(null),cpuset=cri-containerd-679f9845995b4ae4812789eb3c3d1df88040a1bc3f0c046a05c9aa9b5b5f93be.scope,mems_allowed=0,oom_memcg=/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod479f327f_a27b_4eda_8523_90bdabcf0a27.slice,task_memcg=/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod479f327f_a27b_4eda_8523_90bdabcf0a27.slice/cri-containerd-679f9845995b4ae4812789eb3c3d1df88040a1bc3f0c046a05c9aa9b5b5f93be.scope,task=stress-ng-vm,pid=716580,uid=0
Dec 13 07:23:21 aks-ubuntu-26835060-vmss000000 kernel: [36370.037095] Memory cgroup out of memory: Killed process 716580 (stress-ng-vm) total-vm:1104444kB, anon-rss:473048kB, file-rss:644kB, shmem-rss:64kB, UID:0 pgtables:992kB oom_score_adj:1000

このメッセージから、いくつかのことがわかります。

コンテナーレベル/ノードレベルの判断

spec.containers[].resources.limits.memoryにて指定した制限は、
memcg(cgroupsのメモリコントローラ)により適用されます。

cgroupsはLinux上でコンテナーを実現するための主要な機能の一つであり、
control group(cgroup)に分類されたプロセス群について、グループごとに
メモリやCPU等のリソースの使用量を制限するものです。

Control Group v2: Memory

メモリ制限(limits)は、Pod・コンテナーに対応するcgroupに関して
確保・利用可能なメモリ量の上限が設定され、上限を超過したときに
memcgがOOMKillを発生させることで実現されています。

下記の行からは、oom_memcgとして、OOMの発生要因となったcgroupが
/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod479f327f_a27b_4eda_8523_90bdabcf0a27.slice
(特定のPodに対応するcgroup)であることがわかります。すなわち、Pod・コンテナーレベルのOOMKillであると判断できます。

1
oom-kill:constraint=CONSTRAINT_MEMCG,nodemask=(null),cpuset=cri-containerd-679f9845995b4ae4812789eb3c3d1df88040a1bc3f0c046a05c9aa9b5b5f93be.scope,mems_allowed=0,oom_memcg=/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod479f327f_a27b_4eda_8523_90bdabcf0a27.slice,task_memcg=/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod479f327f_a27b_4eda_8523_90bdabcf0a27.slice/cri-containerd-679f9845995b4ae4812789eb3c3d1df88040a1bc3f0c046a05c9aa9b5b5f93be.scope,task=stress-ng-vm,pid=716580,uid=0

一方、ノードレベルの場合は、例えば下記のように、 oom_memcgが/kubepods.sliceとなっている(個々のPod等に対応する
cgroupではなく、その上位のcgroupとなっている)ことから、そのOOMKillがノードレベルのものであると判断できます。

1
oom-kill:constraint=CONSTRAINT_MEMCG,nodemask=(null),cpuset=cri-containerd-4d2af8acef61505159dd1fb6e232eacd1b724e1d629f043fcaa47809544f6d92.scope,mems_allowed=0,oom_memcg=/kubepods.slice,task_memcg=/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-poda9d4b3f1_0189_4f5e_a8ee_94f0a3f53ab0.slice/cri-containerd-4d2af8acef61505159dd1fb6e232eacd1b724e1d629f043fcaa47809544f6d92.scope,task=stress-ng-vm,pid=728241,uid=0

他にわかること

この他、OOMKillメッセージには発生時のcgroup内のメモリ使用量の内訳、プロセス毎のメモリ使用状況などの情報が含まれます。
もし、Pod・コンテナーが意図せず大量のメモリを確保・利用していた場合、これらの情報を参照することで
原因の絞り込みに役立つかもしれません。

子プロセスがOOMKillされたときの挙動

Kubernetes 1.27 まで

既に解説した通り、Pod・コンテナーレベルのOOMKillは、Pod・コンテナーに対応するcgroupに関して
メモリ使用量が制限値を超過することで発生します。
ただ、このとき行われるOOMKillの対象は、あくまでもコンテナー内で(メモリ使用量等の観点で)選ばれた
特定のプロセスとなります。従って、例えばコンテナー内で作成された子プロセスの一つが
OOMKillにより終了した場合、コンテナー内のプロセスの構成次第では
他のプロセスが(場合によってはコンテナーとして不完全なまま)動作を継続する場合があります。

このとき、コンテナーとしての再起動は発生しないため、
kubectl describe podコマンドの結果などからは、そもそもOOMKillが発生したことすらわかりません。

このような場合にOOMKillの発生を検知するには、ノードのログ等から
OOMKillのメッセージの有無を確認する必要があります。
(memcgの統計情報を確認する、などの方法もありますが割愛させて頂きます)

Kubernetes 1.28 以降

Kubernetes バージョン1.28以降では、cgroups v2のmemcgで採用された
memory.oom.groupという機能を、Pod・コンテナーのcgroupに関して
有効化するようになりました。
この機能は、cgroup内の任意のプロセスがOOMKillの対象となった場合に
同じcgroup内の全プロセスに関してOOMKillを実行する、というものです。
すなわち、 Kubernetes バージョンが1.28以降であり、
かつ、利用されているcgroupsがv2の場合、
任意の子プロセスがOOMKillとなった際に、(restartPolicyがNeverでなければ)
確実にコンテナーの再起動が発生するようになります。

[SIG-Node] Cgroups v2 memory.oom.group support (kill all pids in a pod on oom)

use the cgroup aware OOM killer if available

AKS では、Kubernetes バージョン1.25以降のAKSクラスターの
Ubuntuノード(Ubuntu 22.04ノード)でcgroups v2が利用されております。
Azure Linuxノードの場合はKubernetes バージョン1.28の時点にて
まだcgroups v1が利用されますが、バージョン1.29以降では
cgroups v2の利用に切り替わる予定です。

AKS Release 2023-11-28

まとめると、Ubuntuノードの場合は Kuberenetes バージョン1.28以降、
Azure Linuxノードの場合はバージョン1.29以降にて、
Pod・コンテナーのcgroupに対してmemory.oom.groupが有効化され、
OOMKillの発生時にはコンテナー内の全プロセスがOOMKill対象となります。

なお、memory.oom.groupが有効化されているコンテナーに関してOOMKillが発生した場合、
下記のように、ログメッセージでもcgroup内の全プロセスがkillされる旨のメッセージが出力されます。

1
Dec 13 07:54:24 aks-ubuntu-26253795-vmss000000 kernel: [41725.949137] Tasks in /kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podc9658b52_5194_4250_87f2_ec380cce2915.slice/cri-containerd-6793e00dcd36f430871d321242bbd79c1c186a3fad6615a98a1cc0b24c3e7f8f.scope are going to be killed due to memory.oom.group set

まとめ

この記事では、AKSノードにおけるOOOMKillの際の挙動や、これに基づく原因調査方法について紹介しました。
OOMKill発生時には、紹介した方法にて原因を確認の上、Pod・コンテナーレベルのOOMKillの場合は
制限(limits)の増加、ノードレベルの場合は要求(requests)の増加やノードの増強等を
ご検討下さい。
また、memory.oom.group未対応の構成では、Kubernetes リソースの情報としては
わからない形でOOMKillが発生していた、ということもありますので、
プロセスがいつの間にか終了していた、といった場合には
OOMKillが発生していた可能性もご確認下さい。

※本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。