From bfd26ffc0db3b02348784d83832243b9c2f7271c Mon Sep 17 00:00:00 2001 From: namuk2004 Date: Sun, 16 Apr 2023 11:32:15 +0900 Subject: [PATCH] Update outdated files in dev-1.26-ko.1 (M10-M13) --- .../cluster-administration/networking.md | 2 +- .../cluster-administration/proxies.md | 2 +- .../cluster-administration/system-logs.md | 52 +++++---- .../cluster-administration/system-metrics.md | 107 +++++++++++++----- 4 files changed, 110 insertions(+), 53 deletions(-) diff --git a/content/ko/docs/concepts/cluster-administration/networking.md b/content/ko/docs/concepts/cluster-administration/networking.md index cc3df4d5f5922..1a6ce86090c11 100644 --- a/content/ko/docs/concepts/cluster-administration/networking.md +++ b/content/ko/docs/concepts/cluster-administration/networking.md @@ -15,7 +15,7 @@ weight: 50 {{< glossary_tooltip text="파드" term_id="pod" >}}와 `localhost` 통신으로 해결된다. 2. 파드 간 통신: 이 문제가 이 문서의 주요 초점이다. 3. 파드와 서비스 간 통신: 이 문제는 [서비스](/ko/docs/concepts/services-networking/service/)에서 다룬다. -4. 외부와 서비스 간 통신: 이 문제는 [서비스](/ko/docs/concepts/services-networking/service/)에서 다룬다. +4. 외부와 서비스 간 통신: 이 문제도 서비스에서 다룬다. diff --git a/content/ko/docs/concepts/cluster-administration/proxies.md b/content/ko/docs/concepts/cluster-administration/proxies.md index 28599acdfaf09..9e777e13683d3 100644 --- a/content/ko/docs/concepts/cluster-administration/proxies.md +++ b/content/ko/docs/concepts/cluster-administration/proxies.md @@ -1,7 +1,7 @@ --- title: 쿠버네티스에서 프락시(Proxy) content_type: concept -weight: 90 +weight: 100 --- diff --git a/content/ko/docs/concepts/cluster-administration/system-logs.md b/content/ko/docs/concepts/cluster-administration/system-logs.md index 0affb1525953a..a88956dadd91f 100644 --- a/content/ko/docs/concepts/cluster-administration/system-logs.md +++ b/content/ko/docs/concepts/cluster-administration/system-logs.md @@ -4,14 +4,16 @@ # - 44past4 title: 시스템 로그 content_type: concept -weight: 60 +weight: 80 --- 시스템 컴포넌트 로그는 클러스터에서 발생하는 이벤트를 기록하며, 이는 디버깅에 아주 유용하다. 더 많거나 적은 세부 정보를 표시하도록 다양하게 로그를 설정할 수 있다. -로그는 컴포넌트 내에서 오류를 표시하는 것 처럼 간단하거나, 이벤트의 단계적 추적(예: HTTP 엑세스 로그, 파드의 상태 변경, 컨트롤러 작업 또는 스케줄러의 결정)을 표시하는 것처럼 세밀할 수 있다. +로그는 컴포넌트 내에서 오류를 표시하는 것 처럼 간단하거나, +이벤트의 단계적 추적(예: HTTP 엑세스 로그, 파드의 상태 변경, 컨트롤러 작업 또는 스케줄러의 결정)을 +표시하는 것처럼 세밀할 수 있다. @@ -39,14 +41,13 @@ klog 설정에 대한 더 많은 정보는, [커맨드라인 툴](/ko/docs/refer - `--skip-log-headers` - `--stderrthreshold` -출력은 출력 형식에 관계없이 항상 표준 에러(stderr)에 기록될 것이다. -출력 리다이렉션은 쿠버네티스 컴포넌트를 호출하는 컴포넌트가 담당할 것으로 기대된다. -이는 POSIX 셸 또는 systemd와 같은 도구일 수 -있다. +출력은 출력 형식에 관계없이 항상 표준 에러(stderr)에 기록될 것이다. 출력 리다이렉션은 +쿠버네티스 컴포넌트를 호출하는 컴포넌트가 담당할 것으로 기대된다. 이는 POSIX +셸 또는 systemd와 같은 도구일 수 있다. -배포판과 무관한(distroless) 컨테이너 또는 윈도우 시스템 서비스와 같은 몇몇 경우에서, -위의 옵션은 사용할 수 없다. -그런 경우 출력을 리다이렉트하기 위해 +배포판과 무관한(distroless) 컨테이너 또는 윈도우 시스템 서비스와 같은 몇몇 경우에서, 위의 옵션은 +사용할 수 없다. 그런 경우 +출력을 리다이렉트하기 위해 [`kube-log-runner`](https://github.com/kubernetes/kubernetes/blob/d2a8a81639fcff8d1221b900f66d28361a170654/staging/src/k8s.io/component-base/logs/kube-log-runner/README.md) 바이너리를 쿠버네티스 컴포넌트의 래퍼(wrapper)로 사용할 수 있다. 미리 빌드된 바이너리가 몇몇 쿠버네티스 베이스 이미지에 기본 이름 `/go-runner` 와 @@ -63,31 +64,34 @@ klog 설정에 대한 더 많은 정보는, [커맨드라인 툴](/ko/docs/refer ### Klog 출력 -klog 네이티브 형식 예 : +klog 네이티브 형식 예 : + ``` I1025 00:15:15.525108 1 httplog.go:79] GET /api/v1/namespaces/kube-system/pods/metrics-server-v0.3.1-57c75779f-9p8wg: (1.512ms) 200 [pod_nanny/v0.0.0 (linux/amd64) kubernetes/$Format 10.56.1.19:51756] ``` 메시지 문자열은 줄바꿈을 포함하고 있을 수도 있다. + ``` I1025 00:15:15.525108 1 example.go:79] This is a message which has a line break. ``` - ### 구조화된 로깅 {{< feature-state for_k8s_version="v1.23" state="beta" >}} {{< warning >}} -구조화된 로그메시지로 마이그레이션은 진행중인 작업이다. 이 버전에서는 모든 로그 메시지가 구조화되지 않는다. 로그 파일을 파싱할 때, 구조화되지 않은 로그 메시지도 처리해야 한다. +구조화된 로그메시지로 마이그레이션은 진행중인 작업이다. 이 버전에서는 모든 로그 메시지가 구조화되지 않는다. +로그 파일을 파싱할 때, 구조화되지 않은 로그 메시지도 처리해야 한다. 로그 형식 및 값 직렬화는 변경될 수 있다. {{< /warning>}} -구조화된 로깅은 로그 메시지에 통일된 구조를 적용하여 정보를 쉽게 추출하고, -로그를 보다 쉽고 저렴하게 저장하고 처리하는 작업이다. -새로운 메시지 형식은 이전 버전과 호환되며 기본적으로 활성화 된다. +구조화된 로깅은 로그 메시지에 유니폼 구조를 적용하여 +정보를 쉽게 추출하고, 로그를 보다 쉽고 저렴하게 저장하고 처리하는 작업이다. +로그 메세지를 생성하는 코드는 기존의 구조화되지 않은 klog 출력을 사용 또는 +구조화된 로깅을 사용할지 여부를 결정합니다. 구조화된 로그 메시지의 기본 형식은 텍스트이며, 기존 klog와 하위 호환되는 형식이다. @@ -105,6 +109,7 @@ I1025 00:15:15.525108 1 controller_utils.go:116] "Pod status updated" pod= 문자열은 따옴표로 감싸진다. 다른 값들은 [`%+v`](https://pkg.go.dev/fmt#hdr-Printing)로 포맷팅되며, 이로 인해 [데이터에 따라](https://github.com/kubernetes/kubernetes/issues/106428) 로그 메시지가 다음 줄로 이어질 수 있다. + ``` I1025 00:15:15.525108 1 example.go:116] "Example" data="This is text with a line break\nand \"quotation marks\"." someInt=1 someFloat=0.1 someStruct={StringField: First line, second line.} @@ -164,15 +169,18 @@ I0404 18:03:31.171962 452150 logger.go:95] "another runtime" duration="1m0s" {{< feature-state for_k8s_version="v1.19" state="alpha" >}} {{}} -JSON 출력은 많은 표준 klog 플래그를 지원하지 않는다. 지원하지 않는 klog 플래그 목록은, [커맨드라인 툴](/ko/docs/reference/command-line-tools-reference/)을 참고한다. +JSON 출력은 많은 표준 klog 플래그를 지원하지 않는다. 지원하지 않는 klog 플래그 목록은, +[커맨드라인 툴](/ko/docs/reference/command-line-tools-reference/)을 참고한다. -모든 로그가 JSON 형식으로 작성되는 것은 아니다(예: 프로세스 시작 중). 로그를 파싱하려는 경우 JSON 형식이 아닌 로그 행을 처리할 수 있는지 확인해야 한다. +모든 로그가 JSON 형식으로 작성되는 것은 아니다(예: 프로세스 시작 중). +로그를 파싱하려는 경우 JSON 형식이 아닌 로그 행을 처리할 수 있는지 확인해야 한다. 필드 이름과 JSON 직렬화는 변경될 수 있다. {{< /warning >}} `--logging-format=json` 플래그는 로그 형식을 klog 기본 형식에서 JSON 형식으로 변경한다. JSON 로그 형식 예시(보기좋게 출력된 형태)는 다음과 같다. + ```json { "ts": 1580306777.04728, @@ -186,14 +194,15 @@ JSON 로그 형식 예시(보기좋게 출력된 형태)는 다음과 같다. } ``` -특별한 의미가 있는 키: +특별한 의미가 있는 키: + * `ts` - Unix 시간의 타임스탬프 (필수, 부동 소수점) * `v` - 자세한 정도 (필수, 정수, 기본 값 0) * `err` - 오류 문자열 (선택 사항, 문자열) * `msg` - 메시지 (필수, 문자열) - 현재 JSON 형식을 지원하는 컴포넌트 목록: + * {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}} * {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} * {{< glossary_tooltip term_id="kube-scheduler" text="kube-scheduler" >}} @@ -201,8 +210,9 @@ JSON 로그 형식 예시(보기좋게 출력된 형태)는 다음과 같다. ### 로그 상세 레벨(verbosity) -`-v` 플래그로 로그 상세 레벨(verbosity)을 제어한다. 값을 늘리면 기록된 이벤트 수가 증가한다. 값을 줄이면 기록된 이벤트 수가 줄어든다. -로그 상세 레벨(verbosity)를 높이면 점점 덜 심각한 이벤트가 기록된다. 로그 상세 레벨(verbosity)을 0으로 설정하면 중요한 이벤트만 기록된다. +`-v` 플래그로 로그 상세 레벨(verbosity)을 제어한다. 값을 늘리면 기록된 이벤트 수가 증가한다. +값을 줄이면 기록된 이벤트 수가 줄어든다. 로그 상세 레벨(verbosity)를 높이면 +점점 덜 심각한 이벤트가 기록된다. 로그 상세 레벨(verbosity)을 0으로 설정하면 중요한 이벤트만 기록된다. ### 로그 위치 diff --git a/content/ko/docs/concepts/cluster-administration/system-metrics.md b/content/ko/docs/concepts/cluster-administration/system-metrics.md index 47abc62abab1e..0d99eeeeb40f4 100644 --- a/content/ko/docs/concepts/cluster-administration/system-metrics.md +++ b/content/ko/docs/concepts/cluster-administration/system-metrics.md @@ -5,12 +5,13 @@ title: 쿠버네티스 시스템 컴포넌트에 대한 메트릭 # - logicalhan # - RainbowMango content_type: concept -weight: 60 +weight: 70 --- -시스템 컴포넌트 메트릭으로 내부에서 발생하는 상황을 더 잘 파악할 수 있다. 메트릭은 대시보드와 경고를 만드는 데 특히 유용하다. +시스템 컴포넌트 메트릭으로 내부에서 발생하는 상황을 더 잘 파악할 수 있다. 메트릭은 +대시보드와 경고를 만드는 데 특히 유용하다. 쿠버네티스 컴포넌트의 메트릭은 [프로메테우스 형식](https://prometheus.io/docs/instrumenting/exposition_formats/)으로 출력된다. 이 형식은 구조화된 평문으로 디자인되어 있으므로 사람과 기계 모두가 쉽게 읽을 수 있다. @@ -19,7 +20,8 @@ weight: 60 ## 쿠버네티스의 메트릭 -대부분의 경우 메트릭은 HTTP 서버의 `/metrics` 엔드포인트에서 사용할 수 있다. 기본적으로 엔드포인트를 노출하지 않는 컴포넌트의 경우 `--bind-address` 플래그를 사용하여 활성화할 수 있다. +대부분의 경우 메트릭은 HTTP 서버의 `/metrics` 엔드포인트에서 사용할 수 있다. +기본적으로 엔드포인트를 노출하지 않는 컴포넌트의 경우 `--bind-address` 플래그를 사용하여 활성화할 수 있다. 해당 컴포넌트의 예는 다음과 같다. @@ -29,13 +31,18 @@ weight: 60 * {{< glossary_tooltip term_id="kube-scheduler" text="kube-scheduler" >}} * {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} -프로덕션 환경에서는 이러한 메트릭을 주기적으로 수집하고 시계열 데이터베이스에서 사용할 수 있도록 -[프로메테우스 서버](https://prometheus.io/) 또는 다른 메트릭 수집기(scraper)를 구성할 수 있다. +프로덕션 환경에서는 이러한 메트릭을 주기적으로 수집하고 +시계열 데이터베이스에서 사용할 수 있도록 [프로메테우스 서버](https://prometheus.io/) 또는 +다른 메트릭 수집기(scraper)를 구성할 수 있다. -참고로 {{< glossary_tooltip term_id="kubelet" text="kubelet" >}}도 `/metrics/cadvisor`, `/metrics/resource` 그리고 `/metrics/probes` 엔드포인트에서 메트릭을 노출한다. 이러한 메트릭은 동일한 라이프사이클을 가지지 않는다. +참고로 {{< glossary_tooltip term_id="kubelet" text="kubelet" >}}도 +`/metrics/cadvisor`, `/metrics/resource` 그리고 `/metrics/probes` 엔드포인트에서 메트릭을 노출한다. +이러한 메트릭은 동일한 라이프사이클을 가지지 않는다. -클러스터가 {{< glossary_tooltip term_id="rbac" text="RBAC" >}}을 사용하는 경우, 메트릭을 읽으려면 `/metrics` 에 접근을 허용하는 클러스터롤(ClusterRole)을 가지는 사용자, 그룹 또는 서비스어카운트(ServiceAccount)를 통한 권한이 필요하다. +클러스터가 {{< glossary_tooltip term_id="rbac" text="RBAC" >}}을 사용하는 경우, 메트릭을 읽으려면 +`/metrics` 에 접근을 허용하는 클러스터롤(ClusterRole)을 가지는 사용자, 그룹 또는 서비스어카운트(ServiceAccount)를 통한 권한이 필요하다. 예를 들면, 다음과 같다. + ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole @@ -55,6 +62,7 @@ rules: 알파 메트릭은 안정성을 보장하지 않는다. 따라서 언제든지 수정되거나 삭제될 수 있다. 안정적인 메트릭은 변경되지 않는다는 것을 보장한다. 이것은 다음을 의미한다. + * 사용 중단 표기가 없는 안정적인 메트릭은, 이름이 변경되거나 삭제되지 않는다. * 안정적인 메트릭의 유형(type)은 수정되지 않는다. @@ -79,34 +87,52 @@ some_counter 0 some_counter 0 ``` -히든 메트릭은 깔끔함(scraping)을 위해 더 이상 게시되지는 않지만, 여전히 사용은 가능하다. 히든 메트릭을 사용하려면, [히든 메트릭 표시](#히든-메트릭-표시) 섹션을 참고한다. +히든 메트릭은 깔끔함(scraping)을 위해 더 이상 게시되지는 않지만, 여전히 사용은 가능하다. +히든 메트릭을 사용하려면, [히든 메트릭 표시](#히든-메트릭-표시) 섹션을 참고한다. 삭제된 메트릭은 더 이상 게시되거나 사용할 수 없다. - ## 히든 메트릭 표시 -위에서 설명한 것처럼, 관리자는 특정 바이너리의 커맨드 라인 플래그를 통해 히든 메트릭을 활성화할 수 있다. 관리자가 지난 릴리스에서 사용 중단된 메트릭의 마이그레이션을 놓친 경우 관리자를 위한 임시방편으로 사용된다. +위에서 설명한 것처럼, 관리자는 특정 바이너리의 커맨드 라인 플래그를 통해 히든 메트릭을 활성화할 수 있다. +관리자가 지난 릴리스에서 사용 중단된 메트릭의 마이그레이션을 놓친 경우 +관리자를 위한 임시방편으로 사용된다. -`show-hidden-metrics-for-version` 플래그는 해당 릴리스에서 사용 중단된 메트릭을 보여주려는 버전을 사용한다. 버전은 xy로 표시되며, 여기서 x는 메이저(major) 버전이고, y는 마이너(minor) 버전이다. 패치 릴리스에서 메트릭이 사용 중단될 수 있지만, 패치 버전은 필요하지 않다. 그 이유는 메트릭 사용 중단 정책이 마이너 릴리스에 대해 실행되기 때문이다. +`show-hidden-metrics-for-version` 플래그는 해당 릴리스에서 사용 중단된 메트릭을 보여주려는 +버전을 사용한다. 버전은 xy로 표시되며, 여기서 x는 메이저(major) 버전이고, +y는 마이너(minor) 버전이다. 패치 릴리스에서 메트릭이 사용 중단될 수 있지만, 패치 버전은 필요하지 않다. +그 이유는 메트릭 사용 중단 정책이 마이너 릴리스에 대해 실행되기 때문이다. -플래그는 그 값으로 이전의 마이너 버전만 사용할 수 있다. 관리자가 이전 버전을 `show-hidden-metrics-for-version` 에 설정하면 이전 버전의 모든 히든 메트릭이 생성된다. 사용 중단 메트릭 정책을 위반하기 때문에 너무 오래된 버전은 허용되지 않는다. +플래그는 그 값으로 이전의 마이너 버전만 사용할 수 있다. 관리자가 이전 버전을 +`show-hidden-metrics-for-version` 에 설정하면 이전 버전의 모든 히든 메트릭이 생성된다. +사용 중단 메트릭 정책을 위반하기 때문에 너무 오래된 버전은 허용되지 않는다. -1.n 버전에서 사용 중단되었다고 가정한 메트릭 `A` 를 예로 들어보겠다. 메트릭 사용 중단 정책에 따르면, 다음과 같은 결론에 도달할 수 있다. +1.n 버전에서 사용 중단되었다고 가정한 메트릭 `A` 를 예로 들어보겠다. +메트릭 사용 중단 정책에 따르면, 다음과 같은 결론에 도달할 수 있다. * `1.n` 릴리스에서는 메트릭이 사용 중단되었으며, 기본적으로 생성될 수 있다. -* `1.n+1` 릴리스에서는 기본적으로 메트릭이 숨겨져 있으며, `show-hidden-metrics-for-version=1.n` 커맨드 라인에 의해서 생성될 수 있다. +* `1.n+1` 릴리스에서는 기본적으로 메트릭이 숨겨져 있으며, + `show-hidden-metrics-for-version=1.n` 커맨드 라인에 의해서 생성될 수 있다. * `1.n+2` 릴리스에서는 코드베이스에서 메트릭이 제거되어야 한다. 더이상 임시방편은 존재하지 않는다. -릴리스 `1.12` 에서 `1.13` 으로 업그레이드 중이지만, `1.12` 에서 사용 중단된 메트릭 `A` 를 사용하고 있다면, 커맨드 라인에서 `--show-hidden-metrics=1.12` 플래그로 히든 메트릭을 설정해야 하고, `1.14` 로 업그레이드하기 전에 이 메트릭을 사용하지 않도록 의존성을 제거하는 것을 기억해야 한다. +릴리스 `1.12` 에서 `1.13` 으로 업그레이드 중이지만, `1.12` 에서 사용 중단된 메트릭 `A` 를 사용하고 있다면, +커맨드 라인에서 `--show-hidden-metrics=1.12` 플래그로 히든 메트릭을 설정해야 하고, +`1.14` 로 업그레이드하기 전에 이 메트릭을 사용하지 않도록 의존성을 제거하는 것을 기억해야 한다. ## 액셀러레이터 메트릭 비활성화 -kubelet은 cAdvisor를 통해 액셀러레이터 메트릭을 수집한다. NVIDIA GPU와 같은 액셀러레이터의 경우, 이러한 메트릭을 수집하기 위해 kubelet은 드라이버에 열린 핸들을 가진다. 이는 인프라 변경(예: 드라이버 업데이트)을 수행하기 위해 클러스터 관리자가 kubelet 에이전트를 중지해야 함을 의미한다. +kubelet은 cAdvisor를 통해 액셀러레이터 메트릭을 수집한다. 이러한 메트릭을 수집하기 위해, +NVIDIA GPU와 같은 액셀러레이터의 경우, kubelet은 드라이버에 열린 핸들을 가진다. +이는 인프라 변경(예: 드라이버 업데이트)을 수행하기 위해, +클러스터 관리자가 kubelet 에이전트를 중지해야 함을 의미한다. -액셀러레이터 메트릭을 수집하는 책임은 이제 kubelet이 아닌 공급 업체에 있다. 공급 업체는 메트릭을 수집하여 메트릭 서비스(예: 프로메테우스)에 노출할 컨테이너를 제공해야 한다. +액셀러레이터 메트릭을 수집하는 책임은 이제 kubelet이 아닌 공급 업체에 있다. +공급 업체는 메트릭을 수집하여 메트릭 서비스(예: 프로메테우스)에 노출할 +컨테이너를 제공해야 한다. -[`DisableAcceleratorUsageMetrics` 기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/#알파-또는-베타-기능을-위한-기능-게이트:~:text= DisableAcceleratorUsageMetrics,-false)는 [이 기능을 기본적으로 사용하도록 설정하는 타임라인](https://github.com/kubernetes/enhancements/tree/411e51027db842355bd489691af897afc1a41a5e/keps/sig-node/1867-disable-accelerator-usage-metrics#graduation-criteria)를 사용하여 kubelet에서 수집한 메트릭을 비활성화한다. +[`DisableAcceleratorUsageMetrics` 기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/#알파-또는-베타-기능을-위한-기능-게이트:~:text=DisableAcceleratorUsageMetrics,-false)는 +[이 기능을 기본적으로 사용하도록 설정하는 타임라인](https://github.com/kubernetes/enhancements/tree/411e51027db842355bd489691af897afc1a41a5e/keps/sig-node/1867-disable-accelerator-usage-metrics#graduation-criteria)를 +사용하여 kubelet에서 수집한 메트릭을 비활성화한다. ## 컴포넌트 메트릭 @@ -117,7 +143,8 @@ kubelet은 cAdvisor를 통해 액셀러레이터 메트릭을 수집한다. NVID etcd 요청 대기 시간 또는 Cloudprovider(AWS, GCE, OpenStack) API 대기 시간과 같은 컨트롤러 특정 메트릭이 포함되어 클러스터의 상태를 측정하는 데 사용할 수 있다. -쿠버네티스 1.7부터 GCE, AWS, Vsphere 및 OpenStack의 스토리지 운영에 대한 상세한 Cloudprovider 메트릭을 사용할 수 있다. +쿠버네티스 1.7부터 GCE, AWS, Vsphere 및 OpenStack의 스토리지 운영에 대한 +상세한 Cloudprovider 메트릭을 사용할 수 있다. 이 메트릭은 퍼시스턴트 볼륨 동작의 상태를 모니터링하는 데 사용할 수 있다. 예를 들어, GCE의 경우 이러한 메트릭을 다음과 같이 호출한다. @@ -136,9 +163,15 @@ cloudprovider_gce_api_request_duration_seconds { request = "list_disk"} {{< feature-state for_k8s_version="v1.21" state="beta" >}} -스케줄러는 실행 중인 모든 파드의 요청(request)된 리소스와 요구되는 제한(limit)을 보고하는 선택적 메트릭을 노출한다. 이러한 메트릭은 용량 계획(capacity planning) 대시보드를 구축하고, 현재 또는 과거 스케줄링 제한을 평가하고, 리소스 부족으로 스케줄할 수 없는 워크로드를 빠르게 식별하고, 실제 사용량을 파드의 요청과 비교하는 데 사용할 수 있다. +스케줄러는 실행 중인 모든 파드의 요청(request)된 리소스와 요구되는 제한(limit)을 보고하는 선택적 메트릭을 노출한다. +이러한 메트릭은 용량 계획(capacity planning) 대시보드를 구축하고, +현재 또는 과거 스케줄링 제한을 평가하고, 리소스 부족으로 스케줄할 수 없는 워크로드를 빠르게 식별하고, +실제 사용량을 파드의 요청과 비교하는 데 사용할 수 있다. + +kube-scheduler는 각 파드에 대해 구성된 리소스 [요청과 제한](/ko/docs/concepts/configuration/manage-resources-containers/)을 식별한다. +요청 또는 제한이 0이 아닌 경우 kube-scheduler는 메트릭 시계열을 보고한다. +시계열에는 다음과 같은 레이블이 지정된다. -kube-scheduler는 각 파드에 대해 구성된 리소스 [요청과 제한](/ko/docs/concepts/configuration/manage-resources-containers/)을 식별한다. 요청 또는 제한이 0이 아닌 경우 kube-scheduler는 메트릭 시계열을 보고한다. 시계열에는 다음과 같은 레이블이 지정된다. - 네임스페이스 - 파드 이름 - 파드가 스케줄된 노드 또는 아직 스케줄되지 않은 경우 빈 문자열 @@ -147,32 +180,46 @@ kube-scheduler는 각 파드에 대해 구성된 리소스 [요청과 제한](/k - 리소스 이름 (예: `cpu`) - 알려진 경우 리소스 단위 (예: `cores`) -파드가 완료되면 (`Never` 또는 `OnFailure`의 `restartPolicy`가 있고 `Succeeded` 또는 `Failed` 파드 단계에 있거나, 삭제되고 모든 컨테이너가 종료된 상태에 있음) 스케줄러가 이제 다른 파드를 실행하도록 스케줄할 수 있으므로 시리즈가 더 이상 보고되지 않는다. 두 메트릭을 `kube_pod_resource_request` 및 `kube_pod_resource_limit` 라고 한다. +파드가 완료되면 (`Never` 또는 `OnFailure`의 `restartPolicy`가 있고 +`Succeeded` 또는 `Failed` 파드 단계에 있거나, 삭제되고 모든 컨테이너가 종료된 상태에 있음) +스케줄러가 이제 다른 파드를 실행하도록 스케줄할 수 있으므로 시리즈가 더 이상 보고되지 않는다. +두 메트릭을 `kube_pod_resource_request` 및 `kube_pod_resource_limit` 라고 한다. -메트릭은 HTTP 엔드포인트 `/metrics/resources`에 노출되며 스케줄러의 `/metrics` 엔드포인트 -와 동일한 인증이 필요하다. 이러한 알파 수준의 메트릭을 노출시키려면 `--show-hidden-metrics-for-version=1.20` 플래그를 사용해야 한다. +메트릭은 HTTP 엔드포인트 `/metrics/resources`에 노출되며 +스케줄러의 `/metrics` 엔드포인트와 동일한 인증이 필요하다. +이러한 알파 수준의 메트릭을 노출시키려면 `--show-hidden-metrics-for-version=1.20` 플래그를 사용해야 한다. ## 메트릭 비활성화 -커맨드 라인 플래그 `--disabled-metrics` 를 통해 메트릭을 명시적으로 끌 수 있다. 이 방법이 필요한 이유는 메트릭이 성능 문제를 일으키는 경우을 예로 들 수 있다. 입력값은 비활성화되는 메트릭 목록이다(예: `--disabled-metrics=metric1,metric2`). +커맨드 라인 플래그 `--disabled-metrics` 를 통해 메트릭을 명시적으로 끌 수 있다. +이 방법이 필요한 이유는 메트릭이 성능 문제를 일으키는 경우을 예로 들 수 있다. +입력값은 비활성화되는 메트릭 목록이다(예: `--disabled-metrics=metric1,metric2`). ## 메트릭 카디널리티(cardinality) 적용 -제한되지 않은 차원의 메트릭은 계측하는 컴포넌트에서 메모리 문제를 일으킬 수 있다. 리소스 사용을 제한하려면, `--allow-label-value` 커맨드 라인 옵션을 사용하여 메트릭 항목에 대한 레이블 값의 허용 목록(allow-list)을 동적으로 구성한다. +제한되지 않은 차원의 메트릭은 계측하는 컴포넌트에서 메모리 문제를 일으킬 수 있다. +리소스 사용을 제한하려면, `--allow-label-value` 커맨드 라인 옵션을 사용하여 +메트릭 항목에 대한 레이블 값의 허용 목록(allow-list)을 동적으로 구성한다. 알파 단계에서, 플래그는 메트릭 레이블 허용 목록으로 일련의 매핑만 가져올 수 있다. 각 매핑은 `,=` 형식이다. 여기서 `` 는 허용되는 레이블 이름의 쉼표로 구분된 목록이다. 전체 형식은 다음과 같다. -`--allow-label-value ,=', ...', ,=', ...', ...`. + +``` +--allow-label-value ,=', ...', ,=', ...', ... +``` 예시는 다음과 같다. -`--allow-label-value number_count_metric,odd_number='1,3,5', number_count_metric,even_number='2,4,6', date_gauge_metric,weekend='Saturday,Sunday'` +```none +--allow-label-value number_count_metric,odd_number='1,3,5', number_count_metric,even_number='2,4,6', date_gauge_metric,weekend='Saturday,Sunday' +``` ## {{% heading "whatsnext" %}} -* 메트릭에 대한 [프로메테우스 텍스트 형식](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format)에 대해 읽어본다 +* 메트릭에 대한 [프로메테우스 텍스트 형식](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format) + 에 대해 읽어본다 * [안정 버전의 쿠버네티스 메트릭](https://github.com/kubernetes/kubernetes/blob/master/test/instrumentation/testdata/stable-metrics-list.yaml) 목록을 살펴본다 -* [쿠버네티스 사용 중단 정책](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior)에 대해 읽어본다 +* [쿠버네티스 사용 중단 정책](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior)에 대해 읽어본다 \ No newline at end of file