Kafka Connect와 커스텀 SMT의 GitOps 통합 관리 (3): InitContainer를 활용한 동적, 불변적 배포

이전 문서에서 다룬 PVC 기반 전략은 대용량 플러그인 관리에 유용하지만, 외부 스토리지에 대한 의존성과 상태 관리의 복잡성을 동반합니다. 불변성(Immutability)과 상태 비저장(Stateless) 원칙을 지향하는 현대적인 클라우드 네이티브 환경에서는 InitContainer 패턴이 더욱 적합하고 세련된 해법이 될 수 있습니다.

이 전략은 Kafka Connect Pod가 생성될 때마다 필요한 아티팩트를 동적으로 가져오는 방식으로, 외부 스토리지 의존성을 최소화하고 배포의 예측 가능성과 재현성을 극대화합니다.

InitContainer 기반 아키텍처

InitContainer 패턴의 핵심은 주 애플리케이션 컨테이너가 시작되기 전에, 사전 준비 작업을 수행하는 하나 이상의 초기화 컨테이너를 실행하는 것입니다. 이를 Kafka Connect 플러그인 관리에 적용한 아키텍처는 다음과 같습니다.

+-------------------------------------------------------------+
| Kafka Connect Pod                                           |
|                                                             |
|  +-----------------------+      +-------------------------+ |
|  |     InitContainer     |----->| Main Container (Kafka)  | |
|  | (plugin-downloader)   |      |                         | |
|  | - Downloads JAR from  |      | - Reads JAR from volume | |
|  |   Artifact Repository |      | - plugin.path set to    | |
|  | - Saves to emptyDir   |      |   /plugins              | |
|  +-----------------------+      +-------------------------+ |
|             |                            ^                  |
|             | (writes to)                | (reads from)     |
|             v                            |                  |
|  +-------------------------------------------------------+  |
|  |                 Shared Volume (emptyDir)              |  |
|  | - /plugins/my-custom-smt-v1.2.0.jar                   |  |
|  +-------------------------------------------------------+  |
|                                                             |
+-------------------------------------------------------------+

1. 아티팩트 저장소 (Artifact Repository): CI 파이프라인은 빌드된 커스텀 SMT JAR 파일을 Nexus, Artifactory와 같은 아티팩트 저장소나 AWS S3, Google Cloud Storage와 같은 오브젝트 스토리지에 업로드합니다. 모든 아티팩트는 고유한 버전(예: v1.2.0)으로 관리되어야 합니다.
2. emptyDir 볼륨: Kafka Connect Pod 내에 emptyDir 타입의 임시 볼륨을 정의합니다. 이 볼륨은 Pod의 생명주기와 동일하며, Pod가 시작될 때 생성되고 삭제될 때 함께 사라집니다. 여러 컨테이너가 이 볼륨을 공유할 수 있습니다.
3. InitContainer (plugin-downloader): Kafka Connect Pod에 작은 유틸리티 이미지(예: curlimages/curl, alpine/wget, amazon/aws-cli)를 사용하는 InitContainer를 추가합니다. 이 컨테이너의 유일한 역할은 Pod가 시작될 때 아티팩트 저장소에서 특정 버전의 JAR 파일을 다운로드하여 공유 emptyDir 볼륨에 저장하는 것입니다.
4. 메인 Kafka Connect 컨테이너: InitContainer가 성공적으로 완료된 후, 메인 Kafka Connect 컨테이너가 시작됩니다. 이 컨테이너는 동일한 emptyDir 볼륨을 마운트하고, 이 경로를 plugin.path로 설정하여 필요한 플러그인을 로드합니다.

이 구조에서는 Pod의 명세(YAML) 자체가 필요한 플러그인의 버전 정보를 포함하게 되므로, 완벽한 불변성(Immutability)과 배포의 추적성을 달성할 수 있습니다.

GitOps 통합 워크플로우

InitContainer 기반 전략의 GitOps 워크플로우는 매우 명확하고 자동화에 최적화되어 있습니다.

1. SMT 코드 변경 및 CI 실행: 개발자가 SMT 코드를 수정하고 Git에 푸시하면, CI 파이프라인이 트리거됩니다. 파이프라인은 코드를 컴파일하고 테스트한 후, 버전이 명시된 JAR 파일(예: my-smt-v1.2.0.jar)을 생성합니다.
2. 아티팩트 게시: CI 파이프라인은 생성된 JAR 파일을 아티팩트 저장소(예: S3 버킷)에 게시합니다.
3. 매니페스트 업데이트 (핵심 자동화 단계): CI 파이프라인의 가장 중요한 역할은 Kafka Connect의 Kubernetes Deployment 매니페스트 또는 Helm values.yaml 파일을 자동으로 업데이트하는 것입니다. 보통 InitContainer가 참조할 JAR 파일의 URL이나 버전을 환경 변수 또는 어노테이션(annotation) 값으로 수정하고, 이 변경 사항을 Git 저장소에 다시 커밋(commit)합니다.
4. GitOps 동기화: 수정된 매니페스트가 GitOps 관리 저장소(예: main 브랜치)에 푸시되면, Argo CD나 Flux와 같은 GitOps 컨트롤러가 변경을 즉시 감지하고 클러스터의 상태를 Git에 정의된 최신 상태와 동기화합니다.
5. 롤링 업데이트 및 플러그인 다운로드: GitOps 컨트롤러에 의해 새로운 매니페스트가 클러스터에 적용되면, Kubernetes는 롤링 업데이트를 시작합니다. 새로 생성되는 각 Pod는 InitContainer를 먼저 실행하여 지정된 URL에서 새로운 버전의 JAR 파일을 다운로드합니다.
6. Kafka Connect 실행: 다운로드가 완료되면 메인 Kafka Connect 컨테이너가 시작되어 emptyDir에 저장된 최신 플러그인을 로드합니다.

Helm을 통한 InitContainer 설정 예시

values.yaml 파일을 통해 InitContainer를 동적으로 설정하는 예시는 다음과 같습니다.

# values.yaml

# SMT 플러그인 정보. CI 파이프라인이 이 값을 업데이트합니다.
customSmt:
  enabled: true
  version: "1.2.0"
  downloadUrl: "https://my-s3-bucket.s3.amazonaws.com/artifacts/my-custom-smt-1.2.0.jar"

# ...

# plugin.path에 emptyDir 마운트 경로 추가
pluginPaths: "/opt/kafka/plugins,/opt/kafka/custom-plugins"

# InitContainer 설정
initContainers:
  - name: plugin-downloader
    image: curlimages/curl:latest
    # 다운로드 URL을 환경 변수로 주입
    env:
    - name: PLUGIN_DOWNLOAD_URL
      value: {{ .Values.customSmt.downloadUrl }}
    command: ["/bin/sh", "-c"]
    args:
      - "curl -sSLo /opt/kafka/custom-plugins/my-custom-smt.jar $(PLUGIN_DOWNLOAD_URL)"
    volumeMounts:
      - name: custom-plugins-volume
        mountPath: /opt/kafka/custom-plugins

# 메인 컨테이너에 볼륨 마운트
extraVolumeMounts:
  - name: custom-plugins-volume
    mountPath: /opt/kafka/custom-plugins

# 공유 볼륨 정의
extraVolumes:
  - name: custom-plugins-volume
    emptyDir: {}

CI 파이프라인은 SMT 빌드 후 yq나 sed와 같은 도구를 사용하여 values.yaml의 customSmt.version과 customSmt.downloadUrl 값을 업데이트하고 Git에 커밋합니다.

전략 비교 및 최종 선택 가이드

InitContainer 방식은 불변 인프라를 추구하는 현대적인 클라우드 네이티브 환경에 가장 이상적인 선택입니다. 버전 추적과 롤백이 명확하며, GitOps 철학에 완벽하게 부합합니다. Pod 시작 시 약간의 지연이 발생할 수 있지만, 이는 예측 가능하고 일관된 배포가 주는 안정성에 비하면 사소한 트레이드오프입니다.

궁극적으로, 팀의 인프라 환경, 운영 철학, 그리고 자동화 기술 성숙도를 고려하여 가장 적합한 전략을 선택하는 것이 중요합니다. InitContainer 전략은 DevOps와 GitOps 문화를 성숙하게 도입하려는 조직에게 가장 권장되는 접근법입니다.

---

쿠버네티스 패키지관리

     📕교보문고 종이책 구매
     📱교보문고 이북 구매
🛒부크크 종이책 구매

실수로 배우는 자바

📕교보문고 종이책 구매
📱교보문고 이북 구매
🛒 부크크 종이책 구매

AI와 함께하는 협업 바이블

📱교보문고 이북 구매
     🛒부크크 종이책 구매
책은 yes24, 알라딘에도 판매 되고 있습니다.