컨테이너를 지우면 컨테이너 안에서 쓴 파일도 함께 사라집니다. 이 글에서는 이름 있는 볼륨(named volume), 바인드 마운트(bind mount), tmpfs가 각각 데이터를 어디에 저장하고 컨테이너를 지운 뒤 무엇이 남는지 실제로 실행해 확인합니다. 이어서 마운트가 이미지 안의 파일을 가리는 경우, 이미지를 바꿔도 볼륨 내용이 그대로인 경우, VOLUME 지시어가 만드는 익명 볼륨이 쌓이는 경우, non-root 컨테이너의 쓰기 권한(UID) 문제, 백업과 정리 방법까지 정리합니다. 환경은 Docker 29.1.3(Docker Desktop, linux/arm64), alpine 3.22, nginx 1.29-alpine입니다.먼저 한 장으로 봅니다. 컨테이너 안의 경로 세 곳을 각각 named..
Docker 컨테이너는 기본 설정에서 root로 실행되고 14개의 리눅스 권한(capability)을 가집니다. 이 글에서는 --user, --cap-drop, --read-only, --security-opt no-new-privileges, seccomp, --privileged가 각각 무엇을 막거나 여는지, 같은 명령을 옵션 유무로 나눠 실행해 확인하고 모두 합친 docker run 한 줄과 쿠버네티스 securityContext와의 대응까지 정리합니다. 환경은 Docker 29.1.3(Docker Desktop, linux/arm64), busybox 1.36, python 3.12-slim입니다.먼저 한 장으로 봅니다. 같은 명령을 옵션이 없을 때(왼쪽, 열린 쪽)와 옵션이 있을 때(오른쪽, 막..
쉘이 없는 distroless 이미지의 파드는 kubectl exec로 들어갈 수 없고, 죽어 있는 파드는 더더욱 들여다보기 어렵습니다. 이 글에서는 kubectl debug가 기존 파드에 임시 컨테이너(ephemeral container)를 붙이는 방법과 --target의 효과, CrashLoopBackOff 파드에서는 임시 컨테이너가 붙지 않아 --copy-to로 복제해야 하는 이유, 디버그 프로파일과 노드 디버깅, 필요한 RBAC 권한을 로컬 k3s 클러스터(Kubernetes v1.35.9, kubectl v1.34.1)에서 직접 실행해 정리합니다.먼저 전체 그림입니다. 쉘이 없는 app 컨테이너에는 kubectl exec가 실패하지만, kubectl debug는 같은 파드에 도구가 든 임시 컨테..
컨테이너가 표준 출력으로 내보내는 로그는 Docker 기본 설정에서 호스트 디스크의 파일로 쌓이고, 그 파일에는 크기 제한이 없습니다. 이 글에서는 json-file 로그 드라이버의 로테이션 옵션(max-size, max-file)이 실제로 파일을 어떻게 돌려 쓰는지 직접 실행해 확인하고, local 드라이버와의 차이, 설정하는 세 가지 위치, 쿠버네티스에서의 대응을 정리합니다. 환경은 Docker 29.1.3(Docker Desktop, linux/arm64), Docker Compose 2.40.3, busybox 1.36입니다.먼저 로그가 어디에 쌓이는지 그림으로 봅니다. 컨테이너가 출력한 한 줄은 로그 드라이버를 거쳐 호스트 디스크의 파일이 되고, docker logs는 그 파일을 읽어서 보여 줍..
컨테이너에 메모리와 CPU 상한을 주면 커널이 실제로 무엇을 하는지, 직접 한계를 넘겨서 확인한 기록입니다. --memory, --cpus 옵션이 cgroup 값으로 바뀌는 과정, 메모리 한계를 넘었을 때 종료되는 모습(OOMKilled, 종료 코드 137), 스왑이 종료 시점을 바꾸는 것, CPU 제한은 프로세스를 죽이지 않고 느리게 만든다는 것까지 다룹니다. 환경은 Docker 29.1.3(cgroup v2, arm64), python 3.12-slim, busybox 1.36입니다.위 그림이 첫 번째 핵심입니다. docker run의 제한 옵션은 컨테이너의 cgroup 파일 값으로 바뀌고, 이후의 제한은 커널이 집행합니다. 쿠버네티스의 resources.limits도 같은 방식으로 동작하기 때문에,..
노드에 NIC가 여러 개일 때 노드 IP를 어떻게 고르는지(OpenShift의 NODEIP_HINT, RKE2의 node-ip)와, 클러스터 안쪽에서 쓰는 파드·서비스 대역(OpenShift의 clusterNetwork·serviceNetwork, RKE2의 cluster-cidr·service-cidr)을 한 번에 비교합니다. 공식 문서(OKD 4.18~4.21, RKE2)의 내용을 기준으로 하고, NODEIP_HINT용 MachineConfig 값 생성과 대역 겹침 검사는 직접 실행해서 확인했습니다.위 표가 이 글의 요약입니다. 두 플랫폼 모두 "클러스터가 어떤 IP 대역을 쓰는가"를 설정 시점에 정해야 하고, 한 번 정하면 바꾸기 어렵다는 공통점이 있습니다. 설정 키 이름은 공식 문서 기준입니다. ..
