ConfigMap 핫 업데이트를 달성하는 세 가지 일반적인 방법: 사이드카, CI 스크립트 및 사용자 지정 컨트롤러 사용

배경

ConfigMap은 Kubernetes에 구성 정보를 저장하는 데 사용되는 리소스 유형입니다. Kubernetes 클러스터에서 ConfigMap은 애플리케이션 구성 정보를 저장하는 데 널리 사용됩니다. 이러한 구성 정보에는 환경 변수, 구성 파일, 명령줄 매개변수 등이 포함될 수 있습니다. 애플리케이션 실행 중에 구성 정보를 업데이트해야 하는 경우 애플리케이션을 다시 시작해야 합니다. 그러나 프로덕션 환경에서 애플리케이션을 다시 시작하면 약간의 영향을 미칠 수 있으므로 ConfigMap의 핫 업데이트를 달성하기 위해 몇 가지 방법을 수행해야 합니다. 이 기사에서는 ConfigMap 핫 업데이트를 구현하는 세 가지 방법을 소개하고 이러한 방법의 장단점을 분석합니다.

방법 1: ConfigMap-다시 로드 사이드카 사용

ConfigMap-Reload Sidecar는 매우 인기 있는 ConfigMap 핫 업데이트 방법입니다. 이 방법의 기본 아이디어는 ConfigMap의 변경 사항을 모니터링할 수 있는 애플리케이션의 포드에서 사이드카 컨테이너를 시작하는 것입니다. ConfigMap이 변경되면 Sidecar 컨테이너는 애플리케이션의 구성 정보를 다시 로드하고 애플리케이션에 HTTP 요청을 통해 구성 정보를 다시 읽으라고 알립니다.

ConfigMap-Reload Sidecar의 장점은 구현이 간단하고 미러 형태로 빠르게 배포할 수 있다는 점입니다. 또한 Sidecar 컨테이너와 Application 컨테이너가 동일한 Pod에서 실행되기 때문에 동일한 네트워크와 스토리지 볼륨을 공유할 수 있어 데이터 전송 속도가 빠르고 동기식 업데이트 구현이 용이하다.

그러나 ConfigMap-Reload Sidecar에는 몇 가지 단점도 있습니다. 첫째, ConfigMap의 환경 변수가 변경되면 애플리케이션을 다시 시작해야 적용됩니다. 둘째, 사이드카 컨테이너와 애플리케이션 컨테이너가 동일한 포드에서 실행되기 때문에 둘 사이의 수명 주기도 일관되어 불필요한 재시작이 발생할 수 있습니다.

첫 번째 방법을 사용할 때 prometheus의 configmap-reload 이미지를 사용할 수 있습니다. 다음은 yaml 파일의 예입니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: myapp
          image: myapp
          env:
            - name: MY_APP_CONFIG
              valueFrom:
                configMapKeyRef:
                  name: myapp-config
                  key: config.yaml
        - name: config-reloader
          image: prometheus-community/configmap-reload:v0.5.0
          args:
            - --webhook-url=http://localhost:5000/-/reload
            - --volume-dir=/etc/config
            - --watched-dir=/etc/config
          volumeMounts:
            - name: config-volume
              mountPath: /etc/config
      volumes:
        - name: config-volume
          configMap:
            name: myapp-config

이 yaml 파일에서는 두 개의 컨테이너를 사용합니다. 하나는 애플리케이션이고 다른 하나는 configmap-reload의 사이드카입니다. ConfigMap의 구성 파일을 애플리케이션 컨테이너의 환경 변수에 마운트하고 ConfigMap을 config-reloader 컨테이너에 마운트합니다. config-reloader 컨테이너에서 ConfigMap의 Watched-dir 및 volume-dir을 지정하고 webhook-url을 localhost:5000/-/reload로 지정했습니다. ConfigMap이 변경되면 config-reloader는 HTTP POST 요청을 보냅니다. , 응용 프로그램 다시 읽기를 트리거합니다.

방법 2: CI 스크립트를 사용하여 ConfigMap 핫 업데이트 구현

두 번째 방법은 CI 스크립트를 사용하여 ConfigMap 핫 업데이트를 구현하는 것입니다. 이 방법의 기본 아이디어는 ConfigMap이 변경될 때 ConfigMap에 있는 파일의 MD5 값을 계산하고 이를 Deployment의 Annotation 또는 Label에 쓰는 것입니다. 이러한 방식으로 다음 배포 시 Kubernetes는 자동으로 포드를 롤링 방식으로 업데이트하여 핫 업데이트를 달성합니다.

이 접근 방식의 장점은 구현이 간단하고 CI/CD 프로세스를 통해 자동으로 배포할 수 있다는 것입니다. 또한 쿠버네티스가 포드를 자동으로 롤링하고 업데이트하기 때문에 수동 작업이 필요하지 않아 인적 오류가 줄어듭니다.

그러나 이 방법에도 몇 가지 단점이 있습니다. 우선 CI 스크립트를 작성해야 하고 구성이 복잡하며 특정 프로그래밍 기술이 필요합니다. 둘째, 이 방법은 파일 형식의 ConfigMap에만 적용할 수 있으며 ConfigMap의 구성 정보가 환경 변수 또는 명령줄 매개 변수인 경우 적용하려면 여전히 응용 프로그램을 다시 시작해야 합니다.

두 번째 접근 방식에서는 Pod의 주석 또는 레이블을 자동으로 업데이트하는 CI 스크립트를 작성해야 합니다. 다음은 예제 스크립트입니다.

#!/bin/bash
set -e

configmap_name=myapp-config
deployment_name=myapp
namespace=default

# Get current deployment image tag
current_image_tag=$(kubectl get deployment $deployment_name -n $namespace -o jsonpath='{.spec.template.spec.containers[0].image}' | cut -d: -f2)

# Get current configmap md5
configmap_md5=$(kubectl get configmap $configmap_name -n $namespace -o jsonpath='{.data.config\.yaml}' | md5sum | cut -d' ' -f1)

# Update deployment image tag and configmap md5 as annotations
kubectl patch deployment $deployment_name -n $namespace -p "{\"spec\":{\"template\":{\"metadata\":{\"annotations\":{\"configmap-md5\":\"$configmap_md5\"}}},\"spec\":{\"containers\":[{\"name\":\"myapp\",\"image\":\"myapp:$configmap_md5\"}]}}}"

이 스크립트는 현재 배포에서 사용하는 이미지 태그와 ConfigMap의 MD5 값을 가져온 다음 kubectl patch 명령을 사용하여 배포의 주석 및 컨테이너 이미지 태그를 업데이트합니다. ConfigMap이 변경되면 이 스크립트를 실행하면 배포의 이미지 태그와 ConfigMap의 MD5 값이 자동으로 업데이트될 수 있습니다.

방법 3: 컨트롤러를 사용하여 ConfigMap 핫 업데이트 구현

세 번째 방법은 Controller를 사용하여 ConfigMap 핫 업데이트를 구현하는 것입니다.

이 방법의 기본 아이디어는 ConfigMap의 변경 이벤트를 수신하여 자동 업데이트를 실현하는 Controller를 작성하는 것입니다. ConfigMap이 변경되면 Controller는 해당 Pod의 주석 또는 레이블을 업데이트하고 Pod 업데이트를 트리거합니다.

방법 2와 유사하게 컨트롤러를 사용하여 ConfigMap 핫 업데이트를 구현하는 이점은 자동화 수준이 높고 수동 작업이 필요하지 않으며 인적 오류를 줄일 수 있다는 것입니다. 동시에 방법 1과 방법 2에 비해 이 방법은 더 유연하며 환경 변수, 명령줄 매개변수, 파일 등을 포함한 다양한 유형의 ConfigMap을 지원할 수 있습니다. 또한 컨트롤러는 다양한 비즈니스 시나리오에 따라 사용자 지정하여 유연성을 향상시킬 수 있습니다.

그러나 컨트롤러를 사용하여 ConfigMap 핫 업데이트를 구현하는 데에는 몇 가지 단점도 있습니다. 우선, 방법 1 및 방법 2에 비해 이 방법의 구현 복잡성이 더 높고 컨트롤러의 코드를 작성해야 하며 특정 개발 경험이 필요합니다. 둘째, Controller는 ConfigMap 변경 이벤트를 모니터링하고 해당 Pod를 업데이트해야 하므로 클러스터의 부하가 증가하고 클러스터의 안정성에 영향을 미칠 수 있습니다.

결론적으로

위의 세 가지 방법은 ConfigMap의 핫 업데이트를 실현할 수 있으며 서로 다른 장점과 단점이 있습니다. 사용할 방법을 선택할 때 특정 비즈니스 시나리오 및 요구 사항에 따라 절충해야 합니다. 간단하고 빠른 핫 업데이트를 구현해야 하는 경우 방법 1을 사용하는 것을 고려할 수 있으며, 자동 배포 및 롤링 업데이트가 필요한 경우 방법 2를 사용하는 것을 고려할 수 있습니다.

실제 응용 프로그램에서 일부 오픈 소스 프로젝트를 사용하여 ConfigMap의 핫 업데이트를 실현할 수도 있습니다. 예를 들어 Reloader는 상대적으로 인기 있는 오픈 소스 프로젝트로 ConfigMap의 변경 이벤트를 자동으로 모니터링하고 해당 Pod의 업데이트를 트리거할 수 있습니다. ConfigmapController 및 k8s-trigger-controller는 특정 요구 사항에 따라 선택하고 사용할 수 있는 몇 가지 선택적 오픈 소스 프로젝트이기도 합니다.

요컨대 ConfigMap의 핫 업데이트를 실현하는 것은 Kubernetes에서 매우 중요한 기능입니다. 적절한 방법과 도구를 채택함으로써 애플리케이션의 가용성과 안정성을 개선하여 다양한 비즈니스 시나리오의 요구 사항을 충족할 수 있습니다.