Kubernetes는 1.28부터 Native Sidecar 컨테이너 개념을 정식 지원하기 시작했다.
기존에는 Sidecar가 단순히 컨테이너 하나였지만, 이제는 lifecycle, 종료 순서, 재시작 정책 등을 분리하여 컨트롤할 수 있는 구조로 발전했다.
이번 실습에서는 Istio Proxy(Envoy) 를 Native Sidecar 컨테이너로 구성할 수 있는지 실험해보았고, 아직은 실무적용이 어렵지만 기본 개념과 기대 효과를 확인해보는 데 의의가 있었다.
1. 실습 목표
- Kubernetes Native Sidecar 개념 정리
- 기존 Istio의 Proxy Sidecar 방식 이해
- Native Sidecar 형태로 Envoy Proxy를 구성하는 실험
- 향후 적용 가능성 및 한계점 확인
2. Native Sidecar란?
기존 Kubernetes에서는 Pod 내의 모든 컨테이너가 동일한 restart 정책과 lifecycle을 공유했다.
하지만 Native Sidecar는 다음과 같은 차별점을 가진다.
restartPolicy: Always와 별개로 종료 순서를 따로 지정 가능- 애플리케이션 종료 시 sidecar 자동 정리
- 본 컨테이너에 장애가 나도 sidecar만 재시작하거나, 반대의 흐름도 가능
- 컨트롤러가
sidecarContainers를 명시적으로 인식
이는 서비스 메시, 보안 프록시, 모니터링 에이전트 등에 특히 유용한 구조다.
3. 기존 Istio의 Sidecar 방식
Istio에서는 istio-injection=enabled 라벨을 통해 Sidecar(Envoy Proxy)를 자동 주입했다.
이 구조는 다음과 같다:
- initContainer로 iptables 설정
- 메인 컨테이너 외에 istio-proxy 컨테이너가 함께 주입
- restart/lifecycle은 pod 전체 단위로 동작
- graceful termination 등이 설정되지 않으면 요청 유실 발생 가능
즉, Envoy는 엄밀히 말해 Sidecar이지만, Kubernetes Native한 방식은 아님.
4. Native Sidecar로 Envoy 구성 실험
아직 Istio는 Native Sidecar를 공식 지원하지 않지만, 실험적으로 다음과 같은 구성을 시도했다.
Pod의 spec에 다음과 같은 형태로 Sidecar를 정의
containers:
- name: envoy
image: envoyproxy/envoy:v1.25-latest
args: [ "envoy", "-c", "/etc/envoy/envoy.yaml" ]
resources:
limits:
memory: "128Mi"
cpu: "250m"
lifecycle:
type: Sidecar주의할 점:
- 이 기능은 아직 표준 Kubernetes 릴리스에는 기본 활성화되어 있지 않다
- 일부 실험적 KEP 기반의 클러스터에서만 동작
5. 결과 및 한계
테스트 환경에서는 kubelet이 type: Sidecar 속성을 인식하지 못해 적용되지 않았다.
현재 Native Sidecar 기능은 일부 GKE 알파 기능 또는 K3s 커스터마이징에서만 실험 가능하다.
Istio가 이 구조를 정식 지원하려면 다음이 선행되어야 한다
- Istio sidecar-injector가 Pod 생성 시
sidecarContainers를 생성하도록 수정 - iptables 설정을 initContainer 없이 sidecar 컨테이너에서 직접 수행 가능해야 함
- shutdown hook 시 요청 정리 로직도 함께 구성 필요
