서론

해당 글은 일프로 님의 인프런 강의 쿠버네티스 어나더 클래스 (지상편) - Sprint 1, 2의 내용을 정리한 글입니다.

해당 글에 사용된 내용, 사진 및 그림은 모두 강의와 강의 자료에 포함된 내용입니다.

Helm & Kustomize

• 공통점
  • 중복 관리를 최소화하기 위함
    • 원인
      • 마이크로 서비스로 인해 애플리케이션 종류가 많아졌기 때문
      • 다양한 배포 환경이 필요하기 때문
  • 다양한 배포 툴에서 지원
• 차이점
  • 배포 편의기능 갯수
    • Helm < Kustomize
    • 다양한 기능 제공 & 직관적인 사용
  • 한 패키지 당 활용 범위
    • Helm : 마이크로 서비스 AND 다양한 배포 환경
    • Kustomize : 마이크로 서비스 OR 다양한 배포 환경
      • 활용 범위를 넓힐수록 내부 파일량이 많아지는 구조
  • 사용 목적
    • Helm : 프로젝트 관리 패키지용 + 기업 제품 패키지용
    • Kustomize : 프로젝트 관리 패키지용
  • 유즈 케이스
    • Helm : 대형 프로젝트(애플리케이션 종류가 5개 이상인 경우)
    • Kustomize : 간단한 프로젝트(애플리케이션 종류가 5개 미만인 경우)
• 결론
  • 대부분의 오픈소스는 Helm을 사용하므로 Helm 학습은 필수
  • Helm을 사용한다면 Kustomize는 사용할 필요 없음

구조

• Kustomize는 kubectl에 통합된 상태
• Helm은 Artifact HUB를 통해 필요한 패키지 다운로드 가능

사용 방식

• Helm : 함수 방식
  • 배포할 대상이 늘어날수록 명령어 변경
• Kustomize : 오버레이 방식
  • 배포할 대상이 늘어날수록 파일 증가

Helm 배포 실습

• [Sprint2] Helm과 Kustomize 비교하며 사용하기 (1/2) 글을 참고할 것을 권장

# Helm 설치
yum install -y tar
curl -O https://get.helm.sh/helm-v3.13.2-linux-arm64.tar.gz
tar -zxvf helm-v3.13.2-linux-arm64.tar.gz
mv linux-arm64/helm /usr/bin/helm

# 설치 확인
su - jenkins -s /bin/bash
helm

# 템플릿 생성
helm create api-tester

# Kustomize 버전 확인
kubectl version --short --client

• 파이프라인 생성

• GitHub project - Project url 설정

• Pipeline Script from SCM 설정

• 정상적으로 배포가 되는지 확인

• 헬름 템플릿 확인 Stage에서 실행하는 yaml 확인 가능
  • 상황에 따라 위와 같이 검증 로직 추가

Step1 - init

# 템플릿 생성
helm create api-tester
cd api-tester

Step2 - deleting

• 필요없는 디렉토리 삭제
  • 서브 애플리케이션이 없으므로 charts 삭제
  • 애플리케이션 통신 상태를 확인하지 않으므로 tests 삭제

Step3 - modify

• 애플리케이션 yaml에 맞게 Helm Package 수정

• values.yaml 변경

• Chart.yaml 변경

• service.yaml 변경

• Deployment.yaml 변경

Step4 - addition

• template/configmap.yaml 추가

• template/secret.yaml 추가

• deployment.yaml 변경

• values.yaml 변경

• 헬름 템플릿 확인

• 배포 정상동작 확인
  • helm template : helm yaml 모두 확인
  • helm upgrade : helm 배포 명령어
    • install 대신 update --install을 자주 사용함