Skip to content

Kubernetes ‐ Helm & Kustomize

woojin.jang edited this page May 17, 2026 · 1 revision

Helm

  • Helm Chart : 특정 애플리케이션을 쿠버네티스에 배포하기 위해 필요한 모든 YAML 파일들을 하나의 폴더 구조로 묶어놓은 배포 템플릿이다.
  • Helm Repository : Artifactory나 Docker Hub와 같이 전 세계 사람들이 만들어둔 헬름 차트들을 공유하고 다운로드받을 수 있는 공개 저장소이다.
  • Release : 헬름 차트를 이용해 클러스터에 실제로 배포하여 구독 중인 애플리케이션 실체이다. 동일한 차트를 가지고 dev-redis, prod-redis와 같이 설정을 다르게 하여 여러 개 배포할 수 있으며, 이 각각을 릴리즈라고 한다.

Helm 1 - YAML 파일의 템플릿화

  • Helm은 YAML 파일 내부에 고정값을 적지 않고 {{ .Values.image }}을 사용한다. 그리고 환경별로 다른 환경 변수 값들은 단 하나의 values.yaml 파일에만 적어서 주입한다.
  • 코드 수정 없이 설정 파일 하나만 갈아 끼우면 되므로 CI/CD 파이프라인 연동이 극도로 단순화된다.

Helm 2 - 원클릭 설치, 업데이트, 그리고 롤백(Revision 관리)

  • 설치 : helm install kafka-example bitnami/kafka
  • 버전 확인 : helm list를 입력하면 현재 배포된 애플리케이션이 몇 번째 업데이트 상태인지 히스토리를 알 수 있다.
  • 원클릭 롤백 : helm rollback my-app 2라고 입력하면 3번째 배포에서 에러가 났을 때, 직전의 2번째 안정적인 상태로 클러스터 전체 오브젝트가 동시 원복된다.

Helm 차트 표준 디렉터리 구조

my-backend-chart/
├── Chart.yaml          # 차트의 이름, 버전, 설명 등 메타데이터를 적는 곳
├── values.yaml         # 기본값 변수 파일 (애플리케이션의 설정값들이 평문으로 정의됨)
└── templates/          # 구조의 핵심! 실제 쿠버네티스 오브젝트 템플릿 폴더
    ├── deployment.yaml # 고정값 대신 {{ .Values.replicas }} 형태로 구멍이 뚫려있음
    ├── service.yaml
    └── _helpers.tpl    # 공통 공식을 처리하는 커스텀 매크로/함수 파일
# 개발용으로 가볍게 세팅한 값들
replicaCount: 2

image:
  repository: financial-platform/api
  tag: "v2.1.0"

service:
  type: ClusterIP
  port: 80
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}-deployment # 헬름이 실행할 때 부여한 릴리즈 명이 주입됨
spec:
  replicas: {{ .Values.replicaCount }} # values.yaml의 2가 여기에 꽂힘
  selector:
    matchLabels:
      app: {{ .Release.Name }}
  template:
    metadata:
      labels:
        app: {{ .Release.Name }}
    spec:
      containers:
      - name: main-app
        image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}" # 주소와 태그가 동적 결합됨
        ports:
        - containerPort: 8080

Kustomize

  • Helm은 YAML에 템플릿 문법을 채워 넣는 방식이라 문법이 복잡해지면 YAML 파일 자체가 가독성을 잃고 거대한 프로그래밍 코드처럼 변한다는 단점이 있다.
  • Kustomize는 오리지널 템플릿 파일에 절대 손대지 않는다는 철학을 가진다. 원본 파일은 그대로 두고 그 위에 변경할 부분만 덧붙이는 오버레이(overlay) 방식을 사용한다.
    • base(원본 레이어) : dev, staging, prod 환경에서 공통으로 사용할 가장 표준적인 YAML 뼈대이다.
    • overlay(변경 레이어) : 각 환경별로 다르게 가져갈 차이점만 모아둔 설정 팩이다.

Kustomize 표준 디렉터리 구조

my-api-kustomize/
├── base/                     # [1] 공통 뼈대 폴더
│   ├── deployment.yaml       # 순수한 쿠버네티스 명세 (구멍 없음)
│   ├── service.yaml
│   └── kustomization.yaml    # 어떤 파일들을 자원으로 쓸지 묶어주는 선언서
└── overlays/                 # [2] 환경별 차이점 폴더
    ├── dev/
    │   ├── kustomization.yaml # base를 불러와서 dev용 패치를 적용하겠다는 명세
    │   └── replica-patch.yaml # "dev는 파드 1개만 띄워줘" 같은 패치 파일
    └── prod/
        ├── kustomization.yaml
        └── hpa-patch.yaml     # "prod는 HPA 오토스케일러도 같이 붙여줘"
apiVersion: apps/v1
kind: Deployment
metadata:
  name: financial-api
spec:
  replicas: 1 # 기본값은 1개로 설정
  template:
    spec:
      containers:
      - name: main-app
        image: financial-platform/api:latest
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

# 1. 원본 뼈대가 어디 있는지 경로를 지정합니다.
resources:
  - ../../base

# 2. 운영 환경에 맞게 공통으로 붙일 이름 접미사(Suffix)나 라벨을 정의합니다.
nameSuffix: -prod
commonLabels:
  env: production

# 3. 변경하고 싶은 세부 내용(패치) 파일을 연결합니다.
patches:
  - path: replicas-patch.yaml
# 원본의 어떤 오브젝트를 바꿀지 조준(Targeting)합니다.
apiVersion: apps/v1
kind: Deployment
metadata:
  name: financial-api
spec:
  replicas: 4 # 운영 환경이니까 파드를 4개로 덮어쓰기(Overwrite) 하겠다는 선언

📖 Java🔥

📖 Kotlin⭐

📖 Coroutine📎

📖 Spring🔥

📖 Spring Security⭐

📖 Spring Security OAuth2⭐

📖 Spring Batch📎

📖 Database🔥

📖 MySQL🔥

📖 Redis⭐

📖 JPA⭐

📖 QueryDsl📎

📖 MSA⭐

📖 Kafka⭐

📖 Apache Flink📎

  • [Apache Flink - Apache Flink Architecture]
  • [Apache Flink - Stream Processing]
  • [Apache Flink - Data Stream API & Window]
  • [Apache Flink - State Management]

📖 HTTP🔥

📖 AWS⭐

📖 Docker⭐

📖 Kubernetes⭐

📖 Github Actions📎

📖 Jenkins📎

📖 Nginx⭐

📖 Monitoring📎

📖 Test(feat. Load Testing)📎

📖 Test(feat. Java)⭐

📖 Spring AI📎

📖 gRPC📎

  • [gRPC - Writing .proto Files with Protocol Buffers]
  • [gRPC - Various Communication Patterns in gRPC]
  • [gRPC - gRPC Optimization Techniques and Advanced Features]

📖 Spring Cloud Microservice Application📎

📖 TDD(Test-Driven-Development)⭐

📖 PostgreSQL📎

  • [PostgreSQL - Docker만을 사용하는 경량화된 환경 구성 방법]
  • [PostgreSQL - PostgreSQL에서 제공하는 데이터 타입]
  • [PostgreSQL - PostgreSQI의 JSONB, 역인덱싱과 활용 방법]
  • [PostgreSQL - 데이터베이스 성능을 위한 최적화 패턴 및 전략]
  • [PostgreSQL - 트랜잭션과 ACID, Isolation 수준별 차이]
  • [PostgreSQL - Database Lock 교착상태와 읽기/쓰기 성능을 보장하는 MVCC 모델]
  • [PostgreSQL - pgvector와 벡터 저장, 유사도 검색 패턴 개념]
  • [PostgreSQL - 벡터 인덱스 최적화와 벡터 검색과 전문 검색 결합 패턴]
  • [PostgreSQL - PostgreSQL 플러그인]
  • [PostgreSQL - PostGIS - 공간 쿼리와 GIST 인덱스, 지리 타입과 공간 쿼리를 위한 타입과 기본 함수]
  • [PostgreSQL - pg_search - 검색 엔진 없이 텍스트 검색 구현과 주의사항]
  • [PostgreSQL - 단일 인스턴스 한계를 극복하는 분산 패턴과 스케줄링, 분산 환경 구축 방법]
  • [PostgreSQL - Citus - 분산 테이블과 분산 쿼리를 위한 Extension과 데이터 분산 처리]
  • [PostgreSQL - pg_cron - PostgreSQL로 구성하는 CronJob]
  • [PostgreSQL - 스케줄러 + 분산 처리를 동시에 도입하는 주기적 집계 쿼리 패턴]

📖 Workflow-Driven Techniques for Large-Scale Traffic Processing📎

  • [Workflow-Driven Techniques for Large-Scale Traffic Processing - Kafka + Debezium을 활용한 CDC 패턴 설계]
  • [Workflow-Driven Techniques for Large-Scale Traffic Processing - Temporal을 활용한 워크플로우 패턴]
  • [Workflow-Driven Techniques for Large-Scale Traffic Processing - Docker와 경량 이미지를 활용한 환경 구축 방법]
  • [Workflow-Driven Techniques for Large-Scale Traffic Processing - Kafka에서의 메시지 Delivery Guarantee]
  • [Workflow-Driven Techniques for Large-Scale Traffic Processing - 실시간 동기화의 핵심 CDC]
  • [Workflow-Driven Techniques for Large-Scale Traffic Processing - MySQL Binary Log 기반의 CDC]
  • [Workflow-Driven Techniques for Large-Scale Traffic Processing - Binary Log 기반의 CDC 구현 플랫폼 Debezium이란?]
  • [Workflow-Driven Techniques for Large-Scale Traffic Processing - Debezium Architecture]
  • [Workflow-Driven Techniques for Large-Scale Traffic Processing - Debezium Architecture Best Practice와 주의사항]

📖 Reactive Programming📎

📖 ElasticSearch📎

📖 Design Pattern📎

📖 Clean Spring📎

  • [Real MySQL 8.0 - 인덱스]
  • [Real MySQL 8.0 - 실행 계획]
  • [Real MySQL 8.0 - 아키텍처]
  • [Real MySQL 8.0 - 트랜잭션과 잠금]
  • [도메인 주도 설계의 사실과 오해 - DDD 요약]
  • [도메인 주도 설계의 사실과 오해 - Preface, Entity & VO]
  • [도메인 주도 설계의 사실과 오해 - 연관 관계와 애그리거트]
  • [도메인 주도 설계의 사실과 오해 - 애그리거트 구현]
  • [도메인 주도 설계의 사실과 오해 - 레포지토리와 기타 패턴]
  • [도메인 주도 설계의 사실과 오해 - 통찰력을 향한 리팩터링]
  • [도메인 주도 설계의 사실과 오해 - 유연한 설계를 향한 리팩터링]
  • [도메인 주도 설계의 사실과 오해 - 모델의 경계를 긋고, 핵심에 집중하라]

Clone this wiki locally