Merge pull request #22449 from kubernetes/dev-1.18-ko.7

Seventh Korean l10n work for release 1.18
This commit is contained in:
Kubernetes Prow Robot
2020-07-09 21:28:48 -07:00
committed by GitHub
148 changed files with 2604 additions and 1350 deletions
@@ -1,5 +1,6 @@
---
title: "모니터링, 로깅, 그리고 디버깅"
description: 모니터링 및 로깅을 설정하여 클러스터 문제를 해결하거나, 컨테이너화된 애플리케이션을 디버깅한다.
weight: 80
---
@@ -5,15 +5,15 @@ content_type: task
<!-- overview -->
이 페이지는 컨테이너 종료 메시지를 읽고 쓰는
이 페이지는 컨테이너 종료 메시지를 읽고 쓰는
방법을 보여준다.
종료 메시지는 컨테이너가 치명적인 이벤트에 대한 정보를,
종료 메시지는 컨테이너가 치명적인 이벤트에 대한 정보를,
대시보드나 모니터링 소프트웨어 도구와 같이
쉽게 조회 및 표시할 수 있는 위치에
쉽게 조회 및 표시할 수 있는 위치에
기록하는 방법을 제공한다.
대부분의 경우에 종료 메시지에 넣는 정보는
일반
대부분의 경우에 종료 메시지에 넣는 정보는
일반
[쿠버네티스 로그](/ko/docs/concepts/cluster-administration/logging/)에도 쓰여져야 한다.
@@ -32,7 +32,7 @@ content_type: task
## 종료 메시지 읽기 및 쓰기
이 예제에서는, 하나의 컨테이너를 실행하는 파드를 생성한다.
하단의 설정 파일은 컨테이너가 시작될 때 수행하는
하단의 설정 파일은 컨테이너가 시작될 때 수행하는
명령어를 지정한다.
{{< codenew file="debug/termination.yaml" >}}
@@ -41,8 +41,8 @@ content_type: task
kubectl apply -f https://k8s.io/examples/debug/termination.yaml
YAML 파일에 있는 `cmd``args` 필드에서 컨테이너가 10초 간 잠든 뒤에
"Sleep expired" 문자열을 `/dev/termination-log` 파일에 기록하는
YAML 파일에 있는 `cmd``args` 필드에서 컨테이너가 10초 간 잠든 뒤에
"Sleep expired" 문자열을 `/dev/termination-log` 파일에 기록하는
것을 확인할 수 있다. 컨테이너는 "Sleep expired" 메시지를
기록한 후에 종된다.
@@ -70,25 +70,25 @@ content_type: task
Sleep expired
...
1. 종료 메시지만을 포함하는 출력 결과를 보기
1. 종료 메시지만을 포함하는 출력 결과를 보기
위해서는 Go 템플릿을 사용한다.
kubectl get pod termination-demo -o go-template="{{range .status.containerStatuses}}{{.lastState.terminated.message}}{{end}}"
## 종료 메시지 사용자 정의하기
쿠버네티스는 컨테이너의 `terminationMessagePath` 필드에 지정된
종료 메시지 파일에서 종료 메시지를 검색하며, 이 필드의 기본값은
`/dev/termination-log` 이다. 이 필드를 사용자 정의 함으로써
쿠버네티스가 종료 메시지를 검색할 때 다른 파일을 사용하도록 조정할 수 있다.
쿠버네티스는 컨테이너의 `terminationMessagePath` 필드에 지정된
종료 메시지 파일에서 종료 메시지를 검색하며, 이 필드의 기본값은
`/dev/termination-log` 이다. 이 필드를 사용자 정의 함으로써
쿠버네티스가 종료 메시지를 검색할 때 다른 파일을 사용하도록 조정할 수 있다.
쿠버네티스는 지정된 파일의 내용을 사용하여 컨테이너의 성공 및 실패에 대한 상태 메시지를 채운다.
종료 메시지는 assertion failure 메세지처럼 간결한 최종 상태로 생성된다.
kubelet은 4096 바이트보다 긴 메시지를 자른다. 모든 컨테이너의 총 메시지 길이는
12KiB로 제한된다. 기본 종료 메시지 경로는 `/dev/termination-log`이다.
kubelet은 4096 바이트보다 긴 메시지를 자른다. 모든 컨테이너의 총 메시지 길이는
12KiB로 제한된다. 기본 종료 메시지 경로는 `/dev/termination-log`이다.
파드가 시작된 후에는 종료 메시지 경로를 설정할 수 없다.
다음의 예제에서 컨테이너는, 쿠버네티스가 조회할 수 있도록
다음의 예제에서 컨테이너는, 쿠버네티스가 조회할 수 있도록
`/tmp/my-log` 파일에 종료 메시지를 기록한다.
```yaml
@@ -103,12 +103,12 @@ spec:
terminationMessagePath: "/tmp/my-log"
```
또한 사용자는 추가적인 사용자 정의를 위해 컨테이너의 `terminationMessagePolicy`
필드를 설정할 수 있다. 이 필드의 기본 값은 `File` 이며,
이는 오직 종료 메시지 파일에서만 종료 메시지가 조회되는 것을 의미한다.
`terminationMessagePolicy` 필드의 값을 "`FallbackToLogsOnError` 으로
설정함으로써, 종료 메시지 파일이 비어 있고 컨테이너가 오류와 함께 종료 되었을 경우
쿠버네티스가 컨테이너 로그 출력의 마지막 청크를 사용하도록 지시할 수 있다.
또한 사용자는 추가적인 사용자 정의를 위해 컨테이너의 `terminationMessagePolicy`
필드를 설정할 수 있다. 이 필드의 기본 값은 `File` 이며,
이는 오직 종료 메시지 파일에서만 종료 메시지가 조회되는 것을 의미한다.
`terminationMessagePolicy` 필드의 값을 "`FallbackToLogsOnError` 으로
설정함으로써, 종료 메시지 파일이 비어 있고 컨테이너가 오류와 함께 종료 되었을 경우
쿠버네티스가 컨테이너 로그 출력의 마지막 청크를 사용하도록 지시할 수 있다.
로그 출력은 2048 바이트나 80 행 중 더 작은 값으로 제한된다.
@@ -118,9 +118,5 @@ spec:
* [컨테이너](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
에 있는 `terminationMessagePath` 에 대해 읽어보기.
* [로그 검색](/docs/concepts/cluster-administration/logging/)에 대해 배워보기.
* [로그 검색](/ko/docs/concepts/cluster-administration/logging/)에 대해 배워보기.
* [Go 템플릿](https://golang.org/pkg/text/template/)에 대해 배워보기.
@@ -5,10 +5,10 @@ content_type: concept
<!-- overview -->
컨테이너 CPU 및 메모리 사용량과 같은 리소스 사용량 메트릭은
쿠버네티스의 메트릭 API를 통해 사용할 수 있다. 이 메트릭은
`kubectl top` 커맨드 사용과 같이 사용자가 직접적으로 액세스하거나,
Horizontal Pod Autoscaler 같은 클러스터의 컨트롤러에서 결정을 내릴 때 사용될 수 있다.
컨테이너 CPU 및 메모리 사용량과 같은 리소스 사용량 메트릭은
쿠버네티스의 메트릭 API를 통해 사용할 수 있다. 이 메트릭은
`kubectl top` 커맨드 사용과 같이 사자가 직접적으로 액세스하거나,
Horizontal Pod Autoscaler 같은 클러스터의 컨트롤러에서 결정을 내릴 때 사용될 수 있다.
@@ -17,9 +17,9 @@ Horizontal Pod Autoscaler 같은 클러스터의 컨트롤러에서 결정을
## 메트릭 API
메트릭 API를 통해 주어진 노드나 파드에서 현재 사용중인
리소스의 양을 알 수 있다. 이 API는 메트릭 값을 저장하지
않으므로 지정된 노드에서 10분 전에 사용된 리소스의 양을
메트릭 API를 통해 주어진 노드나 파드에서 현재 사용중인
리소스의 양을 알 수 있다. 이 API는 메트릭 값을 저장하지
않으므로 지정된 노드에서 10분 전에 사용된 리소스의 양을
가져오는 것과 같은 일을 할 수는 없다.
이 API와 다른 API는 차이가 없다.
@@ -27,7 +27,7 @@ Horizontal Pod Autoscaler 같은 클러스터의 컨트롤러에서 결정을
- 다른 쿠버네티스 API의 엔드포인트와 같이 `/apis/metrics.k8s.io/` 하위 경로에서 발견될 수 있다
- 동일한 보안, 확장성 및 신뢰성 보장을 제공한다
[k8s.io/metrics](https://github.com/kubernetes/metrics/blob/master/pkg/apis/metrics/v1beta1/types.go)
[k8s.io/metrics](https://github.com/kubernetes/metrics/blob/master/pkg/apis/metrics/v1beta1/types.go)
리포지터리에서 이 API를 정의하고 있다. 여기에서 이 API에 대한 더 상세한 정보를 찾을 수 있다.
{{< note >}}
@@ -38,7 +38,7 @@ Horizontal Pod Autoscaler 같은 클러스터의 컨트롤러에서 결정을
### CPU
CPU는 일정 기간 동안 [CPU 코어](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-cpu)에서 평균 사용량으로 리포트된다. 이 값은 커널(리눅스와 윈도우 커널 모두)에서 제공하는 누적 CPU 카운터보다 높은 비율을 적용해서 얻는다. kubelet은 비율 계산에 사용할 윈도우를 선택한다.
CPU는 일정 기간 동안 [CPU 코어](/ko/docs/concepts/configuration/manage-resources-containers/#cpu의-의미)에서 평균 사용량으로 리포트된다. 이 값은 커널(리눅스와 윈도우 커널 모두)에서 제공하는 누적 CPU 카운터보다 높은 비율을 적용해서 얻는다. kubelet은 비율 계산에 사용할 윈도우를 선택한다.
### 메모리
@@ -47,15 +47,13 @@ CPU는 일정 기간 동안 [CPU 코어](https://kubernetes.io/docs/concepts/con
## 메트릭 서버
[메트릭 서버](https://github.com/kubernetes-incubator/metrics-server)는 클러스터 전역에서 리소스 사용량 데이터를 집계한다.
`kube-up.sh` 스크립트에 의해 생성된 클러스터에는 기본적으로 메트릭 서버가
디플로이먼트 오브젝트로 배포된다. 만약 다른 쿠버네티스 설치 메커니즘을 사용한다면, 제공된
`kube-up.sh` 스크립트에 의해 생성된 클러스터에는 기본적으로 메트릭 서버가
디플로이먼트 오브젝트로 배포된다. 만약 다른 쿠버네티스 설치 메커니즘을 사용한다면, 제공된
[디플로이먼트 components.yaml](https://github.com/kubernetes-sigs/metrics-server/releases) 파일을 사용하여 메트릭 서버를 배포할 수 있다.
메트릭 서버는 각 노드에서 [Kubelet](/docs/admin/kubelet/)에 의해 노출된 Summary API에서 메트릭을 수집한다.
메트릭 서버는 [쿠버네티스 aggregator](/docs/concepts/api-extension/apiserver-aggregation/)를
메트릭 서버는 [쿠버네티스 aggregator](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를
통해 메인 API 서버에 등록된다.
[설계 문서](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md)에서 메트릭 서버에 대해 자세하게 배울 수 있다.