K8S) 망가진 클러스터 심폐소생술 하기_disk,memory부족
평화로운 오후 갑자기, 회사 K8S가 이상하다는 연락이 옵니다
회사 서버실에 있는 쿠버네티스
나는 1년 동안 들어가본적이 없는 쿠버네티스
하지만 내가 살려야하는 쿠버네티스
돌이켜보면 별거 없지만, 클러스터 되살린 과정을 적어보려고 합니다.
예상 독자는 아래와 같습니다
1. k8s 리소스 정리가 필요한 분
2. worker disk pressure, memory 부족이 발생하는 분
3. k8s 이슈 발생시, 확인
환경은 아래와 같습니다.
1. 온프렘
2. master 3, worker 3
3. k8s 1.30 /// ubuntu 22.04
(스포) 를 원하시면 아래 [더 보기]를 눌러주세요
[상황 파악]
1. 무슨 이유에서 인지, ceph에서 문제 발생 (ceph core 덤프 파일이 /var/lib/rook-ceph에 저장)
-> 디스크 부족
2. /var/lib/docker에 영향을 주며 containerd-shim이 정신을 못차림 (pod이 제대로 지워지지 않고, 리소스를 계속 소모)
-> 메모리 부족
[문제 해결]
1. /var/lib/rook-ceph 의 core 파일 살제
-> 디스크 부족 해결
2. containerd 재시작, image 삭제, container 삭제
-> 메모리 부족 해결
자 이제 상황을 파악해봅시다 ㅜ
(대충, 왜 내가 이걸하는지 모르는 짤)
1. 진단하기
그라파나도 내려가있었기 때문에, CLI로 확인해봅니다.
$ k get po -A
> 너무 에러가 많아 잠시 외면합니다.
$ k top nodes
> worker memory 이슈 확인
$k top nodes
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
k8sm01.hgkim.biz 211m 5% 7384Mi 46%
k8sm02.hgkim.biz 218m 5% 6714Mi 42%
k8sm03.hgkim.biz 563m 14% 5830Mi 36%
k8sw01.hgkim.biz 1983m 24% 91196Mi 94%
k8sw02.hgkim.biz 1502m 18% 59698Mi 61%
k8sw03.hgkim.biz 1040m 13% 76341Mi 79%
$ k get event -w
> disk 이슈도 있군요! 어질어질 합니다.
$k get event -w
LAST SEEN TYPE REASON OBJECT MESSAGE
3m8s Warning EvictionThresholdMet node/k8sw01.hgkim.biz Attempting to reclaim ephemeral-storage
$ k get po -n kube-system
> metric이 떠있긴한데, pod당 3~4기가를 실행합니다. 쎄합니다.
심호흡을 하고 다시 들여다봅니다.
뭘하다가 이렇게 망가질 때까지 혹사 시켰을까.
$ helm ls -A
redis, mongodb, stackable, strimzi, kafka, superset, cvat, mlrun, kiali stackable-stable, metallb flink-operator, mysql-operator, mairadb-operator, spark-operator, openebs 등
> 원인이 풀렸습니다. 이것 저것 설치하고, 제대로 안지운 분들이 계셨군요
$ k get ns / k get crd / k get pv / k get crd
> 여기도 상황이 크게 다르지 않았어요.
cluster가 error를 뱉으면 울부짖어도 최근까지 test를 하셨더라고요
이쯤 되면 그냥 "지우고 다시 깔까?" 라는 생각을 하게됩니다.
하지만 고쳐보고 싶은 욕구가 생기더라고요
2. 정밀 진단하기
살리기로 결정했으니, 좀 더 뜯어보죠
[memory 관련]
$ k describe node k8sw01
> memory pressure 발생했으나, worker에는 사용률이 거의 0%임
분명 k8s는 memory 부족하다고 node 상세는 멀쩡하데요
Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits Age
--------- ---- ------------ ---------- --------------- ------------- ---
auth dex-594d497cfb-2dn75 0 (0%) 0 (0%) 0 (0%) 0 (0%) 19d
kube-flannel kube-flannel-ds-m8g27 100m (1%) 0 (0%) 50Mi (0%) 0 (0%) 121d
kube-system fluentd-rvb89 100m (1%) 0 (0%) 200Mi (0%) 200Mi (0%) 18d
kube-system kube-proxy-hm2h2 0 (0%) 0 (0%) 0 (0%) 0 (0%) 139d
rook-ceph csi-cephfsplugin-pjvck 0 (0%) 0 (0%) 0 (0%) 0 (0%) 398d
rook-ceph csi-rbdplugin-qrhxh 0 (0%) 0 (0%) 0 (0%) 0 (0%) 398d
rook-ceph rook-ceph-crashcollector-k8sw01.hgkim-549b679f8b-9tcjj 0 (0%) 0 (0%) 0 (0%) 0 (0%) 31d
rook-ceph rook-ceph-mon-u-65d779884-6rjf7 0 (0%) 0 (0%) 0 (0%) 0 (0%) 31d
rook-ceph rook-ceph-osd-0-79d994df4b-9l6dx 500m (6%) 1 (12%) 1025Mi (1%) 3Gi (3%) 37d
직접 서버에 들어가서 리소스를 확인해봅니다.
$ (k8sw01) top
> worker가 살려달라고 부르는군요.
또 이상해요.
pod 들 실행되는것 다 내렸는데 93% 메모리를 사용하고 있어요.
active process 1개에, 221개는 sleeping고...
일단 메모리 이슈는 싱크가 안맞는구나라고 추정하고 넘깁니다.
디스크도 봐야하니까요
[disk 관련]
디스크를 봅니다.
$ df -h
> 음 왜 root 32G나 잡혓는데 29G를 쓰는걸까
조금 더 자세히 봅니다.
$ du -d 1 -h /var/lib
> 이제 어디가 문제인지 찾으러 들어가봅시다.
$ du -d 1 -h ./
(생략)
/var/lib/rook/rook-ceph/log 24G
$ls -alh | grep G 합계 24G
-rw------- 1 167 167 1.1G 8월 12 11:13 core.10020
-rw------- 1 167 167 1.3G 8월 11 13:11 core.11395
-rw------- 1 167 167 1.1G 6월 2 23:57 core.14002
(생략)
rook-ceph에서 log 쌓는 위치를 root로 했군요..
왜 그랬을까요 어쨋든 진단은 완료했습니다
1. 무슨 이유에서 인지, ceph에서 문제 발생
2. ceph core 덤프 파일이 snapshot 들이 debugging을 위해 계속 저장이되었고
3. 공교롭게 /var/lib/rook-ceph에 저장되며 root disk가 부족
4. /var/lib/docker에 영향을 주며 containerd-shim이 정신을 못차림
5. pod이 제대로 지워지지 않고, 리소스를 계속 소모함
6. k8s worker01 ephemoral 발생
> 결론: 디스크는 부족한게 맞는데, 메모리는 넉넉하다.
3. 조치하기
[memory 관련]
containerd-shim이 너무 많은 리소스를 사용하고 있어요.
라이프사이클 확인하는 친구가 너무 높은 건 말이 매우 이상해요
> containerd가 이상하다는 결론을 내려봅니다.
$ crictl ps -a
> 없어져야하는 pod들이 다 떠있어요
$ crtictl stop 4b
> 삭제가 안되요
WARN[0000] runtime connect using default endpoints: [unix:///run/containerd/containerd.sock unix:///run/crio/crio.sock unix:///var/run/cri-dockerd.sock].
As the default settings are now deprecated, you should set the endpoint instead. E0912 13:29:28.644952 48339 remote_runtime.go:366] "StopContainer from runtime service failed" err="rpc error: code = Unknown desc = failed to kill container \"4b9b153ae9b4fa4af759b820e4320ac986327cd983c08ac9f8b27e0f6d8fcfd1\": unknown error after kill: open /dev/null: too many open files: <nil>: unknown" containerID="4b9" FATA[0000] stopping the container "4b9": rpc error: code = Unknown desc = failed to kill container "4b9b153ae9b4fa4af759b820e4320ac986327cd983c08ac9f8b27e0f6d8fcfd1": unknown error after kill: open /dev/null: too many open files: <nil>: unknown
ulimit 확인해보니 too many files 이슈는 아니에요
$ sudo systemctl restart containerd
> containerd를 재시작해줍니다
$ crictl ps -a | grep Exited
> 다시 시작했는데도 찌거기가 남아있어요
주로 storage pod 관련 이라서, ephemeroral-storage 에러가 발생했음을 기억했어요
$ crictl rm $(crictl ps -a --state Exited -q)
> 귀찮으니까 한번에 다 지워줍니다.
[disk 관련]
아까 /var/lib/rook-ceph가 문제였죠
$ sudo rm -f /var/lib/rook/rook-ceph/log/core.*
# before
$df -h
Filesystem Size Used Avail Use% Mounted on/dev/xvda2 32G 29G 2.8G 92% /
# after
$df -h
Filesystem Size Used Avail Use% Mounted on/dev/xvda2 32G 5.4G 27G 17% /
[기타]
$ k get po -A
> 정상이네요 ㅎㅎ
어 근데 리소스 과하게 쓰는게 있어요
$ k top po -A | grep kube-system
> metrics 가 이상해요
kube-system kube-apiserver-k8sm01.hgkim.biz 67m 3503Mi
kube-system kube-apiserver-k8sm02.hgkim.biz 73m 3407Mi
kube-system kube-apiserver-k8sm03.hgkim.biz 332m 3445Mi
$ kubectl get --raw "/metrics" | grep apiserver_request_total
# 지워지지 않은 찌거기들까지 계속 call 합니다.
하나씩 지워줍니다
$ kubectl get crd | grep kubeflow | awk '{print $1}' | xargs kubectl delete crd
# kubectl delete crd kialis.kiali.io profiles.kubeflow.org runners.actions.summerwind.dev zookeeperznodes.zookeeper.stackable.tech
함참을 지워줍니다. finalize로 안지워지는것들도, hpa 들도 안쓰는건 다 지워줍니다.
kube-apiserver-k8sm01.hgkim.biz 54m 1778Mi
kube-apiserver-k8sm02.hgkim.biz 56m 1776Mi
kube-apiserver-k8sm03.hgkim.biz 111m 1755Mi
정상화는 되었고, pod rebalancing은 따로하지는 않앗어요
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
k8sm01.hgkim.biz 199m 4% 5984Mi 37%
k8sm02.hgkim.biz 278m 6% 4936Mi 31%
k8sm03.hgkim.biz 453m 11% 4008Mi 25%
k8sw01.hgkim.biz 337m 4% 28178Mi 29%
k8sw02.hgkim.biz 1269m 15% 79605Mi 82%
k8sw03.hgkim.biz 2396m 29% 73705Mi 76%
후기
재발 방지를 위해 이제 배포는 argocd로 진행하기로 했어요.
물론 급하다고 다른 방식으로 설치하겠죠 ㅜ
온프렘 서버도, rancher 이용해서 k8s 자동화해야하나 싶네요