[Istio] 엥? 내 istio-proxy가 어디 갔지? 🧐 - Kubernetes Native Sidecar 완벽 분석

안녕하세요! 오늘은 최근 쿠버네티스와 Istio 환경을 다루시는 엔지니어분들이 한 번쯤 겪으셨을 법한 "사라진 사이드카 컨테이너 미스터리"에 대해 깊이 파헤쳐 보려고 합니다.

Istio를 주입(Injection)했는데 YAML 파일에는 프록시 컨테이너가 안 보이고, kubectl에서는 정상적으로 보인다면? 버그가 아닙니다. 바로 Kubernetes Native Sidecar 기능이 적용된 것입니다. 이 변화가 왜 일어났고, 어떤 점이 좋아졌는지 아주 상세하게 알아보겠습니다. 🚀

---

1. 사건의 발단: "컨테이너 개수가 이상해요" 🤔

Istio를 사용하는 환경에서 파드(Pod)를 배포하면 일반적으로 2/2 상태가 됩니다.

1. 내가 만든 애플리케이션 컨테이너
2. Istio가 주입한 프록시 컨테이너 (istio-proxy)

그런데 최근 버전(Istio 1.27+, K8s 1.29+)에서 배포된 파드의 YAML을 뜯어보면 아주 이상한 점을 발견하게 됩니다.

$ kubectl get pod details-v1
NAME                            READY   STATUS    RESTARTS   AGE
details-v1-766844796b-zmr86     2/2     Running   0          5m

 

👉 kubectl 명령어로는 분명히 READY 2/2라고 나옵니다. 즉, 컨테이너 두 개가 정상적으로 돌고 있다는 뜻이죠.

하지만 kubectl get pod details-v1 -o yaml로 명세를 확인해 보면?

spec:
  containers:
  - name: details  # <--- 어라? 컨테이너가 하나밖에 없네?
    image: docker.io/istio/examples-bookinfo-details-v1:1.20.3
    ...

 

spec.containers 섹션에 istio-proxy가 없습니다! 분명히 실행 중인데 YAML 정의에는 보이지 않는 이 귀신같은 상황, 도대체 무슨 일이 벌어진 걸까요?

---

2. 범인은 바로 'initContainers'에 숨어있다! 🕵️‍♂️

해답은 spec.containers가 아닌 spec.initContainers 섹션에 있습니다. 업로드해주신 YAML 파일을 자세히 살펴보면 그 비밀이 풀립니다.

  initContainers:
  - name: istio-init
    image: docker.io/istio/proxyv2:1.28.1
    # ... (iptables 세팅하는 일반적인 init 컨테이너) ...

  - name: istio-proxy  # <--- 여기에 숨어있었네요!
    image: docker.io/istio/proxyv2:1.28.1
    restartPolicy: Always  # <--- ⭐ 핵심 포인트 ⭐

 

원래 initContainers는 메인 애플리케이션이 뜨기 전에 '초기화' 작업만 하고 종료(Completed)되어야 하는 것이 국룰이었습니다. 그런데 istio-proxy가 여기 들어가 있고, 심지어 죽지 않고 계속 살아있습니다.

그 비결은 바로 restartPolicy: Always 라는 설정 때문입니다.

---

3. Kubernetes Native Sidecar란 무엇인가? 💡

이것은 Kubernetes v1.28(Alpha) / v1.29(Beta, Default) 부터 도입된 SidecarContainers라는 기능입니다.

과거의 방식 (Old Sidecar)

예전에는 istio-proxy를 일반 containers 목록에 같이 넣었습니다. 하지만 이 방식에는 치명적인 단점이 있었죠.

• 시작 순서 보장 불가: 애플리케이션이 프록시보다 먼저 떠서 네트워크 통신을 시도하면 실패하는 경우가 발생했습니다.
• 종료 순서 문제 (Job): 배치 작업(Job)이 끝났는데 사이드카인 istio-proxy가 안 죽어서 파드가 영원히 Running 상태로 남는 문제가 있었습니다.

현재의 방식 (Native Sidecar)

이제 쿠버네티스는 initContainers에 restartPolicy: Always를 붙이면 이를 "사이드카 컨테이너"로 인식합니다.

1. 가장 먼저 시작됨: 메인 앱 컨테이너보다 무조건 먼저 시작됩니다.
2. 계속 실행됨: 초기화 후 죽지 않고 메인 앱과 생명주기를 같이 합니다.
3. 가장 늦게 종료됨: 메인 앱이 종료되면 쿠버네티스가 알아서 사이드카를 종료시켜 줍니다. (Job 문제 해결!)

---

4. 왜 갑자기 바뀐 거죠? (버전 히스토리) 📅

이 변화는 Istio와 Kubernetes 버전 업그레이드에 따라 자연스럽게 적용된 것입니다.

• Istio 1.27 이전: Native Sidecar 기능이 있었지만 옵션이었습니다. (ENABLE_NATIVE_SIDECARS=true 설정 필요)
• Istio 1.27 이후: 이 기능이 기본값(Default)이 되었습니다.
• Kubernetes 조건: 클러스터 버전이 v1.29 이상이어야 합니다. (GKE, EKS 등 최신 버전은 대부분 충족)

지금 질문자님의 환경은 "Istio 1.27 이상 + K8s 1.29 이상" 조합이기 때문에, 별도의 설정 없이도 자동으로 이 최신 아키텍처가 적용된 것입니다. 🎉

---

5. 다시 보는 2/2의 의미 🔢

이제 kubectl get pod의 2/2가 어떻게 계산되는지 명확해집니다.

1. Main Container (details): spec.containers에 정의됨 ➡️ +1
2. Native Sidecar (istio-proxy): spec.initContainers에 있지만 restartPolicy: Always임 ➡️ +1
3. Regular Init (istio-init): 할 일 다 하고 종료됨 (Completed) ➡️ 0

그래서 Total 2가 되는 것입니다. 아주 정상적이고 건강한 상태이니 안심하셔도 됩니다!

---

6. 요약 및 마무리 📝

이 변화는 단순한 구조 변경이 아니라, 오랫동안 쿠버네티스 엔지니어들을 괴롭혔던 "사이드카 생명주기 문제(Lifecycle Issue)"를 근본적으로 해결한 아주 환영할 만한 업데이트입니다.

• YAML에서 containers에 프록시가 없다면? 👉 initContainers를 확인하세요.
• restartPolicy: Always가 보이나요? 👉 축하합니다! 최신 Native Sidecar 기능을 사용 중이십니다.
• Job(배치) 워크로드를 돌릴 때: 이제 더 이상 quitquitquit 같은 꼼수를 쓰지 않아도 프록시가 깔끔하게 종료됩니다.

최신 기술 스택을 사용하고 계신 여러분, 변화된 YAML 구조에 당황하지 마시고 이 강력한 기능을 마음껏 누리시길 바랍니다! 오늘도 즐거운 클라우드 항해 되세요! ⛵️☁️

---