Ko: 1st Korean l10n work for release-1.20
- Translate reference/glossary/persistent-volume.md in Korean (#25474) - Update outdated files in the dev-1.20-ko.1 branch (1) (#25576) - Translate blog/dont-panic-kubernetes-and-docker into Korean (#25596) - Update outdated files in the dev-1.20-ko.1 branch(3) (#25728) - Ko: enhance tutorials//cluster-intro translation (#25754) - Fix Outdated files in the dev-1.20-ko.1 branch (2) (#25765) Co-authored-by: seokho-son <shsongist@gmail.com> Co-authored-by: jmyung <jesang.myung@gmail.com> Co-authored-by: Jerry Park <jaehwa@gmail.com> Co-authored-by: santachopa <santachopa@naver.com> Co-authored-by: SEUNGHYUN KO <kosehy@gmail.com> Co-authored-by: June Yi <gochist@gmail.com>
This commit is contained in:
Jerry Park
@@ -17,7 +17,7 @@ weight: 70
|
||||
|
||||
## 이미지 수집
|
||||
|
||||
쿠버네티스는 cadvisor와 imageManager를 통하여 모든 이미지들의
|
||||
쿠버네티스는 cadvisor와 imageManager를 통하여 모든 이미지들의
|
||||
라이프사이클을 관리한다.
|
||||
|
||||
이미지들에 대한 가비지 수집 정책에는 다음 2가지 요소가 고려된다:
|
||||
@@ -36,26 +36,26 @@ kubelet이 관리하지 않는 컨테이너는 컨테이너 가비지 수집 대
|
||||
|
||||
## 사용자 설정
|
||||
|
||||
사용자는 후술될 kubelet 플래그들을 통하여 이미지 가비지 수집을 조정하기 위하여 다음의 임계값을 조정할 수 있다.
|
||||
여러분은 후술될 kubelet 플래그들을 통하여 이미지 가비지 수집을 조정하기 위하여 다음의 임계값을 조정할 수 있다.
|
||||
|
||||
1. `image-gc-high-threshold`, 이미지 가비지 수집을 발생시키는 디스크 사용량의 비율로
|
||||
기본값은 85% 이다.
|
||||
2. `image-gc-low-threshold`, 이미지 가비지 수집을 더 이상 시도하지 않는 디스크 사용량의 비율로
|
||||
기본값은 80% 이다.
|
||||
|
||||
또한 사용자는 다음의 kubelet 플래그를 통해 가비지 수집 정책을 사용자 정의 할 수 있다.
|
||||
다음의 kubelet 플래그를 통해 가비지 수집 정책을 사용자 정의할 수 있다.
|
||||
|
||||
1. `minimum-container-ttl-duration`, 종료된 컨테이너가 가비지 수집
|
||||
되기 전의 최소 시간. 기본 값은 0 분이며, 이 경우 모든 종료된 컨테이너는 바로 가비지 수집의 대상이 된다.
|
||||
1. `minimum-container-ttl-duration`, 종료된 컨테이너가 가비지 수집
|
||||
되기 전의 최소 시간. 기본 값은 0 분이며, 이 경우 모든 종료된 컨테이너는 바로 가비지 수집의 대상이 된다.
|
||||
2. `maximum-dead-containers-per-container`, 컨테이너가 보유할 수 있는 오래된
|
||||
인스턴스의 최대 수. 기본 값은 1 이다.
|
||||
3. `maximum-dead-containers`, 글로벌하게 보유 할 컨테이너의 최대 오래된 인스턴스의 최대 수.
|
||||
기본 값은 -1이며, 이 경우 인스턴스 수의 제한은 없다.
|
||||
|
||||
컨테이너들은 유용성이 만료되기 이전에도 가비지 수집이 될 수 있다. 이러한 컨테이너들은
|
||||
문제 해결에 도움이 될 수 있는 로그나 다른 데이터를 포함하고 있을 수 있다. 컨테이너 당 적어도
|
||||
1개의 죽은 컨테이너가 허용될 수 있도록 `maximum-dead-containers-per-container`
|
||||
값을 충분히 큰 값으로 지정하는 것을 권장한다. 동일한 이유로 `maximum-dead-containers`
|
||||
문제 해결에 도움이 될 수 있는 로그나 다른 데이터를 포함하고 있을 수 있다. 컨테이너 당 적어도
|
||||
1개의 죽은 컨테이너가 허용될 수 있도록 `maximum-dead-containers-per-container`
|
||||
값을 충분히 큰 값으로 지정하는 것을 권장한다. 동일한 이유로 `maximum-dead-containers`
|
||||
의 값도 상대적으로 더 큰 값을 권장한다.
|
||||
자세한 내용은 [해당 이슈](https://github.com/kubernetes/kubernetes/issues/13287)를 참고한다.
|
||||
|
||||
@@ -82,5 +82,3 @@ kubelet이 관리하지 않는 컨테이너는 컨테이너 가비지 수집 대
|
||||
|
||||
|
||||
자세한 내용은 [리소스 부족 처리 구성](/docs/tasks/administer-cluster/out-of-resource/)를 본다.
|
||||
|
||||
|
||||
|
||||
@@ -55,11 +55,12 @@ weight: 50
|
||||
주로 호환된다. 잡이 이전에 VM에서 실행된 경우, VM에 IP가 있고
|
||||
프로젝트의 다른 VM과 통신할 수 있다. 이것은 동일한 기본 모델이다.
|
||||
|
||||
쿠버네티스의 IP 주소는 그것의 IP 주소를 포함하여 `Pod` 범위에 존재한다(`Pod` 내
|
||||
쿠버네티스의 IP 주소는 그것의 IP 주소와 MAC 주소를 포함하여 `Pod` 범위에 존재한다(`Pod` 내
|
||||
컨테이너는 네트워크 네임스페이스를 공유함). 이것은 `Pod` 내 컨테이너가 모두
|
||||
`localhost` 에서 서로의 포트에 도달할 수 있다는 것을 의미한다. 또한
|
||||
`Pod` 내부의 컨테이너 포트의 사용을 조정해야하는 것을 의미하지만, 이것도
|
||||
VM 내의 프로세스와 동일하다. 이것을 "IP-per-pod(파드별 IP)" 모델이라고 한다.
|
||||
VM 내의 프로세스와 동일하다. 이것을 "IP-per-pod(파드별 IP)" 모델이라고
|
||||
한다.
|
||||
|
||||
이것이 어떻게 구현되는 지는 사용 중인 특정 컨테이너 런타임의 세부 사항이다.
|
||||
|
||||
|
||||
@@ -128,6 +128,25 @@ cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"}
|
||||
cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
|
||||
```
|
||||
|
||||
### kube-scheduler 메트릭
|
||||
|
||||
{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
|
||||
|
||||
스케줄러는 실행 중인 모든 파드의 요청(request)된 리소스와 요구되는 제한(limit)을 보고하는 선택적 메트릭을 노출한다. 이러한 메트릭은 용량 계획(capacity planning) 대시보드를 구축하고, 현재 또는 과거 스케줄링 제한을 평가하고, 리소스 부족으로 스케줄할 수 없는 워크로드를 빠르게 식별하고, 실제 사용량을 파드의 요청과 비교하는 데 사용할 수 있다.
|
||||
|
||||
kube-scheduler는 각 파드에 대해 구성된 리소스 [요청과 제한](/ko/docs/concepts/configuration/manage-resources-containers/)을 식별한다. 요청 또는 제한이 0이 아닌 경우 kube-scheduler는 메트릭 시계열을 보고한다. 시계열에는 다음과 같은 레이블이 지정된다.
|
||||
- 네임스페이스
|
||||
- 파드 이름
|
||||
- 파드가 스케줄된 노드 또는 아직 스케줄되지 않은 경우 빈 문자열
|
||||
- 우선순위
|
||||
- 해당 파드에 할당된 스케줄러
|
||||
- 리소스 이름 (예: `cpu`)
|
||||
- 알려진 경우 리소스 단위 (예: `cores`)
|
||||
|
||||
파드가 완료되면 (`Never` 또는 `OnFailure`의 `restartPolicy`가 있고 `Succeeded` 또는 `Failed` 파드 단계에 있거나, 삭제되고 모든 컨테이너가 종료된 상태에 있음) 스케줄러가 이제 다른 파드를 실행하도록 스케줄할 수 있으므로 시리즈가 더 이상 보고되지 않는다. 두 메트릭을 `kube_pod_resource_request` 및 `kube_pod_resource_limit` 라고 한다.
|
||||
|
||||
메트릭은 HTTP 엔드포인트 `/metrics/resources`에 노출되며 스케줄러의 `/metrics` 엔드포인트
|
||||
와 동일한 인증이 필요하다. 이러한 알파 수준의 메트릭을 노출시키려면 `--show-hidden-metrics-for-version=1.20` 플래그를 사용해야 한다.
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
Reference in New Issue
Block a user