매주 한 page, 기술 한 spoon

1️⃣ 문제 상황

Kubernetes v1.27 + containerd 환경에서 PostgreSQL 컨테이너가 CrashLoopBackOff 상태에 빠지는 문제가 발생했습니다.

이로 인해 서비스들이 정상적으로 동작하지 않았고, 컨테이너의 로그를 확인해보니 다음과 같은 오류 메시지가 출력 되었습니다.

ERROR: could not open file "pg_wal/00000001000000000000000A": Too many open files
LOG: could not create file "base/pgsql_tmp/pgsql_tmp1234": Too many open files
FATAL: too many open files in system

🔍 원인 분석

오류 메시지에서 “Too many open files”라는 문구를 확인할 수 있습니다.

이는 컨테이너 또는 호스트 OS에서 파일 핸들(file descriptors) 개수 제한을 초과했다는 의미입니다.

파일 핸들 개수 제한은 리눅스 커널의 fs.file-max 값과 관련이 있으며,

containerd 서비스에서도 nofile 설정이 낮게 잡혀 있다면 문제가 발생할 수 있습니다.

2️⃣ 해결 방법

✅ 1. OS의 파일 핸들 개수 제한(fs.file-max) 증가

우선, 현재 시스템에서 설정된 파일 핸들 개수 제한을 확인합니다.

$ cat /proc/sys/fs/file-max

제한을 증가시키기 위해 /etc/sysctl.conf 파일을 수정합니다.

$ vi /etc/sysctl.conf

아래 값을 추가하거나 수정합니다.

fs.file-max = 500000

변경 사항을 적용합니다.

$ sysctl 

이제 OS에서 허용하는 파일 핸들 개수가 증가했습니다.

✅ 2. containerd의 nofile 제한 값 증가

containerd 서비스에서도 열린 파일 개수를 늘려야 합니다.

아래 파일을 수정합니다.

$ vi /usr/lib/systemd/system/containerd.service

다음 설정을 추가합니다.

```
LimitCORE=infinity
LimitNOFILE=500000
```

이후 변경 사항을 반영하고 containerd 서비스를 재시작합니다.

$ systemctl daemon-reload
$ systemctl restart containerd

3️⃣ 적용 확인

설정이 정상적으로 적용되었는지 확인하기 위해 다시 파일 핸들 개수를 체크합니다.

$ cat /proc/sys/fs/file-max

PostgreSQL 컨테이너가 정상적으로 실행되는지도 확인합니다.

$ kubectl get pods -n <namespace>

만약 Running 상태로 변경되었다면, CrashLoopBackOff 문제가 해결된 것입니다.

4️⃣ 결론

“Too many open files” 오류는 파일 핸들 개수 제한이 너무 낮게 설정되어 발생하는 문제였습니다.

이를 해결하기 위해 OS의 fs.file-max 값을 조정하고, containerd의 nofile 설정을 증가하여 컨테이너가 충분한 파일을 열 수 있도록 했습니다.

🔹 이번 경험을 통해 얻은 교훈

• Kubernetes에서 컨테이너 실행 시, 리소스 제한 설정을 미리 점검하자.
• fs.file-max, nofile 값이 너무 낮으면 PostgreSQL 같은 DB 컨테이너에서 Too many open files 오류가 발생할 수 있다.
• 컨테이너 환경에서는 OS뿐만 아니라 containerd의 설정도 함께 조정해야 한다.

앞으로도 Kubernetes 환경에서 발생하는 다양한 문제 해결 경험을 공유하겠습니다. 🚀

비슷한 문제를 겪으셨다면 댓글로 경험을 나눠주세요! 😊