Pinpoint Agent Helm Chart 작성하기

작년 8월부터 진행했던 Pinpoint Helm Chart 중 Agent에 대한 Helm Chart 제작 과정에 대해서 다루어보고자 합니다. 

---

Introduction

Pinpoint Agent는 Java, Go, NodeJS, C 등 다양한 언어에 대한 agent가 존재하고 각기 다른 사용방법을 가지고 있습니다. 그 중 가장 많이 사용되는 Java Agent에 대해 Helm Chart 작성을 시작하였습니다. Java Agent는 실행을 위한 jar 파일과 적용할 config를 필요로 합니다. jar 파일과 config option을 target application을 실행할 때 부착함으로써 data를 수집, collector로 전송하게 됩니다. 즉, application과 동일한 컨테이너에 agent를 위한 파일이 존재하여야 합니다.

초기 계획했던 방법은 init-container를 사용하여 Pod 시작 전 필요한 파일을 다운받는 방법이었습니다. 하지만 init-container로 설정하게 된다면 모든 Pod들에 대해 동일한 파일(release)를 다운받는 과정이 중복되게 됩니다. 또한 노드의 지역에 따라 네트워크 이슈로 인해 파일을 다운 받는 과정에서 상당한 시간이 소요될 수 있습니다. Pod이 시작될 때 많은 시간이 소요된다는 것은 배포 및 롤백 과정에서 발생하는 시간이 증가하는 것과 동일하기 때문에 서비스 운영 측면에서 지양해야 하는 부분입니다.

이에 따라 결정한 방법은 초기 원하는 버전에 대한 Volume을 생성하고, 해당 볼륨을 Target Application이 존재하는 Pod에서 마운트하여 사용하는 방식입니다. 이를 진행하면서 겪었던 문제 상황, 고민에 대해 공유해보고자 합니다.

---

요구사항

Agent Helm Chart가 수행해야 할 역할을 정리하면 다음과 같습니다.

• 원하는 버전의 Agent Release를 다운받아 볼륨에 저장
• 사용자가 원하는 Custom Config를 ConfigMap으로 생성

---

PVC 생성 및 Read-Only 설정

가장 먼저 해야하는 작업은 공유할 볼륨을 생성하는 작업입니다.

볼륨을 생성하는 방법은 PV를 정의하고 이를 정적 프로비져닝하는 방법도 존재하지만 최대한 일반적인 상황에 적용해야 하는 오픈소스의 특성과 맞지 않다고 생각했고, PVC와 StorageClass를 통해 동적 프로비져닝을 지원할 수 있도록 설정하였습니다. 기본값은 클러스터에 설정된 default StorageClass를 사용하고, 만약 개인적으로 정의된 StorageClass를 사용해야 한다면 해당 값을 삽입할 수 있도록 설정하였습니다. 

PVC를 생성하며 또 하나 고려해야 할 점은 동일한 볼륨을 여러 Pod에서 사용할 수 있기 때문에 예상치 못한 파일 변경이 발생할 수도 있다는 점입니다. 이를 방지하기 위해 PVC의 accessMode를 ReadOnlyMany로 설정을 통해 다수의 Pod이 볼륨을 마운트하여 읽을 수 있지만, 볼륨에 쓰는 작업은 불가능하도록 설정하였습니다. 하지만, 이를 테스트 하며 예상치 못한 문제를 겪었는데 이는 ROX(ReadOnlyMany)로 PVC를 설정하여 마운트했는데도 불구하고 Pod에서 마운트 경로에 파일을 쓸 수 있는 현상이였습니다. 원인을 찾기 위해 kubectl describe pod을 통해 확인해보니 마운트 된 볼륨이 rw 권한을 가지고 있었습니다.

Pod Describe 내용

또한 GKE에서 StorageClass를 설정하지 않았을 때 선택되는 pd-standard로 동적 프로비져닝 된 PV를 살펴보니 여기서도 readOnly: false로 설정되어 있었습니다.

PV Describe 내용

하지만 PVC는 분명 ROX로 설정되어 있는 것을 확인할 수 있었습니다.

PVC Describe 내용

이에 대해 찾아본 결과, 동일한 이슈가 이미 존재하였습니다. GooglePersistentDisk를 사용하는 경우 PVC에 ROX로 설정해주더라도 워크로드에서 readOnly: true를 설정해줘야 readOnly가 적용된다고 하여 이를 적용해서 해결하였습니다.
이에 대한 원인은 이슈에서도 명확히 제시되지 않아서 추후 더 찾아볼 예정입니다.

 

---

Init Job 생성

다음으로 진행해야 할 작업은 Job을 통해 원하는 버전의 pinpoint-agent 파일을 다운받아 볼륨에 공유하는 작업입니다. Job의 Pod은 파일을 저장해야 하기 때문에 readOnly: true를 생략하였습니다.

Job에서 수행하는 작업은 values.yaml에 설정된 agent-version에 맞는 release를 다운받아 볼륨의 /agent/config에 저장하게 됩니다.

---

Helm Lifecycle Hook 설정

Job을 사용함으로써 고려해야 할 점은 해당 Job을 어떻게 트리거 시킬 것인지 입니다. Job을 실행하는 스크립트를 짤 수도 있지만 이는 완전한 자동화가 아니라고 생각했고 관련 내용을 찾던 중 Helm Lifecycle Hook에 대한 내용을 접했습니다. 

Helm Lifecycle Hook 중 "helm.sh/hook"은 언제 해당 작업을 실행할지 결정하는 역할을 합니다. PVC를 생성하고 Job을 실행해야 하는 시점은 Helm Chart를 설치할 떄, 그리고 버전 업그레이드를 진행할 때이기 때문에 "helm.sh/hook": pre-install,pre-upgrade 어노테이션을 추가하여 해당 작업이 설치 및 업그레이드 시 자동으로 이루어질 수 있도록 설정하였습니다.

다음으로 고려할 점은 PVC와 Job 생성의 순서에 대한 부분입니다. PVC가 먼저 수행된 이후에 Job이 수행되어야 하므로 hook의 가중치를 설정하는 "helm.sh/hook-weight" 어노테이션을 사용해 순서를 제어하였습니다. PVC의 가중치는 1로 Job의 가중치는 2로 설정하여 PVC가 생성된 이후 Job이 생성되도록 설정하였습니다.

---

Helm Lookup

다음으로 고려할 점은 Agent의 버전이 변경되지 않았지만 다른 설정들이 변경되는 상황입니다(예를 들면 external configuation이 추가된 경우). agent의 버전이 변하지 않는 경우에는 PVC가 이미 존재하기 때문에 PVC 생성 및 Job 생성 작업이 실패하게 됩니다. 따라서 원하는 Agent Version에 해당하는 PVC가 존재하는 경우에는 위의 작업을 수행하지 말아야 합니다. Helm 문서를 찾아본 결과 kubectl get <resource-type> <name>과 동일한 역할을 하는 lookup 함수라는 것이 있다는 것을 발견했고 이를 통해서 agent version이 변하지 않는 경우에는 PVC 및 Job 생성을 하지 않도록 설정하였습니다.

최종적으로 설정한 PVC와 Job은 다음과 같습니다.

PVC

{{- $agentpvc := (lookup "v1" "PersistentVolumeClaim" .Release.Namespace (printf "agent-%s-pvc" .Values.agent.version )) }}
{{- if not $agentpvc }}
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: agent-{{ .Values.agent.version }}-pvc
  annotations:
    "helm.sh/hook": pre-install,pre-upgrade
    "helm.sh/hook-weight": "1"
  labels:
{{ include "pinpoint-agent.labels" . | indent 4}}
spec:
    {{- if .Values.agent.storageClass }}
    storageClassName: {{ .Values.agent.storageClass}}
    {{- end}}
    accessModes:
        - ReadOnlyMany
    resources:
        requests:
            storage: 1Gi
{{- end -}}

 

Job

{{- $agentJob := (lookup "batch/v1" "Job" .Release.Namespace (printf "agent-%s-downloader" .Values.agent.version )) }}
{{- if not $agentJob }}
apiVersion: batch/v1
kind: Job
metadata:
  name: agent-{{.Values.agent.version}}-downloader
  annotations:
    "helm.sh/hook": pre-install,pre-upgrade
    "helm.sh/hook-delete-policy": before-hook-creation
    "helm.sh/hook-weight": "2"
  labels:
{{ include "pinpoint-agent.labels" . | indent 4}}
spec:
  template:
    spec:
      containers:
        - name: downloader
          image: alpine
          command:
            - sh
            - -c
            - |
              wget https://github.com/pinpoint-apm/pinpoint/releases/download/v{{ .Values.agent.version }}/pinpoint-agent-{{ .Values.agent.version }}.tar.gz
              tar xvzf pinpoint-agent-{{ .Values.agent.version }}.tar.gz
              mv pinpoint-agent-{{ .Values.agent.version }} ./agent-init/pinpoint-agent

          volumeMounts:
          - name: agent-init
            mountPath: /agent-init
      volumes:
      - name : agent-init
        persistentVolumeClaim:
          claimName: agent-{{ .Values.agent.version }}-pvc
      restartPolicy: Never
  backoffLimit: 3
{{- end -}}

---

위의 작업을 통해 공통적으로 사용되는 Pinpont Agent Release 파일은 준비가 되었습니다. 다음으로 해야할 작업은 각 어플리케이션에 맞는 Custom 설정을 주입하는 방법입니다. 

---

ConfigMap 생성

개인적으로 Config 파일을 ConfigMap에 설정하는 방법은 가독성이 떨어진다고 생각하여(개인적인 의견입니다.) 외부에 설정파일을 위치시키는 것을 선호합니다. 따라서 files/conf 이라는 디렉토리를 생성하고 해당 디렉토리 하위에 있는 파일을 ConfigMap으로 사용할 수 있도록 하였습니다. 

이 때 모든 설정파일을 하나의 ConfigMap에 설정할 수는 있지만 결국 하나의 어플리케이션에서 필요한 설정 파일을 하나이고 나머지 파일들은 불필요하다고 생각하여 values.yaml에서 externalConfigName을 통해 application에 추가하기 원하는 설정 파일의 이름을 주입하면 해당하는 configmap만 생성하도록 설정하였습니다. 

파일을 ConfigMap으로 저장하는 부분은 Files.Get을 사용하였습니다.

ConfigMap

{{ if .Values.agent.externalConfigName }}
apiVersion: v1
kind: ConfigMap
metadata:
  name: external-config-{{ .Values.agent.externalConfigName }}
  labels:
{{ include "pinpoint-agent.labels" . | indent 4}}
data:
  {{ .Values.agent.externalConfigName}}.config: |
{{ .Files.Get (printf "files/conf/%s.config" .Values.agent.externalConfigName ) | indent 4 }}
{{- end -}}

---

최종적으로 agent 사용하고자 하는 어플리케이션은 다음과 같은 설정이 필요합니다.

• EXTERNAL_CONFIG_PATH : 커스텀 설정의 위치를 실행 시 옵션으로 넣어주기 위한 환경변수입니다.
• ConfigMap VolumeMount : 원하는 커스텀 설정을 마운트하기 위한 옵션입니다.
• PVC VolumeMount : 원하는 버전의 release 파일을 마운트하기 위한 옵션입니다.

예시 어플리케이션은 다음과 같습니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-deploy-1
  labels:
    app: test-deploy-1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: test-deploy
  template:
    metadata:
      labels:
        app: test-deploy
    spec:
      containers:
      - name: test
        image: alpine
        command:
        - sh
        - -c
        - |
          tail -f /dev/null
        env:
          - name: EXTERNAL_CONFIG_PATH
            value: "/pinpoint/config/{{ .Values.agent.externalConfigName}}"
        volumeMounts:
        - name: agent-init
          mountPath: /agent-init
        - name: agent-external-config
          mountPath: /pinpoint/config
      volumes:
      - name: agent-init
        persistentVolumeClaim:
            claimName: agent-{{ .Values.agent.version }}-pvc
            readOnly: true
      - name: agent-external-config
        configMap:
          name: external-config-{{ .Values.agent.externalConfigName }}

---

부족한 부분이 물론 많지만 그럼에도 불구하고 글을 작성하는 이유는 해당 작업을 진행하면서 평소 놓치고 있었던 accessMode나 Helm의 부가 가능에 대해서 알 수 있던 시간이였고 이를 공유하기 위해서입니다. Agent를 위한 Helm Chart 작성 작업은 여전히 진행 중이고 더 좋은 의견이 있으신 분들은 공유해주시면 감사하겠습니다!

모든 코드는 Github에서 확인하실 수 있습니다.

---

2021.03.23 수정
- jar 파일에 대해 여러 Pod이 사용하는 것이 불가능하기 떄문에, PV를 사용하는 방법은 불가능합니다.