🔍 kubectl run에서 sh가 필요할 때와 필요 없는 이유

Kubernetes에서 kubectl run으로 테스트 Pod를 만들다 보면 이런 의문이 생긴다.

왜 어떤 명령은 sh 없이 실행되고,
어떤 경우는 sh -c를 붙여야 할까?

이 글에서는 그 차이를 정리한다.

---

📦 전제: busybox 이미지

예제로 사용하는 이미지는 busybox.

busybox 특징:

• ENTRYPOINT 없음
• 기본 CMD는 sh
• wget, ls, nslookup 등 실행 파일이 존재
• 멀티콜 바이너리 구조

---

1️⃣ --command 사용한 경우

kubectl run busybox \
  --image=busybox \
  --restart=Never \
  --command -- wget -O- 192.168.255.131:80

내부 동작

• ENTRYPOINT 무시
• command 필드에 직접 wget 지정

실행 형태:

wget -O- 192.168.255.131:80

✔ sh 필요 없음

---

2️⃣ --command 없이 실행

kubectl run busybox \
  --image=busybox \
  --restart=Never \
  -- wget -O- 192.168.255.131:80

내부 동작

• ENTRYPOINT 유지
• args에 wget 전달

busybox에는 /bin/wget이 존재하기 때문에 바로 실행 가능.

실행 형태:

wget -O- 192.168.255.131:80

✔ sh 필요 없음

---

3️⃣ --rm -it 포함 실행

kubectl run busybox \
  --image=busybox \
  --rm -it \
  --restart=Never \
  -- wget -O- 10.1.1.131:80

차이점

• -it → 터미널 연결
• --rm → 종료 후 자동 삭제

하지만 실행 구조는 2번과 동일.

✔ sh 필요 없음
✔ 단지 실행 방식이 인터랙티브일 뿐

---

📊 정리 표

구분	sh 필요 여부	차이점
--command 사용	❌	entrypoint override
--command 없음	❌ (busybox 기준)	args 전달
--rm -it	❌	인터랙티브 + 자동삭제

---

🔥 그럼 sh가 필요한 경우는?

1️⃣ 여러 명령 실행할 때

-- sh -c "wget ... && echo done"

2️⃣ 파이프(|), 리다이렉션(>) 사용 시

-- sh -c "wget ... | grep html"

3️⃣ ENTRYPOINT가 고정된 이미지일 때

예: nginx 이미지

kubectl run test --image=nginx -- wget ...

→ 실행 실패 가능성 높음
→ 반드시 sh -c 필요

---

🧠 핵심 개념

Kubernetes에서:

• --command → ENTRYPOINT를 덮어씀
• -- 뒤 명령 → args로 전달

busybox는 실행 파일이 이미 존재하기 때문에
sh 없이도 바로 실행 가능하다.

하지만 모든 이미지가 그런 것은 아니다.

---

🎯 실무에서 안전한 패턴

헷갈리지 않으려면 이렇게 쓰는 것이 가장 예측 가능하다.

kubectl run tmp \
  --image=busybox \
  --rm -it \
  --restart=Never \
  -- sh -c "wget -O- 10.1.1.131:80"

이 방식은 이미지 종류에 관계없이 안정적으로 동작한다.

---

🏁 결론

이번 3가지 명령은 모두 sh 없이 실행되지만,
그 이유는 busybox 이미지의 구조 때문이다.

핵심은:

• ENTRYPOINT
• command
• args
• 이미지 내부 실행 파일 존재 여부

이 4가지를 이해하면 혼동이 사라진다.