#DevOps

사이드카의 선언적 관리: OpenKruise SidecarSet 도입과 운영

Summary

메인 컨테이너 재시작 없이 사이드카만 쏙! OpenKruise SidecarSet으로 완성하는 선언적 쿠버네티스 운영

DB Pod는 유지한 채 로그·메트릭 수집 사이드카만 안전하게 갱신하는 In-Place 배포 전략과 실무 인사이트

Kubernetes에서 오랜 기간 동작하는 DB 컨테이너 옆에 위치한 사이드카들의 자주 바뀌는 버전과 형상을 어떻게 관리할 수 있을까요? 이 아티클은 스크립트 기반 패치나 오퍼레이터 직접 개발 대신 OpenKruise SidecarSet을 도입해 해결한 실무 경험을 담고 있습니다. In-Place Update가 가능하게 하는 Kubelet의 내부 동작 원리부터, 안정성을 확보하는 partition/maxUnavailable 배포 제어, imageID 기반 완료 판정 메커니즘까지 명쾌하게 설명합니다.

01메인 컨테이너(DB) 재시작을 방지하는 컨테이너 단위 In-Place Update의 동작 메커니즘 분석
02OpenKruise SidecarSet 커스텀 리소스를 활용한 사이드카 형상 선언, 배포 제어 및 상태 모니터링 일원화
03partition(범위 제어)과 maxUnavailable(속도 제어)을 활용한 단계적 롤아웃 구현 전략
04Kubelet과 Controller 간의 역할 경계 및 imageID 기반 다이제스트 비교를 통한 갱신 완료 판정 로직
05사이드카 선언 변경 시 즉시 반영되는 스펙(이미지)과 Pod 재생성이 필요한 스펙 간의 구별점 제시

RECOMMENDATION

Kubernetes 환경에서 로깅, 메트릭, 헬스체크 등 수많은 사이드카를 운영 중이거나, 메인 애플리케이션의 재시작 없이 사이드카만 자주 변경해야 하는 DevOps 엔지니어 및 플랫폼 개발자에게 강력히 추천합니다.

The Problem

Kubernetes 환경의 장기 실행 Pod에서 메인 컨테이너와 사이드카 컨테이너의 라이프사이클 차이로 인해 사이드카 패치 시 메인 컨테이너가 함께 재시작되는 문제가 발생합니다. 또한 표준 Kubernetes 워크로드만으로는 여러 Pod의 사이드카 형상 관리, 수동 인플레이스 수정의 번거로움, 진척도 및 형상 추적 모니터링의 한계가 존재합니다.

The Solution

CNCF 인큐베이팅 프로젝트인 OpenKruise의 SidecarSet CRD를 도입하여 사이드카 정의, 주입 조건, 배포 전략을 한곳에서 선언적으로 관리하였습니다. SidecarSet Controller와 Mutating Webhook을 활용해 메인 컨테이너 영향 없이 사이드카 이미지만 In-Place 방식으로 갱신하고, partition과 maxUnavailable 파라미터로 롤아웃 범위와 속도를 제어하였습니다.

The Result

DB 컨테이너 재시작 없이 실행 중인 Pod의 사이드카 이미지를 안전하게 개별 교체할 수 있게 되어 사이드카 파편화 문제를 해소했습니다. 또한 SidecarSet status의 4가지 필드(matchedPods, updatedPods, readyPods, updatedReadyPods)를 통해 롤아웃 진척 상황과 정상 동작 상태를 한눈에 모니터링할 수 있게 되었습니다.

Trade-off

OpenKruise 컨트롤러와 웹훅 컴포넌트 추가에 따른 외부 컴포넌트 운영 부담 및 클러스터 장애 지점이 증가합니다. 또한 In-Place 갱신은 컨테이너 이미지 변경에만 즉시 적용되며, securityContext, 환경 변수 등 타 스펙은 Pod 재생성 시점에만 적용된다는 구조적 한계가 존재합니다.