헬름 v2를 v3로 마이그레이션
이 가이드에서는 헬름 v2를 v3로 마이그레이션하는 방법을 보여준다. 헬름 v2가 설치되어 있어야 하며, 하나 이상의 클러스터에서 릴리스가 관리되어야 한다.
헬름 3 변경사항 개요
헬름 2 에서 3로의 변경사항 전체 목록은 FAQ 에 작성되어 있다. 다음은 마이그레이션 준비 및 작업간에 사용자가 알아야 할 몇 가지 변경 사항에 대한 요약이다:
- Tiller 제거:
- 클라이언트/서버 구조는 클라이언트/라이브러리 아키텍처로 대체됨 (
helm
바이너리만 해당) - 보안 서비스는 이제 사용자 단위로 제공됨 (쿠버네티스 사용자 클러스터 보안에 위임)
- 릴리스는 이제 클러스터 내의 시크릿으로 저장되고 릴리스 객체 메타 데이터도 변경됨
- 릴리스는 더 이상 Tiller 네임스페이스가 아니라 릴리스 네임스페이스 기반으로 유지됨
- 클라이언트/서버 구조는 클라이언트/라이브러리 아키텍처로 대체됨 (
- 차트 저장소 업데이트:
helm search
는 이제 로컬 저장소 검색과 헬름 허브에 대한 검색 쿼리를 모두 지원함
- 다음의 사양 변경에 대하여 차트 apiVersion 이 "v2"로 증가:
- 동적으로 연결된 차트 의존성이
Chart.yaml
로 이동됨 (requirements.yaml
제거되고, 요구사항(requirements) --> 의존성(dependencies)으로 변경) - 라이브러리 차트(헬퍼/공통 차트)를 동적으로 연결된 차트 의존성으로 추가 가능
- 차트를
application
또는library
차트로 정의하는type
메타 데이터 필드를 가짐. 기본값은 application이며 렌더링 및 설치 가능하다는 의미 - 헬름 2 차트 (apiVersion=v1) 도 여전히 설치 가능함
- 동적으로 연결된 차트 의존성이
- XDG 디렉토리 사양 추가:
- 헬름 홈이 제거되고 구성 파일 저장을 위한 XDG 디렉토리 사양으로 대체
- 헬름 초기화 불필요
helm init
와helm home
명령어 제거
- 추가 변경 사항:
- 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은 무제한)
- delete --> uninstall : 기본적으로 모든 릴리스 기록 제거
(예전에는
- 헬름 3 Go 라이브러리는 많은 변경을 거쳤으며, 헬름 2 라이브러리와는 호환되지 않음
- 릴리스 바이너리가 이제
get.helm.sh
에서 호스팅됨
- Helm 설치/설정 단순화:
마이그레이션 사용 사례
마이그레이션 사용 사례는 다음과 같다:
동일 클러스터를 관리하는 헬름 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 구성과는 독립적이다. 이것은 동일한 시스템에 두 버전이 설치된 경우에만 적용된다.
- v2 및 v3 릴리스 (이력) 저장소는 서로 독립적이다. 변경 사항으로는
스토리지용 쿠버네티스 리소스와, 리소스에 포함된 릴리스 객체 메타 데이터가 있다.
릴리스는 또한 Tiller 네임스페이스를 사용하는 대신 사용자별 네임스페이스에
있게 된다 (예: v2의 기본 Tiller 네임스페이스는 kube-system).
v2는 Tiller 네임스페이스 및
헬름 v2 에서 Helm v3 로 마이그레이션:
- 이 사용 사례는 헬름 v3 에서 기존 헬름 v2 릴리스를 관리하려는 경우에 적용된다.
- 헬름 v2 클라이언트에 대해서는 다음과 같은 부분에 유의해야 한다:
- 헬름 v2 클라이언트 1개에서 다수의 쿠버네티스 클러스터 관리 가능
- 클러스터에 대해 헬름 v2 클라이언트 1 개가 여러 개의 Tiller 인스턴스에 연결 가능
- 이는 릴리스가 Tiller 및 해당 네임스페이스에 의해 클러스터에 배치되므로 마이그레이션 할 때 이를 알고 있어야 한다는 것을 의미한다. 따라서 헬름 v2 클라이언트 인스턴스에서 관리하는 각 클러스터 및 각 Tiller 인스턴스에 대한 마이그레이션을 알고 있어야 한다.
- 권장되는 데이터 마이그레이션 절차는 다음과 같다:
- v2 데이터 백업
- 헬름 v2 구성 마이그레이션
- 헬름 v2 릴리스 마이그레이션
- 헬름 v3가 모든 헬름 v2 데이터(헬름 v2 클라이언트 인스턴스의 모든 클러스터 및 Tiller 인스턴스에 대한)를 예상한대로 잘 관리한다고 확신할 경우, 헬름 v2 데이터 소거
- 마이그레이션 과정은 헬름 v3 2to3 플러그인으로 자동화된다.