Helm
Helm이란?
일반적으로 Kubernetes를 사용해서 Container로 application 서비스를 제공하게 되면
관리자는 Deployment, Service, Volume 등
각종 다양한 kubernetes 리소스를 수십 개, 많게는 수백 개를 생성해서 관리해야 함.
그에 따라 yaml 파일 또한 매우 많아지니 이를 관리하기 위한 편리한 Tool이 필요했음.
그래서 등장한 것이 바로 Helm이라는 Tool임.
Helm은 Kubernetes Package Managing Tool로써
Linux의 yum, apt, Python의 pip, node.js의 npm의 역할과 비슷하게
Kubernetes Package 배포를 가능하게 해주는 Tool.
Deployment, Service, Volume, Namespace 등 리소스를 사용해서
복잡환 application 서비스를 구성을 완료했다면
운영서버, 테스트 서버 분리를 위해 혹은 업데이트를 해야 하는 경우
이러한 복잡한 구성을 다시 똑같이 배포해야 하는 경우가 있는데,
yaml파일을 다시 하나하나 실행시키면서 하기에는 너무 단순 노동이기도 하고,
중간에 실수로 빼먹는 yaml파일이 있어서 문제가 발생할 수도 있음.
하지만 helm을 사용하게 되면 완성이 되어있는 서비스 즉 Kuberentes 리소스를
모두 배포해주는 형태로 Packaging 한 뒤에
해당 Package를 사용해서 언제든지 한 줄의 커맨드로 완성된 application 서비스를 한 번에 배포할 수 있음.
Helm에서 이러한 Package를 Chart라고 부름.
Helm Chart란
Helm의 Package Format.
Chart는 Kubernetes에서 설치하고자 하는 리소스들의 설치 스크립트임.
Chart는 디렉터리 안에 있는 파일들의 집합으로 디렉터리 이름이 바로 Chart의 이름이 됨.
예를 들어 testChar라는 디렉터리 안에 char를 구성하는 파일들이 있다면
해당 Char의 이름은 testChar가 됨.
이러한 Helm Char는 Repository에 저장할 수 있음.
각 파일의 역할
Chart.yaml : 해당 Helm Chart에 대한 정보를 정의하는 yaml파일, Char이름, version 등을 정의함.
values.yaml : 해당 Helm Chart에서 사용하는 각종 값들의 정의에 대한 정보.
chart directory : Dependency를 가지는 Chart에 대한 정보가 담겨있음.
templates : Kubernetes에 배포될 application을 구성하는 정보인 Menifes File들이 정의되어 있는 디렉터리.
NOTES.txt : Chart를 설치 후 출력되는 내용을 정의..
*.yaml : 클러스터에 띄울 리소스 템플릿 파일들.
Helm Repository
Chart들이 저장되어있는 공간이며 Helm Repository를 통해
다양한 Char들을 공유할 수 있음
Git Hub, Docker Hub와 비슷한 역할을 함
종류
local : Helm client가 설치된 local repository. local에 생성한 패키지가 존재
incubator : stable 요건을 만족하지 못하는 차트들이 제공되는 repository, stable로 넘어갈 예정인 차트가 제공됨
stable : 안정 버전에 이른 차트가 존재하는 repository이며
안정된 보안 수준과 기본 설정값을 포함하는 등 일정 요건을 만족하는 차트만 제공됨
Helm Release
Git Hub, Docker Hub의 버전 관리와 마찬가지로
Helm도 배포된 서비스에 대한 version을 관리하기 위해
Helm Release라는 개념이 존재함.
일반적으로 yaml파일만 사용해서 kubernetes를 관리하면
여러 yaml파일에 변경 사항이 있으면 rollback 및 update가 힘들겠지만
Helm 은 Release가 있어서 버전 관리가 가능해지므로
update, rollback 관리가 수훨해짐.
또한 언제 update가 이루어졌는지 날짜 확인도 가능함.
Helm 설치
.sh 파일을 통한 설치
[ Helm 2.0 ]
curl https://raw.githubusercontent.com/helm/helm/master/scripts/get | bash
[ Helm 3.0 ]
curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 | bash
wget을 통한 직접 설치
[ Helm 2.0 ]
wget https://get.helm.sh/helm-v2.16.10-linux-amd64.tar.gz
tar xvzf helm-v2.16.10-linux-amd64.tar.gz
cd linux-amd64/
mv * /usr/local/bin/helm/
[ Helm 3.0 ]
wget https://get.helm.sh/helm-v3.3.0-linux-amd64.tar.gz
tar xvzf helm-v3.3.0-linux-amd64.tar.gz
cd linux-amd64/
mv * /usr/local/bin/helm/
참고) Helm v2 → Helm v3 변동사항
2019년 11월에 Helm version 3가 나오면서 많은 것들이 변경됨.
No more tiller
Tiller는 Server-side Component ( On Cluster ).
Helm v2 개발 당시에는 Kubernetes에 RBAC이 없었음.
Kubernetes 1.6 버전부터 RBAC이 기본으로 적용됨에 따라 Helm v3에서는 Tiller가 빠지게 됨.
Tiller는 Helm 릴리즈 정보나 Helm 상태 유지를 위해 중앙 Hub로도 사용되어왔음.
Helm v3에서는 Helm v2에서와 동일한 정보를 Kubernetes API Server로부터 직접 받아오고.
Charts를 Client-side로 렌더링하여 보다 Native 하고 단순하게 Kubernetes에서 동작하게 되었음.
Tiller가 빠짐으로써 보안 모델 또한 간소화되었음.
Helm 접근권한들은 이제 kubeconfig 파일을 활용하기 때문에 간단하게 주어짐.
따라서 Cluster 관리자들은 Release가 클러스터에 기록되는 동안 유저의 접근권한을
어느 레벨에서나 제한할 수 있으며 나머지의 Helm 기능은 전과 같이 사용할 수 있음.
Changes but tiller
Helm v2에서는 two-way strategic merge patch를 사용했었으며
마지막 적용한 Chart만 고려하기 때문에 Rollback 기능에 대한 필요성이 없었음.
Helm v2에서는 릴리즈 정보를 저장하기 위해 ConfigMap을 사용했었지만
v3에서는 대신 Secret이 사용되며 Helm의 동작에 굉장한 단순성을 얻을 수 있음.
Helm v3에서는 three-way strategic merge patch가 사용됨에 따라 Rollback 기능이 사용 가능해졌음.
Helm v3에서는 Release name에 대한 입력을 필요로 하게 되는데
이는 Uninstall 기능에서 사용 가능하며 자동으로 Namespace를 생성하지 않음.
Helm 사용
Repo 추가
helm repo add stable https://kubernetes-charts.storage.googleapis.com/
helm repo update
helm search repo stable로 추가된 stable 한 repo들 확인
Chart 설치
helm install <release-name> <chart dir>
[ 의존성 해결 ]
cd <stable or incubator>/<chart name>/
helm dependency update
Releases 리스트
helm list
Release 상태
helm status <release-name>
Chart 삭제
helm uninstall <release-name>
제 글을 복사할 시 출처를 명시해주세요.
글에 오타, 오류가 있다면 댓글로 알려주세요! 바로 수정하겠습니다!
'Kubernetes > Kubernetes 이론' 카테고리의 다른 글
Privileged Container (0) | 2020.09.20 |
---|---|
Kubernetes Private Registry image 사용법 (0) | 2020.09.20 |
Kubernetes Update (2) | 2020.08.23 |
Kubernetes Secret (0) | 2020.08.17 |
Kubernetes ConfigMap (0) | 2020.08.17 |