| Table of Contents | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
...
필자 생각에는 참고 삼아 배포하거나 show values 등의 명령을 사용하여 리서치할 용도가 아니라, 본인의 K8s에 배포를 목적으로 한다면, 위 1번이 버전을 따로 관리하기에도 편하고 charts 구조 및 내용을 탐색하기에도 편한 듯 하다.
캐바캐이니, 편한대로 하여도 좋으나, 여기서는 1번 방식으로 배포하도록 하겠다.
Values override
influxdata/influxdb 내부의 values를 상황에 맞게 override 하자.
...
위에서 언급한 것처럼 StatefulSet을 위한 persistence volume claim을 생성하여 production 환경과 유사한 배포를 해볼 것이다.
Deploy Kapacitor
| Info |
|---|
여기에서는 편의상 Headless Service로 생성하지 않을 것이나, 사실 kapacitor의 경우 stateless하며 k8s 클러스터 내부 통신만 허용하면 되고, 더구나 CloudHub에서는 굳이 로드밸런싱할 이유가 (현재까지 상황으로는) 별로 없기 때문에 Headless Service가 더 적합하다. 만일 외부의 telegraf 등에서 직접 kapacitor로 데이터를 전송해야 한다면, Headless Service를 사용하면 곤란해 질 것이다. |
InfluxDB의 배포가 정상 가동되면, 이제 Kapacitor를 배포하여 보자.
...
Etcd cluster 개수의 최소 요구 조건은 3개 이므로,
replicaCount는 3개로 주었다.persistence는 InfluxDB와 마찬가지로 PersistentVolume 부터 따로 다룬 후 적용할 것이다.
지금은enabled: false.현재 테스트 베드 구성 상, worker 노드를 2개만 생성하였다. 1번의 제약으로 인해 control plane에도 생성되게 하기 위해
tolerations를 적용하였다.
물론 Production에서는 worker node에만 생성되게 하는 것을 권장한다.Sevice는 Etcd의 경우 CloudHub 서버에서만 접속 가능하면 되므로, 별도 외부에서 접속할 일이 없을 듯 하여 default values로 두었다override하지 않았다.
아래와 같이 배포한 후, 정상 배포되면 접속 방법 등의 간략한 가이드가 출력될텐데, 어떤 것들이 있는지 눈여겨 봐두면 이후 작업(CloudHub 설정 작업 등)에 도움이 될 수 있을 것이다.
...