헬름 기본사항(Helm Fundamentals)

헬름 + 쿠버네티스 가이드북은 Bharath Thippireddy의 Helm Kubernetes Packaging Manager for Developers and DevOps을 보고 작성되었습니다.

가이드북의 전체 목차 및 인덱싱은 헬름 + 쿠버네티스 가이드북 문서를 참고해주세요.

쿠버네티스 선언 파일

쿠버네티스는 기본적인 선언 파일을 통해서 작동하도록 구성할 수 있습니다. 하지만 여러 가지 한계가 있고 이에 따라서 쿠버네티스 패키지 매니저인 헬름을 사용해야 합니다. 여기서는 시나리오를 생각하고 어떤 한계가 있는지 알아볼 예정입니다.

1. 헬름을 사용하기 전 - 시나리오

2. 헬름을 사용하기 전 - 일관성 불일치 현상

3. 헬름을 사용하기 전 - 버전 관리 불가

4. 헬름을 사용하기 전후

헬름을 사용하기 전 - 시나리오

헬름에 대해서 배우기 전에 헬름 없이 쿠버네티스를 직접 다룰 때 발생하는 문제를 생각해볼 필요가 있습니다.

저희가 다음과 같은 마이크로서비스 응용프로그램을 만들고 있다고 생각해봅시다.

1. 제품에 대한 Deployment

2. 제품을 노출시키기 위한 Service

3. 제품에서 사용할 MySQL 서버에 대한 Deployment

4. 제품에서 사용할 MySQL 서버에서 사용할 ConfigMap

코드 레벨에서 구성한 사례는 다음과 같습니다.

• Service

  apiVersion: v1
  kind: Service
  metadata:
    name: product-app
    labels:
      app: product-app
  spec:
    type: NodePort
    ports:
      - port: 9090
        target: 9090
        nodePort: 30289
    selector:
      app: product-app

• ConfigMap

  apiVersion: v1
  kind: ConfigMap
  metadata:
    name: mysql-initdb-config
  data:
    initdb.sql:
      use mydb;
      create table product(
        id int AUTO_INCREMENT PRIMARY KEY,
        name varchar(20),
        description varchar(100),
        price decimal(8,3)
      );
      create table coupon(
        id int AUTO_INCREMENT PRIMARY KEY,
        code varchar(20) UNIQUE,
        discount decimal(8,3),
        exp_dat varchar(100)
      )

• Deployment

  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: product-app
    labels:
      app: product-app
  spec:
    replicas: 1
    selector:
      matchLabels:
        app: product-app
    template:
      metadata:
        name: proudct-app
        labels:
          app: product-app
      spec:
        containers:
          - name: product-app
            image: bharatht19/productservice

  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: docker-mysql
    labels:
      app: docker-mysql
  spec:
    replicas: 1
    selector:
      matchLabels:
        app: docker-mysql
    template:
      metadata:
        labels:
          app: docker-mysql
      spec:
        volumes:
         - name: mysql-initdb-vol
           configMap:
             name: mysql-initdb-config
        containers:
         

여기서 중요한 부분은 모든 값이 고정적으로 기록되어 있다는 점입니다. 이러한 특징을 일관성(Consistency)라고 부릅니다.

헬름을 사용하기 전 - 일관성 불일치 현상

일반적으로 모든 쿠버네티스 선언 파일은 일관성(Consistency)이 유지가 되기 때문에, 아래의 방법을 사용해서 구성을 변경해야 합니다.

1. 해당 파일을 체크인

2. GitHub에 푸쉬

실제로 아래와 같은 파일들에 대해서 kubectl edit을 통해서 모든 리소스를 배포하거나 수정할 수 있습니다.

1. deploy.yaml

2. service.yaml

3. config.yaml

4. secret.yaml

하지만 직접적으로 kubectl 명령어를 통해서 컨테이너 설정을 변경할 경우, 선언 파일과 실제 상태의 일관성이 유지되지 않습니다.

헬름을 사용하기 전 - 버전 관리 불가

코드 변경, 인프라 수정 등의 다양한 작업들에서 쿠버네티스 선언 파일 및 kubectl 커멘드는 버전기록을 관리하지 않습니다.

따라서 특정 버전으로의 복구 및 롤백이 지원되지 않습니다.

헬름을 사용하기 전후

우리는 헬름을 사용하기 전 - 시나리오와 그 후에 언급한 2가지 문제를 알게 되었습니다. 하지만 헬름을 통해서 우리는 일관성을 유지하고 버전 관리를 가능하게 만들 수 있습니다.

헬름이란?

헬름을 쿠버네티스 생태계를 위한 패키지 매니저입니다.

저는 이미 npm, yarn, pnpm, pip, pip3, mim, yum, apt, choco와 같은 다양한 패키지 매니저를 공부하고 사용한 경험이 있습니다.

헬름은 차트 저장소(Char Repo)에 기록된 파일들을 이용해서 쿠버네티스와 상호작용을 합니다.

helm install apache bitnami/apache --namepsace=web

이러한 구문은 매우 직관적이고 효율적으로 보입니다.
추가적으로 아래 구문들로 업데이트, 롤백, 삭제를 진행할 수 있습니다.

helm upgrade apache bitname/apache --namespace=web
helm rollback apache 1 --namespace=web
helm uninstall apache

헬름을 사용한 후 - 간단한 배포

헬름은 모든 복잡성(Complexity)를 추상화해서 쿠버네티스 배포 과정을 단순화합니다.

일반적으로 개발자가 MongoDB 인스턴스를 쿠버네티스 클러스터를 이용해서 설치하려면 컨테이너 구성, 네트워킹 볼륨 등의 모든 리소스를 이해하고 생성해야 합니다.

• 개발자 → 쿠버네티스 클러스터

  • MongoDB

    • deployment.yaml

    • service.yaml

    • config.map

하지만 개발자가 헬름을 사용하면 모든 과정을 MongoDB 차트(Chart)를 활용하여 해결합니다.

• 개발자 → 차트 저장소 : MongoDB 차트 다운

• 개발 → 쿠버네티스 클러스터 : MongDB 차트 사용

헬름을 사용한 후 - 버전 관리

헬름은 모든 상호작용에 대한 버전 관리를 진행합니다.
따라서 특정 버전으로 복구를 하는 등의 작업을 진행할 수 있습니다.

헬름을 사용한 후 - 동적 구성

앞서 헬름을 사용하기 전 - 시나리오에서는 쿠버네티스 선언 파일은 그 어떤 파라미터도 전달받지 못함을 알 수 있었습니다.

하지만 헬름을 사용하면 파라미터를 전달할 수 있게 되어 동적 구성이 가능해집니다.

1. 개발자 → values.yaml → 쿠너베니스 클러스터

   1. deployment.yaml

   2. service.yaml

   3. configmap.yaml

   4. secret.yaml

헬름을 사용한 후 - 일관성 유지

우리는 모든 설치 및 관리를 헬름을 사용할 수 있습니다.
따라서 헬름 차트 파일과 실제 컨테이너는 항상 일치하게 될 수 있습니다.

헬름을 사용한 후 - 지능적 배포(Intelligent Deployments)

일반 쿠버네티스 선언 파일은 작업의 순서가 너무 중요합니다.
일반적으로 configmap.yaml은 deployment.yaml/service.yaml보다 빨리 생성되어야 합니다.

하지만 헬름 차트는 작업의 순서을 지키지 않아도 자동으로 지켜집니다.

이런 특징은 Terraform과 유사해 보입니다.

즉, deployment.yaml, service.yaml, configmap.yaml을 동시에 실행시켜도 알아서 순서가 지켜집니다.

헬름을 사용한 후 - 라이프 사이클 훅

헬름의 주요한 작업이 완료되었을 때마다 라이프 사이클 훅을 실행할 수 있습니다.

1. pre-install

2. post-install

3. pre-delete

4. post-delete

5. pre-upgrade

6. post-upgrade

7. pre-rollback

8. post-rollback

9. test

헬름을 사용한 후 - 보안

헬름은 차트를 중앙 저장소인 차트 저장소에서 받아옵니다.
이 과정에서 모든 차트는 시그니처(Signitures)와 헤쉬값(Hashes)을 가지고 있습니다.

예제에서 사용할 헬름 저장소

• https://bitnami.com/stacks/helm

결론

쿠버네티스 선언 파일과 헬름 차트의 장단점은 다음과 같습니다.
대다수의 경우 헬름 차트가 훨씬 더 쉽고 안전하게 관리할 수 있습니다.