Google Cloud Managed Service for Prometheus를 사용하여 Kubernetes API 서버, 스케줄러, 컨트롤러 관리자에서 내보낸 특정 측정항목을 Cloud Monitoring으로 전송하도록 Google Kubernetes Engine(GKE) 클러스터를 구성할 수 있습니다. 이 문서에서는 이러한 측정항목을 Cloud Monitoring에 기록할 때 형식을 지정하는 방법과 이를 쿼리하는 방법을 설명합니다. 또한 이 문서에서는 각 집합의 측정항목을 나열하고 해당 측정항목을 사용하는 방법에 대한 정보를 제공합니다.
제어 영역 측정항목을 사용하려면 먼저 수집을 사용 설정해야 합니다.
측정항목 형식
Cloud Monitoring에 기록되는 모든 Kubernetes 제어 영역 측정항목은 prometheus_target 리소스 유형을 사용합니다.
각 측정항목 이름에는 prometheus.googleapis.com/ 프리픽스가 있고 /gauge, /histogram, /counter와 같은 Prometheus 측정항목 유형을 나타내는 서픽스가 있습니다. 그렇지 않으면 각 측정항목 이름은 오픈소스 Kubernetes에 의해 노출된 측정항목 이름과 동일합니다.
Cloud Monitoring에서 내보내기
제어 영역 측정항목은 Cloud Monitoring API를 사용하여 Cloud Monitoring에서 내보낼 수 있습니다. 모든 제어 영역 측정항목은 Google Cloud Managed Service for Prometheus를 사용하여 수집되므로 제어 영역 측정항목은 Prometheus 쿼리 언어(PromQL)를 사용하여 쿼리할 수 있습니다. 모니터링 쿼리 언어(MQL)를 사용하여 쿼리할 수도 있습니다.
측정항목 쿼리
제어 영역 측정항목을 쿼리할 때 사용하는 이름은 PromQL을 사용하는지 또는 MQL과 같은 Cloud Monitoring 기반 기능을 사용하는지 또는 측정항목 탐색기 메뉴 기반 인터페이스를 사용하는지에 따라 다릅니다.
다음 제어 영역 측정항목 표는 각 측정항목 이름의 두 가지 버전을 보여줍니다.
- PromQL 측정항목 이름: Google Cloud 콘솔의 Cloud Monitoring 페이지 또는 Cloud Monitoring API의 PromQL 필드에서 PromQL을 사용하는 경우 PromQL 측정항목 이름을 사용합니다.
- Cloud Monitoring 측정항목 이름: 다른 Cloud Monitoring 기능을 사용하는 경우 아래 테이블에서 Cloud Monitoring 측정항목 이름을 사용합니다. 이 이름에는 테이블의 항목에서 생략된
prometheus.googleapis.com/프리픽스를 붙여야 합니다.
API 서버 측정항목
이 섹션에서는 API 서버 측정항목 목록과 측정항목 해석 및 사용에 대한 추가 정보를 제공합니다.
API 서버 측정항목 목록
API 서버 측정항목이 사용 설정되면 아래 테이블에 표시된 모든 측정항목이 GKE 클러스터와 동일한 프로젝트의 Cloud Monitoring으로 내보내집니다.
이 테이블의 Cloud Monitoring 측정항목 이름에는 prometheus.googleapis.com/ 프리픽스를 붙여야 합니다. 테이블의 항목에서는 이 프리픽스가 생략되었습니다.
| PromQL 측정항목 이름 출시 단계 Cloud Monitoring 측정항목 이름 |
|
|---|---|
|
종류, 유형, 단위
모니터링 리소스 필수 GKE 버전 |
설명 라벨 |
apiserver_current_inflight_requests
GAapiserver_current_inflight_requests/gauge
|
|
Gauge, Double, 1
prometheus_target 1.22.13+ |
현재 사용 중인 것으로 지난 1초 동안 요청 종류당 이 apiserver의 최대 인플라이트 요청 한도 수입니다.request_kind
|
apiserver_flowcontrol_current_executing_seats
베타apiserver_flowcontrol_current_executing_seats/gauge
|
|
Gauge, Double, 1
prometheus_target 1.28.3+ |
API Priority 및 Fairness 서브시스템에서 현재 실행 중인 요청(WATCH의 초기 단계, 그렇지 않으면 모든 단계)으로 점유된 동시성(시트 수)입니다.flow_schema
priority_level
|
apiserver_flowcontrol_current_inqueue_requests
베타apiserver_flowcontrol_current_inqueue_requests/gauge
|
|
Gauge, Double, 1
prometheus_target 1.28.3+ (1.25.16-gke.1360000+, 1.26.11 이상, 이전 부 버전의 경우 1.27.8 이상) |
API Priority 및 Fairness 서브시스템의 큐에서 현재 보류 중인 요청 수입니다.flow_schema
priority_level
|
apiserver_flowcontrol_nominal_limit_seats
베타apiserver_flowcontrol_nominal_limit_seats/gauge
|
|
Gauge, Double, 1
prometheus_target 1.28.3+ (1.26.11+, 이전 부 버전의 경우 1.27.8+) |
각 우선순위 수준에 대해 구성된 실행 시트의 명목 수입니다.priority_level
|
apiserver_flowcontrol_rejected_requests_total
베타apiserver_flowcontrol_rejected_requests_total/counter
|
|
Cumulative, Double, 1
prometheus_target 1.28.3+ (이전 부 버전의 경우 1.25.16-gke.1360000+, 1.26.11 이상, 1.27.8 이상) |
API Priority 및 Fairness 서브시스템에서 거부된 요청 수입니다.flow_schema
priority_level
reason
|
apiserver_flowcontrol_request_wait_duration_seconds
베타apiserver_flowcontrol_request_wait_duration_seconds/histogram
|
|
Cumulative, Distribution, s
prometheus_target 1.28.3+ (1.25.16-gke.1360000+, 1.26.11 이상, 이전 부 버전의 경우 1.27.8 이상) |
요청이 큐에서 기다리는 동안 보낸 시간 길이입니다.execute
flow_schema
priority_level
|
apiserver_request_duration_seconds
GAapiserver_request_duration_seconds/histogram
|
|
Cumulative, Distribution, s
prometheus_target 1.23.6+ |
각 동사, 테스트 실행 값, 그룹, 버전, 리소스, 하위 리소스, 범위, 구성요소에 대한 응답 지연 시간 분포(초)입니다.component
dry_run
group
resource
scope
subresource
verb
version
|
apiserver_request_total
GAapiserver_request_total/counter
|
|
Cumulative, Double, 1
prometheus_target 1.22.13+ |
각 동사, 테스트 실행 값, 그룹, 버전, 리소스, 범위, 구성요소, HTTP 응답 코드별로 구분된 apiserver 요청의 카운터입니다.code
component
dry_run
group
resource
scope
subresource
verb
version
|
apiserver_response_sizes
GAapiserver_response_sizes/histogram
|
|
Cumulative, Distribution, 1
prometheus_target 1.22.13+ |
각 그룹, 버전, 동사, 리소스, 하위 리소스, 범위, 구성요소에 대한 응답 크기 분포(바이트)입니다.component
group
resource
scope
subresource
verb
version
|
apiserver_storage_objects
GAapiserver_storage_objects/gauge
|
|
Gauge, Double, 1
prometheus_target 1.22.13+ |
최종 검사 시점에 저장된 객체 수를 종류별로 분할한 것입니다.resource
|
apiserver_admission_controller_admission_duration_seconds
GAapiserver_admission_controller_admission_duration_seconds/histogram
|
|
Cumulative, Distribution, s
prometheus_target 1.23.6+ |
이름으로 식별되고 각 작업, API 리소스, 유형(검증 또는 허용)별로 구분된 허용 컨트롤러 지연 시간 히스토그램(초)입니다.name
operation
rejected
type
|
apiserver_admission_step_admission_duration_seconds
GAapiserver_admission_step_admission_duration_seconds/histogram
|
|
Cumulative, Distribution, s
prometheus_target 1.22.13+ |
각 작업, API 리소스, 단계 유형(검증 또는 허용)별로 구분된 허용 하위 단계 지연 시간 히스토그램(초)입니다.operation
rejected
type
|
apiserver_admission_webhook_admission_duration_seconds
GAapiserver_admission_webhook_admission_duration_seconds/histogram
|
|
Cumulative, Distribution, s
prometheus_target 1.22.13+ |
이름으로 식별되고 각 작업, API 리소스, 유형(검증 또는 허용)별로 구분된 허용 웹훅 지연 시간 히스토그램(초)입니다.name
operation
rejected
type
|
다음 섹션에서는 API 서버 측정항목에 대한 추가 정보를 제공합니다.
apiserver_request_duration_seconds
이 측정항목을 사용하여 API 서버의 지연 시간을 모니터링합니다. 이 측정항목에 의해 기록된 요청 기간에는 요청이 수신된 시점부터 서버가 클라이언트에 응답을 완료할 때까지의 모든 요청 처리 단계가 포함됩니다. 구체적으로 다음 항목에 소요된 시간이 포함됩니다.
- 요청의 인증 및 승인
- 요청과 연결된 타사 및 시스템 웹훅 호출
- 인메모리 캐시에서 요청된 객체 가져오기(
resourceVersionURL 매개변수를 지정하는 요청의 경우) 또는etcd(다른 모든 요청의 경우)에서 가져오기 group,version,resource,subresource라벨을 사용하여 추가 조사를 위해 느린 요청을 고유하게 식별할 수 있습니다.- 클라이언트에 응답을 작성하고 클라이언트 응답을 수신
이 측정항목 사용에 대한 자세한 내용은 지연 시간을 참조하세요.
이 측정항목의 카디널리티는 매우 높습니다. 이 측정항목을 사용할 때는 필터 또는 그룹화를 사용하여 특정 지연 시간 소스를 찾아야 합니다.
apiserver_admission_controller_admission_duration_seconds
이 측정항목은 타사 웹훅이 아닌 기본 제공 허용 웹훅의 지연 시간을 측정합니다. 타사 웹훅의 지연 시간 문제를 진단하려면 apiserver_admission_webhook_admission_duration_seconds 측정항목을 사용합니다.
apiserver_admission_webhook_admission_duration_seconds 및
apiserver_admission_step_admission_duration_seconds
이러한 측정항목은 외부 타사 허용 웹훅의 지연 시간을 측정합니다.
일반적으로 apiserver_admission_webhook_admission_duration_seconds 측정항목이 더 유용한 측정항목입니다. 이 측정항목 사용에 대한 자세한 내용은 지연 시간을 참조하세요.
apiserver_request_total
이 측정항목을 사용하여 API 서버에서 요청 트래픽을 모니터링합니다. 또한 요청의 성공 및 실패율을 확인할 수도 있습니다. 이 측정항목 사용에 대한 자세한 내용은 트래픽 및 오류율을 참조하세요.
이 측정항목의 카디널리티는 매우 높습니다. 이 측정항목을 사용할 때는 필터 또는 그룹화를 사용하여 오류의 원인을 식별해야 합니다.
apiserver_storage_objects
이 측정항목을 사용하여 시스템의 포화도를 감지하고 가능한 리소스 누수를 식별합니다. 자세한 내용은 포화도를 참조하세요.
apiserver_current_inflight_requests
이 측정항목은 지난 1초 동안 적극적으로 제공 중인 최대 요청 수를 기록합니다. 자세한 내용은 포화도를 참조하세요.
측정항목에는 'watch'와 같은 장기 실행 요청이 포함되지 않습니다.
API 서버 모니터링
API 서버 측정항목을 통해 시스템 상태에 대한 주요 신호를 파악할 수 있습니다.
이 섹션에서는 API 서버 측정항목을 사용하여 API 서버의 상태를 모니터링하는 방법을 설명합니다.
지연 시간
API 서버가 과부하되면 요청 지연 시간이 늘어납니다. API 서버 요청의 지연 시간을 측정하려면 apiserver_request_duration_seconds 측정항목을 사용합니다. 지연 시간의 원인을 보다 구체적으로 식별하려면 verb 또는 resource 라벨을 사용하여 측정항목을 그룹화하면 됩니다.
GET, POST, PATCH와 같은 단일 리소스 호출의 추천 상한값은 1초입니다. 네임스페이스 및 클러스터 범위 LIST 호출 모두에 권장되는 상한은 30초입니다. 상한 값은 오픈소스 Kubernetes 커뮤니티에서 정의한 SLO로 설정됩니다. 자세한 내용은 API 호출 지연 시간 SLI/SLO 세부정보를 참조하세요.
apiserver_request_duration_seconds 측정항목의 값이 예상 기간을 초과하는 경우 다음과 같은 가능한 원인을 조사합니다.
- Kubernetes 제어 영역이 과부하 상태일 수 있습니다.
apiserver_request_total및apiserver_storage_objects측정항목을 확인합니다.code라벨을 사용하여 요청이 성공적으로 처리되는지 확인합니다. 가능한 값에 대한 자세한 내용은 HTTP 상태 코드를 참조하세요.group,version,resource,subresource라벨을 사용하여 요청을 고유하게 식별합니다.
타사 허용 웹훅이 느리거나 응답하지 않습니다.
apiserver_admission_webhook_admission_duration_seconds측정항목의 값이 증가하면 일부 타사 또는 사용자 정의 허용 웹훅이 느려지거나 응답하지 않습니다. 허용 웹훅이 지연되면 작업 예약이 지연될 수 있습니다.Kubernetes 제어 영역의 인스턴스당 99번째 백분위수 웹훅 지연 시간을 쿼리하려면 다음 PromQL 쿼리를 사용합니다.
sum by (instance) (histogram_quantile(0.99, rate(apiserver_admission_webhook_admission_duration_seconds_bucket{cluster="CLUSTER_NAME"}[1m])))또한 50번째, 90번째, 95번째, 99.9번째 백분위수를 확인하는 것이 좋습니다.
0.99값을 수정하여 이 쿼리를 조정할 수 있습니다.외부 웹훅의 제한 시간은 약 10초입니다. 웹훅 제한 시간에 가까워지면 알림을 보내도록
apiserver_admission_webhook_admission_duration_seconds측정항목에서 알림 정책을 설정할 수 있습니다.또한
name라벨에 대해apiserver_admission_webhook_admission_duration_seconds측정항목을 그룹화하여 특정 웹훅과 관련된 가능한 문제를 진단할 수 있습니다.
많은 객체를 나열하고 있습니다. LIST 호출의 지연 시간은 주어진 유형의 객체(응답 크기)가 증가함에 따라 증가할 것으로 예상됩니다.
클라이언트 측 문제:
- 클라이언트에 응답을 제때 수신하기 위한 리소스가 충분하지 않을 수 있습니다. 확인하려면 클라이언트 포드의 CPU 사용량 측정항목을 확인하세요.
- 클라이언트의 네트워크 연결이 느립니다. 클라이언트가 휴대전화과 같은 기기에서 실행 중일 때 이러한 상황이 발생할 수 있지만 Compute Engine 네트워크에서 실행되는 클라이언트의 경우 가능성이 낮습니다.
- 클라이언트가 예기치 않게 종료되었지만 TCP 연결 제한 시간 기간은 수십 초입니다. 연결이 시간 초과되기 전에 서버 리소스가 차단되어 지연 시간이 늘어날 수 있습니다.
트래픽 및 오류율
API 서버에서 트래픽과 성공한 요청 및 실패한 요청 수를 측정하려면 apiserver_request_total 측정항목을 사용합니다. 예를 들어 Kubernetes 제어 영역의 인스턴스당 API 서버 트래픽을 측정하려면 다음 PromQL 쿼리를 사용합니다.
sum by (instance) (increase(apiserver_request_total{cluster="CLUSTER_NAME"}[1m]))
실패한 요청을 쿼리하려면 다음 PromQL 쿼리를 사용하여 4xx 및 5xx 값으로
code라벨을 필터링합니다.sum(rate(apiserver_request_total{code=~"[45].."}[5m]))성공한 요청을 쿼리하려면 다음 PromQL 쿼리를 사용하여 2xx 값으로
code라벨을 필터링합니다.sum(rate(apiserver_request_total{code=~"2.."}[5m]))Kubernetes 제어 영역의 인스턴스별로 API 서버가 거부한 요청을 쿼리하려면 다음 PromQL 쿼리를 사용하여 값 429(
http.StatusTooManyRequests)에 대해code라벨을 필터링합니다.sum by (instance) (increase(apiserver_request_total{cluster="CLUSTER_NAME", code="429"}[1m]))
포화도
apiserver_current_inflight_requests 및 apiserver_storage_objects 측정항목을 사용하여 시스템의 포화도를 측정할 수 있습니다.
apiserver_storage_objects
측정항목의 값이 증가하면 객체를 만들지만 삭제하지 않는 커스텀 컨트롤러에 문제가 있을 수 있습니다. resource 라벨로 측정항목을 필터링하거나 그룹화하여 증가하는 리소스를 식별할 수 있습니다.
API 우선순위 및 공정성 설정에 따라 apiserver_current_inflight_requests 측정항목을 평가합니다. 이러한 설정은 요청 우선순위에 영향을 주므로 측정항목 값만으로는 결론을 내릴 수 없습니다. 자세한 내용은 API 우선순위 및 공정성을 참조하세요.
스케줄러 측정항목
이 섹션에서는 스케줄러 측정항목의 목록과 측정항목 해석 및 사용에 대한 추가 정보를 제공합니다.
스케줄러 측정항목 목록
스케줄러 측정항목이 사용 설정되면 아래 테이블에 표시된 모든 측정항목이 GKE 클러스터와 동일한 프로젝트의 Cloud Monitoring으로 내보내집니다.
이 테이블의 Cloud Monitoring 측정항목 이름에는 prometheus.googleapis.com/ 프리픽스를 붙여야 합니다. 테이블의 항목에서는 이 프리픽스가 생략되었습니다.
| PromQL 측정항목 이름 출시 단계 Cloud Monitoring 측정항목 이름 |
|
|---|---|
|
종류, 유형, 단위
모니터링 리소스 필수 GKE 버전 |
설명 라벨 |
scheduler_pending_pods
GAscheduler_pending_pods/gauge
|
|
Gauge, Double, 1
prometheus_target 1.22.13+ |
큐 유형별로 대기 중인 포드 수입니다. 'active'는 activeQ의 포드 수를 의미하고, 'backoff'는 backoffQ의 포드 수를 의미하며, 'unschedulable'은 unschedulablePods의 포드 수를 의미합니다.queue
|
scheduler_pod_scheduling_duration_seconds
지원 중단됨scheduler_pod_scheduling_duration_seconds/histogram
|
|
Cumulative, Distribution, 1
prometheus_target 1.25.1~1.29(1.22.17-gke.3100 이상, 1.23.11 이상, 이전 부 버전의 경우 1.24.5 이상) |
[v. 1.29에서 지원 중단됨, v. 1.30에서 삭제 및 대체 예정] 여러 예약 시도를 포함할 수 있는 예약 중인 포드의 E2e 지연 시간attempts
|
scheduler_preemption_attempts_total
GAscheduler_preemption_attempts_total/counter
|
|
Cumulative, Double, 1
prometheus_target 1.22.13+ |
현재까지 클러스터에서 시도한 총 선점 횟수입니다. |
scheduler_preemption_victims
GAscheduler_preemption_victims/histogram
|
|
Cumulative, Distribution, 1
prometheus_target 1.22.13+ |
선택된 선점 피해자 수입니다. |
scheduler_scheduling_attempt_duration_seconds
GAscheduler_scheduling_attempt_duration_seconds/histogram
|
|
Cumulative, Distribution, 1
prometheus_target 1.23.6+ |
예약 시도 지연 시간(초)입니다(예약 알고리즘 + 바인딩).profile
result
|
scheduler_schedule_attempts_total
GAscheduler_schedule_attempts_total/counter
|
|
Cumulative, Double, 1
prometheus_target 1.22.13+ |
결과별 포드 예약 시도 횟수입니다. 'unschedulable'은 포드를 예약할 수 없음을 의미하고, 'error'는 내부 스케줄러 문제를 의미합니다.profile
result
|
다음 섹션에서는 API 서버 측정항목에 대한 추가 정보를 제공합니다.
scheduler_pending_pods
scheduler_pending_pods 측정항목을 사용하여 스케줄러의 부하를 모니터링할 수 있습니다. 이 측정항목의 값이 증가하면 리소스 문제가 있을 수 있습니다. 스케줄러에는 3개의 큐가 있으며 이 측정항목은 큐별로 대기 중인 요청 수를 보고합니다. 지원되는 큐는 다음과 같습니다.
active큐- 스케줄러가 예약하려고 하는 포드 집합입니다. 우선순위가 가장 높은 포드가 큐의 맨 위에 있습니다.
backoff큐- 포드 집합은 마지막으로 스케줄러가 시도했을 때 예약할 수 없었지만 다음에 예약할 수 있습니다.
- 이 큐의 포드는 백오프 기간(최대 10초)을 기다려야 하며 이후에는 다른 예약 시도를 위해
active큐로 다시 이동합니다.backoff큐 관리에 대한 자세한 내용은 구현 요청 Kubernetes 문제 75417을 참조하세요.
unschedulableset스케줄러가 예약하려고 시도했지만 예약 불가능으로 확인된 포드 모음입니다. 이 큐에 배치되면 노드 또는 노드 선택기 구성에 준비 또는 호환성 문제가 있을 수 있습니다.
리소스 제약조건으로 인해 포드가 예약되지 않는 경우 포드는 백오프 처리되지 않습니다. 대신 클러스터가 가득 차면 새 포드가 예약되지 않고
unscheduled큐에 추가됩니다.예약되지 않은 포드가 있으면 리소스가 부족하거나 노드 구성 문제가 있음을 나타낼 수 있습니다. 포드는 클러스터 상태를 변경하는 이벤트 후
backoff또는active큐로 이동합니다. 이 큐의 포드는 클러스터에서 포드를 예약할 수 있도록 변경된 사항이 없음을 나타냅니다.어피니티는 포드가 노드에 할당되는 방식에 대한 규칙을 정의합니다. 어피니티 또는 안티-어피니티 규칙을 사용하면 예약되지 않은 포드가 증가할 수 있습니다.
PVC/Service ADD/UPDATE, 포드 종료, 새 노드 등록과 같은 일부 이벤트는 예약되지 않은 일부 또는 모든 포드를
backoff또는active큐로 이동합니다. 자세한 내용은 Kubernetes 문제 81214를 참조하세요.
자세한 내용은 스케줄러 지연 시간 및 리소스 문제를 참조하세요.
scheduler_scheduling_attempt_duration_seconds
이 측정항목은 스케줄러 내에서 단일 예약 시도의 기간을 측정하고 결과(예약, 예약할 수 없음, 오류)에 따라 분류됩니다. 기간은 스케줄러가 포드를 선택한 시점부터 스케줄러가 노드를 찾아 포드를 노드에 배치하거나 포드가 예약 불가능하다고 판단하거나 오류가 발생할 때까지 측정됩니다. 예약 기간에는 바인딩 시간과 예약 프로세스의 시간이 포함됩니다. 바인딩은 스케줄러가 노드 할당을 API 서버에 전달하는 프로세스입니다. 자세한 내용은 스케줄러 지연 시간을 참조하세요.
이 측정항목은 포드가 허용 제어 또는 검증에 소비한 시간을 캡처하지 않습니다.
예약에 대한 자세한 내용은 포드 예약을 참조하세요.
scheduler_schedule_attempts_total
이 측정항목은 예약 시도 횟수를 측정합니다. 포드를 예약하려고 시도할 때마다 값이 증가합니다. 이 측정항목을 사용하여 스케줄러를 사용할 수 있는지 확인할 수 있습니다. 값이 증가하면 스케줄러가 작동 가능합니다. result 라벨을 사용하여 성공 여부를 확인할 수 있습니다. 포드는 scheduled 또는 unschedulable입니다.
이 측정항목은 scheduler_pending_pods 측정항목과 밀접한 관련이 있습니다. 대기 중인 포드가 많은 경우 포드 예약 시도가 여러 번 발생할 수 있습니다. 자세한 내용은 리소스 문제를 참조하세요.
스케줄러에 예약할 포드가 없으면 이 측정항목이 증가하지 않습니다. 커스텀 보조 스케줄러가 있을 경우일 수 있습니다.
scheduler_preemption_attempts_total, scheduler_preemptions_victims
선점 측정항목을 사용하여 리소스 추가해야 하는지 여부를 결정할 수 있습니다.
공간이 부족하므로 예약할 수 없는 우선순위가 더 높은 포드가 있을 수 있습니다. 이 경우 스케줄러는 노드에서 하나 이상의 실행 중인 포드를 선점하여 리소스를 확보합니다. scheduler_preemption_attempts_total 측정항목은 스케줄러가 포드 선점을 시도한 횟수를 추적합니다.
scheduler_preemptions_victims 측정항목은 선점을 위해 선택한 포드를 계산합니다.
선점 시도 수는 result 라벨 값이 unschedulable인 경우 scheduler_schedule_attempts_total 측정항목의 값과 밀접한 상관 관계가 있습니다.
두 값은 동일하지 않습니다. 예를 들어 클러스터에 노드가 0개 있으면 선점 시도가 없지만 예약 시도가 실패할 수 있습니다.
자세한 내용은 리소스 문제를 참조하세요.
스케줄러 모니터링
스케줄러 측정항목을 사용하면 스케줄러의 성능을 파악할 수 있습니다.
- 스케줄러 지연 시간: 스케줄러가 실행 중인가요? 포드를 예약하는 데 시간이 얼마나 걸리나요?
- 리소스 문제: 포드를 예약하려고 시도하면 리소스 제약 조건에 도달하나요?
이 섹션에서는 스케줄러 측정항목을 사용하여 스케줄러를 모니터링하는 방법을 설명합니다.
스케줄러 지연 시간
스케줄러의 태스크는 포드가 실행되는지 확인하기 때문에 스케줄러가 중단되거나 느리게 실행되는 시기를 알 수 있습니다.
- 스케줄러가 실행 중이며 포드를 예약하고 있는지 확인하려면
scheduler_schedule_attempts_total측정항목을 사용합니다. 스케줄러가 느리게 실행되는 경우 다음과 같은 가능한 원인을 조사합니다.
대기 중인 포드의 수가 늘어납니다.
scheduler_pending_pods측정항목을 사용하여 대기 중인 포드 수를 모니터링합니다. 다음 PromQL 쿼리는 클러스터의 큐당 대기 중인 포드 수를 반환합니다.sum by (queue) (delta(scheduler_pending_pods{cluster="CLUSTER_NAME"}[2m]))개별 포드 예약 시도는 느립니다. 예약 시도 지연 시간을 모니터링하려면
scheduler_scheduling_attempt_duration_seconds측정항목을 사용합니다.이 측정항목은 최소한 50번째와 95번째 백분위수에서 관찰하는 것이 좋습니다. 다음 PromQL 쿼리는 95번째 백분위수 값을 검색하지만 조정할 수 있습니다.
sum by (instance) (histogram_quantile(0.95, rate( scheduler_scheduling_attempt_duration_seconds_bucket{cluster="CLUSTER_NAME"}[5m])))
리소스 문제
스케줄러 측정항목은 리소스가 충분한지 평가하는 데에도 도움이 됩니다. scheduler_preemption_attempts_total 측정항목의 값이 증가하면 다음 PromQL 쿼리를 사용하여 scheduler_preemption_victims 값을 확인합니다.
scheduler_preemption_victims_sum{cluster="CLUSTER_NAME"}
예약할 우선순위가 더 높은 포드가 있으면 선점 시도 수와 선점 피해자 수가 모두 증가합니다. 선점 측정항목은 선점을 트리거한 우선순위가 높은 포드가 예약되었는지 여부를 알려주지 않으므로 선점 측정항목의 값이 증가하면 scheduler_pending_pods 측정항목 값을 모니터링할 수도 있습니다. 보류 중인 포드의 수도 증가하면 우선순위가 높은 포드를 처리하기에 충분한 리소스가 없을 수 있습니다. 사용 가능한 리소스를 확장하거나, 리소스 클레임이 줄인 새 포드를 만들거나, 노드 선택기를 변경해야 할 수 있습니다.
선점 피해자 수가 늘어나지 않으면 제거할 수 있는 우선순위가 낮은 포드가 없는 것입니다. 이 경우 새 포드를 할당할 수 있도록 노드를 추가하는 것이 좋습니다.
선점 피해자 수가 늘어나면 우선순위가 높은 포드가 예약 대기 중이므로, 스케줄러가 실행 중인 포드 중 일부를 선점합니다. 선점 측정항목은 우선순위가 높은 포드가 성공적으로 예약되었는지 여부를 알려주지 않습니다.
우선순위가 높은 포드가 예약되고 있는지 중인지 확인하려면
scheduler_pending_pods측정항목 값이 감소하는지 확인합니다. 이 측정항목의 값이 증가하면 노드를 추가해야 할 수도 있습니다.
클러스터에서 워크로드가 예약되는 경우(예: 업데이트 또는 확장과 같은 이벤트 중에) scheduler_pending_pods 측정항목 값이 일시적으로 급증할 수 있습니다.
클러스터에 리소스가 충분한 경우 이러한 급증은 임시적입니다.
대기 중인 포드의 수가 줄어들지 않으면 다음을 수행합니다.
- 노드가 차단되지 않았는지 확인합니다. 차단된 노드는 새 포드를 허용하지 않습니다.
- 다음 예약 지시문을 확인합니다. 잘못 구성되어 포드를 예약할 수 없게 만들 수 있습니다.
- 노드 어피니티 및 선택기
- taint 및 톨러레이션(toleration)
- 포드 토폴로지 분산 제약조건
리소스 부족으로 인해 포드를 예약할 수 없는 경우 기존 노드 중 일부를 확보하거나 노드 수를 늘려보세요.
컨트롤러 관리자 측정항목
컨트롤러 관리자 측정항목이 사용 설정되면 아래 테이블에 표시된 모든 측정항목이 GKE 클러스터와 동일한 프로젝트의 Cloud Monitoring으로 내보내집니다.
이 테이블의 Cloud Monitoring 측정항목 이름에는 prometheus.googleapis.com/ 프리픽스를 붙여야 합니다. 테이블의 항목에서는 이 프리픽스가 생략되었습니다.
| PromQL 측정항목 이름 출시 단계 Cloud Monitoring 측정항목 이름 |
|
|---|---|
|
종류, 유형, 단위
모니터링 리소스 필수 GKE 버전 |
설명 라벨 |
node_collector_evictions_total
GAnode_collector_evictions_total/counter
|
|
Cumulative, Double, 1
prometheus_target 1.24+ |
NodeController의 현재 인스턴스가 시작된 후 발생한 노드 제거 수입니다.zone
|