쉘이 없는 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 대역을 쓰는가"를 설정 시점에 정해야 하고, 한 번 정하면 바꾸기 어렵다는 공통점이 있습니다. 설정 키 이름은 공식 문서 기준입니다. ..
Azure 인프라를 코드로 정의하는 언어 Bicep을 처음 접하는 분을 위해, 용어부터 풀어 쓰고 직접 컴파일한 결과로 설명합니다. Azure 구독 없이 Azure CLI 컨테이너(2.91.0)와 Bicep CLI 0.48.1만으로 컴파일, 린트, 모듈, 파라미터 파일, 역변환(decompile)까지 실행했고, 환경은 Docker 29.1.3, arm64입니다.위 그림이 전체 흐름입니다. 사람이 .bicep 파일을 쓰면 컴파일러가 ARM 템플릿(JSON)으로 바꾸고, 그 JSON을 Azure가 받아서 리소스를 만듭니다. 컴파일까지는 내 PC에서 끝나기 때문에 Azure 구독이 없어도 문법과 구조를 충분히 검증할 수 있습니다.먼저 알아둘 용어Azure가 처음이면 용어가 가장 큰 장벽입니다. 이 글에서 계속..
같은 호스트의 컨테이너끼리 통신할 때 기본 bridge 네트워크와 사용자 정의 bridge 네트워크가 어떻게 다른지, busybox 컨테이너로 직접 실험한 기록입니다. 컨테이너 이름으로 통신되는 조건, 네트워크 간 격리, 같은 이름(alias)을 가진 컨테이너에 대한 DNS 동작, 호스트에서 접근하는 포트 게시(-p)까지 다룹니다. 환경은 Docker 29.1.3(arm64), busybox 1.36.1입니다.위 그림이 이 글의 핵심입니다. 같은 bridge 계열이어도 기본 bridge는 IP로만, 사용자 정의 bridge는 이름으로도 통신됩니다. 아래에서 실제 명령과 결과로 확인합니다.왜 필요한가컨테이너의 IP는 컨테이너를 만들 때 네트워크에서 할당되는 값이라 코드나 설정에 고정해서 쓰기 어렵습니다. ..
