Helm 차트

1 개요

Charts

차트

https://helm.sh/docs/topics/charts/

---

Helm은 차트라는 패키징 형식을 사용합니다. 차트는 관련된 일련의 Kubernetes 리소스를 설명하는 파일 모음입니다. 단일 차트는 memcached pod과 같은 간단한 것을 배포하는 데 사용되거나 HTTP 서버, 데이터베이스, 캐시 등과 같은 전체 웹앱 스택을 포함한 복잡한 것을 배포하는 데 사용될 수 있습니다.

차트는 특정 디렉토리 트리 구조로 배치된 파일로 생성됩니다. 이러한 파일은 버전이 지정된 아카이브로 패키징되어 배포될 수 있습니다.

설치하지 않고 게시된 차트의 파일을 다운로드하고 싶다면 helm pull chartrepo/chartname 명령어를 사용하여 할 수 있습니다.

이 문서는 차트 형식을 설명하고 Helm을 사용하여 차트를 작성하는 기본적인 지침을 제공합니다.

2 차트 파일 구조

차트는 디렉토리 내의 파일 모음으로 구성됩니다. 디렉토리 이름은 차트의 이름(버전 정보 제외)입니다. 따라서 WordPress를 설명하는 차트는 wordpress/ 디렉토리에 저장됩니다.

이 디렉토리 내부에서, Helm은 다음과 같은 구조를 기대합니다:

wordpress/
  Chart.yaml          # 차트에 대한 정보를 포함하는 YAML 파일
  LICENSE             # 선택사항: 차트에 대한 라이선스를 포함하는 일반 텍스트 파일
  README.md           # 선택사항: 휴먼리더블 README 파일
  values.yaml         # 이 차트의 기본 설정 값
  values.schema.json  # 선택사항: values.yaml 파일에 구조를 부여하기 위한 JSON 스키마
  charts/             # 이 차트가 의존하는 차트를 포함하는 디렉토리
  crds/               # 커스텀 리소스 정의
  templates/          # values와 결합될 때 유효한 Kubernetes 매니페스트 파일을 생성하는 템플릿 디렉토리
  templates/NOTES.txt # 선택사항: 짧은 사용법 노트를 포함하는 일반 텍스트 파일

Helm은 charts/, crds/, templates/ 디렉토리와 나열된 파일 이름을 예약하여 사용합니다. 다른 파일은 그대로 유지됩니다.

3 Chart.yaml 파일

Chart.yaml 파일은 차트에 필수입니다. 이 파일은 다음 필드들을 포함합니다:

apiVersion: 차트 API 버전 (필수)
name: 차트의 이름 (필수)
version: SemVer 2 버전 (필수)
kubeVersion: 호환되는 Kubernetes 버전의 SemVer 범위 (선택)
description: 이 프로젝트에 대한 한 문장 설명 (선택)
type: 차트의 유형 (선택)
keywords:
  - 이 프로젝트와 관련된 키워드 목록 (선택)
home: 이 프로젝트의 홈페이지 URL (선택)
sources:
  - 이 프로젝트의 소스 코드 URL 목록 (선택)
dependencies: # 차트 요구사항 목록 (선택)
  - name: 차트의 이름 (예: nginx)
    version: 차트의 버전 (예: "1.2.3")
    repository: (선택) 리포지토리 URL (예: "https://example.com/charts") 또는 별칭 ("@repo-name")
    condition: (선택) 차트를 활성화/비활성화하는 데 사용되는 boolean으로 해결되는 YAML 경로 (예: subchart1.enabled)
    tags: # (선택)
      - 태그는 차트를 그룹화하여 함께 활성화/비활성화하는 데 사용될 수 있음
    import-values: # (선택)
      - ImportValues는 소스 값을 상위 키에 매핑하여 가져오는 항목을 보유합니다. 각 항목은 문자열 또는 자식/부모 하위 목록 항목의 쌍일 수 있습니다.
    alias: (선택) 차트에 사용될 별칭. 동일한 차트를 여러 번 추가해야 할 때 유용함
maintainers: # (선택)
  - name: 유지관리자의 이름 (각 유지관리자에 대해 필수)
    email: 유지관리자의 이메일 (각 유지관리자에 대해 선택)
    url: 유지관리자에 대한 위한 URL (각 유지관리자에 대해 선택)
icon: 아이콘으로 사용할 SVG 또는 PNG 이미지의 URL (선택)
appVersion: 이 차트가 포함하는 앱의 버전 (선택). SemVer일 필요는 없음. 따옴표 권장.
deprecated: 이 차트가 지원중단되었는지 여부 (선택, boolean)
annotations:
  example: 이름별로 키가 지정된 어노테이션 목록 (선택)

v3.3.2 버전부터 추가 필드는 허용되지 않습니다. 권장되는 방법은 annotations에 커스텀 메타데이터를 추가하는 것입니다.

3.1 차트와 버전 관리

모든 차트에는 버전 번호가 있어야 합니다. 버전은 SemVer 2 표준을 따라야 합니다. Helm Classic과 달리, Helm v2 및 이후 버전에서는 버전 번호를 릴리스 마커로 사용합니다. 리포지토리의 패키지는 이름과 버전으로 식별됩니다.

예를 들어, 버전 필드가 version: 1.2.3로 설정된 nginx 차트는 다음과 같이 명명됩니다:

nginx-1.2.3.tgz

더 복잡한 SemVer 2 이름도 지원되며, 예를 들어 version: 1.2.3-alpha.1+ef365와 같은 이름도 사용할 수 있습니다. 그러나 비-SemVer 이름은 시스템에서 명시적으로 금지됩니다.

참고: Helm Classic과 Deployment Manager는 차트와 관련하여 GitHub 지향적이었지만, Helm v2 및 이후 버전에서는 GitHub이나 Git을 요구하지 않습니다. 따라서 Git SHA를 버전 관리에 사용하지 않습니다.

Chart.yaml 내부의 version 필드는 CLI를 포함한 많은 Helm 도구에서 사용됩니다. 패키지를 생성할 때 helm package 명령어는 Chart.yaml에서 찾은 버전 번호를 패키지 이름의 토큰으로 사용합니다. 시스템은 차트 패키지 이름의 버전 번호가 Chart.yaml의 버전 번호와 매치한다고 가정합니다. 이 가정을 충족하지 않으면 오류가 발생합니다.

3.2 apiVersion 필드

Helm 3 이상이 필요한 Helm 차트의 경우 apiVersion 필드는 v2여야 합니다. 이전 Helm 버전을 지원하는 차트는 apiVersion이 v1로 세팅되어 있으며, 여전히 Helm 3으로 설치가능합니다.

v1에서 v2로의 변경사항:

• 차트 의존성을 정의하는 dependencies 필드가 추가되었습니다. v1 차트에서는 이 필드가 별도의 requirements.yaml 파일에 있었습니다(차트 의존성 참조).
• 차트 유형을 구분하는 type 필드가 추가되었습니다. 이를 통해 애플리케이션 차트와 라이브러리 차트를 구별할 수 있습니다(차트 유형 참조).

3.3 appVersion 필드

appVersion 필드는 version 필드와 관련이 없습니다. 이 필드는 애플리케이션의 버전을 지정하는 방법입니다. 예를 들어, drupal 차트는 appVersion: "8.2.1"을 가질 수 있으며, 이는 기본적으로 포함된 Drupal 버전이 8.2.1임을 나타냅니다. 이 필드는 정보 제공용이며 차트 버전 계산에는 영향을 미치지 않습니다. 버전을 따옴표로 묶는 것이 매우 권장됩니다. 이는 YAML 파서가 버전 번호를 문자열로 처리하도록 강제합니다. 따옴표 없이 두면 일부 경우에 파싱 문제가 발생할 수 있습니다. 예를 들어, YAML은 1.0을 부동 소수점 값으로 해석하고, 1234e10 같은 git 커밋 SHA를 과학적 표기법으로 해석합니다.

Helm v3.5.0부터 helm create 명령어는 기본적으로 appVersion 필드를 따옴표로 묶습니다.

3.4 kubeVersion 필드

선택적인 kubeVersion 필드는 지원되는 Kubernetes 버전에 대한 semver 제약조건을 정의할 수 있습니다. Helm은 차트를 설치할 때 버전 제약조건을 확인하고 클러스터가 지원되지 않는 Kubernetes 버전을 실행하는 경우 실패합니다.

버전 제약조건은 다음과 같이 공백으로 구분된 AND 비교로 구성될 수 있습니다.

>= 1.13.0 < 1.15.0

이 비교는 OR || 연산자로 결합될 수 있습니다. 예를 들어

>= 1.13.0 < 1.14.0 || >= 1.14.1 < 1.15.0

이 예시에서는 1.14.0 버전이 제외되는데, 이는 특정 버전의 버그로 인해 차트가 제대로 실행되지 않는 경우 유용할 수 있습니다.

=, !=, >, <, >=, <= 연산자를 사용하는 버전 제약조건 외에도 다음과 같은 축약 표기법이 지원됩니다:

• 폐쇄 구간에 대한 하이픈 범위: 1.1 - 2.3.4는 >= 1.1 <= 2.3.4와 동등합니다.
• 와일드카드 x, X, *: 1.2.x는 >= 1.2.0 < 1.3.0와 동등합니다.
• 틸드 범위 (패치 버전 변경 허용): ~1.2.3는 >= 1.2.3 < 1.3.0와 동등합니다.
• 캐럿 범위 (마이너 버전 변경 허용): ^1.2.3는 >= 1.2.3 < 2.0.0와 동등합니다.

지원되는 semver 제약조건에 대한 자세한 설명은 Masterminds/semver를 참조하십시오.

3.5 차트 지원중단

차트 리포지토리에서 차트를 관리할 때, 때로는 차트를 지원중단해야 할 필요가 있습니다. Chart.yaml의 선택적 필드인 deprecated를 사용하여 차트를 지원중단 상태로 표시할 수 있습니다. 리포지토리 내의 최신 버전의 차트가 지원중단된 것으로 표시되면, 해당 차트는 전체적으로 지원중단된 것으로 간주됩니다. 이후에 지원중단 상태로 표시되지 않은 최신 버전을 게시함으로써 차트 이름을 다시 사용할 수 있습니다. 차트를 지원중단하는 워크플로우는 다음과 같습니다:

• 1. 차트의 Chart.yaml을 업데이트하여 차트를 지원중단 상태로 표시하고, 버전을 올립니다.
• 2. 새 차트 버전을 차트 리포지토리에 릴리스합니다.
• 3. 소스 리포지토리(예: git)에서 차트를 제거합니다.

3.6 차트 유형

type 필드는 차트의 유형을 정의합니다. application과 library의 두 가지 유형이 있습니다. 애플리케이션이 기본 유형이며, 이는 완전히 조작할 수 있는 표준 차트입니다. 라이브러리 차트는 차트 빌더에 유틸리티나 함수를 제공합니다. 라이브러리 차트는 설치할 수 없으며 일반적으로 리소스 객체를 포함하지 않는다는 점에서 애플리케이션 차트와 다릅니다.

참고: 애플리케이션 차트는 라이브러리 차트로 사용할 수 있습니다. type을 library로 세팅하면 이 차트는 라이브러리 차트로 렌더링되어 모든 유틸리티와 함수를 활용할 수 있습니다. 차트의 모든 리소스 객체는 렌더링되지 않습니다.

4 차트 LICENSE, README, NOTES

차트는 설치, 설정, 사용법, 라이선스에 대한 파일을 포함할 수 있습니다.

LICENSE는 차트의 라이선스를 설명하는 일반 텍스트 파일입니다. 차트는 템플릿 내에 프로그래밍 로직을 포함할 수 있으므로, 이 파일은 설정 파일이 아닐 수 있습니다. 또한 차트로 설치되는 애플리케이션에 대한 별도의 라이선스가 필요할 수 있습니다.

README는 Markdown 형식(README.md)으로 작성되어야 합니다. 일반적으로 다음 내용을 포함해야 합니다:

• 차트가 제공하는 애플리케이션 또는 서비스에 대한 설명
• 차트를 실행하기 위한 전제조건 또는 요구사항
• values.yaml 파일의 옵션과 기본 값에 대한 설명
• 설치 또는 설정과 관련된 기타 정보

차트를 설명하는 Hub와 다른 사용자 인터페이스에서는 이러한 세부 정보를 README.md 파일에서 가져옵니다.

차트에는 설치 후 또는 릴리스 상태를 볼 때 출력되는 짧은 일반 텍스트 templates/NOTES.txt 파일도 포함될 수 있습니다. 이 파일은 template으로 평가되며, 차트 릴리스와 관련된 사용법 노트, 다음 단계, 기타 정보를 표시하는 데 사용될 수 있습니다. 예를 들어, 데이터베이스에 연결하거나 웹 UI에 접근하는 방법에 대한 지침을 제공할 수 있습니다. 이 파일은 helm install 또는 helm status를 실행할 때 STDOUT에 출력되므로, 내용을 간결하게 작성하고 자세한 내용은 README 파일을 참조하도록 하는 것이 좋습니다.

5 차트 의존성

Helm에서는 하나의 차트가 여러 다른 차트에 의존할 수 있습니다. 이러한 의존성은 Chart.yaml 파일의 dependencies 필드를 사용하여 동적으로 연결하거나 charts/ 디렉토리로 가져와 수동으로 관리할 수 있습니다.

5.1 dependencies 필드로 의존성 관리

현재 차트에서 필요한 차트는 dependencies 필드의 리스트로 정의됩니다.

dependencies:
  - name: apache
    version: 1.2.3
    repository: https://example.com/charts
  - name: mysql
    version: 3.2.1
    repository: https://another.example.com/charts

• name 필드는 원하는 차트의 이름입니다.
• version 필드는 원하는 차트의 버전입니다.
• repository 필드는 차트 리포지토리의 전체 URL입니다. 또한 로컬에 해당 리포지토리를 추가하려면 helm repo add를 사용해야 합니다.
• 리포지토리 이름을 URL 대신 사용할 수도 있습니다.

$ helm repo add fantastic-charts https://charts.helm.sh/incubator

dependencies:
  - name: awesomeness
    version: 1.0.0
    repository: "@fantastic-charts"

의존성을 정의한 후에는 helm dependency update 명령어를 실행하여 의존성 파일을 사용해 지정된 모든 차트를 charts/ 디렉토리에 다운로드할 수 있습니다.

$ helm dep up foochart
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "local" chart repository
...Successfully got an update from the "stable" chart repository
...Successfully got an update from the "example" chart repository
...Successfully got an update from the "another" chart repository
Update Complete. Happy Helming!
Saving 2 charts
Downloading apache from repo https://example.com/charts
Downloading mysql from repo https://another.example.com/charts

helm dependency update가 차트를 가져오면 charts/ 디렉토리에 차트 아카이브로 저장됩니다. 따라서 위 예제에서는 charts 디렉토리에 다음 파일들이 생성됩니다:

charts/
  apache-1.2.3.tgz
  mysql-3.2.1.tgz

5.1.1 dependencies에서 Alias 필드

위에서 언급한 다른 필드 외에도, 각 요구사항 항목에는 선택적 필드인 alias(별칭)가 포함될 수 있습니다.

의존성 차트에 대한 별칭을 추가하면 alias를 새 의존성의 이름으로 사용하여 의존성에 차트를 추가할 수 있습니다.

차트를 다른 이름으로 접근해야 할 경우 alias를 사용할 수 있습니다.

# parentchart/Chart.yaml

dependencies:
  - name: subchart
    repository: http://localhost:10191
    version: 0.1.0
    alias: new-subchart-1
  - name: subchart
    repository: http://localhost:10191
    version: 0.1.0
    alias: new-subchart-2
  - name: subchart
    repository: http://localhost:10191
    version: 0.1.0

위 예시에서는 parentchart에 대해 다음과 같은 3개의 의존성을 얻을 수 있습니다:

subchart
new-subchart-1
new-subchart-2

수동으로 이를 달성하는 방법은 charts/ 디렉토리에 동일한 차트를 여러 번 다른 이름으로 복사/붙여넣기 하는 것입니다.

5.1.2 dependencies에서 Tags와 Condition 필드

위에서 언급한 다른 필드 외에도 각 요구사항 항목에는 선택적으로 tags와 condition 필드를 포함할 수 있습니다.

모든 차트는 기본적으로 로드됩니다. tags 또는 condition 필드가 있으면 평가되고 적용된 차트의 로딩을 제어하는 데 사용됩니다.

Condition - condition 필드는 하나 이상의 YAML 경로(쉼표로 구분됨)를 포함합니다. 이 경로가 상위 부모의 값에 존재하고 불리언 값으로 해석되면 차트는 해당 불리언 값에 따라 활성화되거나 비활성화됩니다. 목록에서 발견된 첫 번째 유효 경로만 평가되며 경로가 없으면 condition은 아무 효과가 없습니다.

Tags - tags 필드는 이 차트와 연결할 레이블의 YAML 목록입니다. 상위 부모의 값에서 태그가 있는 모든 차트는 태그와 불리언 값을 지정하여 활성화하거나 비활성화할 수 있습니다.

parentchart/Chart.yaml

dependencies:
  - name: subchart1
    repository: http://localhost:10191
    version: 0.1.0
    condition: subchart1.enabled,global.subchart1.enabled
    tags:
      - front-end
      - subchart1
  - name: subchart2
    repository: http://localhost:10191
    version: 0.1.0
    condition: subchart2.enabled,global.subchart2.enabled
    tags:
      - back-end
      - subchart2

parentchart/values.yaml

subchart1:
  enabled: true
tags:
  front-end: false
  back-end: true

위 예제에서 front-end 태그가 있는 모든 차트는 비활성화됩니다. 그러나 subchart1.enabled 경로가 부모의 값에서 true로 평가되므로 조건(condition)이 front-end 태그를 무시하고 subchart1이 활성화됩니다.

subchart2는 back-end 태그가 있고 해당 태그가 true로 평가되므로 subchart2는 활성화됩니다. 또한 subchart2에는 조건(condition)이 지정되어 있지만 부모의 값에 해당하는 경로와 값이 없으므로 해당 조건은 아무 효과가 없습니다.

5.1.2.1 Tags, Conditions와 함께 CLI 사용

--set 매개변수는 태그와 조건 값을 변경하기 위해 사용될 수 있습니다.

helm install --set tags.front-end=true --set subchart2.enabled=false

5.1.2.2 Tags, Condition 해결

• 조건(값에서 설정된 경우)은 항상 태그보다 우선합니다. 존재하는 첫 번째 조건 경로가 우선되며, 해당 차트에 대한 이후 조건들은 무시됩니다.
• 태그는 '차트의 태그 중 하나라도 true이면 차트를 활성화한다'로 평가됩니다.
• 태그 및 조건 값은 최상위 부모의 값에 설정되어야 합니다.
• values 파일의 최상위 키에 tags: 키가 있어야 합니다. 글로벌 및 중첩된 tags: 테이블은 현재 지원되지 않습니다.

5.1.3 dependencies를 통해 자식 값 임포트

어떤 경우에는 자식 차트의 값이 부모 차트로 전파되어 공통 기본값으로 공유되는 것이 바람직할 수 있습니다. exports 형식을 사용하면 사용자가 설정할 수 있는 값을 도구가 추후에 검토할 수 있게 되는 추가적인 이점이 있습니다.

가져올 값을 포함하는 키는 YAML 목록에서 import-values 필드의 부모 차트 dependencies에 지정할 수 있습니다. 목록의 각 항목은 자식 차트의 exports 필드에서 가져온 키입니다.

exports 키에 포함되지 않은 값을 가져오려면 child-parent 형식을 사용합니다. 두 형식의 예시는 아래에 설명되어 있습니다.

6 템플릿과 Values

6.5 스키마 파일

때로는 차트 유지관리자가 값(values)에 구조를 정의하고 싶어할 수 있습니다. 이는 values.schema.json 파일에 스키마를 정의하여 수행할 수 있습니다. 스키마는 JSON Schema로 표현되며, 다음과 같이 생겼습니다:

{
  "$schema": "https://json-schema.org/draft-07/schema#",
  "properties": {
    "image": {
      "description": "Container Image",
      "properties": {
        "repo": {
          "type": "string"
        },
        "tag": {
          "type": "string"
        }
      },
      "type": "object"
    },
    "name": {
      "description": "Service name",
      "type": "string"
    },
    "port": {
      "description": "Port",
      "minimum": 0,
      "type": "integer"
    },
    "protocol": {
      "type": "string"
    }
  },
  "required": [
    "protocol",
    "port"
  ],
  "title": "Values",
  "type": "object"
}

이 스키마는 값(values)을 검증하기 위해 적용됩니다. 다음 명령어들이 실행될 때 검증이 이루어집니다:

• helm install
• helm upgrade
• helm lint
• helm template

이 스키마 요구사항을 충족하는 values.yaml 파일 예시는 다음과 같습니다:

name: frontend
protocol: https
port: 443

스키마는 최종 .Values 객체에 적용되며, 단순히 values.yaml 파일에만 적용되는 것은 아닙니다. 이는 아래와 같이 --set 옵션을 사용하여 차트를 설치하면 다음 yaml 파일이 유효함을 의미합니다.

name: frontend
protocol: https

helm install --set port=443

또한, 최종 .Values 객체는 모든 하위 차트 스키마에 대해 검증됩니다. 이는 상위 차트에서 하위 차트의 제한을 회피할 수 없음을 의미합니다. 이 역방향도 마찬가지로 작동합니다. 하위 차트의 values.yaml 파일에서 요구사항이 충족되지 않은 경우, 상위 차트는 유효하기 위해 해당 제약사항을 만족해야 합니다.

6.6 참고자료

템플릿 작성, 값 설정, 스키마 파일 작업에 있어 도움이 되는 여러 표준 참고 자료가 있습니다.

• Go 템플릿
• 부가 템플릿 함수
• YAML 형식
• JSON 스키마

7 커스텀 리소스 정의(CRD)

Kubernetes는 새로운 유형의 Kubernetes 객체를 선언할 수 있는 메커니즘을 제공합니다. CustomResourceDefinitions(CRD)를 사용하여 Kubernetes 개발자는 커스텀 리소스 타입을 선언할 수 있습니다.

Helm 3에서는 CRD를 특별한 종류의 객체로 취급합니다. CRD는 차트의 나머지 부분이 설치되기 전에 설치되며 몇 가지 제한사항이 있습니다.

CRD YAML 파일은 차트 내부의 crds/ 디렉토리에 배치해야 합니다. 여러 CRD는 YAML 시작 및 종료 마커로 구분하여 동일한 파일에 배치할 수 있습니다. Helm은 CRD 디렉토리의 모든 파일을 Kubernetes에 로드하려고 시도합니다.

CRD 파일은 템플릿화할 수 없습니다. 즉, 단순한 YAML 문서여야 합니다.

Helm이 새 차트를 설치할 때, CRD를 업로드하고 API 서버에 의해 CRD가 사용가능해질 때까지 잠시 대기한 후 템플릿 엔진을 시작하여 나머지 차트를 렌더링하고 이를 Kubernetes에 업로드합니다. 이러한 순서 때문에 CRD 정보는 Helm 템플릿의 .Capabilities 객체에 제공되며, Helm 템플릿은 CRD에서 선언된 객체의 새 인스턴스를 만들 수 있습니다.

예를 들어, 차트에 crds/ 디렉토리에 대한 CronTab CRD가 있는 경우 templates/ 디렉토리에서 CronTab 종류의 인스턴스를 만들 수 있습니다:

crontabs/
  Chart.yaml
  crds/
    crontab.yaml
  templates/
    mycrontab.yaml

crontab.yaml 파일에는 템플릿 지시어 없이 CRD가 포함되어야 합니다:

kind: CustomResourceDefinition
metadata:
  name: crontabs.stable.example.com
spec:
  group: stable.example.com
  versions:
    - name: v1
      served: true
      storage: true
  scope: Namespaced
  names:
    plural: crontabs
    singular: crontab
    kind: CronTab

그런 다음 템플릿 mycrontab.yaml은 새 CronTab을 다음과 같이 생성할 수 있습니다(일반적인 템플릿 사용):

apiVersion: stable.example.com
kind: CronTab
metadata:
  name: {{ .Values.name }}
spec:
   # ...

Helm은 CronTab 종류가 설치되어 Kubernetes API 서버에서 사용가능해질 때까지 기다렸다가 templates/ 내의 항목들을 설치합니다.

7.1 CRD 제한사항

다른 대부분의 Kubernetes 객체와 달리, CRD는 전역적으로 설치됩니다. 이 때문에 Helm은 CRD를 관리할 때 매우 신중한 접근방식을 취합니다. CRD는 다음과 같은 제한사항이 적용됩니다:

• CRD는 절대 재설치되지 않습니다. Helm이 crds/ 디렉토리에 있는 CRD가 이미 존재한다고 판단하면(버전과 관계없이), Helm은 설치 또는 업그레이드를 시도하지 않습니다.
• CRD는 업그레이드 또는 롤백 시 설치되지 않습니다. Helm은 설치 작업에서만 CRD를 생성합니다.
• CRD는 절대 삭제되지 않습니다. CRD를 삭제하면 클러스터의 모든 네임스페이스에서 해당 CRD의 모든 내용이 자동으로 삭제됩니다. 따라서 Helm은 CRD를 삭제하지 않습니다.

운영자는 CRD를 업그레이드하거나 삭제할 때 수동으로 수행하고 매우 신중하게 처리해야 합니다.

8 헬름을 사용한 차트 관리

helm 도구는 차트 작업을 위해 여러 명령어를 제공합니다.

새 차트를 생성할 수 있습니다:

$ helm create mychart
Created mychart/

차트를 편집한 후, helm을 사용하여 차트를 아카이브로 패키징할 수 있습니다:

$ helm package mychart
Archived mychart-0.1.-.tgz

또한 helm을 사용하여 차트의 형식이나 정보에 문제가 있는지 확인할 수 있습니다:

$ helm lint mychart
No issues found

9 차트 리포지토리

차트 리포지토리는 하나 이상의 패키지 차트를 보유한 HTTP 서버입니다. helm을 사용하여 로컬 차트 디렉토리를 관리할 수 있지만, 차트를 공유할 때 선호되는 메커니즘은 차트 리포지토리입니다.

YAML 파일과 tar 파일을 제공하고 GET 요청에 응답할 수 있는 모든 HTTP 서버는 리포지토리 서버로 사용될 수 있습니다. 헬름 팀은 Google Cloud Storage와 웹사이트 모드가 활성화된 S3를 포함한 일부 서버를 테스트했습니다.

리포지토리는 제공하는 모든 패키지 목록과 이러한 패키지를 검색하고 검증할 수 있는 메타데이터가 포함된 특수 파일인 index.yaml의 존재로 특징지어집니다.

클라이언트 측에서는 helm repo 명령어로 리포지토리를 관리합니다. 그러나 헬름은 원격 리포지토리 서버에 차트를 업로드하는 도구를 제공하지 않습니다. 이는 구현 서버에 상당한 요구사항을 추가하고, 리포지토리 설정의 장벽을 높일 수 있기 때문입니다.

10 차트 스타터 팩

helm create 명령어는 선택적인 --starter 옵션을 사용하여 "스타터 차트"를 지정할 수 있습니다. 또한, --starter 옵션의 짧은 별칭으로 -p를 사용할 수 있습니다.

사용 예시:

helm create my-chart --starter starter-name
helm create my-chart -p starter-name
helm create my-chart -p /absolute/path/to/starter-name

스타터는 그냥 일반 차트지만 $XDG_DATA_HOME/helm/starters에 위치합니다. 차트 개발자로서, 스타터로 사용하기 위해 특별히 설계된 차트를 작성할 수 있습니다. 이러한 차트는 다음 사항을 염두에 두고 설계되어야 합니다:

• Chart.yaml은 생성기에 의해 덮어쓰여집니다.
• 사용자는 그러한 차트의 내용을 수정할 것으로 예상되므로, 사용자가 이를 어떻게 수정할 수 있는지에 대한 문서를 제공해야 합니다.
• 모든 <CHARTNAME>은 지정된 차트 이름으로 대체되어 스타터 차트를 템플릿으로 사용할 수 있습니다. 단, 일부 변수 파일에서는 제외됩니다. 예를 들어, vars 디렉토리나 특정 README.md 파일에서 사용되는 커스텀 파일에서는 <CHARTNAME>이 대체되지 않습니다. 추가적으로, 차트 설명은 상속되지 않습니다.