kubectl debug, --copy-to 쓰지 마세요 (production에서는)

오늘 알게 된 건데, 이거 모르는 분 의외로 많더라. kubectl debug 쓸 때 --copy-to 옵션 말이다.

distroless 컨테이너 디버깅 글들 검색하면 거의 다 --copy-to 예제가 나온다. 근데 운영 파드를 진짜로 디버깅해본 분들은 알겠지만, 이게 좀 위험하다.

두 가지 모드, 뭐가 다른가

kubectl debug는 크게 두 가지로 쓸 수 있다.

1. ephemeral container 주입 (기본)

kubectl debug -it my-pod \
  --image=busybox:1.36 \
  --target=app

원본 파드에 임시 컨테이너를 하나 더 끼워 넣는다. PID/network namespace를 공유하니까 ps, netstat, /proc/$PID/... 다 보인다. 원본 컨테이너는 건드리지 않는다.

2. --copy-to (파드 복제)

kubectl debug my-pod \
  --image=busybox:1.36 \
  --share-processes \
  --copy-to=my-pod-debug

파드를 통째로 복제하면서 디버그 컨테이너를 끼운 새 파드를 만든다. 원본은 그대로 두고 사본을 디버깅하는 방식.

언뜻 보면 --copy-to가 더 안전해 보인다. 원본을 건드리지 않으니까. 그런데 함정이 있다.

--copy-to의 문제

장애 대응 중에 --copy-to로 사본을 띄웠는데, 정작 그 사본에서는 문제가 재현되지 않는 경우가 꽤 많다. 이유는 단순하다.

• 새로 만든 파드는 새로운 IP, 새로운 endpoint를 가진다. Service의 endpoint slice에 자동으로 안 들어간다 (label selector가 매칭되면 들어가는데, 그러면 운영 트래픽이 디버그 파드로 가서 더 문제다)
• 클라이언트 연결, 캐시, 워밍업된 JIT 상태가 사본에는 없다. 메모리 누수나 connection leak이 시간이 흐르며 누적된 거라면 사본에서는 안 보인다
• 원본 파드의 로컬 파일시스템 상태(예: 누적된 임시 파일, 핫 캐시) 차이로 재현 실패
• 노드도 다를 수 있다. --copy-to는 스케줄링을 다시 받으니, 원본이 있던 노드 상태(가령 메모리 압박)가 원인이라면 다른 노드로 갈 경우 못 잡는다

거기다 한밤중 P1 장애에서 클러스터에 갑자기 파드 하나가 더 뜬다. 노드 메모리가 빠듯하면 다른 파드가 evict 될 수도 있다. 디버깅하려다가 옆 파드 죽이는 거다. (네, 해봤습니다.)

그래서 뭘 쓰나

운영 장애 대응이면 ephemeral container 일단 써본다. 원본 파드에 직접 주입되니 위에서 말한 문제가 다 없다.

# distroless app 컨테이너에 busybox 끼워서 셸 잡기
kubectl debug -it prod-api-7d9c8-xk2qm \
  --image=busybox:1.36 \
  --target=api \
  --profile=general

--target은 PID namespace 공유 대상이다. 이거 없으면 같은 파드 안이긴 한데 ps aux에 다른 컨테이너 프로세스가 안 보인다.

--profile=general은 1.31에서 stable 된 디버깅 프로파일이다. sysadmin, netadmin, restricted 같은 것도 있어서 상황별로 권한 다르게 줄 수 있다. 옛날엔 디버그 컨테이너가 권한 너무 많거나 너무 적어서 애매했는데 이게 깔끔하게 정리해줬다.

--copy-to는 다음 같은 상황에서만 쓴다:

• 원본 파드의 command/args를 바꿔서 띄워봐야 할 때 (--copy-to에 --set-image 같이)
• crash loop 도는 파드를 sleep으로 띄워놓고 들어가서 봐야 할 때
• 운영 영향 없이 격리된 환경에서 차분히 분석하고 싶을 때 (이때는 사실 장애 대응이 아니라 사후 분석에 가깝다)

한 가지 더

kubectl debug node/<node-name> --image=busybox:1.36 도 가능하다. 노드에 디버그 파드 띄워서 chroot /host 하면 노드 안으로 들어간다. SSH 막혀있는 노드 디버깅할 때 유용. 근데 이건 SecurityContext가 privileged라 PSA 정책 빡빡한 클러스터에서는 거부될 수 있다. 미리 확인하고 가야 한다.

다음에 새벽에 호출 받았을 때 --copy-to 손이 먼저 가지 말고, ephemeral 부터 시도해보자. 그래도 안 되면 그때 가서 사본 떠도 늦지 않다.