Search
Duplicate
📒

[Kubernetes Infra] 07-1. 모니터링/로깅

상태
완료
수업
Kubernetes Infra
주제
4 more properties
참고

쿠버네티스 모니터링

NOTE
쿠버네티스는 Metric(수집지표)를 통해서 자원들을 모니터링한다!
쿠버네티스 메트릭은 크게 4가지로 구분된다.
쿠버네티스 기반의 시스템을 모니터링하기 위해서는 크게 아래와 같이 4가지 계층을 모니터링해야 한다.
1.
Host
쿠버네티스의 클러스터를 구성하는 모든 노드의 Host에 대한 CPU, 메모리, 디스크.. 등을 모니터링한다.
2.
Container
노드에서 실행중인 컨테이너의 CPU, 메모리, 디스크 등을 모니터링한다.
3.
Application
컨테이너에서 구동되는 개별 애플리케이션에 대한 모니터링
ex) 컨테이너에서 가동되는 node.js 기반의 애플리케이션의 http 에러 빈도
4.
Kubernetes
컨테이너를 관리하는 쿠버네티스 자체에 대한 모니터링
ex) 쿠버네티스의 Service, Pod, 계정 정보 등이 포함됨

쿠버네티스 로그(logs)

NOTE
쿠버네티스의 마스터, 워커 노드로부터 수집되는 System Metrics 모니터링을 담당한다!
kubectl logs [파드 이름] kubectl logs -f [파드 이름] # 실시간 확인용도 kubectl logs -f [파드 이름] -c [컨테이너 이름] k logs busybox -c busybox-container-1 # -c(내부 컨테이너 로그출력하기) k logs busybox -c busybox-container-2 k logs busybox -c busybox-container-3
Bash
복사
로그확인 명령어 예시

프로메테우스를 사용한 모니터링

NOTE
쿠버네티스의 마스터, 워커 노드로부터 수집되는 System Metrics 모니터링을 담당한다!
cAdvisor
모든 워커노드의 Kubelet에서 자체적으로 내장하고 있으며, 노드와 컨테이너에 대한 정보를 전달해준다.
cAdvisor에 의해 수집되는 메트릭은 heapster라는 중앙집중화된 지표 수집 시스템에 모이게되고, heapster는 수집된 메트릭을 백엔드에 저장한다.
이렇게 저장된 모니터링 지표는 그래프와 같은 형태로 시각화가 가능하다. (Prometheus , Grafana)

프로메테우스 설치

# 헬름차트 다운 git clone https://github.com/kubernetes/charts # 프로메테우스 디렉토리 이동 cd charts/stable/prometheus # 프로메테우스 설치 helm install -f values.yaml stable/prometheus --name prometheus --namespace prometheus # pod 확인 kubectl get pod -n prometheus # 프로메테우스 포트 9090 노출 kubectl port-forward -n prometheus [프로메테우스 pod이름] 9090
Bash
복사
Helm을 통한 프로메테우스 설치

그라파나 설치

# 그라파나 디렉토리 이동 cd charts/stable/grafana # 그라파타 설치 helm install -f values.yaml stable/grafana --name grafana --namespace grafana # 그라파나 포트 3000 노출 kubectl port-forward -n grafana [그라파나 Pod이름] 3000
Bash
복사

로그 확인하기(사이드카 패턴)

NOTE
노드가 컨테이너 로그를 처리하는 방법
컨테이너화된 애플리케이션의 stdout(표준 출력), stderr(표준 에러) 스트림에 의해 생성된 모든 출력은 컨테이너 런타임이 처리하고 재전송시킨다.
kubectl logs를 통해 로그확인 가능
logrotate는 리눅스 시스템에서 로그 파일의 관리를 자동화해주는 도구이다.
로그 파일을 주기적으로 회전, 압축, 삭제, 백업해준다.

클러스터 레벨의 로깅

클러스터 레벨의 로깅 방법중 하나인 로그-에이전트 사용
각 노드에 노드-레벨 로깅 에이전트를 포함시켜 클러스터-레벨 로깅을 구현할 수 있다.
로깅 에이전트는 해당 노드의 모든 애플리케이션 컨테이너에서 로그 파일이 있는 디렉토리에 접근할 수 있는 컨테이너다.
로깅 에이전트는 모든 노드에서 실행되어야 하므로 Daemonset 형식이 권장된다.
ex) Prometheus node-exporter, Elastic Filebeat
사이드카 패턴 - 주 컨테이너 옆에 배치되어 운영되는 보조 컨테이너
사이드카 패턴
사이드카 컨테이너가 자체 stdout, stderr 스트림으로 기혹하도록 하면, 각 노드에서 이미 실행중인 kuebelet과 로깅 에이전트를 활용할 수 있다.
사이드카 컨테이너는 파일, 소켓, journaId에서 로그를 읽는다.
apiVersion: v1 kind: Pod metadata: name: app namespace: elastic-stack labels: name: app spec: containers: - name: app # 첫 번째 컨테이너의 이름 image: kodekloud/event-simulator # 첫 번째 컨테이너의 이미지 (이벤트 시뮬레이터) volumeMounts: # 볼륨 마운트 정보 - mountPath: /log # 컨테이너 내 마운트 경로 name: log-volume # 참조할 볼륨의 이름 - name: sidecar # 두 번째 컨테이너(사이드카 패턴 사용)의 이름 image: kodekloud/filebeat-configured # 두 번째 컨테이너의 이미지 (파일비트 로그 수집기) volumeMounts: # 볼륨 마운트 정보 - mountPath: /var/log/event-simulator/ # 컨테이너 내 마운트 경로 name: log-volume # 참조할 볼륨의 이름 volumes: # Pod 레벨에서 사용할 볼륨 정의 - name: log-volume hostPath: # 호스트 경로 볼륨 유형 path: /var/log/webapp # 노드에서 볼륨 데이터가 저장될 경로 type: DirectoryOrCreate # 경로가 없는 경우 새 디렉터리를 생성
YAML
복사