Helm은 여러 Kubernetes 매니페스트를 차트 하나로 묶고, 환경마다 다른 값만 바꿔 끼워 배포하게 해 주는 패키지 매니저입니다. 이 글에서는 차트의 구조와 템플릿 문법, 값이 적용되는 우선순위, 배포 이력을 남기는 릴리스와 롤백을 정리하고, 직접 만든 차트로 설치부터 롤백까지 확인합니다. Helm 4에서 바뀐 플래그와 Kustomize, ArgoCD와 함께 쓸 때 주의할 점도 함께 다룹니다.
컨테이너부터 Kubernetes까지 시리즈의 3부 실무 글입니다. 차트 안에 들어가는 Deployment와 ConfigMap은 [Kubernetes] Pod, ReplicaSet, Deployment 정리와 [Kubernetes] ConfigMap과 Secret 정리에서 다뤘고, 전체 순서는 시리즈 목차에 있습니다. 명령과 출력은 Helm 4.2, 로컬 Kubernetes 클러스터 기준입니다.
1. Helm이 해결하는 문제
앱 하나를 Kubernetes에 올리려면 Deployment, Service, ConfigMap, Ingress처럼 YAML이 여러 개 필요합니다. 여기에 dev와 prd 환경까지 생기면 이미지 태그, 레플리카 수, 리소스 설정만 다른 YAML이 환경 수만큼 늘어나고, 한쪽만 고치는 실수가 생기기 쉽습니다. 배포한 뒤에는 "지금 클러스터에 올라간 것이 어떤 설정이었는지", "직전 상태로 되돌리려면 무엇을 다시 apply해야 하는지"도 사람이 기억해야 합니다.
Helm은 이 문제를 세 가지로 풉니다. YAML을 템플릿으로 만들어 바뀌는 부분만 값으로 빼고, 관련 리소스를 차트 하나로 묶어 한 번에 설치하고 지우며, 배포할 때마다 어떤 차트와 값을 썼는지 리비전으로 남깁니다. apt나 brew가 리눅스 패키지를 설치하고 관리하듯, Helm은 Kubernetes 앱 묶음을 설치하고 관리합니다.
| 용어 | 뜻 |
| Chart | 템플릿과 기본값을 묶은 패키지. 폴더 또는 .tgz 파일 |
| Values | 템플릿의 빈칸에 들어갈 값. 차트의 기본값을 배포할 때 덮어씀 |
| Release | 차트를 클러스터에 설치한 결과물 하나. 같은 차트로 이름만 달리해 여러 개 설치 가능 |
| Revision | 릴리스를 설치하거나 바꿀 때마다 1씩 늘어나는 배포 이력 번호 |
| Repository | 차트를 올려 두고 받는 저장소. HTTP 저장소 또는 OCI 레지스트리 |
차트의 템플릿과 값이 합쳐져 매니페스트가 되고, 배포할 때마다 릴리스 리비전으로 기록됩니다
2. 차트 구조
차트는 정해진 구조를 가진 폴더입니다. helm create 이름으로 기본 구조를 만들 수 있는데, Ingress, HPA, ServiceAccount까지 들어 있어 처음 보기에는 복잡합니다. 이 글에서는 꼭 필요한 파일만 남긴 예제 차트 demo-web을 씁니다. nginx가 values에 적은 문구 한 줄을 보여 주는 차트입니다.
demo-web/
├── Chart.yaml # 차트 이름과 버전
├── values.yaml # 기본값
└── templates/
├── _helpers.tpl # 여러 템플릿에서 같이 쓰는 조각
├── configmap.yaml
├── deployment.yaml
├── service.yaml
└── NOTES.txt # 설치 후 화면에 보여 줄 안내 문구
values-prd.yaml # 운영 환경 값 (차트 밖에 둠)# Chart.yaml
apiVersion: v2
name: demo-web
description: nginx로 안내 문구 한 줄을 보여 주는 예제 차트
type: application
version: 0.1.0
appVersion: "1.0.0"version은 차트 자체의 버전이고, appVersion은 차트가 배포하는 앱의 버전입니다. 템플릿이나 기본값을 고치면 version을 올리고, 앱 이미지만 바뀌면 appVersion을 올립니다. apiVersion: v2는 Helm 3와 4가 쓰는 차트 형식이고, Helm 4에서 v3 형식이 실험 기능으로 추가됐지만 기존 v2 차트는 그대로 동작합니다.
# values.yaml
replicaCount: 1
image:
repository: nginx
tag: alpine
pullPolicy: IfNotPresent
message: "hello from helm v1"
service:
type: ClusterIP
port: 80
resources: {}환경별 값 파일은 차트 폴더 밖에 둡니다. 차트 안에 두면 helm package로 묶을 때 운영 설정까지 같이 배포되기 때문입니다. 운영 값에는 기본값과 다른 부분만 적습니다.
# values-prd.yaml
replicaCount: 3
message: "hello from prd"
resources:
requests:
cpu: 100m
memory: 64Mi
limits:
memory: 128Mi3. 템플릿 문법
templates 폴더의 파일은 Go 템플릿 문법으로 쓴 YAML입니다. {{ }} 안에 값을 넣을 자리를 적고, Helm이 렌더링할 때 실제 값으로 바꿉니다. 템플릿 안에서 쓸 수 있는 대표적인 객체는 다음과 같습니다.
| 객체 | 내용 |
| .Values | values.yaml과 배포할 때 넣은 값을 합친 결과 |
| .Release.Name | 릴리스 이름 (helm install 뒤에 적은 이름) |
| .Release.Namespace | 릴리스가 설치되는 네임스페이스 |
| .Release.Revision | 현재 리비전 번호 |
| .Chart.Name, .Chart.Version | Chart.yaml에 적은 값 |
| .Template.BasePath | templates 폴더 경로 |
리소스 이름과 라벨처럼 여러 파일에 똑같이 들어가는 부분은 _helpers.tpl에 define으로 한 번만 정의하고 include로 가져다 씁니다. 파일 이름이 _로 시작하면 Helm은 이 파일을 매니페스트로 만들지 않습니다.
{{/* templates/_helpers.tpl */}}
{{/* 릴리스 이름과 차트 이름으로 리소스 이름을 만든다 */}}
{{- define "demo-web.fullname" -}}
{{- printf "%s-%s" .Release.Name .Chart.Name | trunc 63 | trimSuffix "-" -}}
{{- end -}}
{{/* 모든 리소스에 붙일 공통 라벨 */}}
{{- define "demo-web.labels" -}}
app.kubernetes.io/name: {{ .Chart.Name }}
app.kubernetes.io/instance: {{ .Release.Name }}
app.kubernetes.io/version: {{ .Chart.AppVersion | quote }}
app.kubernetes.io/managed-by: {{ .Release.Service }}
helm.sh/chart: {{ printf "%s-%s" .Chart.Name .Chart.Version }}
{{- end -}}
{{/* Deployment와 Service가 Pod를 찾을 때 쓰는 라벨 */}}
{{- define "demo-web.selectorLabels" -}}
app.kubernetes.io/name: {{ .Chart.Name }}
app.kubernetes.io/instance: {{ .Release.Name }}
{{- end -}}Deployment 템플릿입니다. 앞에서 정의한 조각과 values를 조합합니다.
# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ include "demo-web.fullname" . }}
labels:
{{- include "demo-web.labels" . | nindent 4 }}
spec:
replicas: {{ .Values.replicaCount }}
selector:
matchLabels:
{{- include "demo-web.selectorLabels" . | nindent 6 }}
template:
metadata:
labels:
{{- include "demo-web.selectorLabels" . | nindent 8 }}
annotations:
# ConfigMap 내용이 바뀌면 값이 바뀌어 Pod가 새로 뜬다
checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }}
spec:
containers:
- name: web
image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
imagePullPolicy: {{ .Values.image.pullPolicy }}
ports:
- name: http
containerPort: 80
readinessProbe:
httpGet:
path: /
port: http
{{- with .Values.resources }}
resources:
{{- toYaml . | nindent 12 }}
{{- end }}
volumeMounts:
- name: html
mountPath: /usr/share/nginx/html
volumes:
- name: html
configMap:
name: {{ include "demo-web.fullname" . }}| 문법 | 하는 일 |
| include "이름" . | _helpers.tpl에 정의한 조각을 가져옴. 뒤의 .은 현재 값 전체를 넘긴다는 뜻 |
| | nindent 4 | 줄을 바꾸고 4칸 들여쓰기. YAML 들여쓰기를 맞출 때 가장 많이 씀 |
| toYaml | 값의 묶음을 YAML 그대로 출력. resources처럼 구조가 있는 값에 씀 |
| with / if | 값이 비어 있으면 블록 전체를 건너뜀 |
| quote, default | 따옴표로 감싸기, 값이 없을 때 기본값 쓰기 |
| {{- , -}} | 앞이나 뒤의 공백과 줄바꿈을 지움. 빈 줄이 생기지 않게 할 때 씀 |
checksum/config 주석은 실무에서 자주 쓰는 방법입니다. 9편에서 본 것처럼 ConfigMap만 바꾸면 이미 떠 있는 Pod는 새 값을 바로 읽지 않습니다. ConfigMap 내용의 해시를 Pod 템플릿에 넣어 두면 내용이 바뀔 때 해시도 바뀌고, Deployment는 Pod 템플릿이 바뀐 것으로 보고 롤링 업데이트를 합니다.
템플릿이 제대로 렌더링되는지는 클러스터에 올리기 전에 확인할 수 있습니다.
helm lint ./demo-web # 문법과 구조 검사
helm template web ./demo-web # 렌더링 결과를 화면에 출력 (클러스터 접속 안 함)
helm template web ./demo-web --show-only templates/service.yaml4. 값이 적용되는 우선순위
같은 키가 여러 곳에 있으면 뒤에 오는 것이 이깁니다. 차트의 values.yaml이 가장 약하고, -f로 넘긴 파일이 그 위를 덮고, --set이 가장 강합니다. -f를 여러 번 쓰면 나중에 적은 파일이 우선합니다.
| 순서 | 위치 | 주로 쓰는 곳 |
| 1 (약함) | 차트의 values.yaml | 모든 환경의 기본값 |
| 2 | -f values-prd.yaml | 환경별 차이. Git으로 관리 |
| 3 (강함) | --set key=value | CI에서 이미지 태그처럼 배포마다 바뀌는 값 |
$ helm template web ./demo-web -f values-prd.yaml --set replicaCount=5 | grep -E "replicas:|<h1>"
<h1>hello from prd</h1>
replicas: 5문구는 values-prd.yaml의 값이, 레플리카 수는 --set의 값이 적용됐습니다. 주의할 점은 helm upgrade가 이전 배포에서 넣은 값을 기억하지 않는다는 것입니다. upgrade는 차트 기본값에 이번에 넘긴 값만 더해서 새로 계산합니다. 지난번에 --set으로 바꾼 값이 있다면 이번에도 다시 넘겨야 하고, 그렇지 않으면 기본값으로 돌아갑니다. 아래 직접 해 보기에서 이 동작을 확인합니다. 이전 값을 이어서 쓰는 --reuse-values도 있지만, 차트가 새 버전으로 바뀌면 새로 추가된 기본값을 놓칠 수 있어서 값은 파일로 관리하고 매번 같은 파일을 넘기는 편이 안전합니다.
5. 릴리스와 롤백
릴리스를 설치하거나 바꿀 때마다 Helm은 리비전 번호를 하나 올리고, 그때 쓴 차트와 값, 렌더링한 매니페스트를 릴리스와 같은 네임스페이스의 Secret에 저장합니다. 이름은 sh.helm.release.v1.릴리스이름.v리비전 형태입니다. helm history, helm get values, helm rollback은 모두 이 Secret을 읽어서 동작합니다.
롤백은 이전 리비전의 내용을 복사해 새 리비전을 만듭니다
롤백은 과거 리비전으로 되감는 것이 아니라, 과거 리비전의 내용으로 새 리비전을 만드는 것입니다. 2번으로 롤백하면 기록에서 3번이 지워지지 않고, 2번과 같은 내용의 4번이 새로 생깁니다. 그래서 롤백한 뒤에도 무엇이 언제 어떻게 바뀌었는지 이력이 끊기지 않습니다. 리비전은 기본으로 최근 10개까지 보관하고, --history-max로 개수를 바꿀 수 있습니다.
6. 직접 해 보기
Helm은 kubectl과 같은 kubeconfig로 클러스터에 접속하므로, kubectl이 동작하는 곳이라면 Helm만 설치하면 됩니다.
# Linux: 공식 설치 스크립트 (Helm 4)
curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-4
chmod 700 get_helm.sh
./get_helm.sh
# macOS / Windows
brew install helm
winget install Helm.Helm
helm version예제 차트를 설치합니다. --create-namespace는 네임스페이스가 없으면 만들어 줍니다. 마지막에 나오는 안내 문구가 NOTES.txt로 만든 내용입니다.
$ helm install web ./demo-web -n demo --create-namespace
NAME: web
LAST DEPLOYED: Thu Oct 1 00:39:28 2026
NAMESPACE: demo
STATUS: deployed
REVISION: 1
DESCRIPTION: Install complete
TEST SUITE: None
NOTES:
web 릴리스가 demo 네임스페이스에 배포됐습니다. (revision 1)
접속 확인:
kubectl -n demo port-forward svc/web-demo-web 8080:80
curl localhost:8080문구만 바꿔서 업그레이드하고, 이어서 운영 값 파일로 한 번 더 업그레이드합니다.
helm upgrade web ./demo-web -n demo --set message="hello from helm v2"
helm upgrade web ./demo-web -n demo -f values-prd.yaml3번째 배포에 적용된 값을 확인하면, 2번째 배포에서 --set으로 넣은 문구는 남아 있지 않고 values-prd.yaml의 값만 있습니다. 4장에서 말한 upgrade의 동작 그대로입니다. --all을 붙이면 기본값까지 합친 최종 값을 볼 수 있습니다.
$ helm get values web -n demo
USER-SUPPLIED VALUES:
message: hello from prd
replicaCount: 3
resources:
limits:
memory: 128Mi
requests:
cpu: 100m
memory: 64Mi2번째 배포로 롤백하고 이력을 봅니다.
$ helm rollback web 2 -n demo
Rollback was a success! Happy Helming!
$ helm history web -n demo
REVISION UPDATED STATUS CHART APP VERSION DESCRIPTION
1 Thu Oct 1 00:39:28 2026 superseded demo-web-0.1.0 1.0.0 Install complete
2 Thu Oct 1 00:39:29 2026 superseded demo-web-0.1.0 1.0.0 Upgrade complete
3 Thu Oct 1 00:39:29 2026 superseded demo-web-0.1.0 1.0.0 Upgrade complete
4 Thu Oct 1 00:39:30 2026 deployed demo-web-0.1.0 1.0.0 Rollback to 2리비전마다 Secret이 하나씩 생긴 것도 확인할 수 있습니다.
$ kubectl -n demo get secret -l owner=helm,name=web
NAME TYPE DATA AGE
sh.helm.release.v1.web.v1 helm.sh/release.v1 1 3s
sh.helm.release.v1.web.v2 helm.sh/release.v1 1 2s
sh.helm.release.v1.web.v3 helm.sh/release.v1 1 1s
sh.helm.release.v1.web.v4 helm.sh/release.v1 1 1s자주 쓰는 명령을 정리하면 다음과 같습니다. 실습이 끝나면 helm uninstall로 지웁니다. 차트로 만든 리소스와 릴리스 기록 Secret이 함께 삭제됩니다.
| 작업 | 명령 |
| 설치 / 업그레이드 | helm install web ./demo-web -n demo helm upgrade web ./demo-web -n demo -f values-prd.yaml |
| 없으면 설치, 있으면 업그레이드 | helm upgrade --install web ./demo-web -n demo |
| 릴리스 목록 | helm list -n demo (모든 네임스페이스는 -A) |
| 상태 / 이력 | helm status web -n demo helm history web -n demo |
| 적용된 값 / 매니페스트 | helm get values web -n demo helm get manifest web -n demo |
| 롤백 | helm rollback web 2 -n demo |
| 삭제 | helm uninstall web -n demo |
| 차트를 .tgz로 묶기 | helm package ./demo-web |
7. 외부 차트 가져다 쓰기
직접 만든 차트보다 더 자주 쓰는 것은 다른 사람이 만든 차트입니다. ArgoCD, cert-manager, Prometheus처럼 널리 쓰는 도구는 대부분 공식 차트를 제공합니다. 차트 저장소는 두 가지 방식이 있습니다.
# 1) HTTP 저장소: 저장소를 등록하고 이름으로 찾음
helm repo add argo https://argoproj.github.io/argo-helm
helm repo update
helm search repo argo/argo-cd --versions | head
helm show values argo/argo-cd --version 버전 > argocd-values.yaml
helm install argocd argo/argo-cd -n argocd --create-namespace \
--version 버전 -f argocd-values.yaml
# 2) OCI 레지스트리: 컨테이너 이미지처럼 레지스트리 주소로 바로 받음
helm registry login exampleacr.azurecr.io
helm push demo-web-0.1.0.tgz oci://exampleacr.azurecr.io/helm
helm install web oci://exampleacr.azurecr.io/helm/demo-web --version 0.1.0 -n demo외부 차트를 쓸 때는 두 가지를 습관으로 만드는 것이 좋습니다. 먼저 helm show values로 기본값을 파일로 받아 어떤 설정을 바꿀 수 있는지 읽고, 바꿀 부분만 내 값 파일에 적습니다. 그리고 --version을 항상 적습니다. 버전을 빼면 그 시점의 최신 차트가 설치되어, 같은 명령을 다시 실행해도 결과가 달라질 수 있습니다.
OCI 레지스트리는 따로 차트 저장소를 운영하지 않고 이미지를 두는 레지스트리에 차트도 같이 두는 방식이라, 요즘은 이 방식이 늘고 있습니다. Azure라면 [Azure] Azure Container Registry 사용법 정리에서 만든 ACR에 이미지와 차트를 함께 둘 수 있습니다.
8. Helm 4에서 달라진 점
Helm 4는 2025년 11월에 나왔고, 현재 최신은 4.3입니다. 차트 형식(apiVersion v2)은 그대로라 기존 차트는 수정 없이 쓸 수 있지만, 명령 사용법에서 몇 가지가 바뀌었습니다. Helm 3는 2026년 7월 8일에 버그 수정이 끝났고, 보안 수정도 2026년 11월 11일까지만 나오므로 아직 Helm 3를 쓰고 있다면 옮길 준비를 해야 합니다.
| 항목 | Helm 3 | Helm 4 |
| 실패 시 자동 롤백 | --atomic | --rollback-on-failure (--atomic은 경고와 함께 동작) |
| 리소스 강제 교체 | --force | --force-replace |
| 리소스 적용 방식 | 클라이언트에서 비교 후 적용 | 새 릴리스는 Server-Side Apply가 기본 기존 릴리스는 이전 방식 유지 (--server-side=auto) |
| --wait | Pod, Deployment 등 정해진 리소스의 준비 상태만 확인 | kstatus로 리소스 상태를 확인하는 watcher 방식 플래그를 빼면 hook만 기다림 (hookOnly) |
| 플러그인 | 실행 파일 방식 | WebAssembly 플러그인 지원, post-renderer도 플러그인으로 |
| OCI 차트 | 태그로 설치 | digest(@sha256:...)로 설치 가능 |
실제로 --atomic을 쓰면 Flag --atomic has been deprecated, use --rollback-on-failure instead라는 경고가 나옵니다. CI 스크립트에 예전 플래그가 있다면 이번에 함께 바꿔 두는 것이 좋습니다.
9. Kustomize, ArgoCD와 함께 쓸 때
[CI/CD] GitHub, Jenkins, ArgoCD로 dev/prd 배포 아키텍처 설계에서는 환경별 차이를 Kustomize의 overlay로 나눴습니다. Helm과 Kustomize는 같은 문제를 다른 방식으로 풉니다.
| 항목 | Helm | Kustomize |
| 방식 | 템플릿에 값을 채워 YAML을 만듦 | 평범한 YAML 위에 바뀐 부분만 덧씌움 |
| 배포 이력, 롤백 | 릴리스와 리비전으로 자체 관리 | 없음. Git 이력이나 ArgoCD에 맡김 |
| 배포와 공유 | 차트로 묶어 저장소에 올리고 버전 관리 | Git 저장소 그대로 사용 |
| 잘 맞는 곳 | 외부 도구 설치, 여러 팀이 쓰는 공통 앱 | 우리 팀 앱의 환경별 차이 관리 |
둘 중 하나만 고를 필요는 없습니다. ArgoCD, Ingress Controller처럼 외부에서 가져오는 도구는 Helm 차트로 설치하고, 직접 만든 앱은 Kustomize로 관리하는 조합도 많이 씁니다.
[ArgoCD] ArgoCD 설치와 사용법 정리에서 본 ArgoCD도 Application의 source로 Helm 차트를 바로 지정할 수 있습니다. 이때 ArgoCD는 내부에서 helm template으로 매니페스트만 만들어 적용하고, 배포 이력과 롤백은 ArgoCD가 관리합니다. 그래서 ArgoCD로 배포한 앱은 helm list에 나오지 않고, helm rollback도 쓸 수 없습니다. 같은 앱을 ArgoCD와 helm upgrade로 번갈아 배포하면 두 도구가 서로의 변경을 덮어쓰므로, 앱마다 배포 도구는 하나로 정합니다.
10. 운영 시 주의점
Helm의 성공은 Pod의 정상 동작을 뜻하지 않습니다. Helm 4에서 --wait를 빼면 리소스를 API 서버에 적용하는 순간 성공으로 끝납니다. 이미지 이름을 잘못 적어 Pod가 뜨지 않아도 STATUS: deployed가 나옵니다. CI에서는 --wait와 --timeout을 붙여 실제로 준비될 때까지 기다리고, 실패하면 직전 상태로 되돌리도록 --rollback-on-failure를 함께 씁니다. 이 플래그를 쓰면 --wait는 자동으로 watcher 방식이 됩니다.
helm upgrade --install web ./demo-web -n demo \
-f values-prd.yaml --set image.tag="$IMAGE_TAG" \
--wait --timeout 5m --rollback-on-failure비밀 값은 values 파일에 넣지 않습니다. values는 Git에 올라가고, 릴리스 Secret 안에도 그대로 저장되며, helm get values로 누구나 볼 수 있습니다. DB 비밀번호 같은 값은 [Azure] AKS에서 Key Vault로 Secret 관리 정리처럼 외부 저장소에서 가져오고, 차트에는 Secret의 이름만 넘깁니다.
클러스터에서 직접 고친 내용은 다음 배포 때 사라집니다. 장애 대응 중에 kubectl edit으로 레플리카 수를 바꿨다면, 다음 helm upgrade가 차트의 값으로 다시 덮어씁니다. 급하게 바꾼 설정은 반드시 values 파일에도 반영합니다.
바꾸기 전에 결과를 먼저 봅니다. helm template로 렌더링 결과를 확인하거나, --dry-run=server로 클러스터에 실제로 적용하지 않고 검증만 할 수 있습니다. 운영 배포 전에는 helm get manifest로 받은 현재 매니페스트와 새로 렌더링한 결과를 비교해 보는 것이 좋습니다.
11. 정리
- Helm은 매니페스트를 템플릿으로 만들어 바뀌는 부분만 값으로 빼고, 배포마다 리비전을 남기는 Kubernetes 패키지 매니저입니다.
- 값은 차트의 values.yaml, -f 파일, --set 순서로 덮어쓰고, upgrade는 이전에 넣은 값을 기억하지 않습니다.
- 릴리스 기록은 네임스페이스의 Secret에 남고, 롤백은 과거 내용으로 새 리비전을 만듭니다.
- 외부 차트는 기본값을 먼저 읽고, --version을 항상 고정해서 설치합니다.
- Helm 4에서는 --atomic이 --rollback-on-failure로, --force가 --force-replace로 바뀌었고, 새 릴리스는 Server-Side Apply가 기본입니다.
- CI에서는 --wait와 --rollback-on-failure를 함께 쓰고, 비밀 값은 values에 넣지 않습니다.
참고
'DevOps > Kubernetes' 카테고리의 다른 글
| [Kubernetes] 리소스 requests, limits와 HPA 정리 (0) | 2026.09.28 |
|---|---|
| [Kubernetes] Volume, PV, PVC, StorageClass 정리 (0) | 2026.09.28 |
| [Kubernetes] ConfigMap과 Secret 정리 (0) | 2026.09.28 |
| [Kubernetes] Service와 Ingress, Gateway API 정리 (0) | 2026.09.28 |
| [Kubernetes] Pod, ReplicaSet, Deployment 정리 (0) | 2026.09.28 |
