Kubernetes에 도입된 네이티브 사이드카 컨테이너 Feature를 알아보자

CTF 문제풀이를 위한 'Hack Playgrond' 서비스의 핵심 기술을 설계하던 중, 사용자가 문제 컨테이너에 접속해서 Flag를 찾을 수 있도록 동적으로 Kubernetes 상에서 Pod 리소스를 관리하고 있었다.

 

리소스 최적화를 통해 운영비용을 획기적으로 절감하는게 1차적인 목표였기에 이를 위해서 사용자가 이용을 끝낸 컨테이너를 삭제하는 Pod Garbage Collection을 직접 구현하고 있었다.

 

어떻게 사용자가 이용을 끝냈는지 판단할 수 있는지 고민하던 중, 마침 2024년 쿠버에 네이티브 수준의 사이드카 컨테이너를 프로젝트에 추가했다는 사실을 알게 되어서 프로젝트에 적용 가능한지 확인차 공부해본 내용을 소개하고자 한다.

 

참고로 결국 기술 구현 자체는 Java 라이브러리에서 아직 Native 수준의 Sidecar 기능을 지원하지 않아서 사이드카를 직접 GoLang으로 구현해서 동적으로 관리하도록 처리했다.. 그래도 공부한게 아까우니 작성했다.

 

 

Pod에 컨테이너 여러 개를 넣을 수 있는 이유가 뭘까?

2015년부터 쿠버에서 사용하는 사이드카 패턴

 

Sidecar Containers

 

 

 

Pod는 기본적으로 컨테이너가 여러 개 들어갈 이유가 없다. 근데도 허용하는 이유는,, 하나의 애플리케이션을 Serving하기 위해서 도와줄 확장성 있는 사이드카 컨테이너를 위해서이다.

 

네이티브 수준의 Secondary Containers는 다음과 같이 다양한 케이스에서 활용된다.

• 로그 포워딩
• ServiceMesh의 프록시
• 메트릭 exporter
• Configuration Reloader - config 바뀌면 알아서 갱신
• Job with sidecars
• AI workloads

 

Kubernetes Native Sidecar Container

zesty.co

 

사이드카 패턴에 특화된 쿠버네티스의 지원이 필요 (Jan 30. 2019)

SIG Node / Sidecar Working Group, 2023년

 

문제 상황

시작과 종료 순서가 보장되지 않는다. 사이드카도 쿠버네티스한테는 컨테이너로 취급된다.

• 애플리케이션 컨테이너보다 log forwading, metrics exporter가 먼저 시작되는 경우 문제가 된다.
• Pod의 삭제 요청시에도 사이드카가 뭔지 모르니 모든 컨테이너에게 종료 SIGNAL을 보낸다.

 

해결 방법

Solution 1: 사이드카는 메인 컨테이너보다 먼저 시작한다.

• 어떻게 쿠버는 메인인지 사이드카인지 구분하는가? → Container Health check (start, probe)

Solution 2: 사이드카는 메인 컨테이너보다 나중에 종료된다.

시작과 끝이 존재하는 작업에 사용되는 Job 리소스에서는 사이드카 갖기가 어렵다.

모든 컨테이너가 종료되어야 Job이 완료된걸로 간주한다.

 

Solution 3: 사이드카는 Pod의 종료를 막지 않는다.

Job의 성공 여부는 더이상 모든 컨테이너 종료가 아니라, 모든 “메인 컨테이너”가 종료되는 걸로 설정하고 이후 사이드카를 종료시킨다.

 

 

Init Container의 restartPolicy 도입

• 사이드카의 startUp, liveness, readiness probe 지원
• preStop, postStart hook 지원
• restartPolicy: Never 또는 lifecycle.type: Sidecar로 명시적 구분

 

k3s server --kube-apiserver-arg=feature-gates=SidecarContainers=true

apiVersion: v1
kind: Pod
metadata:
  name: my-app-with-sidecar
spec:
  containers:
    - name: my-main
      image: myapp:latest
      lifecycle:
        type: "Standard"
    - name: my-sidecar
      image: myproxy:latest
      lifecycle:
        type: "Sidecar"    # 사이드카 컨테이너임을 명시

 

 

Pod 종료 시나리오

사이드카 컨테이너는 시작의 반대 순서로 종료된다.

• Pod의 Termination grace period를 공유
• Pod 종료 시점에 전체 컨테이너 preStop Hook 실행
• 순서가 되면 애플리케이션에게 SIGTERM 전달

 

어떻게 Sidecar를 도입해야 하는가?

kubernets v1.29에서 베타 이후로는 기본 활성화

• Istio, gcs-fuse-csi-driver, linkerd

배포 스펙 변경

containers → initContainers로 이동 및 restartPolicy 설정

사이드카와 컨테이너를 위한 처리가 있으면 제거

• e.g. Log forwarding 컨테이너가 SIGTERM 받고 일정 시간 이후로 종료
• e.g. Config reloader의 init 모드와 running 모드 분리

최신 쿠버네티스 업데이트

• SidecarContainers feature gate 설정
• 관련 Admission Webhook 업데이트 (새로운 필드 누락 가능성)

 

Sidecar의 미래에 대한 논의

Pod terminationGracePeriodSeconds가 매우 길다면? 30분?

• main container가 죽는 도중에 sidecar container가 스스로 종료되었다면?
• Pod가 종료중일때도 사이드카 컨테이너는 재시작해야한다.

 

출처 및 인용.

https://kubernetes.io/docs/concepts/workloads/pods/sidecar-containers/

https://kubernetes.io/blog/2023/08/25/native-sidecar-containers/

https://zesty.co/finops-glossary/sidecar-container-kubernetes/