개요

kube-burner는 쿠버네티스 클러스터의 성능을 테스트하는 도구로 불내는데(?) 유용하다.
쿠버네티스 Go 클라이언트 라이브러리인 client-go를 이용에 테스트에 용이하도록 기능을 만든 어플리케이션이다.

기본적으로 api 서버에 대한 여러 요청을 날릴 수 있고 프로메테우스 기반 모니터링, 측정, 알람 기능도 갖추고 있다.
테스트에 사용할 양식 파일을 먼저 만들고, 이후에 kube-burner에서 지원하는 커스텀 리소스 양식으로 이를 참조한 뒤에 사용한다.
그래서 원하는 테스트 상황을 마음대로 만들 수 있다는 장점이 있다.

사용법

사용할 커맨드가 많지 않다.

check-alerts Evaluate alerts for the given time range 주어진 시간 범위 내의 알람 평가
completion   Generates completion scripts for bash shell
destroy      Destroy old namespaces labeled with the given UUID. 사용된 네임스페이스 삭제
health-check Check for Health Status of the cluster 클러스터 헬스체크
help         Help about any command
import       Import metrics tarball tarball 압축 파일에서 메트릭 불러오기
index        Index kube-burner metrics 메트릭 인덱싱(start, end 시간으로 범위 지정)
init         Launch benchmark 벤치마크 실행
measure      Take measurements for a given set of resources without running workload 워크로드 실행 없이 리소스만 테스트
version      Print the version number of kube-burner 

보다시피 init이 벤치마킹을 수행하는 명령어이다.
여기에 -c 옵션으로 설정 파일을 넣어서 실행한다.

벤치마킹의 반환 코드는 다음의 뜻을 가진다.

• 0 - 정상 종료
• 1 - 회복 불가능 에러(api 인가, 파싱 실패 등)
• 2 - 타임아웃. --timeout 인자를 받았을 때 나옴
• 3 - 심각 레벨 알람이 발생할 때 나옴
• 4 - 임계값과 같은 측정치에서 조건을 넘겼을 때

설정 파일 작성법

go-template 양식의 파일을 지원한다.

metricsEndpoints:
{{ if .OS_INDEXING }}
  - prometheusURL: http://localhost:9090
    indexer:
      type: opensearch
      esServers: ["{{ .ES_SERVER }}"]
      defaultIndex: {{ .ES_INDEX }}
{{ end }}
{{ if .LOCAL_INDEXING }}
  - prometheusURL: http://localhost:9090
    indexer:
      type: local
      metricsDirectory: {{ .METRICS_FOLDER }}
{{ end }}

이때 파일은 크게 몇 가지 대범주의 필드로 작성한다.

• global
  • measurements - 측정할 값들에 대한 리스트.
  • gc - 생성된 네임스페이스 삭제 여부
  • timeout - 벤치마킹 타임아웃
  • requestTimeout - 단일 api 요청 타임아웃
• job - 벤치마킹 작업 단위
  • name
  • jobType - create, delete, read, patch
  • jobIterations
  • waitWhenFinished - 한 잡이 끝나고 순회돌지 여부
  • qps - 초당 오브젝트 요청 수(한 잡에서 api 서버로 쿼리 날리는 제한)
  • burst - 쓰로틀을 위한 동시 요청 수
  • objects - 생성할 오브젝트 리스트
    • objectTemplate - 오브젝트 파일 경로
      • read 유형의 잡일 때는 이거 대신 그냥 kind와 라벨 셀렉터만 써도 된다.
      • patch 유형의 잡일 때는 patchType으로 어떻게 패치할지 정하고, objectTemplate으로 패치 파일을 둔다.
        • delete 유형의 잡일 때는 kind를 써도 된다.
    • replicas
    • inputVars - 오브젝트에 넣을 임의 변수
    • wait
    • waitOptions - 어떤 오브젝트가 ready가 될 때까지 기다린 후 실행되며, 순서를 지정할 때 유용하다.
    • runOnce - 잡 순회 간 한번만 실행할 리소스라면 설정
  • watchers - 감시할 리소스 리스트
    • kind, apiVersion, labelSelector로 감시하고자 하는 대상을 지정하는 잡을 만든다.
    • replicas로 와쳐 리소스의 개수를 조절한다.
  • preLoadImages - 잡을 위해 모든 노드에 미리 사용될 이미지를 받는 데몬셋 배치 여부
  • executionMode - 잡 실행모드
    • parallel, sequential

위 4가지 유형의 잡타입 말고, churn이란 동작을 하는 것도 가능하다.

jobs:
- name: cluster-density
  jobIterations: 100
  namespacedIterations: true
  namespace: churning
  churn: true
  churnPercent: 20
  churnDuration: 2h
  churnDelay: 0s
  objects:
  - objectTemplate: deployment.yml
    replicas: 10
  - objectTemplate: service.yml
    replicas: 10

churn은 이전 오브젝트를 지우고 재생성하는 동작이다.
잡 순회를 하며 이전 오브젝트를 일부 지우고 그대로 새로 리소스를 만드는 식으로 동작한다.
휘젓는 느낌이라 churn으로 부르는 모양이다.

오브젝트 파일

기본으로 오브젝트에 주입되는 변수는 다음과 같다.

• Iteration
• Replica
• Jobname
• UUID
• RunID

설명은 생략하고 사용예시만 본다.

apiVersion: v1
kind: Service
metadata:
  name: sleep-app-{{.Iteration}}-{{.Replica}}
  labels:
    name: my-app-{{.Iteration}}-{{.Replica}}
spec:
  selector:
    app: sleep-app-{{.Iteration}}-{{.Replica}}
  ports:
  - name: serviceport
    protocol: TCP
    port: "{{.port}}"
    targetPort: "{{.targetPort}}"
  type: ClusterIP

여기에 여러 함수를 사용할 수 있는데, 기본 고랭 템플릿과 sprig 라이브러리[^1]의 함수들이 지원된다.

측정 지표

위의 measurements에서 설정할 수 있는 지표는 여러 가지가 있다.
기본적으로 지표를 넣으면 측정 수치가 나온다(아래는 podLatency 예시).

{
  "timestamp": "2020-11-15T20:28:59.598727718Z",
  "schedulingLatency": 4,
  "initializedLatency": 20,
  "containersReadyLatency": 2997,
  "podReadyLatency": 2997,
  "metricName": "podLatencyMeasurement",
  "uuid": "c40b4346-7af7-4c63-9ab4-aae7ccdd0616",
  "namespace": "kubelet-density",
  "podName": "kubelet-density-13",
  "nodeName": "worker-001",
  "jobName": "create-pods",
  "jobIteration": "2",
  "replica": "3",
}

이에 대한 메트릭 지표는 다음과 같은 방식으로 합쳐진다.

{
  "quantileName": "Ready",
  "uuid": "23c0b5fd-c17e-4326-a389-b3aebc774c82",
  "P99": 3774,
  "P95": 3510,
  "P50": 2897,
  "max": 3774,
  "avg": 2876.3,
  "timestamp": "2020-11-15T22:26:51.553221077+01:00",
  "metricName": "podLatencyQuantilesMeasurement",
},
{
  "quantileName": "PodScheduled",
  "uuid": "23c0b5fd-c17e-4326-a389-b3aebc774c82",
  "P99": 64,
  "P95": 8,
  "P50": 5,
  "max": 64,
  "avg": 5.38,
  "timestamp": "2020-11-15T22:26:51.553225151+01:00",
  "metricName": "podLatencyQuantilesMeasurement",
}

자세한 측정 지표들에 대한 정보는 문서를 확인한다.[^2]

• podLatency
• jobLatency
• pvcLatency
• serviceLatency - 서비스의 엔드포인트들이 ready가 되면 시간을 재고, 이후 tcp 연결 수행을 하며 수치를 측정한다.
• netpolLatency - 두 개의 잡이 있을 때만 측정되는데, 예시를 참고하자.[^3]

하위 문서

관련 문서

EXPLAIN - 파생 문서

기타 문서

참고