쿠버네티스는 container orchestration 으로 컨테이너를 쉽고 빠르게 배포,관리 해주는 툴이다. 쿠버네티스는 컨테이너화된 어플리케이션을 쉽게 배포할 수 있다.

이런 쿠버네티스를 활용하기 위해서는 가장 먼저 yaml 파일을 작성해야한다. 쿠버네티스에 오브젝트를 정의하고 생성할때 yaml 파일 형식을 활용하기 때문이다.
쿠버네티스를 통해 어플리케이션을 배포하기 위해서는 많은 오브젝트가 필요한데, 대표적으로 deployment, pod, configmap, secret, service, persistent volume, persistent volume claim 등이 있다.

위와 같은 리소르를 다루는데 활용된느 yaml 파일을 관리하는 것은 매우 반복적이고 지루한 작업이다.

어플리케이션을 배포하다 보면 비슷한 틀과 내용을 공유하고, configuration만 일부 변경하면 되는데, 어플리케이션마다 모두 yaml 파일을 만들어줘야 하다보니 매우 번거롭다.

하지만 개발자는 항상 불편함을 개선하는 사람들...이를 편하게 만든 것이 helm이다.helm은 쿠버네티스에서 어플리케이션을 쉽게 배포하기 위해 사용되는 대표적인 패키징 툴이다.

helm을 이용하면 어플리케이션을 쿠버네티스에 쉽게 설치할 수 있고 helm-chart 는 쿠버네티스의 리소스를 하나로 묶은 패키지에 해당한다( 이것도 yaml ).
helm으로 차트를 관리하는 목적은 여러개의 yaml 파일을 쉽게 관리하기 위해서 이다.

그렇다면 본격적으로 helm,helm chart에 대해 알아보자

helm, helm-chart 란 무엇인가??

helm 은 쿠버네티스의 패키지 매니저다. 여기서 패키지는 쿠버네티스 리소스를 하나로 묶은 helm chart를 의미한다.

🙋 패키지 매니저가 뭔데?
🤖 Mac의 brew, Node의 npm 같은거.

그리고 helm chard는 yaml 파일의 묶음으로 이 묶음을 public or private registry에 push 해두고 helm 명령어를 활용해 helm chart 를 설치하여 쿠버네티스 리소스를 배포할 수 있다.

🙋 아까 리소스 말해줬는데, 그게 각각 다 뭔데??
🤖

• service : pod를 외부 IP에 노출 시키기 위해
• deployment : pod를 관리하기 위해
• statefulset: database와 같은 어플리케이션을 위해
• configMap : external config 설정을 위해
• secret : credential 같은 secret 정보를 저장하기 위해

원래는 이런 오브젝트를 생성하기 위해서는 각각의 yaml을 생성해줘야한다. 그리고 위와같은 yaml을 사전에 정의해두고 패키징 한 뒤, 쿠버네티스 클러스터에 어플리케이션을 배포할때 위와같은 오브젝트를 쉽게 배포하기 위해 패키징한게 helm chart 다.

정리하자면, helm chart 는 쿠버네티스 리소스를 정의해둔 yaml 파일의 묶음(패키지)이다. helm는 이런 패키지를 쉽게 관리할 수 있는 툴이다.

helm의 기능은 어떤게 있나?

template engine

여러개의 ms를 개발한다고 가정하면, 이를 배포하는데 사용하는 yaml 파일은 거의 똑같은 구조로 작성돼 리소스를 정의하고 있을 것이다.

만약 helm이 없다면, 각 ms 마다 필요한 오브젝트에 대한 yaml을 개별로 관리해야한다. 하지만 helm 을 사용하면 공통적인 yaml 구조로 helm chart 를 만들고, 그 구조에서 value 만 수정해다며 ms 배포할 때 재사용 할 수 있다!!

이를 value injection이라고 하는데, values.yaml 파일을 만들어 템플릿에 override 하는 방법도 있고, helm 으로 실행할 때 set flag를 cli와 함께 사용할 수 있다.

yaml 사용하는 경우
helm i -f values.yaml -f override.yaml myredis ./redis
--set flag 사용시
helm i --set name=prod myredis ./redis

하나의 차트, 여러 환경

ms를 구현해두고 각각 다른 환경에 배포하는 경우 하나의 helm chart 를 작성하면 여러 환경에 배포할 수 있다.

release management , Tiller

helm 버전 2,3 의 가장 큰 차이점은 Tiller가 삭제된 것이다. 갑자기?? 싶겠지만 release management를 다루기 위해서임을 이해해달라.. 먼저 Tiller는 helm chart 를 통합 관리와 설치를 위해 활용되는 특별한 pod다. Tiller는 기존에 설치한 Chart를 통합 관리하고 이에 따라 아래와 같은 release management 기능을 Tiller를 통해 실행할 수 있도록 해준다.

helm history {RELEASE NAME} -n {NAMESPACE NAME}
을 통해 배포돼왔던 release들의 history를 확인한 뒤,
helm rollback {RELEASE NAME} {REVISTION NUMBER}
을 통해 이전의 버전으로 rollback 할 수 있다.

또한 helm upgrade를 통해 helm 차트 변동사항을 release에 적용할 수 있다.
helm upgrade {RELEASE NAME} <차트경로> -n {NAMESPACE NAME}

하지만 버전2의 Tiller를 사용하는 방식은 쿠버 1.6부터 적용된 RBAC를 위해 Tiller에 cluster-admin 을 부여하며 너무 많은 권한을 Tiller가 가져서 보안문제가 발생하게 됐다.

🙋 RBAC 권한이 뭡니까?
🤖 사용자에게 리소스에 대한 액세스 권한 부여 여부를 결정하기 위해 역할과 권한을 정의하는 액세스 제어 메커니즘

이런 문제를 방지하기 위해 Tiller가 아닌 쿠버네티스 API를 통해 설치된 helm chart들을 쿠버네티스 그 자체에 저장하게 된다.

또한 chart를 설치하는 RBAC 권한은 사용자가 사용한 kubeconfig 를 활용하는 방식으로 수정됐다. 따라서 좀더 직관적으로 변했고 Cluster관리자들은 release가 클러스터에 기록 되는 동안 유저의 접근 권한을 제어할 수 있고 나버지 Helm기능은 전과 같이 사용 하면서 prod 환경에서 더 안심하고 Helm 을 사용할 수 있게 된다!