- Facts
: 배운것 - 로깅과 모니터링 - Findings
:
로깅
- 로컬 파일 시스템의 지정된 위치에 파일로 로그를 저장하도록 구성
- 로그를 일정 시간 이상 저장했거나 로그가 일정 용량이면 오래된 로그를 자동으로 삭제
- 특정 앱 컨테이너의 로그를 확인하려면 전체 클러스터의 노드 중 어떤 노드에 해당 컨테이너가 실행되었는지 확인해야 로그도 확인 가능
- 파드 로그 확인 : kubectl은 개별 노드에 접근하지 않고 직접 파드의 로그를 확인
- 로그를 모아 살펴보도록 하는 오픈 소스 도구로는 카프카, 플루언트디, 로그스태시, 일래스틱서치, 키바나 등
- 일래스틱서치 : 클러스터 형태로 여러 대 노드에서 실행하도록 개발한 검색 엔진 시스템
- 키바나 : 일래스틱서치 전용 대시보드 UI로 일래스틱서치의 데이터를 검색하므로 접근할 도메인을 알아야함
- 클러스터 레벨 로깅 : 생명 주기와 분리된 스토리지를 구축하는 아키텍처
- 플루언트디 : 쿠버네티스와 같은 CNCF에서 관리하는 범용 로그 수집용 오픈소스 프로젝트. 루비 기반으로 개발했고 다양한 플러그인을 사용. 쿠버네티스 이외의 인프라 환경에서도 사용할 수 있지만 같은 CNCF에서 관리하므로 쿠버네티스와의 연계가 잘 되어 있다.
- 스턴 : 실시간 로그 모니터링 도구. 셸에서 바로 여러 개 파드의 로그를 실시간으로 볼 수 있어 서비스 개발을 진행하는 중 파드 상태를 확인할 때 유용
쿠버네티스 모니터링 아키텍처
- 시스템 메트릭 : 노드나 컨테이너의 CPU, 메모리 사용량 같은 시스템 관련 메트릭
코어 메트릭 : 쿠버네티스 내부 컴포넌트들이 사용하는 메트릭
비코어 메트릭 : 쿠버네티스가 직접 사용하지 않는 다른 시스템 메트릭
- 서비스 메트릭 : 애플리케이션을 모니터링할 때 필요한 메트릭
쿠버네티스 인프라 컨테이너에서 수집하는 메트릭 : 클러스터를 관리할 때 참고해 사용
사용자 애플리케이션에서 수집하는 메트릭 : 웹서버 응답 시간 관련 값이나 시간당 HTTP 500 에러가 몇 건이나 나타났는지 등 서비스 관련 정보를 파악
- 코어 메트릭 파이프라인 : 쿠버네티스 관련 구성 요소를 직접 고나리하는 파이프라인. 코어 시스템 메트릭을 수집해 핵심 요소의 모니터링을 담당
cAdvisor : 노드/파드/컨테이너의 사용량 정보를 수집
메트릭 서버 : 이 정보들을 kubeletㅇ서 불러와 메모리에 저장
메트릭 API : 다른 시스템 컴포넌트가 조회할 수 있다.
- 모니터링 파이프라인 : 기본 메트릭을 포함한 여러 가지 메트릭을 수집. 시스템 메트릭과 서비스 메트릭 모두 수집 가능
메트릭 서버
- 쿠버네티스 모니터링 아키텍처에서 코어 메트릭 파이프라인을 효율적으로 사용하려고 힙스터 대신 모니터링 표준으로 도입.
- 힙스터를 간소화한 것.
- kubelet으로 수집해 메모리에 저장한 파드나 노드의 메트릭 데이터를 kube-apiserver로 조회하는 메트릭 API를 제공
- 메트릭 서버용으로 실행한 파드를 재시작하면 수집됐던 데이터가 사라짐
- 프로메테우스 : 모니터링 도구로 시계열 데이터를 저장할 수 있는 다차원 데ㅣ터 모델과 데이터 모델을 효과적으로 화용할 수 있는 PromQL이라는 쿼리언어가 있다. 기본적인 모니터링 데이터 수집은 프로메테우스 서버가 수집하려는 대상에서 데이터를 가져오는 풀 구조
- 그라파나 : 대시보드 도구로 프로메테우스의 기본 웹 UI 이외에 저장된 모니터링 데이터 조회 시 이용
<수업 메모>
볼륨
- 쿠버네티스는 파드 삭제 시 데이터가 함께 삭제 (데이터가 영구적이지 않다)
- 데이터를 영구적으로 저장 / 컨테이너끼리 데이터 공유를 위해 사용 (볼륨)
- 기본적으로 볼륨의 경우 해당 스토리지에 대한 지식이 필요
- 일반적으로 개발자(일반사용자) 들은 스토리지 지식이 부족
- 스토리지 지식이 없이도 사용할 수 있도록 PV 와 PVC 로 나누어 사용
- 사용자는 PVC 에서 필요한 크기를 요청만 하도록 구성
- 관리자가 직접 PV 를 만들어주는 방식 (정적인 볼륨)
- 매번 PV 를 직접 만들기 힘들어서 자동으로 생성 ( 동적인 볼륨 프로비저닝 방식 )
- 사용자가 PVC 생성 시 SC 를 지정 (이름)
- SC 에 대한 구성 및 실제 스토리지에 대한 구성을 미리 준비
- 볼륨 사용 시에는 필요에 따라 STS 로 파드 구성
네트워크
- 기본적으로 도커의 브릿지 타입과 유사한 형태
- 컨테이너들이(하나의 파드) 서로 동일한 네트워크를 공유 ( ->링크 )
- pause 컨테이너가 항상 동작 ( 사용자 컨테이너를 재시작해도 동일한 IP 사용 )
- 노드 여러 개에서 파드들이 동작하기 때문에 파드의 IP 주소에 대한 라우팅(NAT) 설정이 필요
- CNI (플러그인) 가 위와 같은 역할 수행
DNS
- 기본적으로 쿠버네티스는 클러스터 내부적인 DNS 서비스를 제공
- kubedns 를 사용하다가 coredns 로 변경
- nodeLocalDns 를 이용해 부하 감소
- 각 파드 생성 시 /etc/resolv.conf 파일에는 nodeLocalDns 주소가 설정
- 클러스터 내부 도메인
대상의이름 . 네임스페이스이름 . 오브젝트종류 . 클러스터도메인
-> webpod.default.pod.cluster.local / lb.default.svc.cluster.local
로깅
- 시스템 및 어플리케이션 등에서 발생하는 각종 이벤트를 기록 및 처리
- 기본적인 운영체제에서는 로컬 스토리지의 지정된 경로에 파일 형태로 저장
-> 클러스터 운영 환경에서는 좋지않다.
- logrotate 와 같은 도구를 통해 이러한 로그 처리 기능 제공 ( 오래된 로그 제거 )
- 쿠버네티스에서도 기본적으로 로컬 스토리지를 사용 ( /var/log/containers , /var/log/pods )
- 파드가 동작하는 해당 노드에서 확인
- 명령어로도 확인 가능 ( kubectl logs XXX )
- 기본적인 구성으로는 파드가 삭제될 경우 로그까지 함께 제거 (오래된 경우도 제거)
- 파드가 없으면 로그 확인이 불가능
- 로그를 중앙 시스템에서 모아서 관리하는 방식의 로그 처리 방식 고려
ELK 구성
- ElasticSearch
- Logstash
- Kibana
EFK 구성
- ElasticSearch
- Fluentd
- Kibana
Elastic Stack
- ElasticSearch
- Logstash + Beat
- Kibana
ElasticSearch : 검색엔진 + 분석기능
Logstash / Fluentd : 로그를 수집 + 필터링
Kibana : 시각화 (+ 관리기능)
Beat : 각각의 어플리케이션에서 데이터 수집을 할 수 있게 기능 제공
모니터링
시스템 메트릭 - 노드 / 컨테이너 들의 CPU / RAM 사용량을 측정
코어 메트릭 : 일반으로 쿠버네티스에 의해 사용 중인 메트릭
비 코어 메트릭 : 쿠버네티스 이외에 사용하는 메트릭
서비스 메트릭 - 어플리케이션에서 수집하는 메트릭 정보
코어 메트릭 파이프라인
- 쿠버네티스 관련 요소를 직접 관리
- 스케줄러나 HPA 등에서 활용
- 메모리에 저장하므로 단기간 보관 가능
모니터링 파이프라인
- 쿠버네티스에서 직접 관리 X
- 사용자에게 필요한 모니터링 정보 제공
- 외부 시스템을 통해 관리
Heapster -> Promethous
'GOORM' 카테고리의 다른 글
GOORM: Kubernetes-49 (0) | 2022.01.09 |
---|---|
GOORM: Kubernetes-48 (0) | 2022.01.09 |
GOORM: Kubernetes-46 (0) | 2022.01.07 |
GOORM: Kubernetes-45 (0) | 2022.01.07 |
GOORM: Kubernetes-44 (0) | 2022.01.07 |
댓글