Eleventh Korean l10n work for release 1.18
- Update outdated files in the dev-1.18-ko.11 branch (#23643) - Fix inconsistent translation in Ko (#23683) Co-authored-by: Jerry Park <jaehwa@gmail.com> Co-authored-by: Daehyun Paik <paik@a30a.dev>
This commit is contained in:
Daehyun Paik
@@ -5,24 +5,20 @@ content_type: task
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
이 페이지는 초기화 컨테이너의 실행과 관련된 문제를
|
||||
조사하는 방법에 대해 보여준다. 아래 예제의 커맨드 라인은 파드(Pod)를 `<pod-name>` 으로,
|
||||
초기화 컨테이너를 `<init-container-1>` 과
|
||||
이 페이지는 초기화 컨테이너의 실행과 관련된 문제를
|
||||
조사하는 방법에 대해 보여준다. 아래 예제의 커맨드 라인은 파드(Pod)를 `<pod-name>` 으로,
|
||||
초기화 컨테이너를 `<init-container-1>` 과
|
||||
`<init-container-2>` 로 표시한다.
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
* 사용자는 [초기화 컨테이너](/ko/docs/concepts/workloads/pods/init-containers/)의
|
||||
* 사용자는 [초기화 컨테이너](/ko/docs/concepts/workloads/pods/init-containers/)의
|
||||
기본 사항에 익숙해야 한다.
|
||||
* 사용자는 [초기화 컨테이너를 구성](/ko/docs/tasks/configure-pod-container/configure-pod-initialization/#초기화-컨테이너를-갖는-파드-생성)해야 한다.
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## 초기화 컨테이너의 상태 체크하기
|
||||
@@ -33,7 +29,7 @@ content_type: task
|
||||
kubectl get pod <pod-name>
|
||||
```
|
||||
|
||||
예를 들어, `Init:1/2` 상태는 두 개의 초기화 컨테이너 중
|
||||
예를 들어, `Init:1/2` 상태는 두 개의 초기화 컨테이너 중
|
||||
하나가 성공적으로 완료되었음을 나타낸다.
|
||||
|
||||
```
|
||||
@@ -41,7 +37,7 @@ NAME READY STATUS RESTARTS AGE
|
||||
<pod-name> 0/1 Init:1/2 0 7s
|
||||
```
|
||||
|
||||
상태값과 그 의미에 대한 추가 예제는
|
||||
상태값과 그 의미에 대한 추가 예제는
|
||||
[파드 상태 이해하기](#파드의-상태-이해하기)를 참조한다.
|
||||
|
||||
## 초기화 컨테이너에 대한 상세 정보 조회하기
|
||||
@@ -82,7 +78,7 @@ Init Containers:
|
||||
...
|
||||
```
|
||||
|
||||
파드 스펙의 `status.initContainerStatuses` 필드를 읽어서
|
||||
파드 스펙의 `status.initContainerStatuses` 필드를 읽어서
|
||||
프로그래밍 방식으로 초기화 컨테이너의 상태를 조회할 수도 있다.
|
||||
|
||||
|
||||
@@ -102,8 +98,8 @@ kubectl get pod nginx --template '{{.status.initContainerStatuses}}'
|
||||
kubectl logs <pod-name> -c <init-container-2>
|
||||
```
|
||||
|
||||
셸 스크립트를 실행하는 초기화 컨테이너는, 초기화 컨테이너가
|
||||
실행될 때 명령어를 출력한다. 예를 들어, 스크립트의 시작 부분에
|
||||
셸 스크립트를 실행하는 초기화 컨테이너는, 초기화 컨테이너가
|
||||
실행될 때 명령어를 출력한다. 예를 들어, 스크립트의 시작 부분에
|
||||
`set -x` 를 추가하고 실행하여 Bash에서 명령어를 출력할 수 있도록 수행할 수 있다.
|
||||
|
||||
|
||||
@@ -112,8 +108,8 @@ kubectl logs <pod-name> -c <init-container-2>
|
||||
|
||||
## 파드의 상태 이해하기
|
||||
|
||||
`Init:` 으로 시작하는 파드 상태는 초기화 컨테이너의
|
||||
실행 상태를 요약한다. 아래 표는 초기화 컨테이너를 디버깅하는
|
||||
`Init:` 으로 시작하는 파드 상태는 초기화 컨테이너의
|
||||
실행 상태를 요약한다. 아래 표는 초기화 컨테이너를 디버깅하는
|
||||
동안 사용자가 확인할 수 있는 몇 가지 상태값의 예이다.
|
||||
|
||||
상태 | 의미
|
||||
|
||||
@@ -7,7 +7,7 @@ title: 엘라스틱서치(Elasticsearch) 및 키바나(Kibana)를 사용한 로
|
||||
|
||||
Google 컴퓨트 엔진(Compute Engine, GCE) 플랫폼에서, 기본 로깅 지원은
|
||||
[스택드라이버(Stackdriver) 로깅](https://cloud.google.com/logging/)을 대상으로 한다. 이는
|
||||
[스택드라이버 로깅으로 로깅하기](/docs/user-guide/logging/stackdriver)에 자세히 설명되어 있다.
|
||||
[스택드라이버 로깅으로 로깅하기](/docs/tasks/debug-application-cluster/logging-stackdriver)에 자세히 설명되어 있다.
|
||||
|
||||
이 문서에서는 GCE에서 운영할 때 스택드라이버 로깅의 대안으로,
|
||||
[엘라스틱서치](https://www.elastic.co/products/elasticsearch)에 로그를 수집하고
|
||||
@@ -87,7 +87,8 @@ monitoring-influx-grafana-v1-o79xf 2/2 Running 0 2h
|
||||
|
||||
엘라스틱서치 및 키바나 서비스는 모두 `kube-system` 네임스페이스에
|
||||
있으며 공개적으로 접근 가능한 IP 주소를 통해 직접 노출되지 않는다. 이를 위해,
|
||||
[클러스터에서 실행 중인 서비스 접근](/ko/docs/tasks/access-application-cluster/access-cluster/#클러스터에서-실행되는-서비스로-액세스)에 대한 지침을 참고한다.
|
||||
[클러스터에서 실행 중인 서비스 접근](/ko/docs/tasks/access-application-cluster/access-cluster/#클러스터에서-실행되는-서비스로-액세스)에
|
||||
대한 지침을 참고한다.
|
||||
|
||||
브라우저에서 `elasticsearch-logging` 서비스에 접근하려고 하면,
|
||||
다음과 같은 상태 페이지가 표시된다.
|
||||
@@ -118,5 +119,3 @@ monitoring-influx-grafana-v1-o79xf 2/2 Running 0 2h
|
||||
|
||||
키바나는 로그를 탐색하기 위한 모든 종류의 강력한 옵션을 제공한다! 이를 파헤치는 방법에 대한
|
||||
아이디어는 [키바나의 문서](https://www.elastic.co/guide/en/kibana/current/discover.html)를 확인한다.
|
||||
|
||||
|
||||
|
||||
@@ -10,9 +10,6 @@ content_type: concept
|
||||
`kubectl top` 커맨드 사용과 같이 사용자가 직접적으로 액세스하거나,
|
||||
Horizontal Pod Autoscaler 같은 클러스터의 컨트롤러에서 결정을 내릴 때 사용될 수 있다.
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 메트릭 API
|
||||
@@ -38,11 +35,19 @@ Horizontal Pod Autoscaler 같은 클러스터의 컨트롤러에서 결정을
|
||||
|
||||
### CPU
|
||||
|
||||
CPU는 일정 기간 동안 [CPU 코어](/ko/docs/concepts/configuration/manage-resources-containers/#cpu의-의미)에서 평균 사용량으로 리포트된다. 이 값은 커널(리눅스와 윈도우 커널 모두)에서 제공하는 누적 CPU 카운터보다 높은 비율을 적용해서 얻는다. kubelet은 비율 계산에 사용할 윈도우를 선택한다.
|
||||
CPU는 일정 기간 동안
|
||||
[CPU 코어](/ko/docs/concepts/configuration/manage-resources-containers/#cpu의-의미)에서
|
||||
평균 사용량으로 리포트된다. 이 값은 커널(리눅스와 윈도우 커널 모두)에서 제공하는
|
||||
누적 CPU 카운터보다 높은 비율을 적용해서 얻는다.
|
||||
kubelet은 비율 계산에 사용할 윈도우를 선택한다.
|
||||
|
||||
### 메모리
|
||||
|
||||
메모리는 메트릭이 수집된 순간 작업 집합으로 리포트 된다. 이상적인 환경에서 "작업 집합(working set)"은 압박(memory pressure)에서 풀려날 수 없는 사용 중인(in-use) 메모리의 양이다. 그러나 작업 집합의 계산은 호스트 OS에 따라 다르며, 일반적으로 휴리스틱스를 사용해서 평가한다. 쿠버네티스는 스왑(swap)을 지원하지 않기 때문에 모든 익명(파일로 백업되지 않은) 메모리를 포함한다. 호스트 OS가 항상 이러한 페이지를 회수할 수 없기 때문에 메트릭에는 일반적으로 일부 캐시된(파일 백업) 메모리도 포함된다.
|
||||
메모리는 메트릭이 수집된 순간 작업 집합으로 리포트 된다.
|
||||
이상적인 환경에서 "작업 집합(working set)"은 압박(memory pressure)에서 풀려날 수 없는 사용 중인(in-use) 메모리의 양이다.
|
||||
그러나 작업 집합의 계산은 호스트 OS에 따라 다르며, 일반적으로 휴리스틱스를 사용해서 평가한다.
|
||||
쿠버네티스는 스왑(swap)을 지원하지 않기 때문에 모든 익명(파일로 백업되지 않은) 메모리를 포함한다.
|
||||
호스트 OS가 항상 이러한 페이지를 회수할 수 없기 때문에 메트릭에는 일반적으로 일부 캐시된(파일 백업) 메모리도 포함된다.
|
||||
|
||||
## 메트릭 서버
|
||||
|
||||
@@ -51,9 +56,11 @@ CPU는 일정 기간 동안 [CPU 코어](/ko/docs/concepts/configuration/manage-
|
||||
디플로이먼트 오브젝트로 배포된다. 만약 다른 쿠버네티스 설치 메커니즘을 사용한다면, 제공된
|
||||
[디플로이먼트 components.yaml](https://github.com/kubernetes-sigs/metrics-server/releases) 파일을 사용하여 메트릭 서버를 배포할 수 있다.
|
||||
|
||||
메트릭 서버는 각 노드에서 [Kubelet](/docs/admin/kubelet/)에 의해 노출된 Summary API에서 메트릭을 수집한다.
|
||||
메트릭 서버는 각 노드에서 [Kubelet](/docs/reference/command-line-tools-reference/kubelet/)에 의해
|
||||
노출된 Summary API에서 메트릭을 수집한다.
|
||||
|
||||
메트릭 서버는 [쿠버네티스 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)에서 메트릭 서버에 대해 자세하게 배울 수 있다.
|
||||
[설계 문서](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md)에서
|
||||
메트릭 서버에 대해 자세하게 배울 수 있다.
|
||||
|
||||
@@ -5,38 +5,41 @@ title: 리소스 모니터링 도구
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
애플리케이션을 스케일하여 신뢰할 수 있는 서비스를 제공하려면,
|
||||
애플리케이션이 배포되었을 때 애플리케이션이 어떻게 동작하는지를 이해해야 한다.
|
||||
컨테이너, [파드](/ko/docs/concepts/workloads/pods/pod),
|
||||
[서비스](/ko/docs/concepts/services-networking/service), 그리고 전체 클러스터의 특성을
|
||||
검사하여 쿠버네티스 클러스터 내의 애플리케이션 성능을 검사할 수 있다. 쿠버네티스는 각 레벨에서
|
||||
애플리케이션을 스케일하여 신뢰할 수 있는 서비스를 제공하려면,
|
||||
애플리케이션이 배포되었을 때 애플리케이션이 어떻게 동작하는지를 이해해야 한다.
|
||||
컨테이너, [파드](/ko/docs/concepts/workloads/pods/pod),
|
||||
[서비스](/ko/docs/concepts/services-networking/service),
|
||||
그리고 전체 클러스터의 특성을 검사하여
|
||||
쿠버네티스 클러스터 내의 애플리케이션 성능을 검사할 수 있다. 쿠버네티스는 각 레벨에서
|
||||
애플리케이션의 리소스 사용량에 대한 상세 정보를 제공한다.
|
||||
이 정보는 애플리케이션의 성능을 평가하고
|
||||
이 정보는 애플리케이션의 성능을 평가하고
|
||||
병목 현상을 제거하여 전체 성능을 향상할 수 있게 해준다.
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
쿠버네티스에서 애플리케이션 모니터링은 단일 모니터링 솔루션에 의존하지 않는다. 신규 클러스터에서는, [리소스 메트릭](#리소스-메트릭-파이프라인) 또는 [완전한 메트릭](#완전한-메트릭-파이프라인) 파이프라인으로 모니터링 통계를 수집할 수 있다.
|
||||
쿠버네티스에서 애플리케이션 모니터링은 단일 모니터링 솔루션에 의존하지 않는다.
|
||||
신규 클러스터에서는, [리소스 메트릭](#리소스-메트릭-파이프라인) 또는
|
||||
[완전한 메트릭](#완전한-메트릭-파이프라인) 파이프라인으로 모니터링 통계를 수집할 수 있다.
|
||||
|
||||
## 리소스 메트릭 파이프라인
|
||||
|
||||
리소스 메트릭 파이프라인은 [Horizontal Pod Autoscaler](/ko/docs/tasks/run-application/horizontal-pod-autoscale)
|
||||
컨트롤러와 같은 클러스터 구성요소나 `kubectl top` 유틸리티에 관련되어 있는
|
||||
리소스 메트릭 파이프라인은
|
||||
[Horizontal Pod Autoscaler](/ko/docs/tasks/run-application/horizontal-pod-autoscale)
|
||||
컨트롤러와 같은 클러스터 구성요소나
|
||||
`kubectl top` 유틸리티에 관련되어 있는
|
||||
메트릭들로 제한된 집합을 제공한다. 이 메트릭은 경량의 단기 인메모리 저장소인
|
||||
[metrics-server](https://github.com/kubernetes-incubator/metrics-server)에
|
||||
의해서 수집되며 `metrics.k8s.io` API를 통해 노출된다.
|
||||
의해서 수집되며 `metrics.k8s.io` API를 통해 노출된다.
|
||||
|
||||
metrics-server는 클러스터 상의 모든 노드를 발견하고 각 노드의
|
||||
[Kubelet](/docs/reference/command-line-tools-reference/kubelet)에 CPU와 메모리
|
||||
metrics-server는 클러스터 상의 모든 노드를 발견하고 각 노드의
|
||||
[Kubelet](/docs/reference/command-line-tools-reference/kubelet/)에 CPU와 메모리
|
||||
사용량을 질의한다. Kubelet은 쿠버네티스 마스터와 노드 간의 다리 역할을 해서
|
||||
머신에서 구동되는 파드와 컨테이너를 관리한다. Kubelet은 각각의 파드를 해당하는
|
||||
컨테이너로 변환하고 컨테이너 런타임 인터페이스를 통해서 컨테이너 런타임에서
|
||||
개별 컨테이너의 사용량 통계를 가져온다. Kubelet은 이 정보를 레거시 도커와의
|
||||
개별 컨테이너의 사용량 통계를 가져온다. Kubelet은 이 정보를 레거시 도커와의
|
||||
통합을 위해 kubelet에 통합된 cAdvisor를 통해 가져온다. 그 다음으로 취합된 파드
|
||||
리소스 사용량 통계를 metric-server 리소스 메트릭 API를 통해 노출한다. 이 API는
|
||||
kubelet의 인증이 필요한 읽기 전용 포트 상의 `/metrics/resource/v1beta1`에서
|
||||
kubelet의 인증이 필요한 읽기 전용 포트 상의 `/metrics/resource/v1beta1`에서
|
||||
제공된다.
|
||||
|
||||
## 완전한 메트릭 파이프라인
|
||||
@@ -50,5 +53,3 @@ kubelet의 인증이 필요한 읽기 전용 포트 상의 `/metrics/resource/v1
|
||||
|
||||
CNCF 프로젝트인, [프로메테우스](https://prometheus.io)는 기본적으로 쿠버네티스, 노드, 프로메테우스 자체를 모니터링할 수 있다.
|
||||
CNCF 프로젝트가 아닌 완전한 메트릭 파이프라인 프로젝트는 쿠버네티스 문서의 범위가 아니다.
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user