day-log

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