day-log

어제 팀원이 distroless 이미지로 뜬 파드에 붙어서 tcpdump를 뜨려다가 삽질했다. kubectl exec 안 되는 건 알아서 kubectl debug까지는 갔는데, 그 다음에 막혔다. 컨테이너는 붙었는데 /proc/1 못 읽고, 네트워크 인터페이스도 안 보이고. "이거 왜 이러지?" 하길래 옆에서 --profile=sysadmin 하나 붙여줬더니 바로 됐다.이 옵션 모르는 사람이 생각보다 많아서 짧게 정리한다.profile이 뭐냐kubectl debug는 기본적으로 ephemeral container를 파드에 끼워넣는다. 근데 이 컨테이너의 securityContext를 어떻게 세팅할지가 문제다. 그냥 붙이면 non-root에 capability 다 벗겨진 상태로 뜬다. nsenter, tc..

이거 모르는 분 꽤 많더라. 요즘 이미지 최적화한다고 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 컨테이너 파드 안에서 tcpdump 뜨고 싶은데 어떻게 해요?" 라고 물어봐서 답해주다가, 생각보다 kubectl debug --profile 옵션을 모르는 사람이 많다는 걸 알았다. 나도 예전엔 급하면 그냥 securityContext.privileged: true 넣은 사이드카 파드 하나 붙여서 디버깅했는데, 지금은 그럴 필요가 없다.프로필이 뭘 해주냐면kubectl debug로 ephemeral container를 붙일 때 --profile 플래그 하나로 필요한 capability 조합을 미리 세팅해준다. 손으로 securityContext YAML을 쓰지 않아도 된다는 얘기다. 현재 지원되는 프로필은 다섯 개다.general — 일반적인 디버깅용 기..

이거 모르는 분 꽤 많더라. 어제 팀원이 "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..

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

오늘 알게 된 건 아니지만, 최근에 팀 내부 트러블슈팅 가이드 다듬다가 다시 한 번 짚어둘 만하다 싶어서 짧게 적는다. 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..