사이드카의 선언적 관리: OpenKruise SidecarSet 도입과 운영
데브옵스
사이드카의 선언적 관리: OpenKruise SidecarSet 도입과 운영
두줄요약
OpenKruise SidecarSet으로 DB Pod를 유지한 채 사이드카를 선언적으로 갱신하는 방식을 설명했습니다. 웹훅·컨트롤러·kubelet의 역할과 롤아웃 및 상태 모니터링 방법을 다뤘습니다.
문제 상황
- 장기 실행 DB Pod에서 사이드카만 자주 갱신해야 하지만, Kubernetes 기본 워크로드 갱신은 DB 컨테이너 재시작 유발
- Pod별 수동 이미지 수정으로 인한 사이드카 버전 불일치와 반영 상태 추적 어려움
해결 방법
- OpenKruise SidecarSet CR로 사이드카 정의, 주입 대상, 롤링 갱신 정책을 한곳에서 선언
- 컨트롤러가 실행 중 Pod의 사이드카 이미지만 in-place 갱신하고, DB 컨테이너는 유지
- 완료 판정·재시도·진행 집계가 필요한 조정 루프를 SidecarSet 컨트롤러에 위임
구조와 흐름
- Pod 생성 시 mutating 웹훅이 SidecarSet의 최신 사이드카 정의와 관리 어노테이션 주입
- 컨트롤러가 선언 해시와 Pod 기록을 비교해 갱신 대상을 선정하고 이미지 필드 수정
- kubelet이 스펙 해시가 달라진 사이드카 컨테이너만 재시작하고, 컨트롤러가 완료 상태 확인
성능/운영 포인트
- partition으로 갱신 범위를 제한하고 maxUnavailable로 동시 교체 수 제어
- matchedPods, updatedPods, readyPods, updatedReadyPods로 롤아웃 진척과 정상 상태 관찰
- 이미지 외 securityContext·볼륨·환경 변수 등 변경은 Pod 재생성 시에만 반영
