22.6.08 k8s Keywords

Metricbeat

🤔  metric: 측정을 통하여 소프트웨어의 품질, 생산성 또는 개발 비용 등을 추정할 수 있는 척도.

메트릭 서버는 클러스터 전체의 리소스 사용 데이터를 집산한다. 각 노드에 설치된 kubelet을 통해 노드나 컨테이너의 cpu, 메모리 사용량 같은 메트릭을 수집.

Metricbeat는 시스템 및 서비스에서 메트릭을 수집하는 경량 수집기다.

Linux, Windows, Mac 호스트에 배포하고 Elasticsearch와 연결하면 시스템의 cpu사용률과 메모리, 파일 시스템, 디스크 IO, 네트워크 IO에 대한 통계와 시스템에서 실행되는 모든 프로세스에 대한 통계를 확인하고, 가볍게 전송할 수 있다.

Metricbeat는 무료 라이센스이며, 시계열 (장비)모니터링의 경우 elasticsearch와의 조합으로 사용하기 용이하다. 데이터를 쌓을 때 doc하나에 다양한 metric을 한번에 쌓기 때문에 데이터 구조가 효율적이며, 쌓은 지표에 대한 검색 성능이 뛰어나다. 또한 es에 시계열로 metric을 적재할 스키마를 본인들이 알아서 생성해 주는 것도 장점이다. 더불어 kibana 대시보드도 자동으로 생성할 수 있기 때문에 직관적으로 오버뷰 지표들을 살펴볼 수 있다.

CPU, MEM,DISK,NETWORK같은 물리 장비에 대한 metric 수집 뿐만 아니라 JMX 지원으로 인해 JVM기반 기술들도 상당수 수집이 가능하다.

• 제공되는 모듈 예시

System, Aerospike, Apache, Ceph, Couchbase, Docker, Dropwizard, Elasticsearch

Etcd, Golang, expvar, HAProxy, HTTP, json, Jolokia, jmx, Kafka, Kibana, Kubernetes

Logstash, Memcached, MongoDB, dbstats, MySQL, Nginx, PHP_FPM, PostgreSQL

RabbitMQ, Redis, vSphere, Windows, ZooKeeper

http://www.kwangsiklee.com/2018/04/메트릭비트metricbeat로-시스템-모니터링-하기/

kafka

대용량, 대규모 데이터를 빠르게 처리하도록 개발된 구독형 분산 메시징 플랫폼이다.

실시간 로그 스트리밍을 위해 특별히 제작되었으며, 여러 소스에서 데이터 스트림을 처리하고 여러 사용자에게 전달하도록 설계되었다. 초당 수백만 개의 데이터 포인트를 처리할 수 있어 빅데이터 과제에 적합하다. 카프카는 잔여 메모리를 사용해 디스크 Read/Write를 하지 않고, 페이지 캐시를 통하기 때문에 처리 속도가 매우 빠르다.

카프카를 사용하면 클러스터를 활용해 확장성을 높일 수 있고, 스케일 아웃으로 고가용성을 갖추고, 높은 처리량을 통한 실시간 스트리밍이 가능하다.

서로 다른 구성 요소 간의 안정적인 데이터 교환, 애플리케이션 요구 사항 변경에 따라 메시징 워크로드를 분할하는 기능, 데이터 처리를 위한 실시간 스트리밍, 데이터/메시지 재생에 대해 지원한다.

쿠버네티스로 카프카를 확장하는 것은 이상적인 방식인데, 카프카의 배포, 설정, 관리 및 사용을 간소화 할 수 있기 때문이다. 또한 쿠버네티스의 확장성과 고가용성, 이식성 및 배포 편의성도 활용할 수 있다.

카프카 도입 이전에는 point to point 방식으로, 데이터 전송 라인이 많아 배포 및 장애 대응이 어렵고, 데이터 포맷의 변경 사항이 생길 때 유지 보수가 어려웠다.

카프카 도입은 중간에 Topic을 마련해(Pub/Sub 방식) 특정 토픽이나 이벤트에 대한 통지를 비동기 방식으로 받을 수 있게 해준다. publisher가 Topic에 메시지를 보내면 해당 topic을 구독하는 모든 사용자들에게 메시지가 전송된다.

Zookeeper

분산 코디네이션 서비스(분산 시스템에서 시스템간의 정보 공유, 상태 체크, 서버들 간의 동기화를 위한 락 등을 처리해줌)를 제공하는 오픈소스 프로젝트. 분산 작업을 제어하기 위한 트리 형태의 데이터 저장소다.

zookeeper를 사용해 멀티 kafka Broker들 간의 정보를 공유, 동기화를 진행한다.

브로커의 목록/설정을 관리할 수 있고, zookeeper 없이는 kafka가 작동할 수 없으며, zookeeper는 홀수의 서버로 작동하게 되어있다.

Leader(writes)와 나머지 Follower(reads) 서버로 되어있다.

cf) 카프카는 크게 프로듀서, 브로커, 컨슈머, 주키퍼로 구성된다.

• 프로듀서: 카프카와 통신하면서 메시지를 보내는 역할, 데이터를 만들어낸다.
• 브로커: 카프카 애플리케이션이 설치되어 있는 서버 또는 노드를 지칭
• 컨슈머: 카프카와 통신하면서 메시지를 가져오는 역할, 데이터를 소비한다.
• 주키퍼: 분산 애플리케이션 관리를 위한 코디네이션 시스템. 분산된 노드의 정보를 중앙에 집중하고 구성관리, 그룹 네이킹, 동기화 등의 서비스를 수행한다. 카프카는 여러 브로커들의 클러스터링을 위해 주키퍼를 사용하여 브로커의 추가 및 장애상황 대응을 간단하게 할 수 있다.

elasticsearch

Apache Lucene(모든 검색 엔진의 시초) 기반의 Java 오픈소스 분산 검색 엔진. 텍스트, 숫자, 위치 기반 정보, 정형 및 비정형 데이터 등 모든 유형의 데이터를 검색, 분석할 수 있다. 단독으로 사용하기보다는 ELK 스택이라고 부르는 Logstash, Kibana, Beats를 추가적으로 사용.
컨테이너가 떴을 때 로그를 보고 싶으면 실제로는 파일로 노드에 남겨져 있다. 그런데 컨테이너가 죽으면 로그도 죽으므로 엘라스틱 서치에 쌓아놓게 한다. 그렇게 쌓인 데이터들을 확인하는 용도.

기본적으로 HTTP 프로토콜로 접근이 가능한 REST API를 통해 데이터 조작을 지원한다.

RDB는 행을 기반으로 데이터를 저장하나, ES는 단어를 기반으로 (역인덱스, Inverted Index) 저장한다.

NoSQL의 일종으로 분류할 수 있고, 분산처리를 통해 실시간성으로 빠른 검색이 가능하다. 기존 데이터로 처리하기 힘든 대량의 비정형 데이터 검색이 가능하며, 전문 검색과 구조 검색 모두를 지원한다.

kibana

elasticsearch는 restful한 속성과 json 문서 기반의 통신을 지원하므로 http 프로토콜을 사용해 어떤 클라이언트와도 손쉽게 연동할 수 있다.

kibana는 elasticsearch를 연결해 쉽게 시각화하고, elastic stack을 탐색하여, 쿼리 부하 추적부터 앱을 통해 요청이 흐르는 방식을 진행할 수 있도록 만들어진 데이터 시각화 플랫폼이다. 로그와 시계열 분석, 애플리케이션 모니터링, 운영 인텔리전스 사용 사례에 사용되어 데이터 시각화 및 탐색을 담당한다.

• Discover: elasticsearch에 색인된 소스 데이터들의 검색을 위한 메뉴다. 데이터를 간편하게 검색, 필터링할 수 있으며, 검색된 데이터의 원본 문서를 확인하거나 보고 싶은 필드만 선택해서 테이블 형태로 조회 가능 하다.
• Visualize: aggregation 집계 기능을 통해 조회된 데이터의 통계를 다양한 차트로 표현할 수 있는 패널을 만드는 메뉴다. 다양한 시각화 도구를 사용할 수 있고, 여기서 만들어진 패널을 조합해 대시보드를 만든다.
• Dashboard: Visualize 메뉴에서 만들어진 시각화 도구들을 조합해 대시보드 화면을 만들고, 저장, 불러오기 등을 할 수 있다. 검색창에 쿼리를 입력하거나 시각화 도구들을 클릭해서 조회할 데이터들의 필터링이 가능하고, URL로 대시보드를 다른 사람들과 공유하거나 json 형식으로 내보내기, 불러오기가 가능하다.

prometheus

현재 kubernetes 상에서 가장 많이 사용되는 오픈 소스 기반 모니터링 시스템이자, 시계열 DB의 한 종류.

간단한 텍스트 형식으로 메트릭을 쉽게 노출할 수 있고 데이터 모델은 key-value형태로 label 집계 후 Kibana/Grafana같은 대시 보드 시스템에서 그래프로 쉽고 간단하게 대시 보드를 만들 수 있다.

쿠버네티스 환경에서 전체 인프라 환경과 application에 대한 모니터링이 중요해졌다. 전체적인 가시성을 확보해야 application의 가용성과 안정성을 확보할 수 있으며, 모니터링 결과를 통화 고도화된 cloud native system을 구축할 때 지표로 활용할 수 있다.

노드가 떴을 때 시계열로 퍼센트를 계속 저장하고 모니터링한다. 아주 다양한 시계열 정보가 저장되며, 치타에서는 필요한 경우 정보를 뽑아와서 사용한다.

Kube-state-metrics

쿠버네티스 사용 중에 운영 관점에서 다양한 메트릭 정보를 수집해 모니터링하거나, 특정한 상황(Pod의 장애 상황 발생)에 별도 채널로 알림을 발송할 필요가 있을 수 있다.

이런 경우, 쿠버네티스 클러스터 레벨에서 워커노드로 사용중인 서버의 CPU, 메모리, 디스크 뿐만 아니라 쿠버네티스 클러스터 내부의 Pod가 사용중인 리소스 메트릭과 네트워크 IO, Deployment 개수, Pod 개수 등의 다양한 정보를 수집해야 한다.

kube-state-metrics는 위와 같은 다양한 메트릭을 수집해서 데이터를 /metrics라는 HTTP 엔드포인트로 제공해준다. (디폴트 포트는 8080)

kube-state-metrics/docs at master · kubernetes/kube-state-metrics

Node-exporter

Prometheus Node Exporter는 UNIX계열 커널을 가진 하드웨어의 상태와 서버 시스템(cpu, loadAvg, memory) 및 네트워크 관련 정보들을 나타내는 수집기다. 쿠버네티스의 DaemonSet 리소스로 정의되어 있다. 쿠버네티스의 각 노드들에 node-exporter가 설치 된다.

node-exporter는 설치된 노드의 CPU, 메모리, 네트워크 같은 호스트 관련 메트릭을 수집해 API로 노출한다. 모니터링을 위해 host system에 접근해야 하기 때문에 도커 컨테이너로 배포되는 것은 적절하지 않다고 한다.
https://github.com/prometheus/node_exporter

Node feature discovery

NFD는 플랫폼의 하드웨어 및 시스템 구성을 감지하고 알리는 쿠버네티스 추가 기능으로, 이를 통해 워크로드의 지능적인 스케쥴링을 용이하게 할 수 있다. 쿠버네티스에 대한 노드 기능 검색이 가능하며, 쿠버네티스 클러스터의 각 노드에서 사용 가능한 하드웨어 기능을 감지하고, 노드 레이블을 사용해 해당 기능을 알려준다.

아래 3가지 소프트웨어 컴포넌트로 구성되어 있다.

nfd-master: 쿠버네티스 API에 대한 통신을 담당하는 데몬. nfd-worker로부터 레이블링 요청을 수신하고 그에 따라 노드 객체를 수정한다.

nfd-worker: 기능 감지를 담당한다. 그 다음 실제 노드 레이블링을 수행하는 NFD-master에 정보를 전달한다. nfd-worker의 한개 인스턴스는 클러스터의 각 노드에서 실행 되어야 한다.

nfd-topology-updater: worker 노드에 할당 된 리소스를 검사해 영역별로 새 파드에 할당할 수 있는 리소스를 조사하는 데몬이다. 그 다음 클러스터의 모든 노드에 해당하는 NodeResouceTopology CR을 생성하는 nfd-master에 정보를 전달한다. nfd-topology-updater의 한 개 인스턴스는 클러스터의 각 노드에서 실행 되어야 한다.
https://github.com/kubernetes-sigs/node-feature-discovery

Istio

개발과 운영 과정에서 컨테이너의 연결, 트래픽 관리, 모니터링 및 보안과 같은 중앙컨트롤러 역할을 하도록 쿠버네티스 클러스터에서 구성 가능한 서비스 메시 툴이다.

Public Cloud 환경의 K8s Web Application 배포에서, 외부에서 접근할 수 있도록 Ingress Controller를 사용한다. 여러 개의 서비스를 노출해야 하는 상황에서, 모든 Service를 Loadbalancer 타입으로 생성하기엔 비용과 흩어진 Entrypoint 등의 문제가 발생한다.

이런 문제를 해결하기 위해 Ingress Controller를 최전선에 두고 Ingress Rule을 추가하여 Hostname과 Path에 따라 지정된 서비스로 Routing할 수 있다. 다만 K8s에서 기본적으로 제공하지 않고 Third-party App(ex: ALB, Nginx, Traefik)을 통해 이러한 기능이 제공된다.

Istio는 여기서 한층 더 발전해 Service Mesh의 경계에서 Inbound/Outbound 트래픽을 처리할 수 있는 Loadbalancer를 제공하며, 이를 'Gateway'라는 Istio Resource로 설정할 수 있다.

(오픈소스이므로 어떤 클러스터 소프트웨어에서도 실행할 수 있지만, 가장 널리 사용되는 use case는 쿠버네티스에서의 사용이다.)

Istio는 온프레미스, 클라우드 호스팅, k8s 컨테이너, 가상 머신에서 실행되는 서비스 등 다양한 환경에서 구동되도록 설계되었다.

🤔  서비스 메시 : 보안, 로드밸런싱, 모니터링, HealthCheck, 서킷 브레이커, 트래픽 처리 로직 등 서비스간의 통신을 인프라 내부에서 추상화를 통해 기능 제공 하는 것을 서비스 메시라고 한다.

Filebeat

경량 데이터 전송기.

많은 애플리케이션들이 생성하는 로그 파일들을 하나의 서버에 일일이 ssh 터미널을 이용해 로그 파일을 수집하는 것은 비합리적이다. 이에 로그 및 파일을 경량화된 방식으로 전달하고, 중앙 집중화 하여 작업을 보다 간편하게 만들어주는 producer인 Filebeat를 사용할 수 있다.

Filebeat는 지정한 로그 파일 또는 위치를 모니터링해 로그 이벤트를 수집하고, 다음 인덱싱을 위해 Elasticsearch 또는 Logstash(다양한 플러그인을 이용하여 데이터를 수집)로 전달한다.

grafana

시계열 데이터에 대한 대시보드를 제공해주는 오픈소스 메트릭 데이터 시각화 도구.

다양한 DB를 연결하여 DB 데이터를 가져와 시각화할 수 있으며, 그래프를 그리는 방법도 간단히 마우스 클릭으로 완료할 수 있다.

다양한 플러그인이 있어 내부적으로 쉽게 기능 확장도 가능하다.

dcgm exporter

NIVIDIA에서 제공하는 Tesla 시리즈의 그래픽 카드를 장착한 클러스터 또는 데이터센터 환경에서 비교적 가벼운 cost로 GPU를 모니터링하게 해주는 역할을 한다.

GPU 메트릭을 수집하고, 워크로드 동작을 이해하거나 클러스터의 GPU를 모니터링할 수 있는 NVIDIA DCGM에 대한 Go API를 기반으로 하는 도구. Prometheus와 같은 모니터링 솔루션을 위해 HTTP 엔드포인트에서 GPU 메트릭을 노출한다.

독립적으로 컨테이너에서 실행하거나, k8s 클러스터의 GPU 노드에 데몬 세트로 배포할 수 있다.

argo workflow

쿠버네티스 위에서 동작하는 workflow engine이다. 워크 플로우란 작업의 흐름으로서, 기계 학습이나 데이터 처리를 위해 컴퓨팅 집약적인 작업을 단시간에 실행할 수 있도록 해준다. 쿠버네티스 CRD(Custom Resource Definition)으로 구현된다.

원하는 Job을 구성해 각 Job간의 종속성을 부여하고 순서대로 실행할 수 있다. 또한 병렬로 여러 Job을 동시에 실행할 수도 있다.

• 동작 방법
  1. 사용자가 YAML DAG 명세를 작성하여 쿠버네티스 마스터에 요청.
  2. 쿠버네티스 API 서버가 명세를 받아 etcd DB에 workflow 정보를 저장.
  3. Argo controller가 reconcilation loop에서 etcd DB의 새로운 정보를 확인하고 kube-scheduler에 필요한 Pod를 요청.
  4. kube-scheduler는 Pod를 적절한 노드에 스케줄링.
  5. Argo controller가 다음번 reconcilation loop에서 다음 dependency가 걸려 있는 Job을 요청.
• 장점
  1. 실행 단위가 컨테이너이므로 고립성이 높다. 따라서 개별 Job마다 실행 환경이 다양해도 서로 엉키지 않고 단독적으로 실행 환경을 제공할 수 있다.
  2. 하나의 역할만을 담당하는 Job을 단일하게 개발할 수 있기 때문에 재사용성을 높일 수 있다.
• 단점
  1. Pod를 생성하고 삭제하는 비용이 적지 않아 작은 일을 처리하는 Job을 많이 생성할 경우 오히려 성능 저하가 발생할 수 있다. 이 경우에는 차라리 프로세스, 쓰레드 레벨에서 처리하는 것이 효율적일 수도 있다.
  2. 각 스탭마다 개별 컨테이너를 실행하므로 Job간의 데이터를 빠르게 공유하는 것이 비교적 힘들다.