헬름 v2를 v3로 마이그레이션

이 가이드에서는 헬름 v2를 v3로 마이그레이션하는 방법을 보여준다. 헬름 v2가 설치되어 있어야 하며, 하나 이상의 클러스터에서 릴리스가 관리되어야 한다.

헬름 3 변경사항 개요

헬름 2 에서 3로의 변경사항 전체 목록은 FAQ 에 작성되어 있다. 다음은 마이그레이션 준비 및 작업간에 사용자가 알아야 할 몇 가지 변경 사항에 대한 요약이다:

  1. Tiller 제거:
    • 클라이언트/서버 구조는 클라이언트/라이브러리 아키텍처로 대체됨 (helm 바이너리만 해당)
    • 보안 서비스는 이제 사용자 단위로 제공됨 (쿠버네티스 사용자 클러스터 보안에 위임)
    • 릴리스는 이제 클러스터 내의 시크릿으로 저장되고 릴리스 객체 메타 데이터도 변경됨
    • 릴리스는 더 이상 Tiller 네임스페이스가 아니라 릴리스 네임스페이스 기반으로 유지됨
  2. 차트 저장소 업데이트:
    • helm search 는 이제 로컬 저장소 검색과 헬름 허브에 대한 검색 쿼리를 모두 지원함
  3. 다음의 사양 변경에 대하여 차트 apiVersion 이 "v2"로 증가:
    • 동적으로 연결된 차트 의존성이 Chart.yaml 로 이동됨 (requirements.yaml 제거되고, 요구사항(requirements) --> 의존성(dependencies)으로 변경)
    • 라이브러리 차트(헬퍼/공통 차트)를 동적으로 연결된 차트 의존성으로 추가 가능
    • 차트를 application 또는 library 차트로 정의하는 type 메타 데이터 필드를 가짐. 기본값은 application이며 렌더링 및 설치 가능하다는 의미
    • 헬름 2 차트 (apiVersion=v1) 도 여전히 설치 가능함
  4. XDG 디렉토리 사양 추가:
    • 헬름 홈이 제거되고 구성 파일 저장을 위한 XDG 디렉토리 사양으로 대체
    • 헬름 초기화 불필요
    • helm inithelm home 명령어 제거
  5. 추가 변경 사항:
    • Helm 설치/설정 단순화:
      • 헬름 클라이언트 (헬름 바이너리) 만 있으면 됨 (Tiller 불필요)
      • Run-as-is 패러다임
    • local 또는 stable 저장소는 기본적으로 미설정
    • crd-install 훅은 제거되고, 차트 내 모든 CRD가 정의되어 있고 차트 렌더링 전에 설치되는 crds 디렉토리로 대체됨
    • test-failure 훅 어노테이션 값은 제거되고, test-success는 사용 중단(deprecated). 대신 test 를 사용하자
    • 제거/교체/추가 된 명령어:
      • delete --> uninstall : 기본적으로 모든 릴리스 기록 제거 (예전에는 --purge 옵션이 필요했음)
      • fetch --> pull
      • home (제거됨)
      • init (제거됨)
      • install: 릴리스 이름 또는 --generate-name 인수 필요
      • inspect --> show
      • reset (제거됨)
      • serve (제거됨)
      • template: -x/--execute 인수의 이름이 -s/--show-only 로 변경
      • upgrade: 릴리스당 저장되는 최대 리비젼 수를 제한하는 인수 --history-max 추가됨 (0은 무제한)
    • 헬름 3 Go 라이브러리는 많은 변경을 거쳤으며, 헬름 2 라이브러리와는 호환되지 않음
    • 릴리스 바이너리가 이제 get.helm.sh 에서 호스팅됨

마이그레이션 사용 사례

마이그레이션 사용 사례는 다음과 같다:

  1. 동일 클러스터를 관리하는 헬름 v2 및 v3:

    • 이 사용 사례는 헬름 v2 를 단계적으로 제거하려는 경우에만 권장되며 v2로 배포한 릴리스를 관리하는 데 v3가 필요한 것은 아니다. 배포되는 모든 새 릴리스는 v3 에서 수행해야 하며, 기존에 v2 로 배포된 릴리스는 v2 에서만 업데이트/제거된다.
    • 헬름 v2 와 v3 는 같은 클러스터를 원활하게 관리할 수 있다. 헬름 버전들은 동일 또는 개별 시스템에 설치될 수 있다.
    • 만약 동일한 시스템에 헬름 v3를 설치하는 경우, 헬름 v2 클라이언트를 제거할 준비가 될 때까지 두 클라이언트 버전이 공존할 수 있도록 추가 작업을 수행해야 한다. 충돌을 피하기 위해 헬름 v3 바이너리의 이름을 바꾸거나 다른 폴더에 넣도록 한다.
    • 그밖에는 다음과 같은 구별에 따라 두 버전 간에 충돌이 발생하지 않는다.
      • v2 및 v3 릴리스 (이력) 저장소는 서로 독립적이다. 변경 사항으로는 스토리지용 쿠버네티스 리소스와, 리소스에 포함된 릴리스 객체 메타 데이터가 있다. 릴리스는 또한 Tiller 네임스페이스를 사용하는 대신 사용자별 네임스페이스에 있게 된다 (예: v2의 기본 Tiller 네임스페이스는 kube-system). v2는 Tiller 네임스페이스 및 TILLER 소유권 아래의 "ConfigMaps" 또는 "Secrets" 를 사용한다. v3는 사용자 네임스페이스에 있는 "Secrets" 과 helm 소유권을 사용한다. 릴리스는 v2 및 v3에서 모두 증가한다.
      • 유일한 문제는 쿠버네티스 클러스터 범위의 리소스(예: clusterroles.rbac)가 차트에 정의된 경우이다. 이런 경우 리소스가 충돌할 수 있으므로 네임스페이스에서 고유하더라도 v3 배포는 실패하게 된다.
      • v3 구성은 더이상 $HELM_HOME 을 사용하지 않고 대신 XDG 디렉토리 사양을 사용한다. 또한 필요에 따라 즉시 생성된다. 따라서 v2 구성과는 독립적이다. 이것은 동일한 시스템에 두 버전이 설치된 경우에만 적용된다.
  2. 헬름 v2 에서 Helm v3 로 마이그레이션:

    • 이 사용 사례는 헬름 v3 에서 기존 헬름 v2 릴리스를 관리하려는 경우에 적용된다.
    • 헬름 v2 클라이언트에 대해서는 다음과 같은 부분에 유의해야 한다:
      • 헬름 v2 클라이언트 1개에서 다수의 쿠버네티스 클러스터 관리 가능
      • 클러스터에 대해 헬름 v2 클라이언트 1 개가 여러 개의 Tiller 인스턴스에 연결 가능
    • 이는 릴리스가 Tiller 및 해당 네임스페이스에 의해 클러스터에 배치되므로 마이그레이션 할 때 이를 알고 있어야 한다는 것을 의미한다. 따라서 헬름 v2 클라이언트 인스턴스에서 관리하는 각 클러스터 및 각 Tiller 인스턴스에 대한 마이그레이션을 알고 있어야 한다.
    • 권장되는 데이터 마이그레이션 절차는 다음과 같다:
      1. v2 데이터 백업
      2. 헬름 v2 구성 마이그레이션
      3. 헬름 v2 릴리스 마이그레이션
      4. 헬름 v3가 모든 헬름 v2 데이터(헬름 v2 클라이언트 인스턴스의 모든 클러스터 및 Tiller 인스턴스에 대한)를 예상한대로 잘 관리한다고 확신할 경우, 헬름 v2 데이터 소거
    • 마이그레이션 과정은 헬름 v3 2to3 플러그인으로 자동화된다.

참조

  • 헬름 v3 2to3 플러그인
  • 2to3 플러그인 사용법을 예제와 함께 설명하는 블로그 게시글