728x90
- 몇 주 전부터 테스트 서버에 설정해 놓은 CPU 사용량 알람이 불규칙하게 발생했다.
- 이 알람은 CPU 사용량이 5분간 90% 이상일 때만 전송되도록 설정한 것이었는데 사용량이 아예 없는 새벽에도 뜬금없이 메일이 오기도 했다.
- 최근에 잦아진 느낌이 들어 리눅스 명령어를 통해 원인을 파악해 보았다.
🛠️ top 명령어 실행
$ top
# 출력문
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2603276 systemd+ 20 0 2441220 2.3g 4 S 187.7 14.9 4:29.73 kuuqohhxo
...- top 명령어는 현재 실행 중인 프로세스의 cpu와 메모리 사용량을 알 수 있다.
- 그럼 사용량 순으로 정렬이 되는데 COMMAND를 보면 불규칙적인 문자열 프로세스가 리소스를 많이 잡아먹고 있었다.
- 불필요한 내용이라고 판단하여 몇 번이나 삭제했음에도 다른 문자열로 재생성되었다.
- 재생성 시기 역시 최단 1분 이내부터 하루나 며칠 뒤까지 매우 불규칙했다.
👮🏻♂️ 추적해 보기
# 새로 생긴 프로세스 이름을 복사하여 파일 위치 확인
$ sudo find / -name "kuuqohhxo" 2>/dev/null
# 출력
/var/lib/docker/overlay2/18aa6c1f707129482c9f63032304103bb3b3884a98be7c3e6dc72dd4a48656be/diff/tmp/.fhbtzbkeo/kuuqohhxo
/var/lib/docker/overlay2/18aa6c1f707129482c9f63032304103bb3b3884a98be7c3e6dc72dd4a48656be/merged/tmp/.fhbtzbkeo/kuuqohhxo- 먼저 이 불규칙한 문자열의 프로세스가 어느 위치에 있는지부터 추적해 봤다.
- find 명령어로 찾아본 결과 Docker의 overlay2 디렉터리였다. 즉, Docker의 특정 컨테이너가 범인이다.
- 이곳에 저장되는 디렉터리 명은 Docker의 OverlayFS 스냅샷(레이어) ID이다.
- 이곳은 Docker가 컨테이너를 실행할 때 이미지 레이어를 저장하는 용도로 사용된다.
- 이 스냅샷을 사용 중인 컨테이너가 무엇인지 알면 어느 컨테이너에서 발생한 것인지를 알 수 있을 것이다.
⛴️ overlay2 들어가 보기
# 루트 권한으로만 접근 가능하다.
$ sudo su root
[root@...]# cd /var/lib/docker/overlay2/
[root@...]# ls -al
# 출력
...
drwx--x---. 5 root root 69 Feb 11 12:49 18aa6c1f707129482c9f63032304103bb3b3884a98be7c3e6dc72dd4a48656be
drwx--x---. 4 root root 72 Feb 11 12:49 18aa6c1f707129482c9f63032304103bb3b3884a98be7c3e6dc72dd4a48656be-init- 스냅샷의 생성 시간으로도 얼추 유추할 수 있지만 보다 정확한 확인을 위해 스냅샷의 ID를 이용하여 찾아보자.
👀 컨테이너 탐색
# --no-trunc container id의 생략 없이 전부 나옴
$ docker ps -a --no-trunc
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
xxxxxxxxxxxx be-product "sh -c 'exec java -D…" 23 hours ago Up 23 hours 0.0.0.0:xxxx->xxxx/tcp, :::xxxx->xxxx/tcp be-product-1
xxxxxxxxxxxx postgres:16.2 "docker-entrypoint.s…" 23 hours ago Up 23 hours 0.0.0.0:xxxx->xxxx/tcp, :::xxxx->xxxx/tcp db-product-1위 스냅샷과 비슷한 시기에 created 된 컨테이너를 찾았고 이제 컨테이너의 상세 정보를 파악하자.
👀 postgres 컨테이너 상세 검색
$ docker inspect <container id>
# 출력문
...
"Image": "sha256:8e4fc9e184899a58735e7ee333f5e272d7d2298cf59302006b71f33e217be130",
...
"GraphDriver": {
"Data": {
...
"MergedDir": "/var/lib/docker/overlay2/18aa6c1f707129482c9f63032304103bb3b3884a98be7c3e6dc72dd4a48656be/merged",
"UpperDir": "/var/lib/docker/overlay2/18aa6c1f707129482c9f63032304103bb3b3884a98be7c3e6dc72dd4a48656be/diff",
"WorkDir": "/var/lib/docker/overlay2/18aa6c1f707129482c9f63032304103bb3b3884a98be7c3e6dc72dd4a48656be/work"
}
...- "Image" 값은 컨테이너를 띄울 때 사용된 로컬 이미지의 id이다.
- GraphDriver.Data.xxxDir의 경로를 통해 posrgres:16.2를 사용하는 컨테이너가 범인임을 확인했다.
- 그럼 여기서 유추해 볼 수 있는 것은 postgres:16.2가 공식 이미지가 아닌 악성 코드나 프로그램이 심어진 조작된 이미지이고, 그걸 사용해서 생긴 문제가 아닌가 하는 점이다.
- 실제로 이 프로젝트는 외국 외주 업체를 통해 개발된 것이기 때문에 개발 스펙 및 이미지를 외주업체에서 정했었다.
- 혹시나 잘못된 경로로부터 받은 이미지인지를 확인해 보자.
👀 postgres image 상세 검색
$ docker inspect <image id>
# 출력
[
{
"Id": "sha256:8e4fc9e184899a58735e7ee333f5e272d7d2298cf59302006b71f33e217be130",
"RepoTags": [
"postgres:16.2"
],
"RepoDigests": [
"postgres@sha256:4aea012537edfad80f98d870a36e6b90b4c09b27be7f4b4759d72db863baeebb"
],
...- 해당 postgres 이미지를 inspect 명령어로 상세 검색하면 "Id" 값이 나오는데 이 값과 위의 컨테이너 상세 검색 시 나온 "Image"의 값이 일치함을 확인할 수 있다.
- 이제 repoDigests를 보면 다시 sha256으로 시작하는 다이제스트가 나오는데 이 값이 dockerhub에 있는 공식 이미지의 다이제스트 값과 같다면 공식 이미지를 사용한 것으로 볼 수 있다.
🐳 dockerhub 내 postgres 특정 태그 이미지 찾기
- 태그에 버전을 입력하여 검색한다.
- INDEX DIGEST를 확인한다.
- 위의 postgres:16.2에 해당하는 로컬 이미지의 다이제스트와 같음을 확인할 수 있다.
- 즉, 공식 이미지를 사용한 것이 맞다.
- 다음으로 공식 이미지 내에 악성 프로그램 혹은 DB 내 특정 문제로 과부하가 주기적으로 발생하는 상황을 상상해 보았다.
- 이 과정에서 하루가 지나갔고, 프로세스 과부하 문제가 다시 발생하여 프로세스를 kill을 한 상태에서 컨테이너도 다시 띄우고 추적을 시작했다.
👾 암호화폐 마이닝(채굴) 멀웨어?!
- 악성 프로그램보다는 postgres 내 DB가 과부하에 걸리는 상황이 있을 확률이 높기 때문에 구글링을 먼저 해보았다.
- 검색어는 postgresql image cpu usage로 했다.
- 그런데, kdevtmpfsi 프로세스라는 멀웨어가 공식 이미지에서 문제를 일으켰다는 내용의 이슈를 확인할 수 있었다.
😈 kdevtmpfsi & kinsing: 암호화폐 채굴 악성코드(Malware)
- 비슷한 류의 악성 코드를 찾아보니 여러 개가 있었고 그중 대표적인 것을 간략하게 정리해 봤다.
kdevtmpfsi
리눅스 시스템에서 발견되는 암호화폐 채굴 악성코드
- /tmp/kdevtmpfsi 같은 경로에서 실행됨
- CPU 사용량 급증, 서버 리소스 과다 점유
kinsing
- Docker 및 Kubernetes 환경을 노리는 악성코드
- 컨테이너 취약점을 이용해 백도어 설치 & 채굴 활동
- kdevtmpfsi와 함께 동작하는 경우 많음
정리하면 다음과 같다.
암호화폐 채굴 멀웨어는 감염된 서버의 CPU 자원을 몰래 사용하여 암호화폐를 채굴한다.
- 그 결과, 서버의 CPU 사용률이 비정상적으로 높아지고 성능 저하가 발생할 수 있다.
Docker 공식 이미지 자체에는 악성코드가 포함되지 않지만,
- 이미 감염된 호스트(OS)에서 컨테이너가 실행되면 내부로 유입될 가능성이 있다.
컨테이너의 포트 설정, 보안 설정이 취약하면 감염 위험이 커진다.
- 예를 들어, 잘 알려진 포트(22, 2375 등)를 오픈하거나,
- root 권한으로 컨테이너를 실행하면 공격자가 쉽게 침투할 수 있다.
보안 강화가 필수!
- 최신 패치 적용, root 권한 제한, 방화벽 설정 강화, 의심스러운 프로세스 주기적 점검이 필요하다.
👨🏻✈️ 잠복 근무하기
- 먼저 리눅스 로컬에서 위 멀웨어와 관련된 키워드로 검색해 보았지만 전혀 나오지 않았다.
- 이 때문에 로컬에서 컨테이너로 감염된 것이 아니라 이미지 자체가 문제인 것 같다는 생각도 들었다.
- 멀웨어의 저장 위치를 정확히 추적하기 위해 해당 프로세스가 다시 나타나기를 기다렸다.
- 컨테이너를 새로 띄운 상태여서인지 몇 시간을 기다려봤지만 나타나지 않았다.
- 그래서 우선 멀쩡한 상태의 postgres 컨테이너의 정보를 기록해 두었다.
🏃🏻♂️➡️ postgres 컨테이너를 새로 띄운 직후
# 도커 컨테이너 내 실행 중인 프로세스를 확인
$ docker top <container id>
# 출력
UID PID PPID C STIME TTY TIME CMD
systemd+ 19832 19811 0 14:24 ? 00:00:00 postgres
systemd+ 19912 19832 0 14:24 ? 00:00:00 postgres: checkpointer
systemd+ 19913 19832 0 14:24 ? 00:00:00 postgres: background writer
systemd+ 19921 19832 0 14:24 ? 00:00:00 postgres: walwriter
systemd+ 19922 19832 0 14:24 ? 00:00:00 postgres: autovacuum launcher
systemd+ 19923 19832 0 14:24 ? 00:00:00 postgres: logical replication launcher
root 61634 19811 0 14:49 pts/0 00:00:00 /bin/bash
# 컨테이너 내부 접속
$ docker exec -it <container id> /bin/bash
# /tmp 폴더 이동
root@020dcd076130:/# cd /tmp/
# 숨김폴더까지 확인
root@020dcd076130:/tmp# ls -al
total 0
drwxrwxrwt. 2 root root 6 Apr 24 2024 .
drwxr-xr-x. 1 root root 29 Feb 13 14:24 ..
# /var/tmp 폴더 이동
root@020dcd076130:/# cd /var/tmp/
# 숨김폴더까지 확인
root@020dcd076130:/var/tmp# ls -al
total 0
drwxrwxrwt. 2 root root 6 Jan 29 2024 .
drwxr-xr-x. 1 root root 17 Apr 24 2024 ..- 이 정보를 보면 postgres 컨테이너 내 실행 중인 프로세스에 이상한 점은 없으며 컨테이너 내부에 들어가 /tmp 등 멀웨어가 저장될만한 공간을 전부 들어가 보았지만 아무것도 없었다.
- 심지어 인스턴스에서 위 멀웨어와 관련된 키워드로 검색해 보았지만 전혀 나오지 않았다.
😈 다시 실행된 의문의 프로세스
# top
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
167357 systemd+ 20 0 2441228 2.3g 4 S 191.7 14.9 250:24.48 gylnuhwro
root@020dcd076130:/tmp# ls -al
total 0
drwxrwxrwt. 1 root root 42 Feb 14 01:12 .
drwxr-xr-x. 1 root root 40 Feb 13 14:24 ..
drwx------. 2 postgres postgres 23 Feb 14 01:12 .vrbuzemjt
drwx------. 2 postgres postgres 23 Feb 13 22:12 .xwaphstex
root@020dcd076130:/tmp# cd .vrbuzemjt/
root@020dcd076130:/tmp/.vrbuzemjt# ls -al
total 1988
drwx------. 2 postgres postgres 23 Feb 14 01:12 .
drwxrwxrwt. 1 root root 42 Feb 14 01:12 ..
-rwxr-xr-x. 1 postgres postgres 2032004 Feb 14 01:12 gylnuhwro- top 명령어를 통해 해당 프로세스가 다시 동작중임을 확인했다.
- 이후 문제의 컨테이너인 postgres:16.2 컨테이너에 접속하여 컨테이너 내부의 /tmp 폴더에 들어가 보았다.
- 해당 경로를 살펴보니 postgres 유저 이름으로 불분명한 문자열의 숨김폴더가 생성되었음을 확인할 수 있었다.
- 해당 폴더 중 제일 최근에 생성된 폴더를 들어가니 로컬 호스트의 COMMAND에 표시된 문자열과 동일한 문자열의 파일을 찾을 수 있었다.
🐳 docker 컨테이너 내부 탐색하기
# 컨테이너 내부에서 패키지 다운로드
# procps → ps, top, uptime, free 명령어 사용 가능하게 다운로드
# net-tools → netstat, ifconfig 명령어 사용 가능하게 다운로드
$ apt update && apt install -y net-tools procps
# 컨테이너 내부 실행 중인 모든 프로세스를 확인
root@020dcd076130:/tmp# ps -aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
postgres 1 0.0 0.1 220136 18264 ? Ss Feb13 0:02 postgres
root 116 0.0 0.0 7196 540 pts/0 Ss+ Feb13 0:00 /bin/bash
root 147 0.0 0.0 7196 544 pts/1 Ss+ Feb13 0:00 /bin/bash
root 706 0.0 0.0 7196 516 pts/2 Ss+ Feb13 0:00 /bin/bash
postgres 943 0.0 0.0 6716 4428 ? Sl Feb13 0:00 postgres:
root 1724 0.0 0.0 7196 2628 pts/3 Ss+ 03:22 0:00 /bin/bash
root 2983 0.0 0.0 7196 4100 pts/4 Ss 11:36 0:00 /bin/bash
postgres 3571 186 14.9 2441228 2402536 ? Sl 12:12 143:09 /bin/bash
...
root@020dcd076130:/tmp# ls -l /proc/3571/exe
lrwxrwxrwx. 1 postgres postgres 0 Feb 14 12:12 /proc/3571/exe -> /tmp/.qyoopvprr/xkvmnjdrv
# PID로 부모 프로세스 추적
root@020dcd076130:/tmp# ps -o pid,ppid,cmd -p 3571
PID PPID CMD
3571 943 /bin/bash
# PID로 부모 프로세스 추적
root@020dcd076130:/tmp# ps -o pid,ppid,user,cmd -p 943
PID PPID USER CMD
943 1 postgres postgres:
# 프로세스 트리로 확인해보기
root@020dcd076130:/tmp# pstree -ap
postgres,1
├─emwddcpwo,943
│ ├─xkvmnjdrv,3571
│ │ ├─{xkvmnjdrv},3572
│ │ ├─{xkvmnjdrv},3573
│ │ ├─{xkvmnjdrv},3574
│ │ ├─{xkvmnjdrv},3575
│ │ ├─{xkvmnjdrv},3576
│ │ ├─{xkvmnjdrv},3582
│ │ └─{xkvmnjdrv},3583
│ └─{emwddcpwo},944
├─postgres,8966
├─postgres,8967
├─postgres,8968
├─postgres,8969
├─postgres,8970
├─postgres,8973
├─postgres,8974
├─postgres,8975
├─postgres,8976
├─postgres,8977
├─postgres,8978
├─postgres,8979
├─postgres,8980
├─postgres,8981
└─postgres,8982- 좀 더 명확한 정보 수집을 위해 컨테이너에 ps, netstat 등과 같은 명령어를 사용하려고 했으나 기본 이미지 내 OS에는 해당 명령어를 제공해주지 않아 직접 설치해야 했다.
- 이후 ps -aux와 같은 명령어를 통해 해당 프로세스가 컨테이너 내부에서 실행 중임을 확인했다.(PID 3571)
- 해당 PID로 부모프로세스를 추적해 보니 postgres라는 user 이름이 최상단에 위치해 있었다.
- 이로써 공식 이미지를 사용한 컨테이너임에도 멀웨어 의심 프로세스가 동작중임이 확인되었다.
# 현재 시스템의 네트워크 연결 상태를 확인하는 명령어
root@020dcd076130:/tmp# netstat -antp
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.x.x.x:xxxxx 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:xxxx 0.0.0.0:* LISTEN -
tcp 0 0 172.x.x.x:xxxx 172.x.x.x:xxxxx ESTABLISHED -
tcp 0 0 172.x.x.x:xxxx 172.x.x.x:xxxxx ESTABLISHED -
tcp 0 0 172.x.x.x:xxxx 172.x.x.x:xxxxx ESTABLISHED -
tcp 0 0 172.x.x.x:39830 185.10.68.220:443 ESTABLISHED -
...
tcp6 0 0 :::xxxx :::* LISTEN -- 또한 컨테이너 내부에서 netstat 명령어를 통해 182.10.68.220과 같은 처음 보는 IP와 연결되고 있음이 확인되었다.
- Local Address에 적힌 39830 포트는 해당 프로세스를 죽여 다시 재생성되었을 때 변하지만 Foreign Address의 IP는 변하지 않고 그대로였다.
- 아이피 주소를 검색해 보니 인도네시아로 나왔다.(프로세스를 죽이고 컨테이너를 재시작 했을 때 루마니아로 변경된 걸 보면 실행 프로세스마다 유동적인 것 같다)
- 처음엔 DB의 과부하였나 싶었는데 멀웨어임을 확신하는 순간이었다.
🫥 상황 정리하기
- 의문의 프로세스가 CPU를 엄청 잡아먹는 것을 발견
- top로 해당 프로세스 위치 추적
- 특정 docker container에서 실행 중임을 확인
- 암호화폐 마이닝 멀웨어 이슈가 있다는 걸 알게 됨
- 로컬 호스트에서 해당 멀웨어 이름을 여러 번 검색했지만 나오지 않음
- 문제의 컨테이너로 들어가 컨테이너 내부에서 리눅스 명령어 사용하도록 패키지 다운로드를 함
- Linux 명령어를 통해 /tmp 폴더에 멀웨어 의심 프로세스가 생성됨을 확인
😤 대처하기
- 이후에 해당 컨테이너 내부에 멀웨어가 있다고 가정하고 멀웨어의 위치를 찾으려고 별 짓을 다해봤지만 컨테이너 내부에서는 도저히 찾을 수 없었다.
- 이거만 지우면 완전한 승리인데 매우 아쉬웠다.
- 여기서 거의 포기 직전이었기 때문에 임시방편으로 더 이상 해당 멀웨어에 프로세스 사용량을 뺏기지 않게만 막도록 하려고 했다.
- 왜냐하면 이미지 자체가 문제라고 여겨 해당 이미지를 업데이트하기에는 해당 프로젝트는 우리 회사 프로젝트와는 전혀 관계가 없었고, 우리 서버를 빌려주고 운영을 도와주며 약간의 유지보수만 하고 있었기 때문이다.
- 마음대로 버전을 바꾸다가 문제가 발생하면 굉장히 곤란해지기 때문에 이미지를 변경하는 것보다 문제 해결을 더 우선으로 했다.
- 그래서 해당 프로세스의 원리를 생각해 봤다.
- 분명 이러하다.
- 해당 컨테이너가 띄워지면 어떤 트리거인지는 모르나 매우 불규칙하게 postgres 유저 권한으로 /tmp 폴더에 불분명한 랜덤 문자열의 숨김 폴더가 생성되며, 해당 폴더 안에는 다시 불분명한 랜덤 문자열의 프로세스가 설치되고 이 프로세스가 cpu를 갉아먹는다.
- 만약 postgres의 db 관련 임시파일이었다면 postgres 폴더 내에 생성되었을 것이다.
- 그래서 단순히 이렇게 접근해 봤다. /tmp 폴더의 접근권한을 root 계정으로 막아버리면 psotgres 유저 권한으로는 파일을 생성 못하지 않을까?
🔐 컨테이너 내 멀웨어 설치 폴더 권한 변경하기
# tmp 폴더 권한 변경(루트만 읽고 쓸 수 있도록 변경)
root@020dcd076130:/# chmod 600 /tmp
# 권한 변경 후 모습 ls -al
drw-------. 1 root root 6 Feb 14 15:04 tmp- 이렇게 바꿔주니 놀랍게도 최근 하루에도 여러 번 생성되던 프로세스가 3일째 나타나지 않았다.
- 그리고, 로컬 호스트에서 top 명령어로 매일 체크하고 있는데 매우 놀라운 걸 발견했다.
👮🏻♂️ 로컬 호스트에서 kdevtmpfsi의 등장 잡았다 요놈!
# 로컬 호스트에서 top
$ top
# 출력
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
...
26 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kdevtmpfs- 이게 연관이 있는지는 모르겠으나 tmp 권한 변경으로 더 이상 컨테이너 내부 postgres 유저의 권한으로 멀웨어 프로세스를 설치하지 못하게 하자 한 번도 보이지 않던 kdevtmpfsi가 로컬 호스트에 등장했다.
- 또한, 여러 글을 찾아 본 바 로컬 호스트에서 컨테이너에 접근하여 컨테이너 내부에 프로세스를 설치한다는 내용이 대다수였다.
- 아마 kdevtmpfsi가 컨테이너에 멀웨어를 설치하기 위해 계속 실행중인 것이 아닐까 생각이 들었다.(권한 문제로 계속 실패하기 때문에 시도만 하는 것 아닌가..?)
- 사실 이 프로세스를 삭제하는 방법은 매우 단순했다.
- 그저 find 명령어로 프로세스 위치를 찾아 지우는 것이었는데 나의 경우 처음에는 검색이 되지 않아 멀웨어가 아니구나 생각했던 것이다.
🤔 부모 프로세스 추적과 찜찜한 해결
26 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kdevtmpfs
$ sudo find / -name kdevtmpfs
# 출력 아무것도 안나옴
# 부모 프로세스 추적
$ ps -o pid,ppid,cmd -p 26
PID PPID CMD
26 2 [kdevtmpfs]
$ ps -o pid,ppid,cmd -p 2
PID PPID CMD
2 0 [kthreadd]
# 프로세스 트리로 확인
$ pstree -ap 2
(kthreadd,2)
...
├─(kdevtmpfs,26)
...- kthreadd는 Linux 커널의 스레드 관리자 프로세스이며, 이 프로세스에 의해 kdevtmpfsi가 실행됨을 확인할 수 있다.
- 그러나, 로컬 호스트에서 kdevtmpfsi는 여전히 검색되지 않았고, kill 명령어도 먹히지 않았다.
- 스텍오버플로우나 블로그를 보면 대부분의 경우 이 프로세스에서 cpu 사용량을 엄청 잡아먹는데, 아직 그런 문제는 발생하지 않았다.
- 나의 경우는 kdevtmpfsi 대신 불분명한 랜덤 문자열의 프로세스였다.
- 만약 kdevtmpfsi 프로세스가 cpu 사용량을 초과해 버리는 문제가 발생하면 그때 다시 내용을 업데이트하겠다.
😵💫 정리
- 로컬 호스트인지 Docker Image인지 특정 감염 경로를 통해 postgres:16.2 이미지를 사용한 컨테이너에서 멀웨어 프로세스가 지속적으로 생성됨을 확인했다.
- 멀웨어의 정확한 위치를 찾지 못해 해당 멀웨어가 이용하는 폴더의 권한을 root로 업데이트해줘 임시로 해결했다.
- 그랬더니 보이지 않던 kdevtmpfsi가 로컬호스트 프로세스 목록에 나왔다.
- 찾아서 지우려고 했으나 찾을 수 없는 상태이다.
- 만약 이 프로세스가 다시 다른 문제를 일으킨다면 그때 다시 해결 후 블로깅하겠다. 끗
참고
chatGPT
https://stackoverflow.com/questions/60151640/kdevtmpfsi-using-the-entire-cpu
728x90
'[DevOps] > Docker' 카테고리의 다른 글
| Docker Compose 정리 (0) | 2023.07.08 |
|---|---|
| Docker로 다중 컨테이너 애플리케이션 구축하기 - 2 (네트워크로 묶기, 데이터 지속성 추가) (0) | 2023.07.07 |
| Docker로 다중 컨테이너 애플리케이션 구축하기 - 1 (여러 개의 컨테이너 만들기) (0) | 2023.07.07 |
| Docker - 컨테이너 통신 (0) | 2023.07.05 |
| Docker - Volumn & Bind Mount 이해하기 (1) | 2023.06.30 |