kubectl debug --profile, 이거 모르는 사람 꽤 많더라

어제 팀원이 distroless 이미지로 뜬 파드에 붙어서 tcpdump를 뜨려다가 삽질했다. kubectl exec 안 되는 건 알아서 kubectl debug까지는 갔는데, 그 다음에 막혔다. 컨테이너는 붙었는데 /proc/1 못 읽고, 네트워크 인터페이스도 안 보이고. "이거 왜 이러지?" 하길래 옆에서 --profile=sysadmin 하나 붙여줬더니 바로 됐다.

이 옵션 모르는 사람이 생각보다 많아서 짧게 정리한다.

profile이 뭐냐

kubectl debug는 기본적으로 ephemeral container를 파드에 끼워넣는다. 근데 이 컨테이너의 securityContext를 어떻게 세팅할지가 문제다. 그냥 붙이면 non-root에 capability 다 벗겨진 상태로 뜬다. nsenter, tcpdump, strace 같은 거 대부분 못 쓴다.

그래서 --profile 플래그로 프리셋을 골라주면 된다. 1.30부터 GA된 기능이고 지금은 그냥 당연하게 쓴다.

주로 쓰는 프로필은 이 정도:

• legacy (기본값) — 아무것도 안 붙여줌. 대상 컨테이너의 securityContext를 상속받지도 않음
• general — target 컨테이너의 UID/GID를 상속
• baseline — Pod Security의 baseline 수준
• restricted — 가장 제약 많음
• netadmin — NET_ADMIN, NET_RAW capability. tcpdump, iptables 볼 때
• sysadmin — privileged. 뭐든 다 볼 때

실제로 쓰는 케이스

네트워크 디버깅할 때는 netadmin.

kubectl debug -it my-pod \
  --image=nicolaka/netshoot \
  --target=app \
  --profile=netadmin \
  -- bash

이렇게 하면 컨테이너 안에서 tcpdump -i eth0 같은 게 그냥 된다. --target이 중요한데, 이걸 안 붙이면 대상 컨테이너의 프로세스가 안 보인다. PID 네임스페이스 공유가 안 되기 때문.

시스템 레벨 파고들 때는 sysadmin.

kubectl debug -it my-pod \
  --image=busybox \
  --target=app \
  --profile=sysadmin \
  -- sh

/proc/<pid>/root 통해서 대상 컨테이너 파일시스템도 볼 수 있고, nsenter로 필요하면 다른 네임스페이스도 들어갈 수 있다.

함정 하나

주의할 게 있는데, ephemeral container는 한 번 추가하면 파드 spec에서 못 지운다. 파드를 새로 만들기 전까지 그대로 붙어 있다. 프로덕션에서 남발하면 파드 spec이 지저분해진다. 디버깅 끝나면 그냥 파드 지우고 새로 뜨는 게 낫다.

그리고 issue #1650에 올라온 건데, 파드 레벨 runAsUser가 root 아닌 값으로 강제되어 있으면 sysadmin 프로필 붙여도 non-root로 뜬다. privileged: true인데 non-root라서 정작 필요한 건 못 하는 상황이 나온다. 이럴 땐 파드 spec에서 그 부분 확인해야 한다.

왜 이걸 쓰지 않는지

솔직히 예전에는 그냥 kubectl run --rm -it netshoot로 임시 파드 띄워서 클러스터 안에서 디버깅했다. 근데 그러면 대상 파드의 네트워크 네임스페이스가 아니라 그냥 클러스터 네트워크만 보인다. Service 통해서 접근은 되지만 진짜 "저 파드 안에서" 무슨 일이 일어나는지는 안 보인다.

kubectl debug --target은 완전히 다르다. 대상 파드의 네임스페이스에 그대로 붙어서 본다. 이 차이를 모르고 kubectl run으로 계속 우회하는 사람 은근 많다.

혹시 다른 좋은 디버깅 워크플로우 쓰시는 분 있으면 알려주세요.

---

태그: #kubernetes #kubectl #debugging #devops #ephemeral-container