day-log

오늘 후배가 distroless 이미지로 돌아가는 파드를 디버깅하느라 새벽까지 헤매고 있길래 옆에서 한마디 했다. "그냥 --profile=netadmin 붙여." 그랬더니 표정이 묘했다. "그게 뭔데요?" 아... 이거 1.27에서 들어온 게 벌써 3년이 다 돼가는데 의외로 안 쓰는 사람이 많다. 짧게 정리한다.무슨 문제를 푸는가kubectl debug로 ephemeral container를 띄울 때 기본값은 권한이 거의 없다. 그래서 tcpdump나 iptables -L 같은 걸 돌리면 그냥 막힌다. 우리 팀에서도 처음엔 sidecar로 netshoot을 띄워놓던 시절이 있었는데, 그건 그것대로 메모리 잡아먹고 보안팀이 싫어한다.--profile 플래그는 이런 류의 권한 세트를 미리 정의해놓은 프리셋..

상황운영 중인 파드가 한 개 있다. 베이스 이미지는 gcr.io/distroless/static:nonroot. 셸은커녕 ls도 없다. 그런데 갑자기 이 파드만 외부 API 호출이 실패하기 시작한다. DNS 문제인지, 라우팅 문제인지, 인증서 문제인지 확인하고 싶다. 파드를 재시작하면 증상이 사라질 수도 있으니 살아있는 상태에서 보고 싶다. 자, 어떻게 할까?이거 모르는 분 꽤 많더라. 어제 후배가 "프로덕션 파드에 들어가서 curl 좀 찍어보고 싶은데 distroless라서 kubectl exec가 안 먹힌다"라고 슬랙에 글 올린 거 보고 깜짝 놀랐다. kubectl debug가 GA 된 게 1.25 (2022년 후반) 인데, 2026년 지금까지도 의외로 안 쓰는 사람이 많은 것 같아서 짧게 정리한다...

우리 팀이 자주 쓰는 형태오늘 점심에 동료가 "운영 Pod에 strace 한 번만 떠보면 알 것 같은데 못 들어간다"고 한참 끙끙대길래 옆에서 봤다. distroless 이미지라 shell이 없고, 그렇다고 ephemeral container를 그냥 띄우자니 같은 PID namespace가 아니라 프로세스가 안 보인다는 거였다. 사실 이거 의외로 많이들 모르고 지나가더라.kubectl debug에 --copy-to랑 --share-processes를 같이 주면 거의 다 해결된다. 1.30 GA 이후로 옵션 동작도 안정돼서 운영에서 그냥 쓰면 된다.원본 Pod는 그대로 두고, 동일한 spec의 복제 Pod에 디버그 컨테이너를 끼워넣는 방식. 트래픽 받는 Pod 직접 손대지 않아도 된다.kubectl deb..

오늘 알게 된 건 아니지만, 최근에 팀 내부 트러블슈팅 가이드 다듬다가 다시 한 번 짚어둘 만하다 싶어서 짧게 적는다. kubectl debug로 ephemeral container 띄울 때 --target 빠뜨리고 쓰는 분들이 의외로 많다. 1.25부터 EphemeralContainers feature gate가 GA로 켜진 게 벌써 한참 됐는데도.무슨 문제냐면distroless 이미지를 쓰는 파드에 들어가서 curl이나 netstat 한 번 쳐보고 싶을 때 보통 이렇게 쓴다.kubectl debug -it my-pod -n prod --image=nicolaka/netshoot이걸로 컨테이너는 잘 붙는다. 근데 막상 들어가서 ps를 쳐보면 본인 프로세스만 보인다. 본 컨테이너의 PID가 안 보인다는 ..

ephemeral container를 붙이면 끝난다오늘 알게 된 건데, 의외로 kubectl debug 안 써본 분들 꽤 많더라.우리 팀은 보안팀 권고로 작년부터 베이스 이미지를 distroless로 통일했다. 공격 표면 줄이고 CVE 대응 줄이는 데는 좋은데, 막상 운영 중에 컨테이너 안으로 들어가서 뭐 좀 보려고 하면 막막하다. kubectl exec -it pod sh 치면 OCI runtime exec failed: exec: "sh": executable file not found in $PATH 떨어지는 그 상황. 옛날에는 이걸 우회하려고 디버깅용 -debug 태그 이미지를 따로 빌드해서 RollingUpdate로 갈아끼우는 짓을 했다. 지금 생각하면 좀 한심한데, 그땐 그게 최선처럼 보였다...

오늘 알게 된 것도 아니고, 알고는 있는데 막상 새벽에 장애 터지면 까먹는 옵션 하나를 정리해두려고 한다. kubectl debug --target. 같이 일하는 주니어한테 알려주니까 "어 이게 되네요?" 하길래.흔한 상황운영 중인 Pod에서 네트워크가 이상하다. DNS는 되는데 특정 외부 IP로만 connect timeout. 컨테이너는 distroless라서 kubectl exec로 들어가도 쉘이 없다. 사이드카로 디버깅 컨테이너 박아서 재배포? 새벽 두 시에 그건 좀 그렇다.이럴 때 쓰는 게 ephemeral container, 그리고 kubectl debug다. K8s 1.25에서 GA된 후로 죽 안정적이다. 근데 의외로 --target 옵션을 안 쓰고 그냥 띄워서 "어 왜 안 보이지" 하는 경우..

운영 환경에서 Pod가 CrashLoopBackOff에 빠지거나, 네트워크 연결이 안 되거나, 파일시스템 상태를 확인해야 할 때가 있습니다. 문제는 대부분의 프로덕션 컨테이너 이미지에는 curl, dig, netstat 같은 디버깅 도구가 없다는 것입니다.distroless 이미지나 최소화된 Alpine 기반 이미지를 사용하면 보안과 이미지 크기 면에서 이점이 있지만, 장애 상황에서 원인을 파악하기가 까다로워집니다. kubectl debug는 이런 상황을 위해 만들어진 도구입니다.이 글에서는 kubectl debug의 세 가지 모드를 실전 예제와 함께 살펴보겠습니다.Ephemeral Container로 실행 중인 Pod 디버깅가장 많이 쓰이는 패턴입니다. 실행 중인 Pod에 임시 컨테이너(Ephemera..