12. 헬름 Starter Packs 및 헬름 Diff 이용
이번 장은 사내에서 자체 개발한 애플리케이션을 쿠버네티스 환경에 설치하기 위해서 헬름 템플릿을 이용하는 방법을 알아보겠습니다. 헬름 Starter Packs를 이용하면 커스텀 템플릿을 편리하게 사용할 수 있어 편의성과 보안을 높일 수 있습니다. 그리고 운영 환경에서 헬름 업그레이드를 안전하게 작업할 수 있는 헬름 Diff 명령어를 실습과 함께 알아보겠습니다.
주요 내용
- 각 회사, 개인 환경에 따라 사전 정의한 헬름 템플릿을 사용하는 헬름 Starter Packs를 사용하여 효율적으로 헬름 차트를 관리할 수 있습니다.
- 헬름 diff를 사용하면 업그레이드 작업 시 변경 사항을 미리 확인할 수 있어 장애를 예방하는데 많은 도움이 됩니다.
실습 과제
- 헬름 Starter Packs를 이용한 헬름 템플릿 차트 생성
- 헬름 업그레이드 작업 – 헬름 diff 명령어를 사용하여 헬름 차트 업그레이드 작업 전 변경 내역 사전 확인
깃헙 링크
- https://github.com/junghoon2/k8s-class/tree/main/helm-starter-template
- https://github.com/junghoon2/k8s-class/tree/main/foo
1. 기본 설정으로 헬름 차트 생성 – Helm Create
사용자 정의 헬름 차트를 생성하는 기본 명령어는 ‘helm create’입니다.
새 Helm 차트를 시작할 때, helm create 명령어는 빠르게 시작할 수 있는 표준 디렉토리 구조와 함께 필요한 파일 세트를 제공합니다. 이 명령어를 실행하면, Helm은 개발자가 수정하고 자신의 애플리케이션 요구 사항에 맞게 채워넣을 수 있는 기본 템플릿을 생성합니다. 해당 템플릿에 필요한 values.yaml 파일을 변경하여 각 사용자가 필요한 애플리케이션을 만들 수 있습니다.
간단한 실습으로 상세 내용을 알아보겠습니다. 사용하는 버전에 따라 약간 차이가 있을 수 있으므로 헬름 버전을 확인합니다. 저는 ‘v3.12.3’ 버전을 사용합니다.
(latte-prod:kube-system)k8s-class$ helm version
version.BuildInfo{Version:"v3.12.3", GitCommit:"3a31588ad33fe3b89af5a2a54ee1d25bfe6eaa5e", GitTreeState:"clean", GoVersion:"go1.20.7"}
새로운 헬름 차트를 생성합니다.
$ (⎈ |switch-singapore-test:argocd) helm create foo-chart Creating foo-chart
foo-chart라는 새로운 디렉토리가 생성되며 아래와 같은 구조로 파일이 만들어집니다.
$ (⎈ |switch-singapore-test:argocd) ls foo-chart Chart.yaml charts templates values.yaml
$ (⎈ |switch-singapore-test:argocd) tree -L 2 foo-chart foo-chart ├── Chart.yaml ├── charts ├── templates │ ├── NOTES.txt │ ├── _helpers.tpl │ ├── deployment.yaml │ ├── hpa.yaml │ ├── ingress.yaml │ ├── service.yaml │ ├── serviceaccount.yaml │ └── tests └── values.yaml 4 directories, 9 files
기본으로 포함된 templates 디렉토리, values.yaml, Chart.yaml을 수정하여 원하는 차트를 만들 수 있습니다. 하지만 실제 운영 환경에서 많이 사용하는 ConfigMap, Secret 등의 리소스 파일이 포함되지 않는 등 수동으로 해야 할 작업이 많이 있습니다.
기본 템플릿을 기준으로 수정을 완료하면 ‘helm package’ 명령어를 사용하여 전체 헬름 차트를 압축 파일로 만들 수 있습니다.
$ (⎈ |switch-singapore-test:argocd) helm package foo-chart Successfully packaged chart and saved it to: /Users/jerry/private/k8s-class/foo-chart-0.1.0.tgz $ (⎈ |switch-singapore-test:argocd) ls foo-chart-0.1.0.tgz foo-chart-0.1.0.tgz
해당 압축 파일로 헬름 차트를 공유할 수 있습니다.
하지만 언급하였듯이 위와 같은 방법으로 헬름 차트를 생성하면 매번 values.yaml, templates 디렉토리를 새롭게 수정해야 하는 번거로움이 있습니다. 해당 작업을 매번 사람이 해야 하므로 실수가 발생할 수 있고 추가 시간이 소요됩니다.
커스텀 차트를 사용할 수 있는 헬름 Starter Packs 옵션을 알아봅니다.
2. 헬름 Starter Packs를 이용한 커스텀 애플리케이션 설치 실습
기본으로 제공하는 헬름 차트는 ConfigMap, Secret, 보안 설정 등이 부족합니다. 헬름 Starter Packs 템플릿은 쿠버네티스 애플리케이션을 더 빠르고 편리하게 개발하고 배포하기 위해 사용되는 템플릿 세트입니다. 각 회사 혹은 개인이 별도로 템플릿을 지정하고 해당 템플릿을 기준으로 새로운 헬름 차트를 만들 수 있는 옵션입니다.
Starter Packs는 각 프로젝트를 시작하는 데 필요한 기본 구성과 설정을 포함할 수 있어 개발자와 운영자가 애플리케이션을 쉽게 시작하고 관리할 수 있게 도와줍니다. 각 조직과 개인 별 애플리케이션 개발과 배포에 필요한 표준화된 구조를 제공하여 팀 간의 일관성을 유지하고 애플리케이션 프로젝트의 유지 보수를 용이하게 합니다.
그리고 기본적인 쿠버네티스 리소스 및 Helm Chart 구조를 제공하여 새로운 프로젝트를 시작할 때 복잡한 설정 작업 없이 바로 애플리케이션 개발에 집중할 수 있습니다. 보안 및 베스트 프랙티스 기반으로 작성하여 보안 위험을 최소화하고 운영의 효율성을 높입니다.
–starter(시작자) 옵션을 사용하면 말 그대로 시작하는 파일을 임의로 지정하여 해당 템플릿 파일을 기준으로 헬름 차트를 작성할 수 있습니다. 템플릿 파일에 사전에 필요한 보안 구성, ConfigMap 등을 포함하면 회사의 보안 정책 등을 준수하는 헬름 차트를 만들 수 있습니다.
필자가 사용하는 Starter Packs 템플릿 디렉토리입니다. 깃헙에서 전체 파일을 내려 받을 수 있습니다.
$ (⎈ |SWITCH-SEOUL-PROD:nlp) tree -L 2 helm-starter-template
helm-starter-template
├── Chart.yaml
├── ci
│ └── values.yaml
└── templates
├── NOTES.txt
├── _helpers.tpl
├── deployment.yaml
├── env-cm.yaml
├── hpa.yaml
├── ingress.yaml
├── service.yaml
├── serviceaccount.yaml
├── servicemonitor.yaml
└── tests
4 directories, 11 files
. ci/values.yaml
기본 values.yaml 파일을 ci 디렉토리로 이동하였습니다. 환경 구성에 따라 values.yaml 파일을 복사하여 test-values.yaml, dev/stage/prod-values.yaml 등으로 헬름 values 파일을 추가하여 사용할 수 있습니다.
. templates 파일 수정
기본 템플릿에 포함되지 않았던 servicemonitor, ingress, env-cm(configMap) 등의 파일을 추가하였고 기본 deployment.yaml 파일에 terminationGracePeriodSeconds 등의 커스텀 설정을 추가하였습니다.
그럼 상세한 설정을 알아봅니다. 수정한 헬름 values 파일입니다.
image:
repository: pengbai/docker-supermario
pullPolicy: Always
tag: "latest" # 이미지 태그를 지정합니다.
env: {}
# 위에 {}를 지우고 <환경변수>: <값>을 쓰세요
# e.g.
# SERVER_PORT: 8080
# SERVER_HOST: atlas-default
# ...
secrets: {}
# 위에 {}를 지우고 <환경변수>: <값>을 쓰세요
# e.g.
# PostgreSQL_PASSWORD: cGFzc3dvcmQ=
# ...
terminationGracePeriodSeconds: 30
metrics:
enabled: false # 메트릭을 사용할지 결정합니다
path: /metrics # 메트릭 경로를 지정합니다.
probes:
liveness:
enabled: false
path: / # liveness 경로를 바꿀 수 있습니다 e.g. /healthz
readiness:
enabled: false
path: / # readiness 경로를 바꿀 수 있습니다 e.g. /healthz
imagePullSecrets: []
nameOverride: ""
fullnameOverride: ""
# Authentication
serviceAccount:
create: false
annotations: {}
name: ""
podAnnotations: {}
# Security
podSecurityContext: {}
securityContext:
allowPrivilegeEscalation: false
privileged: false
capabilities:
drop:
- ALL
readOnlyRootFilesystem: true
# Networking
container:
port: 8080
service:
type: ClusterIP
port: 80
ingress:
enabled: false
className: ""
annotations: {}
hosts:
- host: chart-example.local
paths:
- path: /
pathType: ImplementationSpecific
tls: []
# Conatiner resources
resources:
limits:
# memory: 128Mi
requests:
cpu: 10m
memory: 128Mi
# HPA
autoscaling:
enabled: false
minReplicas: 1
maxReplicas: 10
targetCPUUtilizationPercentage: 80
# Scheduling
nodeSelector: {}
tolerations: []
affinity: {}
. image.repository
사내(Harbor) 혹은 외부 이미지 저장소(ECR)의 주소를 지정합니다.
. image.pullPolicy: Always
보안 상 기본 ‘IfNotPresent’ 보다는 ‘Always’ 사용을 권고합니다. 매번 이미지를 내려받아 네트워크 트래픽이 증가하고 파드가 실행하는 속도는 늦어질 수 있지만 악성 사용자가 로컬에 다운받은 이미지를 변경하여 악성 코드 등을 추가하는 공격을 예방할 수 있습니다. Prod 환경에서는 ‘Always’, Dev/Stage 환경에서는 ‘‘IfNotPresent’ 사용하는 것이 일반적입니다.
‘latest’ 버전을 사용하고 ‘‘IfNotPresent’ 옵션을 사용하면 이미지 변경 사항이 반영되지 않는 문제가 발생할 수 있으므로 컨테이너 이미지 버전은 ‘latest’를 사용하지 않는 것을 권고합니다.
. env, secrets
컨테이너 이미지 내의 구성 정보를 하드코딩하지 않도록 필수로 사용하는 ConfigMap, Secret으로 별도로 분리하였습니다. 환경 변수로 분리하여 Dev/Stage/Prod 등 환경에 따라 달라지지 않는 불변 이미지를 사용하는 것을 적극 권고합니다.
물론 Secret 파일은 민감한 정보를 포함하므로 base64 인코딩 내용을 그대로 사용하는 것을 권고하지 않습니다. 실제 운영 환경에서는 Vault, Sealed Secret, SOPS 등을 사용하는 것을 권장합니다.
. terminationGracePeriodSeconds
서비스 안정성을 위하여 Grace Shutdown 설정을 별도로 분리하였습니다. 사용하는 애플리케이션에 따라 서비스가 비정상 종료되지 않고 안정적으로 종료할 수 있도록 필요한 시간을 지정합니다. 필자는 ‘14400’(4시간)도 많이 지정하였습니다.
. metrics
각 애플리케이션 마다 별도로 Custom 메트릭을 사용하는 경우 ServiceMonitor CRD에 등록니다. ServiceMonitor는 Prometheus Operator를 사용하여 커스텀 메트릭을 수집하고 쿠버네티스 환경에서 서비스를 모니터링하는데 사용합니다. ServiceMonitor 리소스는 Prometheus Operator가 관리하는 Prometheus 인스턴스에 의해 자동으로 발견되며, 이는 메트릭 수집을 위한 타겟 서비스의 목록을 동적으로 업데이트합니다.
. probes
컨테이너가 정상적으로 동작하고 있는지 여부를 확인하는 데 사용하는 Liveness Probe와 컨테이너가 요청을 처리할 준비가 되었는지 여부를 확인하는 데 사용하는 Readiness Probe 설정을 추가하였습니다.
. securityContext
회사의 컨테이너 보안 정책을 추가하였습니다. 보안이 항상 그렇듯이 처음부터 정책으로 제공하지 않으면 이 후 수정하기 어렵습니다. 파드 실행 시 강제하도록 헬름 차트에 기본으로 포함하였습니다.
. securityContext.allowPrivilegeEscalation
‘allowPrivilegeEscalation’ 옵션이 ‘true’로 설정되면 컨테이너 프로세스가 더 높은 권한을 얻을 수 있는 조건이 됩니다. 이는 주로 컨테이너가 실행되는 프로세스가 set-user-ID 또는 set-group-ID 권한을 가진 실행 파일을 사용할 때 발생합니다. 이러한 실행 파일을 사용하면 프로세스는 파일을 소유한 사용자나 그룹의 권한으로 실행될 수 있습니다.
‘false’ 옵션으로 지정하면 권한 상승, 즉 ‘root’ 실행을 방지하여 좀 더 안전하게 사용할 수 있습니다. 보안 권고 사항입니다.
. securityContext.privileged
Kubernetes의 securityContext 설정에서 privileged 옵션은 컨테이너가 호스트 시스템의 모든 장치에 대해 액세스할 수 있도록 허용하는 설정입니다. 이 옵션이 true로 설정되면, 컨테이너 내의 프로세스는 호스트 시스템에서 거의 모든 작업을 수행할 수 있는 권한을 갖게 됩니다.
privileged 모드로 실행되는 컨테이너는 호스트 머신의 커널 기능에 대해 더 높은 수준의 접근 권한을 가지게 되며, 이는 일반 컨테이너보다 훨씬 더 많은 권한을 부여받습니다. 예를 들어, 호스트의 네트워크 스택을 조작하거나 다른 컨테이너에 영향을 미치는 등의 작업을 할 수 있습니다.
명시적으로 ‘false’ 설정을 권고합니다.
. securityContext.capabilities
capabilities는 Linux 기능(capabilities)을 컨테이너 프로세스에 추가하거나 삭제하는 것을 관리합니다. Linux 기능은 전통적인 루트 권한을 더 세분화하여, 특정 권한을 프로세스에 부여할 수 있게 하는 시스템입니다. 만약 추가 권한이 필요하다면 필요한 기능만 명시적으로 지정하여 실행합니다.
. container.port: 8080
컨테이너가 실행하는 port 입니다. 시스템 사용자가 사용하는 ‘1024’ 이후의 포트를 사용하는 것을 권고합니다.
. service.port: 80
외부 파드 혹은 사용자가 접속하는 서비스 포트입니다. 컨테이너 내부 포트가 아니라 외부에서 접속하는 포트이므로 일반 웹에서 사용하는 것과 동일하게 ‘80’ 포트를 사용하는 것이 편리합니다.
. ingress
파드가 외부 접근이 필요하면 인그레스를 이용하도록 인그레스 설정을 추가하였습니다. Annotations, Host 정보 등을 추가하면 헬름 차트 배포 시 인그레스 리소스가 같이 배포됩니다. External DNS Controller를 함께 사용하는 Host 정보를 기준으로 자동으로 Route 53의 도메인까지 등록하므로 추가 작업이 필요없으므로 편리합니다.
. resources
기본 설정에 간과하기 쉬운 자원의 Requests, Limits 설정을 포함합니다. 참고로 필자는 자원을 효과적으로 사용하기 위하여 CPU는 Limit 설정을 하지 않습니다.
. autoscaling
헬름 차트에 HPA 리소스도 같이 배포할 수 있도록 autoscaling 설정을 포함하였습니다. 필요에 따라 ‘true’, ‘false’ 옵션을 지정합니다.
. tolerations, affinity
Advanced Scheduling 관련 설정을 추가하였습니다. taint 설정된 노드에 스케줄링 가능하게 toleration 설정을 추가합니다. podAffinity, nodeAffinity 설정으로 필요한 파드와 노드에 실행합니다.
그럼 해당 Starter Packs 차트를 기준으로 새로운 차트를 만들어보겠습니다. helm create 옵션에 –starter를 추가하여 위에서 생성한 Starter Packs 디렉토리 위치를 지정합니다.
$ (⎈ |SWITCH-SEOUL-PROD:nlp) helm create foo --starter ~/private/k8s-class/helm-starter-template Creating foo
새로운 foo 헬름 차트가 생성되었습니다. (필자 깃헙 파일) 해당 차트에 원하는 설정을 포함하여 새로운 헬름 애플리케이션을 배포합니다.
기존 values.yaml 파일에 ConfigMap과 Secret 부문을 아래와 같이 변경합니다. ‘secrets’에 등록한 변수는 base64 인코딩된 값으로 등록합니다.
ci/values.yaml
env: SERVER_PORT: 8080 secrets: PostgreSQL_PASSWORD: cGFzc3dvcmQ=
헬름 차트를 설치합니다.
(jerry-test:default)foo$ cd foo
(jerry-test:default)foo$ k ns default
(jerry-test:default)foo$ helm install foo -f ci/values.yaml .
NAME: foo
LAST DEPLOYED: Wed Nov 8 05:34:21 2023
NAMESPACE: default
STATUS: deployed
REVISION: 1
NOTES:
1. Get the application URL by running these commands:
export POD_NAME=$(kubectl get pods --namespace default -l "app.kubernetes.io/name=foo,app.kubernetes.io/instance=foo" -o jsonpath="{.items[0].metadata.name}")
export CONTAINER_PORT=$(kubectl get pod --namespace default $POD_NAME -o jsonpath="{.spec.containers[0].ports[0].containerPort}")
echo "Visit http://127.0.0.1:8080 to use your application"
kubectl --namespace default port-forward $POD_NAME 8080:$CONTAINER_PORT
헬름 Starter 차트에 포함된 설정이 ConfigMap, Secret 리소스로 정상 설치됩니다.
(jerry-test:default)foo$ k get pod,cm,secret NAME READY STATUS RESTARTS AGE pod/foo-655c44d96b-gtzqb 1/1 Running 0 97s NAME DATA AGE configmap/foo-env 1 98s NAME TYPE DATA AGE secret/foo-secret Opaque 1 98s
실행된 파드에 접속하여 환경 변수를 확인하면 ConfigMap, Secret에 등록한 내용을 확인할 수 있습니다. base64로 인코딩된 문자열이 평문으로 변환되어 정상으로 출력됩니다.
$ (⎈ |switch-singapore-test:default) k exec -it foo-starter-6f9d56858c-rtkxm -- sh $ echo $SERVER_PORT 8080 $ echo $PostgreSQL_PASSWORD password
간단히 port-forwarding 명령어를 이용하여 웹 페이지에 접속할 수 있습니다.
(jerry-test:default)foo$ k get svc foo NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE foo ClusterIP 172.20.107.67 <none> 80/TCP 3m7s (jerry-test:default)foo$ k port-forward svc/foo 8080:80 Forwarding from 127.0.0.1:8080 -> 8080 Forwarding from [::1]:8080 -> 8080
서비스 이름을 기준으로 port-forwarding 명령어를 실행합니다. 필자가 기본 이미지로 지정한 슈퍼마리오가 정상으로 실행되는 것을 확인할 수 있습니다.
3. 헬름 Diff 명령어를 이용하여 안전하게 헬름 업그레이드 하기
실제 쿠버네티스를 운영하면 헬름 차트로 설치한 애플리케이션을 변경해야 하는 경우가 많습니다. Helm 차트를 업그레이드할 때는 예기치 않은 변경 사항으로 인한 문제를 피하기 위해 주의가 필요합니다. 여기서 Helm Diff 플러그인의 역할이 중요해집니다. Helm Diff 명령어를 사용하여 Helm 차트를 안전하게 업그레이드 하는 방법을 알아봅니다.
모든 작업이 유사하지만 항상 작업을 하기 전에는 해당 작업의 변경 사항을 정확하게 파악하는 것이 필요한데, Helm Diff가 많은 도움이 됩니다. 유사하게 argocd diff, terraform plan 등도 꼭 필요합니다. CI Process에 변경 사항을 체크하는 부분을 자동화하여 사람의 실수를 방지하는 것도 아주 좋은 방법입니다.
필자도 Helm Diff를 사용한 이 후로 장애를 많이 줄일 수 있었습니다.
Helm Diff 플러그인은 현재 배포된 릴리스와 변경하려는 차트 버전 간의 차이점을 시각적으로 비교할 수 있게 해주는 도구입니다. 이를 사용하는 이유는 다음과 같습니다:
- 변경 사항 파악: 업그레이드 전에 변경될 리소스의 정확한 내용을 확인할 수 있습니다.
- 문제 예방: 실수로 발생할 수 있는 구성 오류를 미리 감지하고 수정할 수 있습니다.
- 검토 및 승인 프로세스: 변경 사항에 대한 동료의 검토를 받거나 승인 프로세스를 거칠 수 있습니다.
Helm Diff는 헬름에 부가적으로 사용할 수 있는 플러그인으로 아래와 같이 설치합니다.
helm plugin install https://github.com/databus23/helm-diff
그럼 실습을 진행합니다. 실무에서 Resource Request, Limit을 변경하는 작업은 자주 발생하는데 해당 케이스 기준으로 설명드립니다.
앞서 설정한 foo 헬름 차트의 Memory Limit를 Request와 동일하게 128Mi로 설정하겠습니다.
Before
# Container resources
resources:
limits:
# memory: 128Mi
requests:
cpu: 10m
memory: 128Mi
After
# Container resources
resources:
limits:
memory: 128Mi
requests:
cpu: 10m
memory: 128Mi
운영 환경에서는 메모리 Request, Limit를 동일하게 설정하는 것을 권고합니다. Limit을 설정하지 않거나 Request 보다 높게 설정한 경우 해당 파드의 사용량이 증가하면 같은 노드에 있는 다른 파드에 영향을 끼칠 수 있어 OOM(Out Of Memory) 장애가 발생할 수 있습니다.
그럼 ‘helm diff’ 명령어로 변경 사항을 확인합니다.
(jerry-test:default)foo$ helm diff upgrade foo -f ci/values.yaml . default, foo, Deployment (apps) has changed: # Source: foo/templates/deployment.yaml (...) - limits: null + limits: + memory: 128Mi
의도한대로 limits 설정만 변경되었습니다. limits: null 설정이 제외되고 limits: memory: 128Mi 설정이 추가됩니다. 만약 limits 설정 변경 이 외 다른 변경 사항이 있으면 현재 코드와 실제 쿠버네티스 실행되는 상태가 서로 다름을 알 수 있습니다. ‘k edit’ 등으로 임의로 변경하고 소스를 수정하지 않는 경우가 대표적입니다.
실무에서는 다른 사용자가 깃허브 소스 코드의 Commit 없이 임의로 변경한 경우 ‘helm diff’로 확인할 수 있습니다. helm diff 명령어로 확인하지 않고 바로 업그레이드 작업을 진행하면 변경된 사항이 다시 이전 설정으로 원복되어 장애로 이어지는 사태를 미리 막을 수 있어 매우 유용합니다.
변경 사항을 확인하고 업그레이드 작업을 진행합니다.
(jerry-test:default)foo$ helm upgrade foo -f ci/values.yaml .
Release "foo" has been upgraded. Happy Helming!
NAME: foo
LAST DEPLOYED: Thu Nov 9 09:14:49 2023
NAMESPACE: default
STATUS: deployed
REVISION: 2
NOTES:
1. Get the application URL by running these commands:
export POD_NAME=$(kubectl get pods --namespace default -l "app.kubernetes.io/name=foo,app.kubernetes.io/instance=foo" -o jsonpath="{.items[0].metadata.name}")
export CONTAINER_PORT=$(kubectl get pod --namespace default $POD_NAME -o jsonpath="{.spec.containers[0].ports[0].containerPort}")
echo "Visit http://127.0.0.1:8080 to use your application"
kubectl --namespace default port-forward $POD_NAME 8080:$CONTAINER_PORT
새롭게 생성한 파드의 설정을 grep -A(after) 5 명령어로 확인하면 원하는 설정이 정상으로 반영되었습니다.
(jerry-test:default)foo$ k get pod foo-7d46f9cb5b-t67kd -oyaml |grep -i -A 5 resources
resources:
limits:
memory: 128Mi
requests:
cpu: 10m
memory: 128Mi
위와 같이 헬름 upgrade 작업 시 꼭 diff 명령어로 먼저 확인하는 습관을 들이면 사전에 장애를 많이 예방할 수 있습니다. 이번 장의 실습을 완료하였습니다. 관련 자원을 삭제합니다.
(jerry-test:default)foo$ helm ls helmNAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION foo default 2 2023-11-09 09:14:49.182849 +0900 KST deployed foo-0.1.0 0.1.0 (jerry-test:default)foo$ helm delete foo release "foo" uninstalled
헬름 리스트를 먼저 확인하고(ls) 리소스를 삭제합니다.
이번 장에서 헬름 Starter Packs와 헬름 Diff에 관하여 알아보았습니다.
해당 기술 블로그에 질문이 있으시면 언제든지 문의해 주세요. 직접 답변해 드립니다.
k8sqna@jennifersoft.com
1.헬름 Starter Packs 공식 홈페이지 : https://helm.sh/docs/topics/charts/#chart-starter-packs
2. 헬름 diff 공식 홈페이지 : https://github.com/databus23/helm-diff
