Github

아래 예제들에 대한 전체 helm chart는 https://github.com/snetsystems/K8s-Objects/tree/master/helm-charts 에서 볼 수 있다.

Walkthrough overview

이번 장에서는 보다 더 다양한 production 환경에 근접한 실습이 될 수 있도록 위 서비스를 배포하여 본다.
또한, K8s application package 관리의 편의성을 위해 Helm Chart를 사용하기로 한다.

기본적인 사용법은 Quickstart Helm 을 참고하고, 아래 컴포넌트들을 하나씩 배포하여 보자.

Deploy InfluxDB

CloudHub와 호환되는 InfluxDB의 버전은 1.18이므로, InfluxDB:1.18로 배포하기 위해 아래 influxdata의 repo를 추가한다.

Add Helm Repo

만일 아래 influxdata의 repo가 추가되어 있지 않다면, 아래 명령어로 추가하여 준다.

Installation

설치 명령어

위의 여러 버전들 중에 influxdata/influxdb 4.12.3 1.8.10을 목표 버전으로 하고, Helm chart를 통해 설치하는 방법은 아래 두 가지(세부적으로는 세 가지) 정도가 있다.

1. helm pull influxdata/influxdb를 통해 로컬에 다운로드 후, 아래 명령 중 하나로 설치.
   참고 -g: Deploy 이름 자동 생성 모드

   1. helm install -n helm-test -g influxdb-4.12.3.tgz

   2. tar xzf influxdb-4.12.3.tgz && helm install -n helm-test -g ./influxdb

2. Helm repo를 통해 설치.
   helm install -n helm-test -g influxdata/influxdb

필자 생각에는 참고 삼아 배포하거나 show values 등의 명령을 사용하여 리서치할 용도가 아니라, 본인의 K8s에 배포를 목적으로 한다면, 위 1번이 버전을 따로 관리하기에도 편하고 charts 구조 및 내용을 탐색하기에도 편한 듯 하다.
캐바캐이니, 편한대로 하여도 좋으나, 여기서는 1번 방식으로 배포하도록 하겠다.

Values override

influxdata/influxdb 내부의 values를 상황에 맞게 override 하자.

참고 사용 가능한 values는 위 influxdb-4.12.3.tgz를 압축 해제한 폴더의 values.yaml을 보면 되며,
helm show values influxdata/influxdb명령을 통해서도 볼 수 있다.

--set 옵션을 통해 override 할 수 있으나, 항목이 여러 개일 경우 번거로우므로 influxdb_override.yaml내에 oerride할 내용을 기입하여 create 혹은 upgrade 시 반영하도록 한다.

object 키워드 및 형식은 대부분 k8s object yaml과 동일하다.

1. Influxdb는 데이터베이스 이므로 당연히 상태를 가지는 pod(kind: StatefulSet)가 생성되어야 한다.
   하지만 현재 persistence volume을 생성해두지 않았으므로, 일단 persistence.enabled = false로 하여 생성하여 pod 생성이 잘 되는 지 등, 그 밖에 기능들이 생각한 대로 워킹하는지 확인한다.
   차후, persistence volume으로 대체하기로 한다.

2. helm show values influxdata/influxdb 결과의 values.config.http.bind-address: ":8086" 이므로 서비스 포트를 8086으로 지정하였다.
   또한, 외부 접근을 위해 externalIPs도 추가하였다.

3. 1과 같이 공유 persistence volume을 사용하지 않기 때문에 pod가 업그레이드 되거나 혹은 재 생성되거나 할 때, 데이터 유지를 위해서는 반드시 같은 노드에 생성되어야 한다.
   따라서 nodeSelector를 통해 worker01노드에만 생성되도록 하였다.

Install influxdb

그럼 위의 influxdb_override.yaml와 함께 배포해본다.

필자의 경우에는 이미 helm install -n helm-test -g ./influxdb명령어를 통해 불완전하게나마 생성을 한 상태이다.

따라서, 아래와 같이 upgrade 를 통해 influxdb_override.yaml의 내용을 적용하도록 하겠다.

Override된 내용은 아래 명령을 통해서 변경된 내용만 확인도 가능하다.

여기까지 성공적으로 수행이 되었다면, http://10.20.2.235:8086 으로 CloudHub의 data source로 추가도 가능할 것이다.

Open

To do

위에서 언급한 것처럼 StatefulSet을 위한 persistence volume claim을 생성하여 production 환경과 유사한 배포를 해볼 것이다.

Deploy Kapacitor

InfluxDB의 배포가 정상 가동되면, 이제 Kapacitor를 배포하여 보자.

CloudHub latest 버전인 v1.4.4에서는 Kapacitor 호환 버전 KAPACITOR_TAG=1.5.4를 사용하고 있다.
그런데, 현재 Helm artifacthub의 공식 influxdata/kapacitor는 아래와 같이 APP VERSION = 1.6.4만 업로드 되어 있다.

물론, github에는 여러 버전의 chart들이 업로드 되어 있고, Docker hub에도 다양한 버전으로 tag된 image들이 있으므로 version skew를 최소화 할 수 있으나, Kapacitor 공식 문서나 Github CHANGELOG.md를 봐도 호환이 가능할 것 같다는 생각이 들어, 일단 APP VERSION = 1.6.4으로 배포하여 테스트를 진행하기로 한다.

Values override

Kapacitor는 특별히 상태를 가지지 않아도 되므로 Deployment로 배포된다.
따라서 nodeSeletor는 따로 지정하지 않는다.

problem 위의 yaml로 helm install -n helm-test -g -f kapacitor_override.yaml ./kapacitor를 하면 실제 서비스 포트는 9092, externalIPs는 잡히지 않는다.

Reason kapacitor/templates/service.yaml을 보게되면,

spec.type과 selector.app을 제외하면 모두 변수가 아니라 상수로 지정되어 있다.

Solution 따라서, kapacitor/templates/service.yaml과 kapacitor/values.yaml을 적절히 수정한다.

Values override를 하지 않으면 default 값이 템플릿으로 넘어 갈 수 있도록 아래와 같이 values.yaml도 수정해준다.

Install kapacitor

이제 위에 만들어둔 kapacitor_override.yaml와 함께 설치(이미 설치되어 있으므로 upgrade)해 본다.

필자의 try & error로 인해 벌써 REVISION: 18까지 올라간 것을 볼 수 있다.

이제, 앞서 연결한 InfluxDB data source에 위 kapacitor를 연결하면 정상 작동 할 것이다.

Open

Deploy ETCD

일단 모든 공개 허브에서 etcd를 검색해보면, 아래와 같이 여러 APP VERSION의 Repo가 출력된다.

Kapacitor와 마찬가지로, CloudHub에서 현재까지 공식 호환 Etcd 버전은 3.3.11이지만, 최신 버전도 호환되는 지 여부 등을 테스트 해보기 위해 APP VERSION=3.5.9로 설치할텐데, 이는 이미 이전에 bitnami repo가 추가된 상태이므로 바로 repo를 다운로드할 수 있다.

etcd helm chart를 보면 매우 복잡한 구조로 되어 있음을 볼 수 있다.
일단, ./etcd/templates/statefulset.yaml과 ./etcd/values.yaml을 살펴보고 필요한 항목을 override한다.

필자가 추가한 내용은 다음과 같다.

1. Etcd cluster 개수의 최소 요구 조건은 3개 이므로, replicaCount는 3개로 주었다.

2. persistence는 InfluxDB와 마찬가지로 PersistentVolume 부터 따로 다룬 후 적용할 것이다.
   지금은 enabled: false.

3. 현재 테스트 베드 구성 상, worker 노드를 2개만 생성하였다. 1번의 제약으로 인해 control plane에도 생성되게 하기 위해 tolerations를 적용하였다.
   물론 Production에서는 worker node에만 생성되게 하는 것을 권장한다.

4. Sevice는 Etcd의 경우 CloudHub 서버에서만 접속 가능하면 되므로, 별도 외부에서 접속할 일이 없을 듯 하여 override하지 않았다.

아래와 같이 배포한 후, 정상 배포되면 접속 방법 등의 간략한 가이드가 출력될텐데, 어떤 것들이 있는지 눈여겨 봐두면 이후 작업(CloudHub 설정 작업 등)에 도움이 될 수 있을 것이다.

Deploy CloudHub

위의 예제들과 기본적 개념은 유사하므로, https://github.com/snetsystems/K8s-Objects/tree/master/helm-charts 를 참고하도록 한다.