쿠버네티스 모니터링 시스템과 아키텍처

모니터링 서비스 플랫폼

쿠버네티스를 지원하는 다양한 모니터링 플랫폼

쿠버네티스의 메트릭 수집 모니터링 아키텍처에서 코어메트릭 파이프라인 경량화
힙스터를 deprecated하고 모니터링 표준으로 메트릭서버(metrics-server) 도입

$ kubectl top node
NAME                                       CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
gke-cluster-1-default-pool-f6cef6fa-hbbq   82m          8%     1092Mi          41%
gke-cluster-1-default-pool-f6cef6fa-hmlx   67m          7%     935Mi           35%
gke-cluster-1-default-pool-f6cef6fa-m8cn   96m          10%    1037Mi          39%

$ kubectl top pod

리소스 모니터링 도구

쿠버네티스 클러스터 내의 애플리케이션 성능을 검사
쿠버네티스는 각 레벨에서 애플리케이션의 리소스 사용량에 대한 상세 정보를 제공
애플리케이션의 성능을 평가하고 병목 현상을 제거하여 전체 성능을 향상을 도모
리소스 메트릭 파이프라인
- kubectl top 등의 유틸리티 관련된 메트릭들로 제한된 집합을 제공
- 단기 메모리 저장소인 metrics-server에 의해 수집
- metrics-server는 모든 노드를 발견하고 kubelet에 CPU와 메모리를 질의
- kubelet은 kubelet에 통합된 cAdvisor를 통해 레거시 도커와 통합 후 metric-server 리소스 메트릭으로 노출
- /metrics/resource/v1beta1 API를 사용
완전한 메트릭 파이프라인
- 보다 풍부한 메트릭에 접근
- 클러스터의 현재 상태를 기반으로 자동으로 스케일링하거나 클러스터를 조정 ➢ 모니터링 파이프라인은 kubelet에서 메트릭을 가져옴
- CNCF 프로젝트인 프로메테우스가 대표적
- custom.metrics.k8s.io, external.metrics.k8s.io API를 사용

그림 출처: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/monitoring_architecture.md

Metrics-server 설치 방법

메트릭스 서버는 쿠버네티스에서 리소스 메트릭 파이프라인을 구성하는 가장 기본적인 방법이다
그러나 쿠버네티스를 설치한다고해서 메트릭 서버가 자동으로 설치되지는 않으므로 직접 설치하는 과정이 필요하다

다음 두 명령을 실행해 공개된 yaml 파일을 사용하여 metrics-server 사용할 수 있도록 yaml 파일을 적용한다

$ kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.4.0/components.yaml

여기까지 실행하면 metrics 서버는 돌지만 kubelet 에 접근해 포드와 노드의 정보를 얻어오지 못하는 현상이 일어난다

$ kubectl top nodes
error: metrics not available yet

이 현상은 tls 통신이 제대로 이뤄지지 않기 때문이므로 다음과 같이 metrics 서버의 내용을 수정하여 서버 통신이 원활하게 할 수 있도록 옵션을 바꾼다

메트릭스 디플로이의 설정을 변경하기 위해 다음 명령어 실행한다

$ kubectl edit deployments.apps -n kube-system metrics-server

yaml 파일 내부에서 args를 찾아가서 다음 설정 두 개 추가한다

참고 사이트: https://github.com/kubernetes-sigs/metrics-server/issues/300

아규먼트	설명
`- --kubelet-insecure-tls`	인증서가 공인 기관에 승인 받지 않은 안전하지 않기 때문에 보안적으로 취약하지만 무시하겠다는 의미
`- --kubelet-preferred-address-types=InternalIP`	kubelet 연결에 사용할 때 사용하는 주소 타입을 지정

추가된 다음의 모습은 다음과 같다
기존의 옵션은 유지하도록 한다

...
template:
  ...
  spec:
    containers:
    - args:
      - --cert-dir=/tmp
      - --secure-port=4443
      - --kubelet-insecure-tls # 추가된 옵션
      - --kubelet-preferred-address-types=InternalIP # 추가된 옵션
...

정보 수집에 시간이 걸리므로 1분 정도 지난 후 포드와 노드의 리소스를 요청하면 정상적으로 리소스를 모니터링 할 수 있다

포드의 리소스 질의를 해보자

$ kubectl top pod -n kube-system
NAME                              CPU(cores)   MEMORY(bytes)   
coredns-6955765f44-cfn8r          2m           21Mi            
coredns-6955765f44-qvw44          1m           16Mi            
etcd-master                       9m           47Mi            
kube-apiserver-master             19m          325Mi           
kube-controller-manager-master    4m           54Mi            
kube-proxy-9whjc                  1m           19Mi            
kube-proxy-d8cnw                  1m           17Mi            
kube-proxy-lnvvm                  1m           24Mi            
kube-scheduler-master             2m           22Mi            
metrics-server-6ffdb54684-v4tpv   1m           12Mi            
weave-net-7c9fc                   1m           59Mi            
weave-net-7qtwm                   1m           74Mi            
weave-net-dk9vb                   1m           65Mi

다음은 nodes의 리소스를 질의해보자

$ kubectl top nodes
NAME     CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%   
master   175m         8%     2880Mi          75%       
work1    29m          1%     2653Mi          69%       
work2    21m          1%     2319Mi          60%

메트릭스 서버가 잘 동작한다

연습문제

현재 가장 많은 CPU를 사용하는 포드는 무엇인가?
현재 가장 낮은 MEM을 사용하는 포드는 무엇인가?
각각의 포드 이름을 /tmp/maxcpu와 /tmp/minmem에 저장하라

728x90

저작자표시 비영리 변경금지