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 Batch

📖 Reactive Programming

📖 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

📖 CI/CD

📖 Nginx

📖 Monitoring🥈

  • [Monitoring - Log Concept]
  • [Monitoring - Log Level & Filter]
  • [Monitoring - Logback]
  • [Monitoring - Log Collection with ELK Stack]
  • [Monitoring - Log Monitoring with Kibana]
  • [Monitoring - Building a Monitoring System with Spring Boot Actuator]
  • [Monitoring - Server Monitoring with Prometheus and Grafana with Discord Alerts]

📖 Test

📖 Effective Java 3/E

📖 Kotlin Academy - Effective Kotlin

📖 Kotlin Academy - 핵심편

📖 스프링으로 시작하는 리액티브 프로그래밍

📖 가상 면접 사례로 배우는 대규모 시스템 설계 기초 1

📖 가상 면접 사례로 배우는 대규모 시스템 설계 기초 2

📖 Clean Code

📖 리팩토링 2판

📖 주니어 백엔드 개발자가 반드시 알아야 할 실무 지식

📖 GraphQL

Clone this wiki locally