44. Kubernetes Monitoring : HPA

 

 

 

Kubernetes Monitoring : HPA

 

---

[Kubernetes Monitoring 관련 글 목록]

Kubernetes Monitoring : Metrics
Kubernetes Monitoring : HAP

Kubernetes Monitoring : Prometheus 개념

Kubernetes Monitoring : Prometheus 설치

Kubernetes Monitoring : Grafana

---

 

 

HPA ( Horizontal Pod Autoscaler )을 실습하며 

Metrics-Server 동작을 확인해봄.

 

---

 

HPA (Horizontal Pod Autoscaler)란?

 

Metric 종류 중 System Metric에 해당하는 Node나 Container의 

CPU, 메모리 사용량 정보를 Core metric pipeline 방법으로 지속적으로 수집하며

해당 정보를 관찰함.

그 뒤 Replicaset, Deployment 등 Controller로 Pod을 개수를 자동으로 조절하는 역할을 수행함.

CPU등 리소스 사용량이 증가 하면 Pod 개수를 늘리고, 

리소스 사용량이 감소하면 다시 Pod 개수를 줄임. 

 

Horizontal Pod Autoscaler는 크기를 조정할 수 없는 Object (ex : DaemonSet, Service 등등)에는 적용되지 않음.

 

 

Metrics-Server와 HPA

kubernetes cluster를 구성한 뒤에 바로 HPA Test를 하면

Pod에 아무리 과부하를 줘도 HPA가 동작을 하지 않음.

그 이유는 Metrics-Server가 없기 때문.

Metrics-Server는 kubernetes에서 공식적으로 지원하는 Addon임으로

사용자가 Metrics-Server Addon을 별도로 설치해줘야함.

Metrics-Server가 정상적으로 배치가 되면 그때 HPA가 동작함.

 

Metrics-Server가 없는 상태에서 

kubectl top 명령을 해보면 아래와 같음.

Error from server (NotFound): the server could not find the requested resource (get services http:heapster:)

해당 Error msg는 Node에서 system metric을 수집하는 Metrics-Server가 없기 때문.

즉 Kubernetes cluster 구성 시 default로 있는 server가 아니고 

Metrics-Server를 별도로 추가적으로 구축해줘야함.

 

[ 참고]

kubernetes 에서 제공하는 Metrics-Server 이외에도

사용자가 custom metrics server 별도로 생성한 뒤 

hpa가 해당 custom metrics 정보를 바라보게 할 수도 있음.

https://sysdig.com/blog/kubernetes-autoscaler/

HPA 알고리즘

 

원하는 레플리카 수 = ceil[현재 레플리카 수 * ( 현재 메트릭 값 / 원하는 메트릭 값 )]

 

 

HPA Scale 확인 시간 간격 (HPA check interval)

기본 HPA 확인 간격은 30초. 

kube-controller 모듈의 horizontal-pod-autoscaler-sync-period 플래그를 통해 설정할 수 있음

기본 HPA metrics 정보 허용 오차는 10 %.

HPA는 Metric이 안정화 될 수 있도록 마지막 Scale 확장 후에 3 분 동안 대기함. 

해당 설정은 horizontal-pod-autoscaler-upscale-delay 플래그를 통해 설정할 수 있음

 

Core Metric Ppipline 방법으로 HPA 동작

 

자세한 설명은 Kubernetes Monitoring : Metric 글 참고

 

1. 모든 Worker Node의 cAdvisor에서 System Metric 정보를 수집.

2. cAdvisor는 수집한 정보를 kubelet으로 전송.

3. kubelet에 있는 System Metric 정보를 Metrics-Server가 받아와서 메모리에 저장함.

4. Metrics-Server에서는 System metric 정보를 사용하기 위해 Custom API를 k8s Aggregator를 통해 미리 API server에 등록해놓았음.

5. 등록된 Metrics API를 통해 수집된 System Metric 정보가 HPA로 전송됨.

6. 설정한 값에 따라 HPA에서는 kube-controller manager에 명령을 내림

7. 명령을 받은 kube-controller manager에서 pod을 scale-out 시킴

 

 

 

---

 

 

 

HPA 실습

 

Test 환경

 

Master Node server

 OS = CentOS 7

 리눅스 커널 버전 : Linux 3.10.0-1062.el7.x86_64

 docker version : 1.13.1

 api verison : 1.26

 

Worker Node server

 OS = CentOS 7

 리눅스 커널 버전 : Linux 3.10.0-1062.el7.x86_64

 docker version : 1.13.1

 api verison : 1.26

 

Kubernetes version

1.19.2

 

 

 

 

 

1. Metrics-Server Addon 설치

 

kubernetes에서 공식적으로 제공하고 있는 Addon인 Metrics-Server 설치 yaml을 받아옴.

참고 : https://github.com/kubernetes-sigs/metrics-server

 

[명령어]

wget https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.3.7/components.yaml

 

[결과]

 

 

 

2. Metrics-Server 인증서 수정

 

kubernetes cluster의 kube-apiserver와 통신할 때 사용하는 TLS 인증서를 수정해야함.

Metrics-Server는 Public TLS를 기본으로 하지만 kube-apiserver에서는 

kubernetes cluster에서 사용하는 TLS를 사용하기 때문에 

인증서 수정 작업을 해줘야함

즉 사용하는 인증서가 신뢰되지 않은 경우와 

호스트 이름을 찾지 못하는 경우를 방지하기 위해

배포하기 이전에 yaml파일을 수정해야함.

 

[명령어]

vi components.yaml

 

[수정 부분]

인증서 설정 부분에 아래 2개의 설정을 추가함.

 

          - --kubelet-insecure-tls

          - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname

 

 

 

 

3. Metrics-Server 배포

 

[명령어]

kubectl apply -f components.yaml

 

[결과]

생성되는 object중에서 중간쯤 보면 Metric API도 생성되는것을 확인할 수 있음

 

 

4. Metrics-Server 정상 배포 확인

 

[명령어]

kubectl top nodes

 

[결과]

Metrics-Server가 정상적으로 생성이 되면 kubectl top 명령이 정상 동작함.

 

 

5. HPA Test용 Deployment 생성

 

test용도로 사용했던 tomcat image

replicas를 1로 설정함.

resources 설정으로 cpu 자원 사용량을 제한걸어놓음

 

[test.yaml]

apiVersion: apps/v1 kind: Deployment metadata:   name: iksoon-deployment-tomcat   labels:     app: iksoon-tomcat-test spec:   replicas: 1   selector:     matchLabels:       app: iksoon-pod-tomcat   template:     metadata:       labels:         app: iksoon-pod-tomcat     spec:       containers:       - name: iksoon-tomcat         image: peksoon/iksoon_tomcat:1.0.6         ports:         - containerPort: 8080         resources:           limits:             cpu: 300m           requests:             cpu: 100m ---   apiVersion: v1 kind: Service metadata:   name: iksoon-tomcat-service spec:   ports:   - port: 8080     targetPort: 8080   selector:     app: iksoon-pod-tomcat

 

 

 

 

6. HPA 생성

 

Horizontal Pod Autoscaler 생성.

 

[test-HPA.yaml]

apiVersion: autoscaling/v1 kind: HorizontalPodAutoscaler metadata:   name: hpa-test spec:   scaleTargetRef:     apiVersion: apps/v1     kind: Deployment     name: iksoon-deployment-tomcat # deployment의 name이 와야함 # pod개수가 줄어들때 최소한으로 유지시킬 pod 수 설정   minReplicas: 1  # Autoscaler가 적용되서 pod개수를 증가시킬 때 최대 몇개까지 증가시킬지 설정   maxReplicas: 10   # CPU 사용량이 30%가 됐을 때 Autoscaler가 적용되도록 설정   targetCPUUtilizationPercentage: 30

[결과]

 

 

 

 

7. deployment 에 과부하를 줘서 Autoscaling 되는지 확인

 

기존 상태는 아래와 같이 

Pod는 1개만 생성되어 있고

HPA를 확인해보면 2%로 표시되어 있음.

 

 

해당 상태에서 tomcat Server에 과부하를 주겠음.

[명령어]

while true;do curl WAS주소;done

ex) while true;do curl 10.108.147.136:8080/iksoon_test/iksoon_home.jsp;done

 

해당 명령을 실행한 후 HPA를 확인해보면 TARGETS 가 158%로 늘어나고

그 순간 Pod가 점점 늘어남

 

 

과부하를 중단하면

이후 천천히 Pod가 줄어들고 

다시 최소 유지 pod 수로 돌아옴

 

 

 

 

 

---

제 글을 복사할 시 출처를 명시해주세요.
글에 오타, 오류가 있다면 댓글로 알려주세요! 바로 수정하겠습니다!

---

 

 

참고

https://kubernetes.io/ko/docs/tasks/run-application/horizontal-pod-autoscale/

https://github.com/kubernetes-sigs/metrics-server