[쿠버네티스 쉽게 이해하기 15] 더 알면 좋을 주제들: 무중단 배포, 모니터링, HPA

Cloud/Kubernetes

[쿠버네티스 쉽게 이해하기 15] 더 알면 좋을 주제들: 무중단 배포, 모니터링, HPA

Happy@Cloud 2022. 5. 22. 21:03

15. 더 알면 좋을 주제들

드디어 쿠버네티스의 마지막 편입니다.
여기까지 학습하신것만으로도 여러분은 쿠버네티스를 이용하시는데 큰 불편은 없을 겁니다.
마지막 편에서는 조금 더 알면 좋을 주제들을 모아서 설명하려고 합니다.

첫번째로는 버전업 시 엔드 유저들이 서비스 중단을 느끼지 않고 무중단으로 파드를 배포하고 문제 발생 시 롤백하는 방법을 알아 보겠습니다.
두번째 쿠버네티스에 배포된 오브젝트들의 사용 현황을 모니터링 하기 위한 통합 모니터링 환경을 구축하는 방법을 배워 보겠습니다.
세번째로는 컨테이너의 꽃이라고 할 수 있는 부하에 따라 파드를 자동 증감 시키는 스케일링에 대해 알아 보겠습니다.

15.1 무중단 배포와 롤백

여러분이 ‘OTT 추천 서비스'를 개발하여 서비스를 시작하였고 사용자들의 피드백을 반영하여 다음 버전을 출시 하려고 한다고 생각해 봅시다.
폰이나 PC와 같은 단말기에 설치된 프로그램은 어쩔 수 없이 새로운 버전을 사용자가 설치하여야 합니다.
단말기가 아닌 서버 사이드의 프로그램이라면 서비스를 중단하지 않고 자동으로 새로운 버전이 설치되길 원할 겁니다.
어떻게 무중단으로 새로운 버전의 파드를 배포할 수 있을까요 ?
쿠버네티스에서는 무중단 배포 전략으로 블루-그린Blue-Green 배포, 롤링 업데이트Rolling Update, 카나리Canary 배포라는 세가지 방법을 사용할 수 있습니다.
이번에는 각 배포 전략과 롤백 방법에 대해 배워 보도록 하겠습니다.

1) 블루-그린 배포
블루-그린 배포는 구버전과 신버전을 모두 배포하고 라우터에서 일순간에 새 버전으로 트래픽을 바꿔주는 방법입니다.
쿠버네티스에서는 새로운 버전의 파드와 서비스를 배포하여 테스트 한 후 인그레스에서 새로운 버전의 서비스 오브젝트로 연결하는 방법으로 구현할 수 있습니다.
아키텍처에 따라 인그레스가 아닌 웹서버나 API 게이트웨이에서 라우팅을 새로운 버전으로 바꾸는 방법도 쓸 수 있습니다.
어쨋든 블루-그린은 구버전과 신버전이 같은 운영 환경에 일정 시간 존재해야 합니다.
<그림>

출처: https://martinfowler.com/bliki/BlueGreenDeployment.html
</>
블루 버전과 그린 버전 중 어떤것이 과거 버전인지는 중요하지 않습니다.
위 MSA의 대부인 마틴 파울러의 글에서 처럼 블루 버전으로 서비스 하고 있을 때는 그린 버전이 새 버전이고 그 반대라면 블루 버전이 새 버전입니다.

블루-그린 배포의 장점은 신버전 검증 완벽도가 높고 전환이 빠르다는 겁니다.
동일 또는 유사한 운영 환경에서 검증 할 수 있으니 당연히 테스트를 더 정확히 할 수 있고 라우팅 방향만 바꿔주면 되므로 순식간에 새 버전으로 전환할 수 있습니다.
반면 단점은 더 많은 비용이 든다는 것입니다.
새로운 버전의 배포를 위해 동일한 리소스를 가지는 워커 노드가 추가로 필요하니 당연하겠지요.

블루-그린 배포의 주요 고려 사항은 데이터베이스 마이그레이션입니다.
구버전과 신버전이 동일한 데이터베이스를 쓴다면 문제가 안되겠지만 구/신 버전도 독립적이어야 한다는 마이크로서비스의 원칙을 준용한다면 신버전의 데이터베이스로 마이그레이션과 롤백시 다시 구버전의 데이터베이스로 마이그레이션은 힘든 작업이 될 수 있습니다.
특히 구버전과 신버전의 데이터베이스 스키마가 다르다면 이 마이그레이션 작업은 반드시 필요 합니다.
이 문제 해결을 위해 마틴 파울러가 제안하는 방법은 어플리케이션 전환과 데이터베이스 전환을 분리하라는 것입니다.
데이터베이스 리팩토링을 통해 데이터베이스를 구/신버전 어플리케이션을 모두 지원하도록 먼저 바꾸라는 것입니다.
이렇게 한 후 구/신 버전의 데이터베이스를 CDCChange Data Capture와 같은 툴로 데이터 동기화를 한다면 이 문제를 해소할 수 있습니다.

블루-그린 배포의 롤백은 매우 단순 합니다.
라우팅을 구버전으로 다시 바꿔 주기만 하면 되니까요.

블루-그림 배포는 굳이 실습하지 않겠습니다.
인그레스 오브젝트를 바꿔서 새 버전으로 라우팅하게 하는건 이미 배우신걸로 충분히 혼자 하실 수 있고 웹서버 프락싱이나 API 게이트웨이를 이용하는 것은 이 책의 범위를 벗어 나기 때문입니다.

2) 롤링 업데이트
롤링 업데이트는 구버전의 파드는 하나씩 줄여 나가면서 신버전의 파드를 하나씩 생성하여 전환하는 방법입니다.

<그림>

출처: 조대협의 블로그
</>
롤링 업데이트는 쿠버네티스의 기본 배포 전략입니다.
제일 많이 사용하는 워크로드 컨트롤러인 디플로이먼트와 스테이트풀셋에서는 아래와 같이 롤링 업데이트 전략을 지정할 수 있습니다.
디플로이먼트는 ‘spec.strategy.rollingUpdate’ 하위에 정의 합니다. ‘maxSurge’는 지정된 파드수를 초과할 수 있는 비율이고 ‘maxUnavailable’은 지정된 파드수 중 사용 못하는 파드 수 비율입니다.
아래 예제대로라면 최대 7개(5+5*40%)의 파드까지 생성될 수 있고 최대 1개(5*20%) 파드까지만 사용 못하므로 항상 4개의 파드는 사용할 수 있도록 보장 합니다.
롤링 전략을 명시하지 않았을때는 기본 값은 ‘masSurge’와 ‘maxUnavailable’ 모두 25% 입니다.

…
spec:
  …
  replicas: 5
  strategy:
    rollingUpdate:
      maxSurge: 40%
      maxUnavailable: 20%
    type: RollingUpdate

  template:
…

스테이트풀셋은 ‘spec.updateStrategy.rollingUpdate’하위에 정의하고 ‘partition’에 몇번 파드까지교체할지를 지정 합니다. 스테이트풀셋은 기존 파드를 삭제하는게 아니라 대체하는 것이므로 디플로이먼트로 배포할때와는 조금 다릅니다. 예를 들어 아래와 같이 설정하면 일련번호 ‘4’번까지만 교체되므로 나머지 4개 파드는 구 버전으로 남게 됩니다. 이를 이용하면 일부 파드만 신버전으로 교체하여 새 버전에 대한 사용자 반응을 볼 수 있습니다.
모든 파드를 교체하려면 ‘partition’을 ‘0’으로 지정하여야 합니다. 기본 값이 ‘0’이므로 모든 파드를 교체할 때는 롤링 전략을 정의할 필요 없습니다.

…
spec:
  …
  replicas: 5
  updateStrategy:
    rollingUpdate:
      partition: 4
    type: RollingUpdate

  template:
…

롤링 업데이트의 장점은 신버전 파드를 미리 배포하지 않아도 되므로 비용이 절약된다는 것입니다.
단점은 신버전 배포 시 블루-그린 배포 보다 약간 더 시간이 걸리고 신버전에 대한 안정성 보장 수준이 낮다는 것입니다.

롤링 업데이트 시 고려할 점은 새 버전의 파드에는 스타트업 프로브나 레디니스 프로브가 있어야 된다는 것입니다.
그래야 서비스 오브젝트가 준비가 된 후에 새버전의 파드로 연결해 주기 때문입니다. 만약 스타트업 프로브나 레디티스 프로브가 없다면 준비가 안된 새 버전 파드로 연결되어 에러가 날 수도 있습니다.
롤링 업데이트로 배포 하면서 데이터베이스 마이그레이션까지는 할 수 없습니다. 데이터베이스 전환은 별도로 분리하여 배포하여야 합니다.

롤링 업데이트의 롤백은 아래 명령으로 할 수 있습니다.
kubectl rollout undo {워크로드 컨트롤러 리소스명} {워크로드 컨트롤러 오브젝트명} --to-revision={리비전 번호}
예1) kubectl rollout undo deploy busybox --to-revision=1
예2) kubectl rollout undo sts busybox --to-revision=1

리비전 번호는 아래 명령으로 확인할 수 있으면 배포할 때 마다 1씩 증가 합니다.
kubectl rollout history {워크로드 컨트롤러 리소스명} {워크로드 컨트롤러 오브젝트명}
예1) kubectl rollout history deploy busybox
예2) kubectl rollout history sts busybox

롤백은 위 명령으로도 할 수 있지만 컨테이너 이미지를 바꿔서도 할 수 있습니다.
kubectl set image {워크로드 컨트롤러 리소스명} {워크로드 컨트롤러 오브젝트명} {컨테이너명}={이미지 경로}
예1) kubectl set image deploy busybox busybox=docker.io/library/busybox:unstable
예2) kubectl set image sts busybox busybox=docker.io/library/busybox:unstable

그럼 디플로이먼트와 스테이트풀셋으로 배포 시 롤링 업데이트를 실습 해 보겠습니다.
배천 노드에서 작업 디렉토리로 이동하고 디플로이먼트 롤링 업데이트를 테스트 할 야믈 파일을 다운로드 하십시오.

[root@osboxes ~]# cd ~/k8s/yaml
[root@osboxes yaml]# kubens ott
[root@osboxes yaml]# wget https://hiondal.github.io/k8s-yaml/3.15/deploy-busybox-rolling.yaml

기존에 파드가 있으면 모두 삭제하여 주십시오.
야믈 파일의 내용을 보면 파드 수는 5개이고 maxSurge는 40%이며 maxUnavailable은 20%로 지정되어 있습니다.
KubeConfig 파일을 ‘kubenetes-admin’ 유저용으로 바꾸고 파드를 배포 하십시오.

[root@osboxes yaml]# export KUBECONFIG=$HOME/.kube/admin.conf
[root@osboxes yaml]# k apply -f deploy-busybox-rolling.yaml

터미널 한 개를 더 열고 아래 명령으로 파드의 변화를 모니터링 하십시오.

[root@osboxes yaml]# watch k get po

5개의 파드가 모두 실행이 되면 파드를 배포했던 터미널에서 아래 명령으로 새로운 버전을 배포 합니다.

[root@osboxes yaml]# k set image deploy busybox busybox=docker.io/library/busybox:stable

파드를 모니터링하는 터미널 탭에서 사용 가능한 파드가 항상 4개 이상인지 체크 해 보십시오.

롤백을 해 보겠습니다.
‘kubectl rollout history’명령으로 배포 히스토리를 확인 합니다.

[root@osboxes yaml]# k rollout history deploy busybox
deployment.apps/busybox
REVISION CHANGE-CAUSE
1 <none>
2 <none>

위와 같이 최초 배포한 리비전1과 이미지 명을 바꾼 리비전2가 나옵니다.
‘CHANGE-CAUSE’가 ‘<none>’으로 되어 있어서 어떤것이 변했는지 알기가 힘듭니다.
‘CHANGE-CAUSE’를 셋팅하는 방법은 ‘kubectl annotate’명령이나 야믈파일의 어노테이션으로 지정하는 방법이 있습니다.
야믈 파일에 지정할 때는 아래와 같이 하면 됩니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: busybox
  namespace: ott
  annotations:
    kubernetes.io/change-cause: "deploy unstable version"
spec:
…

이 방법은 매번 야믈 파일을 바꿔야 하므로 불편할 수 있습니다.
‘kubectl annotate’명령을 이용하여 셋팅해 보겠습니다. 아래와 같이 리비전 2에 변경 코멘트가 셋팅 되었습니다.

[root@osboxes yaml]# k annotate deploy busybox kubernetes.io/change-cause="deploy stable version"
deployment.apps/busybox annotated
[root@osboxes yaml]# k rollout history deploy busybox
deployment.apps/busybox
REVISION CHANGE-CAUSE
1 <none>
2 deploy stable version

리비전 1으로 롤백을 해 봅니다.

[root@osboxes yaml]# k rollout undo deploy busybox --to-revision=1
[root@osboxes yaml]# k annotate deploy busybox kubernetes.io/change-cause="rollback to unstable version"
[root@osboxes yaml]# k rollout history deploy busybox
deployment.apps/busybox
REVISION CHANGE-CAUSE
2 deploy stable version
3 rollback to unstable version

위와 같이 리비전1이 없어지고 리비전3에 롤백한 히스토리가 나옵니다.
리비전 히스토리의 최대 갯수는 디폴트로 10개 입니다. 조정 하려면 ‘spec.revisionHistoryLimit’에 지정해 주면 됩니다.
리비전 히스토리가 10개인데 순서대로 쌓이면 헷갈리지 않을 텐데 쿠버네티스는 동일 컨테이너 이미지 변경인 경우 과거 리비전은 지워버립니다. 나름 똑똑하게 처리한건데 사용하다 보면 헷갈립니다.

테스트로 파드 이미지를 아래와 같이 ‘busybox:latest’로 바꾸면 리비전이 하나 늘어난걸 확인할 수 있습니다.

[root@osboxes yaml]# k set image deploy busybox busybox=docker.io/library/busybox:latest
deployment.apps/busybox image updated
[root@osboxes yaml]# k annotate deploy busybox kubernetes.io/change-cause="to latest version"
deployment.apps/busybox annotated
[root@osboxes yaml]# k rollout history deploy busybox
deployment.apps/busybox
REVISION CHANGE-CAUSE
2     deploy stable version
3     rollback to unstable version
4     to latest version

이번에는 스테이트풀셋 배포와 롤백을 테스트 하겠습니다.

테스트할 야믈 파일을 다운로드 하십시오.

[root@osboxes yaml]# wget https://hiondal.github.io/k8s-yaml/3.15/sts-busybox-rolling.yaml

야믈 파일의 내용을 보면 파드 수는 5개이고 partition은 ‘0’으로 되어 있는걸 볼 수 있습니다.
파드를 배포하고 변경 이력을 셋팅 합니다. 스테이트풀셋은 버그인지 ‘kubectl annotate’명령으로 변경 이력이 셋팅되지 않습니다. 변경 이력 테스트는 스킵 하도록 하겠습니다.

[root@osboxes yaml]# k apply -f sts-busybox-rolling.yaml
[root@osboxes yaml]# k annotate sts busybox kubernetes.io/change-cause="deploy unstable version"
[root@osboxes yaml]# k rollout history sts busybox
REVISION CHANGE-CAUSE
1 <none>

이미지를 ‘busybox:stable’로 변경하고 파드가 교체되는걸 모니터링 해 보십시오.

[root@osboxes yaml]# k set image sts busybox busybox=docker.io/library/busybox:stable

일련번호가 가장 높은 파드부터 ‘0’번 파드까지 하나씩 교체 되는걸 볼 수 있습니다.

NAME     READY STATUS     RESTARTS AGE
busybox-0     1/1     Running     0     5m12s
busybox-1     1/1     Running     0     5m12s
busybox-2     1/1     Running     0     5m12s
busybox-3     1/1     Terminating 0     5m12s
busybox-4     1/1     Running     0     7s

이제 이전 버전으로 롤백을 해 봅니다.

[root@osboxes yaml]# k rollout undo sts busybox --to-revision=1

3) 카나리 배포
카나리 배포는 신버전으로 모두 바꾸는게 아니라 일부만 신버전으로 배포하는 방법입니다.
새로운 버전을 실험하기 위한 목적으로 사용합니다.
옛날에 광부들이 갱도가 안전한지를 테스트 하기 위해 카나리아를 먼저 갱도 안으로 날려 보내던 것에서 유래 하였습니다.

카나리 배포의 장점은 새로운 버전을 미리 테스트 해 볼 수 있다는 것입니다.
반면 단점이라면 카나리 버전에 문제가 있을때 일부 사용자는 서비스를 제대로 사용 못할 수 있다는 것입니다.

카나리 배포를 할 때 고려할 점은 카나리 버전으로 몇 프로의 트래픽을 보낼 것인가 결정하는 것입니다.

카나리 배포의 롤백은 카나리 버전을 제거하면 됩니다.

쿠버네티스에서는 파드 수를 조정하여 카나리 배포를 할 수 있습니다.
예를 들어 버전1으로 4개를 배포하고 버전2로 1개를 배포하고 서비스 오브젝트가 5개의 파드를 연결하게 만들면 20%의 트래픽은 카나리 버전으로 연결되게 할 수 있습니다.
스테이트풀셋으로 배포한 busybox파드 중 5번째 파드만 카나리 버전으로 바꿔서 실습 하겠습니다.
먼저 기존에 배포한 파드를 모두 지우고 다시 배포 하십시오.

[root@osboxes yaml]# k delete -f sts-busybox-rolling.yaml
[root@osboxes yaml]# k apply -f sts-busybox-rolling.yaml
[root@osboxes yaml]# k get po busybox-4 -o yaml | grep image:
image: docker.io/library/busybox:unstable
image: docker.io/library/busybox:unstable

5개의 파드는 위와 같이 ‘busybox:unstable’ 이미지로 배포가 되었습니다.
이제 ‘busybox-4’번 파드를 카나리 버전으로 바꿉니다.

[root@osboxes yaml]# k set image po busybox-4 busybox=docker.io/library/busybox:stable
pod/busybox-4 image updated
[root@osboxes yaml]# k get po busybox-4 -o yaml | grep image:
image: docker.io/library/busybox:stable
image: docker.io/library/busybox:stable

4) 배포 전략 요약
지금까지 배운 배포 전략을 요약하면 아래와 같습니다.

배포전략	설명	장점	단점	고려사항	롤백
블루-그린	구/신버전이 동일/유사 환경에 공존하고 라우팅만 신버전으로 교체하는 방법	신버전 검증도 향상과 신속한 전환 속도	구/신버전 공존으로 비용 증가	데이터베이스 전환은 별도 분리하여 수행	라우팅을 구버전으로 전환
롤링	구버전 수는 점차 줄이고 신버전 수를 점차 늘려 교체하는 방법	비용 절감	신버전 검증 수준 저하와 전환에 보다 시간 소요	스타트업 프로브/레디니스 프로브 설정으로 준비된 파드만 연결되게 함	kubectl rollout undo 또는 kubectl set image 사용
카나리	일부 트래픽만 신버전으로 연결하여 신버전 테스트 하는 방법	신버전 미리 검증	신버전 문제 시 서비스 장애 발생 가능	신버전으로 연결할 비율	카나리 버전 파드 제거

15.2 모니터링

모니터링은 안정적인 서비스를 위해 절대적으로 필요하고 중요합니다.
모니터링은 아래와 같이 Host, Container, Application, K8s에 대해서 수행되며 각각 모니터링 대상이 다릅니다.

이 중에 어플리케이션의 로그를 모니터링하기 위해서는 ‘13. 통합 로깅을 위한 EFK스택'에서 구성한 통합 로깅 환경을 이용하면 됩니다.
모니터링 환경 구성을 위해서 메트릭Metric 정보를 수집하여 저장하는 프로메테우스Prometheus와 수집된 메트릭을 대시보드로 가시화하여 제공하는 그라파나Grafana라는 툴을 이용합니다.
메트릭이란 정량화된 사용 현황을 의미하며 위 모니터링 항목에 대해 사용현황을 측정한 결과 입니다.

프로메테우스와 그라파나를 이용한 모니터링 환경 아키텍처를 먼저 말씀 드리겠습니다.
그리고 프로메테우스와 그라파나를 헬름차트를 이용하여 설치 하겠습니다.
마지막으로 그라파나에서 대시보드를 작성하는 방법을 학습 하도록 하겠습니다.

1) 통합 모니터링 환경 아키텍처
노드 메트릭은 각 워커 노드의 노드 익스포터Node Exporter가 제공하고 파드의 메트릭은 cAdvisor에 의해 제공되며 쿠버네티스 오브젝트들의 메트릭 정보는 컨트롤 플레인의 메트릭 API를 통해 제공 됩니다.
프로메테우스는 제공 받은 메트릭 정보를 자체 데이터베이스에 저장 합니다.
그라파나는 프로메테우스에 저장된 메트릭 정보를 대시보드로 보기 편하게 제공 합니다.

2) 설치 사전 작업
프로메테우스와 그라파나는 헬름 차트를 이용하여 별도의 네임스페이스에 파드로 설치를 합니다.
이를 위해서는 아래와 같은 선행 작업이 필요 합니다.
- 사용할 KubeConfig 변경
‘cluster-admin’역할을 가진 유저 ‘kubernetes-admin’으로 작업할 것이므로 환경변수 KUBECONFIG를 ‘~/.kube/admin.conf’로 변경 하십시오.

[root@osboxes yaml]# export KUBECONFIG=~/.kube/admin.conf

- 헬름 클라이언트 설치: 배천 노드에 설치하면 되고 이미 설치되어 있습니다.

- 프로메테우스와 그라파나 헬름 차트 저장소 추가
배천노드에서 아래와 같이 추가 합니다.

[root@osboxes yaml]# helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
[root@osboxes yaml]# helm repo add kube-state-metrics https://kubernetes.github.io/kube-state-metrics
[root@osboxes yaml]# helm repo add grafana https://grafana.github.io/helm-charts
[root@osboxes yaml]# helm repo ls
…
prometheus-community https://prometheus-community.github.io/helm-charts
kube-state-metrics https://kubernetes.github.io/kube-state-metrics
grafana https://grafana.github.io/helm-charts
[root@osboxes yaml]# helm repo update

- 프로메테우스와 그라파나가 설치될 네임스페이스 생성
‘monitor’라는 이름의 네임스페이스를 생성 합니다. 네임스페이스명은 바꾸셔도 되나 이후 제공되는 예제의 네임스페이스가 ‘monitor’로 되어 있어 맞춰서 바꾸셔야 합니다.
아래와 같이 네임스페이스를 만들고 현재 네임스페이스도 바꿔 주십시오.

[root@osboxes yaml]# k create ns monitor
[root@osboxes yaml]# kubens monitor

- NFS서버 설치와 동적 프로비저닝 구성
이미 완료한 작업 입니다. NFS서버의 ‘/data’디렉토리를 동적 프로비저닝 시 볼륨 디렉토리로 구성하셨을 겁니다.

- 작업 디렉토리 구성 및 이동
배천 노드에 ‘~/install/monitor’라는 디렉토리를 만들고 이동 하십시오.

[root@osboxes yaml]# mkdir ~/install/monitor
[root@osboxes yaml]# cd ~/install/monitor

3) 프로메테우스 설치
프로메테우스의 헬름 차트명을 먼저 찾아 설치 설정 파일을 다운로드 합니다.
우리가 사용할 헬름 차트는 ‘prometheus-community/prometheus’입니다.

[root@osboxes monitoring]# helm search repo prometheus
NAME CHART VERSION APP …
prometheus-community/prometheus 15.3.0 2.31.1
…
[root@osboxes monitoring]# helm inspect values prometheus-community/prometheus > values-prometheus.yaml

설치 설정 파일은 위에서 다운로드한 파일을 고쳐도 되고 아래처럼 샘플 설정 파일을 다운로드하셔서 사용해도 됩니다.

[root@osboxes monitoring]# wget https://hiondal.github.io/k8s-yaml/3.15/values-prometheus.yaml

❶ 인그레스 주소는 본인의 클러스터 VM 중 하나의 퍼블릭 IP로 바꾸십시오.
❷ 볼륨 디렉토리는 NFS 동적 프로비저닝 구성 시 지정한 ‘/data’디렉토리를 지정 합니다.
❸ 파드 수는 필요한 만큼 지정 하십시오.
❹ 수집한 메트릭 정보의 보관일 수 있니다. 실제 사용할 때는 적절하게 늘려 줍니다.

설치 설정 파일 ‘values-prometheus.yaml’과 헬름 차트 ‘prometheus-community/prometheus’를 이용하여 설치 합니다.
설치 전에 ‘--dry-run’옵션으로 사전 검증을 먼저 해 봅니다.

[root@osboxes monitoring]# helm install prometheus -f values-prometheus.yaml prometheus-community/prometheus --dry-run

문제가 없으면 설치 합니다.

[root@osboxes monitoring]# helm install prometheus -f values-prometheus.yaml prometheus-community/prometheus

설치 후에 파드가 모두 정상 실행될때까지 기다립니다.

[root@osboxes monitoring]# watch k get po

인그레스 주소를 확인하고 브라우저에서 엽니다.

[root@osboxes monitoring]# k get ing
NAME CLASS HOSTS …
prometheus-server <none> prometheus.169.56.70.201.nip.io

상단 메뉴에서 ‘Status > Targets’를 클릭 합니다. 결과 리스트는 메트릭을 제공하는 정보 제공자 리스트 입니다.

4) 그라파나 설치
그라파나도 동일하게 헬름차트 이름을 찾고 설치 설정 파일을 만들고 사전 검증 후 설치하면 됩니다.

[root@osboxes monitoring]# helm search repo grafana
NAME CHART VERSION APP …
grafana/grafana 6.21.5 8.3.5
…
[root@osboxes monitoring]# helm inspect values grafana/grafana > values-grafana.yaml

설치 설정 파일은 위에서 다운로드한 파일을 고쳐도 되고 아래처럼 샘플 설정 파일을 다운로드하셔서 사용해도 됩니다.

[root@osboxes monitoring]# wget https://hiondal.github.io/k8s-yaml/3.15/values-grafana.yaml

❶ 파드 수는 필요한 만큼 지정 하십시오.
❷ 인그레스 주소는 본인의 클러스터 VM 중 하나의 퍼블릭 IP로 바꾸십시오.
❸ 스토리지클래스명은 동적 프로비저닝을 지원하는 ‘nfs-dynamic’으로 합니다.
❹ 그라파나 관리자의 사용자명과 암호를 지정 합니다.

설치 설정 파일 ‘values-grafana.yaml’과 헬름 차트 ‘grafana/grafana’를 이용하여 설치 합니다.
설치 전에 ‘--dry-run’옵션으로 사전 검증을 먼저 해 봅니다.

[root@osboxes monitoring]# helm install grafana -f values-grafana.yaml grafana/grafana --dry-run

문제가 없으면 설치 합니다.

[root@osboxes monitoring]# helm install grafana -f values-grafana.yaml grafana/grafana

설치 후에 파드가 모두 정상 실행될때까지 기다립니다.

[root@osboxes monitoring]# watch k get po

인그레스 주소를 확인하고 브라우저에서 엽니다.

[root@osboxes monitoring]# k get ing
NAME CLASS HOSTS …
grafana <none> grafana.169.56.70.201.nip.io

웹브라우저를 열고 인그레스 주소로 접근 합니다.
지정한 그라파나 관리자의 사용자명과 암호로 로그인 한 후 아래와 같은 화면이 나오면 설치 성공입니다.

5) 프로메테우스와 연결
프로메테우스와 연결하려면 좌측바 메뉴에서 아래와 같이 ‘Configuration > Data sources’를 클릭 한 후 [Add data source]버튼을 누르십시오.

‘Prometheus’를 클릭 합니다.

URL에 ‘http://prometheus-server’라고 입력 합니다.
그라파나 파드에서 프로메테우스 파드를 접속하는 주소입니다. 프로메테우스 파드를 접근해야 하니 프로메테우스 서비스 오브젝트의 이름을 입력하면 됩니다.
프로메테우스 서비스 오브젝트의 이름은 ‘kubectl get svc’로 확인하면 됩니다.

제일 하단으로 내려서 [Save & test]를 누릅니다. 바로 위에 ‘Data source is working’이라고 나오면 정상적으로 연결된 겁니다.

6) 대시보드 작성
대시보드는 기존에 다른 사람이 만들어 놓은 것을 복사하여 수정하는 것이 편합니다.
아래 사이트로 접속 합니다.
https://grafana.com/grafana/dashboards/

접속 후 아래로 스크롤을 조금 내려 Data Source가 Prometheus인 것 중 다운로드 수가 많은 대시보드의 ID를 구합니다.

예를 들어 ‘Node Exporter Full’을 클릭하고 우측 부분을 보면 아래와 같이 대시보드 ID가 나옵니다.

아래와 같이 대시보드를 작성합니다.

위 번호를 입력하고, Load버튼을 누릅니다.

데이터 소스로 추가한 ‘Prometheus’를 선택하고 [Import]버튼을 누릅니다.

아래 예시와 같이 프로메테우스에 저장된 메트릭 정보를 이용하여 보기 편한 대시보드가 생성됩니다.

그 외 다른 대시보드를 추가하려면 그라파나 사이트(https://grafana.com/grafana/dashboards)에서 원하는 대시보드를 찾아 추가 하시면 됩니다.

대시보드는 PromQL(Prometheus Query Language)이라는 언어를 사용하여 만들 수 있습니다.
기존 대시보드의 내용을 수정하려면 아래와 같이 수정할 영역의 타이틀을 클릭하고 ‘Edit’버튼을 누른 후 PromQL언어로 수정하면 됩니다.
PromQL언어에 대해서는 별도로 학습하시기 바랍니다.

15.3 파드 자동 스케일링

간단한 실습 예제는 아래 링크를 참조하세요.

https://blog.naver.com/hiondal/221609927896

4. K8s Resources > Auto scaling: HorizontalPodAutoscaler

4.8 Auto scaling: HorizontalPodAutoscaler Pod 실행 시 CPU와 Memory의 Limit를 지정하고, H...

blog.naver.com

jMeter를 이용한 Stress Test의 내용에서 HPA(Horizontal Pod Autoscaler)를 참고 하세요.
https://happycloud-lee.tistory.com/199?category=832250

이상으로 15편에 걸친 쿠버네티스 쉽게 이해하기 시리즈를 마치도록 하겠습니다.
아무쪼록 제 글이 쿠버네티스를 배우는 여러분들에게 조금이나마 도움이 되셨으면 좋겠습니다.
수고 많으셨습니다.

쿠버네티스 쉽게 이해하기 시리즈 목차

저작자표시 비영리