HELM

쿠버네티스 패키지 매니저: 헬름
파일과 디렉터리를 압축해서 모아둔 것을

바이너리 릴리스로 헬름 설치

유닉스 계열에서 바이너리는 실행파일을 의미한다.

헬름은 소스 또는 미리-빌드된(pre-built) 바이너리 릴리스로 설치할 수 있다. 바이너리 릴리스로 헬름의 모든 릴리스는 다양한 OS들의 바이너리 릴리스를 제공한다. 이 바이너리 버전들은 수동으로 다운로드하여 설치할 수 있다.

1.원하는 버전을 다운로드한다. Linux amd64: https://get.helm.sh/helm-v3.11.0-linux-amd64.tar.gz
2.압축해제한다.
3.압축해제된 디렉토리에서 helm 바이너리를 찾아서, 원하는 목적지로 이동시킨다. (cp linux-amd64/helm /usr/local/bin/)
3. 거기서부터, 클라이언트를 구동하고 stable 저장소를 추가할 수 있어야 한다: helm help.

참고: 헬름 자동화 테스트는 CircleCi 빌드와 릴리스 사이에, 리눅스 AMD64에서만 수행된다. 다른 OS들에 대한 테스트는, 대상 OS에 대한 헬름을 요청하는 커뮤니티에서 담당한다

# 다운로드
cd ~
wget https://get.helm.sh/helm-v3.11.0-linux-amd64.tar.gz


# 압축해제 후 설치, helm은 실행파일임
tar xf helm-v3.11.0-linux-amd64.tar.gz
sudo install linux-amd64/helm /usr/local/bin/

# 설치 확인 
helm version

• 헬름 차트 리포지토리 초기화
  헬름이 준비되면, 차트 리포지토리를 추가할 수 있다. 처음에 주로 사용하는 곳은 공식 헬름 stable 차트들이다

# 이름 내맘대로 지정가능
helm repo add bitnami https://charts.bitnami.com/bitnami

# 저장소 확인
helm repo list

# 차트 리포지토리 추가가 완료되면 설치할 수 있는 차트들의 목록을 볼 수 있다.
# 패키지(차트)의 이름
helm search repo bitnami

yum update: 설치된 패키지들 중에 최신버전으로 업데이트 가능한 것들만 업데이트
apt update: 패키지의 목록을 업데이트 해줌

• repo update은 apt처럼 패키지의 목록을 업데이트 해준다.

helm repo update 

#         릴리스이름 / 차트이름
helm install mydb bitnami/mysql

# 설치된 패키지 확인
helm list

# mydb-mysql이 설치된 것을 볼 수 있다.
kubectl get all

차트를 설치하는 것을 릴리스라고 함

• 릴리스 삭제

# 릴리스 상태확인  
helm status mydb # 릴리스 이름

# 릴리스 삭제 
helm uninstall mydb

# 삭제된 것 확인
helm status mydb
kubectl get all

스테이트풀셋을 쓰고있고 pvc를 동적으로 요청을 함,default가 설정되어 있지 않으면 pending 상태로 유지됨

• 스테이트풀셋이기에 pv, pvc는 수동으로 제거해줘야 한다.

kubectl delete pvc data-mydb-mysql-0

• 헬름을 성공적이고 안전하게 사용하려면 다음과 같은 전제 조건들이 필요하다.
  1.쿠버네티스 클러스터
  2.설치를 위해 어떤 보안 구성을 사용할 것인지 결정하기(필요시)
  3.헬름 설치 및 구성( -> 이것이 kubeconfig 이다.)

버전2의 헬름구성

차트 저장소: repo
클라이언트: v2와 v3가 있는데 이 그림은 v2이다.
쿠버네티스클러스터 내에 있는 api server와 통신하는 Tiler하는 파드(v2에서만 사용)가 있는데 이것과 클라이언트 헬름 명령과 통신한다.

현재 사용하는 v3는 Tiler가 존재하지 않는다. tiler는 외부의 노출이 되어있고 api에 요청을 해야하기에 cluster-admin 권한을 가지고 있다. 따라서 이게 해킹되면 모든 정보가 노출되는 보안적 이슈가 있어 사라졌다.
v3에서는 헬름 명령어가 https 통신으로 api-server와 직접 통신한다. 이때 kubeconfig파일이 필요한 것이다.

helm search검색 명령어

헬름은 강력한 검색 명령어를 제공한다. 서로 다른 2가지 소스 유형을 검색하는데 사용할 수 있다.

• helm search hub는 여러 저장소들에 있는 헬름 차트들을 포괄하는 헬름 허브를 검색한다.
  -> 쿠버네티스 패키지(차트)를 찾고 설치할 수 있는 사이트

• helm search repo는 helm repo add를 사용하여 로컬 헬름 클라이언트에 추가된 저장소들을 검색한다. 검색은 로컬 데이터 상에서 이루어지며, 퍼블릭 네트워크 접속이 필요하지 않다.

helm search hub를 실행하면 공개적으로 사용 가능한 차트들을 찾아볼 수 있다.

helm search hub nginx

Customizing the Chart Before Installing

이 차트의 기본 구성 옵션들만 사용할 것이다. 대부분의 경우 선호하는 구성을 사용하기 위해 차트를 커스터마이징하게 될 것이다.

# 차트에 어떤 옵션이 구성 가능 확인
helm show values bitnami/mysql # 차트이름

# 파일로 저장
helm show values bitnami/mysql > mysql-param.yaml

vi mysql-param.yaml
464 서비스 타입: ClusterIP   # default 값

서비스타입을 NodePort로 바꾸고 install하면 서비스 타입이 ClusterIP가 아닌 NodePort로 설치된다. 이를 커스텀이라고 한다.

bitnami 차트 깃허브
-> bitnami -> 차트 종류들 확인 가능 -> mysql
차트의 필수 항목은 templates(내부에는 오브젝트, manifast의 내용 존재), Chart.yaml(이 패키지의 메타데이터를 정의), values.yaml 이 3가지이다.

templates에서의 내용을 직접 수정한 이후 클론하는 것도 커스텀할수 있는 한가지 방법이다.

설치 작업에 구성 데이터를 전달하는 방법

• --values (또는 -f): 오버라이드(override)할 YAML 파일을 지정한다. 여러 번 지정할 수 있지만 가장 오른쪽에 있는 파일이 우선시된다.

• --set: 명령줄 상에서 오버라이드(override)를 지정한다.

둘다 사용하면, --set 값은 더 높은 우선순위를 가진 --values 으로 병합된다. --set에 명시된 오버라이드 사항들은 컨피그맵(ConfigMap)으로 보관된다.

보통 자신이 어떤 것을 커스템 했는지 확인하기 위해 yaml파일로 만들어서 사용한다.

# 필요한 부분만 설정
vi my-pram.yaml
primary:
  service:
    type: LoadBalancer
    
helm install mydb bitnami/mysql -f my-pram.yaml

# 로드밸런스로 되어있는 것을 확인 가능
kubectl get svc


# 직접 설정, 잘 사용하지 않음
helm install mydb bitnami/mysql --set 'primary.service.type=NodePort'

릴리스 업그레이드 및 실패 복구

새로운 버전의 차트가 릴리스되었을 때, 또는 릴리스의 구성을 변경하고자 할 때, helm upgrade 명령어를 사용할 수 있다.

업그레이드는 현존하는 릴리스를 가지고, 사용자가 입력한 정보에 따라 업그레이드한다. 쿠버네티스 차트는 크고 복잡할 수 있기 때문에, 헬름은 최소한의 개입으로 업그레이드를 수행하려고 한다. 최근 릴리스 이후로 변경된 것들만 업데이트하게 될 것이다.

릴리스가 계획대로 되지 않는다면, helm rollback [RELEASE][REVISION]를 사용하여 이전 릴리스로 간단히 롤백할 수 있다.

# 기존에 그대로 설치
helm install mydb bitnami/mysql


# 업그레이드
helm upgrade mydb bitnami/mysql -f my-pram.yaml

# revision이 2로 되어있고 파일대로 업그레이드 된 것을 볼 수 있다.
helm list 
# 서비스 타입이 로드밸런서임
kuebectl get svc

# 이전 버전 보기
helm history mydb

# 이전 버전으로 돌아기기
helm rollback mydb 1

# revision이 3으로 바뀌고 상태에 이전 상태로 돌아간다.
helm list 
helm history mydb

# 서비스 타입이 ClusterIP임
kuebectl get svc

# 제거작업
helm uninstall mydb
kubectl delete pvc --all

쿠버네티스 대쉬보드

쿠버네티스 대쉬보드는 Kubernetes 클러스터를 위한 범용 웹 기반 UI이다. 이를 통해 사용자는 클러스터에서 실행 중인 애플리케이션을 관리하고 문제를 해결할 수 있을 뿐만 아니라 클러스터 자체를 관리할 수 있다.

• 쿠버네티스 대쉬보드
  여기서 야물파일로 설치

# 대시보드 UI 배포
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.7.0/aio/deploy/recommended.yaml

• 직접 아티팩트허브에서 해보기
  kubernetes-dashboard

helm repo add kubernetes-dashboard https://kubernetes.github.io/dashboard/

# 레포정보 확인
helm repo list

# kube-system에 비치시킬 것이고 서비스타입을 바꿈 
helm install kubernetes-dashboard kubernetes-dashboard/kubernetes-dashboard -n kube-system

# 설치 확인
helm list -n kube-system

# 파라미터 수정
vi dashboard-pram.yaml
service:
    type: LoadBalancer

# 파일 설정을 하여 업그레이드      
helm upgrade kubernetes-dashboard kubernetes-dashboard/kubernetes-dashboard -n kube-system -f dashboard-pram.yaml  

# 설치 확인
helm list -A

# 로드 밸런서로 바뀐 것을 확인
kubectl get svc -n kube-system

처음부터 직접 설정해서 설치해도 무관
helm install kubernetes-dashboard kubernetes-dashboard/kubernetes-dashboard -n kube-system -f dashboard-pram.yaml

관리하기 위한 목적의 대쉬보드이기 때문에 외부에 노출시키지 않고 필요할때만 포트포워딩으로 통신한다. 가상 컴퓨터에는 웹 브라우저가 없기때문에 포트포워딩을 해도 접속을 할 수 없다.

https://192.168.56.200/ 로 접속하고 안전하지 않아도 로그인 한다고 들어가면 밑 화면이 나온다.

• 예전에는 서비스어카운트를 인증할 수 있는 토큰이 만들어졌는데 지금은 자동으로 만들어지지 않아서 명령을 통해 새로 만들어야 한다. 예전 토큰방식은 토큰을 영구적으로 유지했지 때문에 사라진 것이다.

# sa계정 확인
kubectl get sa -n kube-system kubernetes-dashboard

# 확인한 서비스 어카운트에 토큰 생성, 기본은 24시간만 유효
kubectl create token -n kube-system kubernetes-dashboard

# 토큰 내용 복사해서 대시보드 로그인 

들어가서 확인하면 다 접근이 불가능하여 데이터가 나오지 않는다. 사용자는 만들어졌지만 권한이 없다고 나온것이다.

해결: 클러스터 롤바인딩:cluetser-admin

vi kubernetes-dashboard.yaml

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: kubernetes-dashboard
subjects:
- kind: ServiceAccount
  name: kubernetes-dashboard
  namespace: kube-system
  apiGroup: ""
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: "rbac.authorization.k8s.io"

# 클러스터 롤바인딩 생성
kubectl create -f kubernetes-dashboard.yaml 

# 토큰 생성 후 재인증해서 들어가면 정상적으로 실행되는 것을 볼 수 있다.

'+' 버튼을 눌러 새로 지정도 가능하다. 하지만 구성할때 몇가지 제한사항은 있다.

• 문제가 발생했을시에는 공식문서를 참조하여 문제를 해결하도록 노력하는 것이 중요하다.
  kubernetes / dashboard 공식문서

프로메테우스

프로테메우스는 오픈소스 모니터링 시스템이다.쿠버네티스뿐만 아니라 일반적인 리눅스 시스템, 네트워크 장비 등 하드웨어 장치들이나 VM, OS, APM(Application Performance Monitoring) 등을 전부 모니터링 할 수 있다.
프로메테우스가 모니터링 할 수 있는 장치들

프로메테우스 구성요소

구성요소들이 다 파드로 띄어진다.

Premetheus Server: 제일 중요, 모니터링 하는 것이다.

• retrieval: 타켓으로부터 데이터를 가져옴
• TSDB(time series DB): 시계열 데이터베이스, 모니터링 도구는 RDB에 저장하기에 좋지 않기 때문에 시간에 따른 정보를 저장하기 좋은 TSDB에 데이터 저장
• HTTP Server: 자체적인 http 서버, 기본적으로 여러 그래프를 확인가능

jobs/exports: 모니터링 타켓(쿠버네티스의 각 요소들 파드,)

Short-lived jods: 생명주기가 짧은 것들은 Pushgateway에 쌓아두고 나중에 가져옴

service discovery: 프로메터우스 서버가 쿠버네티스에서 무엇을 측정해야할지 목록을 가져옴(api서버로 부터)

Alertmanager: CPU가 얼마 이상 넘어가면 알림를 보낼 수 있음

prometheus web UI: 자체적인 http 서버을 보여주는 웹서버로 실질적인 모니터링 용도가 아닌 프로메테우스 서버를 테스트하고 개발하기 위한 용도임

PromQL: 프로메테우스 서버의 DB에 저장된 정보를 퀴리하기위한 언어

Grafana: 프로메테우스에 포함되어 있는 것이 아닌 같이 포함되어있는 오픈 소스, 데이터 시각화를 위한 용도로 이를 설치함

힙스터(heapster)

힙스터

쿠버네티스의 모니터링 도구인데 현재는 사라졌다. 다른 대체재가 존재하고 쿠버네티스에서 모니터링까지 사용하기 힘들기 때문에 중단했다고 한다.

Heapster 기능의 잠재적 마이그레이션 경로

• 기본 CPU/메모리 HPA 지표의 경우 : metrics-server를 사용
  ->매트릭스 서버에는 DB가 없이 실시간으로만 데이터를 볼 수 있다. 즉 HPA를 위해서만 존재한다.

• 일반 모니터링의 경우 : Prometheus 형식 측정항목을 수집할 수 있는 타사 모니터링 파이프라인을 고려해야한다. kubelet은 Heapster가 내보낸 모든 메트릭을 Prometheus 형식으로 노출한다. 이러한 모니터링 파이프라인 중 하나는 이러한 목적으로 Prometheus 자체를 배포하는 Prometheus Operator를 사용하여 설정할 수 있다.
  ->과거의 정보를 기록해두기 위해서

CNCF 클라우드 네이티브 인터랙티브 환경

설치

# repo 생성
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts

helm repo update

• 별도의 네임 스페이스 생성해서 진행

kubectl create ns monitor

프로메테우스 차트 저장소
-> helm-charts/charts/kube-prometheus-stack/

kube-prometheus-stack은 패키지가 패키징 되어있는 것이다.

• values.yaml에 파라미터가 지정되어있다. grafana를 모니터링 하는데 우리는 여기서 grapana의 서비스 타입을 바꿔준다.

helm repo list

vi prometheus-grafana.yaml

grafana:
  service:
    type: LoadBalancer
    #type: NodePort
    

helm install prometheus prometheus-community/kube-prometheus-stack -n monitor -f prometheus-grafana.yaml

# 많은 것들이 설치됨
kubectl get  all -n monitor

# 서비스 접속
kubectl get svc -n monitor

데몬셋인 node-exporter가 각 노드마다 배치가 되어있을 것이다. 거기서 모든 매트릭을 측정해서 가져온다.

• 관리 목적이기때문에 얘도 외부에 노출시키면 안된다.
  기본 계정은 admin/prom-operator 이다.

로드밸런서의 IP를 확인한 이후 192.168.56.201 로 접속하고 계정으로 로그인하면 모니터링 가능하다.
좌측에 dashboard가 있는데 일반적으로 Kubernetes/Compute Resources 이게 실제 대쉬보드이고 general은 분류일 뿐이다. Compute Resources/Cluster를 확인해본 것이다.

다른 것을 보려면 저장하지 않고 다른 대쉬보드로 들어가서 확인하면 된다.

• 리소스를 많이 잡아먹음으로 사용하지 않으면 제거해주는 것이 좋다.

helm uninstall prometheus -n monitor

로깅

/var/log/pods, /var/log/container이 따로 남는 로그들을 통합해서 관리해야한다. 이를 위한 방식이다.

• ELK stack(Elasticserach 검색엔진 Logstach 로그 수집기 Kibana 데이터 시각화): java로 만들어져 있고 로그수집기가 무거움.

• EFL stack(Elasticserach Fluentd Kibana): 제일 선호하는 방식, CNCF 프로젝트이고 쿠버네티스에서는 C,C++로 만들어진 이 로그수집기를 사용한다.
  가공과 필터기능이 있는데 이를 많이 제거해서 경량화 시킨것이 FluentBit이다.

• Elastic Stack(Elasticserach Beats Kibana)

로그를 긁어서 가져오는 것을 로그 수집기가 해주고 이를 저장해야한다. 저장한 데이터를 검색하기 위해 쓰는 것이 Elasticserach이고 쿼리문들 통해 프로메테우스로 정보를 가져와 검색을 하고 Kibana 로 보기 쉽게 만든다.

• elasticsearch
  7.17.3 버전 사용

cd ~/goorm-8th-k8s/manifests/13_helm
mkdir 03_efk
cd 03_efk

kubectl create ns logging

# 레포 추가
helm repo add elastic https://helm.elastic.co
helm repo update

helm show values --version 7.17.3 elastic/elasticsearch > elasticsearch-value.yaml


# 설정 파일 리소스 내용 커스텀
vi elasticsearch-value.yaml

:set nu

 18 replicas: 1
 19 minimumMasterNodes: 1
 ...
 80 resources:
 81   requests:
 82     cpu: "1000m"
 83     memory: "1Gi"
 84   limits:
 85     cpu: "1000m"
 86     memory: "1Gi"

# 설치
helm install elasticsearch elastic/elasticsearch --version 7.17.3 -f elasticsearch-value.yaml -n logging

스테이트 풀셋으로 구성되어있다.

• fluent-bit 설치

helm repo add fluent https://fluent.github.io/helm-charts
helm repo update

helm install fluent-bit fluent/fluent-bit -n logging

# 설정 파일 리소스 내용 커스텀
helm show values --version 7.17.3 elastic/kibana > kibana-value.yaml

vi kibana-value.yaml

:set nu

 49 resources:
 50   requests:
 51     cpu: "1000m"
 52     memory: "1Gi"
 53   limits:
 54     cpu: "1000m"
 55     memory: "1Gi"
...
119 service:
120   type: LoadBalancer

helm install kibana elastic/kibana --version 7.17.3 -f kibana-value.yaml -n logging

# 서비스 확인
kubectl get svc -n logging

데몬셋으로 구성되어 있다.

서비스에서 확인한 IP를 보고 http://192.168.56.201:5601 접속,여기서는 포트가 지정되어있기때문에 꼭 포트번호까지 작성해줘야한다. kibana가 작동하기까지 시간이 걸리기 때문에 kubectl get all -n logging로 준비상태가 되었는지 확인한 후 접속한다.

elasticserach가 제대로 작동하지 않기때문에 키바나가 작동하지 않을 수 있다.

로깅 확인방법

1.Welcome 페이지: Explorer on my own 버튼 클릭
2.좌측 상단 햄버거 메뉴(≡): Management -> Stack Management 선택
3.Kibana -> Index Patterns 선택
4.Create Index pattern 선택
5.Name: logstash-* 입력 -> 오른쪽에 파일이 보여야함
6.Temestamp filed(시간정렬): @timestamp 선택
7.Create index pattern 버튼
8.좌측 햄버거(≡) 메뉴 -> Analytics -> Discover
9.쿠버네티스의 모든 로그가 검색됨

위에서 로그 검색을 할 수 있다.