kubernetesエージェントノードのメモリ調査
k8sを構成するエージェントノードのうちの１台がメモリ使用率がほぼ100%になっていたので調査しました。
まずはvmstatでFreeメモリを確認。
root@host3:~# vmstat 3
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 1402460 97368 5017088 0 0 1922 8 1 2 1 1 92 6 0
1 0 0 1401328 97368 5016984 0 0 0 20 1233 4908 0 0 99 0 0
0 0 0 1401864 97368 5017048 0 0 0 20 870 4224 1 0 99 0 0
Freeが1.4GB程度しかない。
エージェントノードのリソース確認
podが該当ノードに偏ってしまったのか確認。
user@work-server:$ kubectl describe node host3
Name: host3
Roles: agent
(省略)
Conditions:
Type Status LastHeartbeatTime LastTransitionTime Reason Message
---- ------ ----------------- ------------------ ------ -------
OutOfDisk False Fri, 15 Feb 2019 00:44:14 +0000 Thu, 31 Jan 2019 01:06:41 +0000 KubeletHasSufficientDisk kubelet has sufficient disk space available
MemoryPressure False Fri, 15 Feb 2019 00:44:14 +0000 Thu, 31 Jan 2019 01:06:41 +0000 KubeletHasSufficientMemory kubelet has sufficient memory available
DiskPressure False Fri, 15 Feb 2019 00:44:14 +0000 Thu, 31 Jan 2019 01:06:41 +0000 KubeletHasNoDiskPressure kubelet has no disk pressure
PIDPressure False Fri, 15 Feb 2019 00:44:14 +0000 Mon, 21 Jan 2019 08:13:51 +0000 KubeletHasSufficientPID kubelet has sufficient PID available
Ready True Fri, 15 Feb 2019 00:44:14 +0000 Thu, 31 Jan 2019 01:06:51 +0000 KubeletReady kubelet is posting ready status. AppArmor enabled
(省略)
Non-terminated Pods: (3 in total)
Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits AGE
--------- ---- ------------ ---------- --------------- ------------- ---
dd-agent dd-agent-zpqxd 200m (1%) 200m (1%) 1Gi (3%) 1Gi (3%) 18m
kube-system kube-proxy-fff9p 100m (0%) 0 (0%) 0 (0%) 0 (0%) 24d
my-api-b-001-ro my-api-deployment-c77fc9c5-g9bnq 2 (12%) 2 (12%) 4Gi (12%) 4Gi (12%) 15h
Allocated resources:
(Total limits may be over 100 percent, i.e., overcommitted.)
Resource Requests Limits
-------- -------- ------
cpu 2300m (14%) 2200m (13%)
memory 5Gi (15%) 5Gi (15%)
ephemeral-storage 0 (0%) 0 (0%)
alpha.kubernetes.io/nvidia-gpu 0 0
Events: <none>
そうでもない。
k8sのメモリ使用量は5Giで15%程度なのでpodが圧迫してるわけではない。
メモリ消費してるプロセスをtopコマンドで確認。
KiB Mem : 32939376 total, 1416364 free, 26408848 used, 5114164 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 5084536 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2023 root 20 0 1756856 183680 25828 S 2.0 0.6 719:07.23 kubelet
32406 user 20 0 5143476 1.578g 4804 S 1.0 5.0 14:37.36 java
1640 root 20 0 25.601g 0.020t 26752 S 0.7 66.3 1375:04 dockerd
1887 root 20 0 2552428 39952 6956 S 0.7 0.1 78:41.76 docker-containe
4962 root 20 0 224656 24188 8648 S 0.7 0.1 0:54.60 python3
3400 root 20 0 1619184 51140 25192 S 0.3 0.2 37:40.95 hyperkube
24245 root 20 0 3881536 285560 52264 S 0.3 0.9 0:35.35 agent
32172 root 20 0 413060 4948 2304 S 0.3 0.0 1:07.55 docker-containe
1 root 20 0 38012 5852 3776 S 0.0 0.0 0:16.35 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.25 kthreadd
4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/0:0H
6 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 mm_percpu_wq
7 root 20 0 0 0 0 S 0.0 0.0 0:04.81 ksoftirqd/0
8 root 20 0 0 0 0 I 0.0 0.0 13:14.36 rcu_sched
9 root 20 0 0 0 0 I 0.0 0.0 0:00.02 rcu_bh
10 root rt 0 0 0 0 S 0.0 0.0 0:00.96 migration/0
11 root rt 0 0 0 0 S 0.0 0.0 0:01.99 watchdog/0
12 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/0
13 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/1
14 root rt 0 0 0 0 S 0.0 0.0 0:01.81 watchdog/1
15 root rt 0 0 0 0 S 0.0 0.0 0:01.10 migration/1
16 root 20 0 0 0 0 S 0.0 0.0 0:03.49 ksoftirqd/1
18 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/1:0H
19 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/2
20 root rt 0 0 0 0 S 0.0 0.0 0:02.37 watchdog/2
21 root rt 0 0 0 0 S 0.0 0.0 0:00.89 migration/2
22 root 20 0 0 0 0 S 0.0 0.0 0:13.43 ksoftirqd/2
24 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/2:0H
25 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/3
26 root rt 0 0 0 0 S 0.0 0.0 0:02.33 watchdog/3
27 root rt 0 0 0 0 S 0.0 0.0 0:00.89 migration/3
28 root 20 0 0 0 0 S 0.0 0.0 0:11.50 ksoftirqd/3
30 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/3:0H
31 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/4
32 root rt 0 0 0 0 S 0.0 0.0 0:02.43 watchdog/4
33 root rt 0 0 0 0 S 0.0 0.0 0:00.92 migration/4
34 root 20 0 0 0 0 S 0.0 0.0 0:12.42 ksoftirqd/4
36 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/4:0H
37 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/5
38 root rt 0 0 0 0 S 0.0 0.0 0:02.33 watchdog/5
39 root rt 0 0 0 0 S 0.0 0.0 0:00.90 migration/5
40 root 20 0 0 0 0 S 0.0 0.0 0:12.48 ksoftirqd/5
42 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/5:0H
43 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/6
44 root rt 0 0 0 0 S 0.0 0.0 0:02.09 watchdog/6
45 root rt 0 0 0 0 S 0.0 0.0 0:00.88 migration/6
dockerdが怪しい。
dockerコンテナの確認
起動してるdockerコンテナを確認。
root@host3:~# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
6222e152f33b datadog/agent@sha256:e04cc178565977c606ef8ef4bcd385d62ea800ba66d8c0be8014eb8e95f27f2e "/init" 46 minutes ago Up 46 minutes k8s_dd-agent_dd-agent-zpqxd_dd-agent_3740c758-30b8-11e9-b8c1-000d3a50757b_0
ca9311718119 k8s-gcrio.azureedge.net/pause-amd64:3.1 "/pause" 46 minutes ago Up 46 minutes k8s_POD_dd-agent-zpqxd_dd-agent_3740c758-30b8-11e9-b8c1-000d3a50757b_0
b5608bcab43b my-api@sha256:77a4f0e88724458f378449f65f43dfaea29dd5ef02741b23edbb647030859db4 "./entrypoint.sh -..." 15 hours ago Up 15 hours k8s_backend_my-api-deployment-c77fc9c5-g9bnq_my-api-b-001-ro_ff5961b4-3038-11e9-b8c1-000d3a50757b_0
08964df69d37 nginx@sha256:e0292d158b6b353fde34909243a4886977cb9d1abb8a8a5fef9e0ff7138dd3e2 "nginx -g 'daemon ..." 15 hours ago Up 15 hours k8s_frontend_my-api-deployment-c77fc9c5-g9bnq_my-api-b-001-ro_ff5961b4-3038-11e9-b8c1-000d3a50757b_0
900a73503095 k8s-gcrio.azureedge.net/pause-amd64:3.1 "/pause" 15 hours ago Up 15 hours k8s_POD_my-api-deployment-c77fc9c5-g9bnq_my-api-b-001-ro_ff5961b4-3038-11e9-b8c1-000d3a50757b_0
f13a26b9ca73 nginx@sha256:e0292d158b6b353fde34909243a4886977cb9d1abb8a8a5fef9e0ff7138dd3e2 "nginx -g 'daemon ..." 4 days ago Up 4 days k8s_frontend_my-api-deployment-bf5b6fcd6-pr7rs_my-api-b-001-rw_75c07464-29dd-11e9-b8c1-000d3a50757b_5
91dd88cb0499 nginx@sha256:e0292d158b6b353fde34909243a4886977cb9d1abb8a8a5fef9e0ff7138dd3e2 "nginx -g 'daemon ..." 4 days ago Up 4 days k8s_frontend_my-api-deployment-bf5b6fcd6-pr7rs_my-api-b-001-rw_75c07464-29dd-11e9-b8c1-000d3a50757b_4
422551d39e3c nginx@sha256:e0292d158b6b353fde34909243a4886977cb9d1abb8a8a5fef9e0ff7138dd3e2 "nginx -g 'daemon ..." 7 days ago Up 7 days k8s_frontend_my-api-deployment-bf5b6fcd6-pr7rs_my-api-b-001-rw_75c07464-29dd-11e9-b8c1-000d3a50757b_1
ebd8e5778b63 nginx@sha256:e0292d158b6b353fde34909243a4886977cb9d1abb8a8a5fef9e0ff7138dd3e2 "nginx -g 'daemon ..." 10 days ago Up 10 days k8s_frontend_my-api-deployment-5994cc4897-c8qt7_my-api-b-001-rw_bfa5adce-2519-11e9-b8c1-000d3a50757b_3
5a5bf0e44c24 nginx@sha256:e0292d158b6b353fde34909243a4886977cb9d1abb8a8a5fef9e0ff7138dd3e2 "nginx -g 'daemon ..." 10 days ago Up 10 days k8s_frontend_my-api-deployment-85b85bc4c6-xjnz4_my-api-b-001-ro_2a695ff0-2519-11e9-b8c1-000d3a50757b_3
511a5bf6f167 nginx@sha256:e0292d158b6b353fde34909243a4886977cb9d1abb8a8a5fef9e0ff7138dd3e2 "nginx -g 'daemon ..." 10 days ago Up 10 days k8s_frontend_my-api-deployment-85b85bc4c6-kdfl8_my-api-b-001-ro_2a65141a-2519-11e9-b8c1-000d3a50757b_2
595a00b5ff3e nginx@sha256:e0292d158b6b353fde34909243a4886977cb9d1abb8a8a5fef9e0ff7138dd3e2 "nginx -g 'daemon ..." 10 days ago Up 10 days k8s_frontend_my-api-deployment-85b85bc4c6-6m94j_my-api-b-001-ro_2a5e5ef5-2519-11e9-b8c1-000d3a50757b_2
823fb2f47759 nginx@sha256:e0292d158b6b353fde34909243a4886977cb9d1abb8a8a5fef9e0ff7138dd3e2 "nginx -g 'daemon ..." 11 days ago Up 11 days k8s_frontend_my-api-deployment-85b85bc4c6-xjnz4_my-api-b-001-ro_2a695ff0-2519-11e9-b8c1-000d3a50757b_2
398392fd90c3 nginx@sha256:e0292d158b6b353fde34909243a4886977cb9d1abb8a8a5fef9e0ff7138dd3e2 "nginx -g 'daemon ..." 11 days ago Up 11 days k8s_frontend_my-api-deployment-5994cc4897-c8qt7_my-api-b-001-rw_bfa5adce-2519-11e9-b8c1-000d3a50757b_2
e94402dcb2ed nginx@sha256:e0292d158b6b353fde34909243a4886977cb9d1abb8a8a5fef9e0ff7138dd3e2 "nginx -g 'daemon ..." 12 days ago Up 12 days k8s_frontend_my-api-deployment-5994cc4897-c8qt7_my-api-b-001-rw_bfa5adce-2519-11e9-b8c1-000d3a50757b_1
80c4d7eb906a nginx@sha256:e0292d158b6b353fde34909243a4886977cb9d1abb8a8a5fef9e0ff7138dd3e2 "nginx -g 'daemon ..." 12 days ago Up 12 days k8s_frontend_my-api-deployment-85b85bc4c6-6m94j_my-api-b-001-ro_2a5e5ef5-2519-11e9-b8c1-000d3a50757b_1
8bed3e796fc6 nginx@sha256:e0292d158b6b353fde34909243a4886977cb9d1abb8a8a5fef9e0ff7138dd3e2 "nginx -g 'daemon ..." 12 days ago Up 12 days k8s_frontend_my-api-deployment-85b85bc4c6-xjnz4_my-api-b-001-ro_2a695ff0-2519-11e9-b8c1-000d3a50757b_1
da55ff083bad nginx@sha256:e0292d158b6b353fde34909243a4886977cb9d1abb8a8a5fef9e0ff7138dd3e2 "nginx -g 'daemon ..." 12 days ago Up 12 days k8s_frontend_my-api-deployment-85b85bc4c6-kdfl8_my-api-b-001-ro_2a65141a-2519-11e9-b8c1-000d3a50757b_1
d2fc182ba710 nginx@sha256:3be25b5301acfcaad024ec274caf459ecd2bba4f9aa88145589afa729e346776 "nginx -g 'daemon ..." 2 weeks ago Up 2 weeks k8s_frontend_my-api-deployment-5994cc4897-c8qt7_my-api-b-001-rw_bfa5adce-2519-11e9-b8c1-000d3a50757b_0
ee1989c5bcb6 nginx@sha256:3be25b5301acfcaad024ec274caf459ecd2bba4f9aa88145589afa729e346776 "nginx -g 'daemon ..." 2 weeks ago Up 2 weeks k8s_frontend_my-api-deployment-85b85bc4c6-kdfl8_my-api-b-001-ro_2a65141a-2519-11e9-b8c1-000d3a50757b_0
8c25e48b27a2 nginx@sha256:3be25b5301acfcaad024ec274caf459ecd2bba4f9aa88145589afa729e346776 "nginx -g 'daemon ..." 2 weeks ago Up 2 weeks k8s_frontend_my-api-deployment-85b85bc4c6-xjnz4_my-api-b-001-ro_2a695ff0-2519-11e9-b8c1-000d3a50757b_0
e10920dc83ad nginx@sha256:3be25b5301acfcaad024ec274caf459ecd2bba4f9aa88145589afa729e346776 "nginx -g 'daemon ..." 2 weeks ago Up 2 weeks k8s_frontend_my-api-deployment-85b85bc4c6-6m94j_my-api-b-001-ro_2a5e5ef5-2519-11e9-b8c1-000d3a50757b_0
9575ec9116b6 k8s-gcrio.azureedge.net/hyperkube-amd64@sha256:badd2b1da29d4d530b10b920f64bf66a1b41150db46c3c99b49d56f3f18a82db "/hyperkube proxy ..." 2 weeks ago Up 2 weeks k8s_kube-proxy_kube-proxy-fff9p_kube-system_85d2d6da-1d54-11e9-840e-000d3a5185c7_1
1336b0d9fc52 k8s-gcrio.azureedge.net/pause-amd64:3.1 "/pause" 2 weeks ago Up 2 weeks k8s_POD_kube-proxy-fff9p_kube-system_85d2d6da-1d54-11e9-840e-000d3a5185c7_1
当システムでは１つのpodを以下の3つのコンテナで構成しているのですが、
・nginx（webサーバ）
・App（アプリケーション）
・pause(k8sのシステム管理)
・・・どうみてもnginxがたくさんいる。
コンテナのimage名から動作中のコンテナは、
b5608bcab43b my-api@sha256:77a4f0e88724458f378449f65f43dfaea29dd5ef02741b23edbb647030859db4 "./entrypoint.sh -..." 15 hours ago Up 15 hours k8s_backend_my-api-deployment-c77fc9c5-g9bnq_my-api-b-001-ro_ff5961b4-3038-11e9-b8c1-000d3a50757b_0
08964df69d37 nginx@sha256:e0292d158b6b353fde34909243a4886977cb9d1abb8a8a5fef9e0ff7138dd3e2 "nginx -g 'daemon ..." 15 hours ago Up 15 hours k8s_frontend_my-api-deployment-c77fc9c5-g9bnq_my-api-b-001-ro_ff5961b4-3038-11e9-b8c1-000d3a50757b_0
900a73503095 k8s-gcrio.azureedge.net/pause-amd64:3.1 "/pause" 15 hours ago Up 15 hours k8s_POD_my-api-deployment-c77fc9c5-g9bnq_my-api-b-001-ro_ff5961b4-3038-11e9-b8c1-000d3a50757b_0
だけのはず。残りはzombieということか。
直接原因の判明と対処
以前から稼働中のコンテナをOOMkillされたり、kubectlで落ちきらないpodを強制deleteとかしていたのでその時の残骸が起動し続けていてメモリを圧迫していた。
そこで稼働中のコンテナを特定し、それ以外のコンテナを停止しようと試みた。
まずは正常停止。
root@host3:~# docker stop f13a26b9ca73
f13a26b9ca73
root@host3:~# docker ps -a | grep f13a26b9ca73
f13a26b9ca73 nginx@sha256:e0292d158b6b353fde34909243a4886977cb9d1abb8a8a5fef9e0ff7138dd3e2 "nginx -g 'daemon ..." 4 days ago Up 4 days k8s_frontend_my-api-deployment-bf5b6fcd6-pr7rs_my-api-b-001-rw_75c07464-29dd-11e9-b8c1-000d3a50757b_5
root@host3:~#
死なない。
次に強制停止その１。
root@host3:~# docker kill f13a26b9ca73
f13a26b9ca73
root@host3:~# docker ps -a | grep f13a26b9ca73
f13a26b9ca73 nginx@sha256:e0292d158b6b353fde34909243a4886977cb9d1abb8a8a5fef9e0ff7138dd3e2 "nginx -g 'daemon ..." 4 days ago Up 4 days k8s_frontend_my-api-deployment-bf5b6fcd6-pr7rs_my-api-b-001-rw_75c07464-29dd-11e9-b8c1-000d3a50757b_5
死なない。。
次に強制停止その２。
root@host3:~# docker rm --force f13a26b9ca73
Error response from daemon: Driver overlay2 failed to remove root filesystem f13a26b9ca73701bf65a1cf8e573a631d0b509583f47c86de728c112c85c0bea: remove /var/lib/docker/overlay2/cf99d43d3405e58c1cc9ab8cec36dc13014789bbb85c76f49cd52b29ebc77bc0/merged/bin: directory not empty
root@host3:~#
削除対象のディレクトリが空じゃないから消せないようなので中身を見てみる。
root@host3:~# ls -l /var/lib/docker/overlay2/cf99d43d3405e58c1cc9ab8cec36dc13014789bbb85c76f49cd52b29ebc77bc0/merged
total 0
何もいません。。。
メモリをどうにか空けるためOSコマンドでのkillを試みる。まずは-15で。
root@host3:~# kill -15 26779
root@host3:~#
root@host3:~#
root@host3:~# ps -aef | grep f13a26b9ca73
root 26779 1887 0 Feb10 ? 00:02:28 docker-containerd-shim f13a26b9ca73701bf65a1cf8e573a631d0b509583f47c86de728c112c85c0bea /var/run/docker/libcontainerd/f13a26b9ca73701bf65a1cf8e573a631d0b509583f47c86de728c112c85c0bea docker-runc
root 32403 19055 0 01:48 pts/0 00:00:00 grep --color=auto f13a26b9ca73
死なない。。。。
最終手段でzombieにヘッドショット。
root@host3:~# kill -9 26779
root@host3:~#
root@host3:~#
root@host3:~# ps -aef | grep f13a26b9ca73
root 1162 19055 0 01:48 pts/0 00:00:00 grep --color=auto f13a26b9ca73
root@host3:~#
さすがに死にました。
dockerコマンドで死活を確認。
root@host3:~# docker ps
^C
dockerコマンドが無応答になりました。(´▽｀)
dockerコマンドが効かなくなったためk8sにNotReadyを言い渡されました。
user@work-server:~$ kubectl get node
NAME STATUS ROLES AGE VERSION
host0 Ready agent 24d v1.10.2
host1 Ready agent 24d v1.10.2
host2 Ready agent 24d v1.10.2
host3 NotReady agent 24d v1.10.2
host4 Ready agent 24d v1.10.2
host5 Ready agent 24d v1.10.2
host6 Ready agent 24d v1.10.2
k8s-master-33366746-0 Ready master 24d v1.10.2
k8s-master-33366746-1 Ready master 24d v1.10.2
k8s-master-33366746-2 Ready master 24d v1.10.2
結局、ノードOSのメモリ使用量も減ってません。
root@host3:~# vmstat 3
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 1257536 99784 5076520 0 0 1918 8 1 0 1 1 92 6 0
0 0 0 1255436 99784 5076492 0 0 0 20 684 3142 0 0 99 0 0
NotReadyになったことで該当エージェントにあったpodは「STATUS」が"Unknown"となり、evictされていたので最終手段としてノードVMの再起動を実施。
NAME READY STATUS RESTARTS AGE IP NODE
my-api-deployment-f77f49cdb-gvrkm 2/2 Running 0 16h IPaddress host5
my-api-deployment-f77f49cdb-mj47t 2/2 Running 0 16h IPaddress host6
my-api-deployment-f77f49cdb-ms4zp 2/2 Running 0 16h IPaddress host1
my-api-deployment-f77f49cdb-shl66 2/2 Running 0 16h IPaddress host4
my-api-deployment-f77f49cdb-xlzq6 2/2 Running 0 16h IPaddress host6
user@work-server:~$
user@work-server:~$ kubectl get pod -n my-api-b-001-ro -o wide
NAME READY STATUS RESTARTS AGE IP NODE
my-api-deployment-c77fc9c5-5mb5z 2/2 Running 0 16h IPaddress host4
my-api-deployment-c77fc9c5-8zqlh 2/2 Running 0 16h IPaddress host5
my-api-deployment-c77fc9c5-9mcmf 2/2 Running 0 16h IPaddress host6
my-api-deployment-c77fc9c5-bnjpm 2/2 Running 0 16h IPaddress host0
my-api-deployment-c77fc9c5-chkbc 2/2 Running 0 1m IPaddress host2
my-api-deployment-c77fc9c5-g9bnq 2/2 Unknown 0 16h IPaddress host3
ここで再起動前後で/var/
再起動後、とりあえずZombieコンテナは一掃され、
root@host3:~# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
0c7101761e13 datadog/agent@sha256:e04cc178565977c606ef8ef4bcd385d62ea800ba66d8c0be8014eb8e95f27f2e "/init" 3 days ago Up 3 days k8s_dd-agent_dd-agent-zpqxd_dd-agent_3740c758-30b8-11e9-b8c1-000d3a50757b_1
d2f60990f374 k8s-gcrio.azureedge.net/hyperkube-amd64@sha256:badd2b1da29d4d530b10b920f64bf66a1b41150db46c3c99b49d56f3f18a82db "/hyperkube proxy ..." 3 days ago Up 3 days k8s_kube-proxy_kube-proxy-fff9p_kube-system_85d2d6da-1d54-11e9-840e-000d3a5185c7_2
d14e3e204328 k8s-gcrio.azureedge.net/pause-amd64:3.1 "/pause" 3 days ago Up 3 days k8s_POD_dd-agent-zpqxd_dd-agent_3740c758-30b8-11e9-b8c1-000d3a50757b_1
9b605582fa18 k8s-gcrio.azureedge.net/pause-amd64:3.1 "/pause" 3 days ago Up 3 days k8s_POD_kube-proxy-fff9p_kube-system_85d2d6da-1d54-11e9-840e-000d3a5185c7_2
root@host3:~#
メモリもFreeが大量に確保されました。
root@host3:~# vmstat 3
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 28280936 155804 1821380 0 0 0 7 9 3 0 0 99 0 0
0 0 0 28280780 155804 1821456 0 0 0 20 745 2779 0 0 99 0 0
^C
ちなみに再起動前後で、/var/lib/docker配下のlsリストを出力していたのですが、
/var/lib/docker/container配下のディレクトリ数が整理され、30 → 8個に減少しました。
./containers:
total 32
drwx------ 3 root root 4096 Feb 15 02:16 0c7101761e1350263499167f00fd98162be42414af3bce542e847e0931d20369
drwx------ 3 root root 4096 Feb 15 02:16 d2f60990f374a91b297ff4376604356b3fee49d8dd6018322e3dd63d06bbcd02
drwx------ 4 root root 4096 Feb 15 02:16 d14e3e20432868018c66e9bb664b1e45322db37ceef14b029608936a650b5b05
drwx------ 4 root root 4096 Feb 15 02:16 9b605582fa18c13651e44caa79713a115fb31b831effdd7cae03b5e9216bf361
drwx------ 4 root root 4096 Feb 15 02:16 ca93117181199c5309249dc798a451661ba7a9fa2f0409771d9117b37cc3f905
drwx------ 3 root root 4096 Feb 15 02:16 9575ec9116b6c54799fff26c85147b4711a82269d2a66966fd7bfa2095b83a70
drwx------ 3 root root 4096 Feb 15 02:16 6222e152f33bbe6738ae3c3661f14e667c8c34532a4434594c2bd5dc3a22ab50
drwx------ 4 root root 4096 Feb 15 02:16 1336b0d9fc525921e9a9bdd91815aa50e0762af6ad3afe6f6d3a19bc9b704a50
まとめ
実際に起動しているが管理されていないZombieコンテナが、ホストOSのメモリを圧迫していることが分かり、それらを一掃することで回復することができました。
が、Zombieコンテナの一掃方法については、該当ホスト上の”生きてる”podを退避し、ホストOSの再起動を行うという方法しか思いつきませんでした。
今後発生したら、今のところ同様の方法でホストOS再起動するしかありません。
そもそもpodの強制削除などZombieコンテナを発生させるような状況をなくしたいです。