day-log

오늘 알게 된 건데, 이거 모르는 분 꽤 많더라. 아니 정확히는 알긴 아는데 실제로 프로덕션에서 써본 적 없는 분들. 나도 얼마 전까지 그러다.distroless 이미지 쓰는 서비스에서 이슈가 났다. 컨테이너 내부에서 curl 한 번만 때려보고 싶은데 kubectl exec -it pod -- sh 하면 당연히 sh: no such file or directory. 그렇다고 이미지를 alpine 기반으로 다시 말아 재배포? 프로덕션에서 그건 좀. 그럴 때 kubectl debug가 답이다.기본 사용법kubectl debug -it my-app-pod \ --image=busybox:1.36 \ --target=app \ -- sh--target=app이 핵심이다. 대상 컨테이너의 프로세스 네임스페이..

이거 모르는 분 꽤 많더라. 요즘 이미지 최적화한다고 distroless로 다 갈아엎는 팀이 늘어나면서, 정작 장애 났을 때 파드 안에 들어갈 방법이 없어서 당황하는 경우를 몇 번 봤다. kubectl exec 때려도 sh not found 뜨고, 로그만 봐서는 원인 파악이 안 되는 상황.kubectl debug 로 ephemeral container 붙이면 된다. 1.25에서 GA 됐고 지금은 안정적이다. 오늘 자주 쓰는 패턴 3개만 정리한다.1. distroless 파드에 셸 붙이기가장 흔한 케이스. target 컨테이너의 프로세스/네트워크 네임스페이스를 공유하는 임시 컨테이너를 하나 띄운다.kubectl debug -it my-pod \ --image=nicolaka/netshoot \ --ta..

이거 모르는 분 꽤 많더라. 어제 팀원이 "distroless 이미지로 바꿨더니 이제 파드 안 들여다볼 수가 없어요"라고 물어봐서, 그 자리에서 알려준 팁. 사실 별 것도 아닌데 정리해두면 다음에 또 물어보는 사람 나오니까.상황distroless 베이스로 만든 컨테이너는 셸도 없고 cat도 없다. 그러니 kubectl exec -it pod -- sh 는 당연히 안 먹힌다. 예전에는 어쩔 수 없이 debug용 이미지 하나 더 만들거나, 파드를 아예 복제해서 이미지만 갈아끼우거나 했었다. 근데 Kubernetes 1.25부터 ephemeral container가 stable 됐고, kubectl debug 로 훨씬 편해졌다.문제는 그냥 kubectl debug pod/foo -it --image=busyb..

Distroless 이미지는 좋다. CVE 스캔 결과가 깨끗하고, attack surface가 작고, 이미지 크기도 작다. 그런데 사고가 났을 때가 문제다. sh도 없고 curl도 없고 ls도 없다. 컨테이너 안에 들어가서 뭔가 보고 싶어도 들어갈 수단 자체가 없는 셈이다.kubectl debug 한 줄이면 끝나는 일이긴 하다. -it --image=nicolaka/netshoot --target=app. 이렇게 치면 netshoot 컨테이너가 붙고, ps도 보이고, tcpdump도 된다. 신기하다. 분명히 distroless 컨테이너 안에는 셸이 없는데 어떻게 그 컨테이너의 프로세스를 들여다보고 있는 걸까. 이게 사실 처음 봤을 때 좀 헷갈렸다. 그래서 한번 파봤다.표면적으로는 pod.spec.ephe..

상황운영 중인 파드가 한 개 있다. 베이스 이미지는 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가 안 보인다는 ..

지난주 화요일 오전이었다. 평소처럼 백오피스 서비스 배포를 돌렸는데, 운영팀 슬랙에 "1분쯤 전에 잠깐 페이지가 안 떴어요"라는 메시지가 떴다. 처음 듣는 얘기는 아니다. 사실 우리 팀에서는 배포할 때 5xx가 한두 건 튀는 걸 그냥 "Kubernetes의 미세한 빈틈"이라고 부르며 넘기고 있었다. 근데 이번엔 운영팀 화면에 명확히 보일 정도로 길었다는 게 문제였다.Grafana로 들어가서 Ingress 컨트롤러의 5xx 그래프를 봤다. 배포 시점에 503이 약 7초간 spike. 평소에는 1초 미만이었는데 이번엔 길었다. 우리 환경은 EKS 1.32, NGINX Ingress Controller, replicas 6짜리 평범한 Deployment. 이쯤이면 "또 종료 시퀀스 문제겠지" 싶었지만, 막상 ..

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로 갈아끼우는 짓을 했다. 지금 생각하면 좀 한심한데, 그땐 그게 최선처럼 보였다...