whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge pull request #28739 from kubernetes/dev-1.21-ko.5

Browse Source 
[ko] 5th Korean localization work for v1.21
This commit is contained in:
Kubernetes Prow Robot
2021-07-01 18:08:12 -07:00
committed by GitHub
parent 0b3ee6bbd5 a0cab7282a
commit e87ee3e927
136 changed files with 996 additions and 498 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/concepts/architecture/controller.md
+3 -3
View File
@@ -159,11 +159,11 @@ IP 주소 관리 도구, 스토리지 서비스, 클라우드 제공자의 API
또는 쿠버네티스 외부에서 실행할 수 있다. 가장 적합한 것은 특정 컨트롤러의 기능에
따라 달라진다.
## {{% heading "whatsnext" %}}
* [쿠버네티스 컨트롤 플레인](/ko/docs/concepts/overview/components/#컨트롤-플레인-컴포넌트)에 대해 읽기
* [쿠버네티스 오브젝트](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/)의 몇 가지 기본 사항을 알아보자.
* [쿠버네티스 API](/ko/docs/concepts/overview/kubernetes-api/)에 대해 더 배워 보자.
* 만약 자신만의 컨트롤러를 작성하기 원한다면, 쿠버네티스 확장하기의 [확장 패턴](/ko/docs/concepts/extend-kubernetes/extend-cluster/#익스텐션-패턴)을 본다.
* 만약 자신만의 컨트롤러를 작성하기 원한다면,
쿠버네티스 확장하기의 [확장 패턴](/ko/docs/concepts/extend-kubernetes/#익스텐션-패턴)을
본다.
content/ko/docs/concepts/cluster-administration/_index.md
Executable → Regular
View File
content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md
+27 -15
View File
@@ -1,5 +1,4 @@
---
title: kubelet 가비지(Garbage) 수집 설정하기
content_type: concept
weight: 70
@@ -7,12 +6,13 @@ weight: 70
<!-- overview -->
가비지 수집은 사용되지 않는 [이미지](/ko/docs/concepts/containers/#컨테이너-이미지)들과 [컨테이너](/ko/docs/concepts/containers/)들을 정리하는 kubelet의 유용한 기능이다. Kubelet은 1분마다 컨테이너들에 대하여 가비지 수집을 수행하며, 5분마다 이미지들에 대하여 가비지 수집을 수행한다.
별도의 가비지 수집 도구들을 사용하는 것은, 이러한 도구들이 존재할 수도 있는 컨테이너들을 제거함으로써 kubelet 을 중단시킬 수도 있으므로 권장하지 않는다.
가비지 수집은 사용되지 않는
[이미지](/ko/docs/concepts/containers/#컨테이너-이미지)들과
[컨테이너](/ko/docs/concepts/containers/)들을 정리하는 kubelet의 유용한 기능이다. Kubelet은
1분마다 컨테이너들에 대하여 가비지 수집을 수행하며, 5분마다 이미지들에 대하여 가비지 수집을 수행한다.
별도의 가비지 수집 도구들을 사용하는 것은, 이러한 도구들이 존재할 수도 있는 컨테이너들을 제거함으로써
kubelet을 중단시킬 수도 있으므로 권장하지 않는다.
<!-- body -->
@@ -28,10 +28,24 @@ weight: 70
## 컨테이너 수집
컨테이너에 대한 가비지 수집 정책은 세 가지 사용자 정의 변수들을 고려한다: `MinAge` 는 컨테이너를 가비지 수집 할 수 있는 최소 연령이다. `MaxPerPodContainer` 는 모든 단일 파드 (UID, 컨테이너 이름) 쌍이 가질 수 있는
최대 비활성 컨테이너의 수량이다. `MaxContainers` 죽은 컨테이너의 최대 수량이다. 이러한 변수는 `MinAge` 를 0으로 설정하고, `MaxPerPodContainer` 와 `MaxContainers` 를 각각 0 보다 작게 설정해서 비활성화 할 수 있다.
컨테이너에 대한 가비지 수집 정책은 세 가지 사용자 정의 변수들을 고려한다.
`MinAge` 는 컨테이너를 가비지 수집할 수 있는 최소 연령이다.
`MaxPerPodContainer` 는 모든 단일 파드(UID, 컨테이너 이름)
쌍이 가질 수 있는 최대 비활성 컨테이너의 수량이다.
`MaxContainers` 는 죽은 컨테이너의 최대 수량이다.
이러한 변수는 `MinAge` 를 0으로 설정하고,
`MaxPerPodContainer` 와 `MaxContainers` 를 각각 0 보다 작게 설정해서 비활성화할 수 있다.
Kubelet은 미확인, 삭제 또는 앞에서 언급 한 플래그가 설정 한 경계를 벗어나거나, 확인되지 않은 컨테이너에 대해 조치를 취한다. 일반적으로 가장 오래된 컨테이너가 먼저 제거된다. `MaxPerPodContainer` 와 `MaxContainer` 는 파드 당 최대 컨테이너 수 (`MaxPerPodContainer`)가 허용 가능한 범위의 전체 죽은 컨테이너의 수(`MaxContainers`)를 벗어나는 상황에서 잠재적으로 서로 충돌할 수 있습니다. 이러한 상황에서 `MaxPerPodContainer` 가 조정된다: 최악의 시나리오는 `MaxPerPodContainer` 를 1로 다운그레이드하고 가장 오래된 컨테이너를 제거하는 것이다. 추가로, 삭제된 파드가 소유 한 컨테이너는 `MinAge` 보다 오래된 컨테이너가 제거된다.
Kubelet은 미확인, 삭제 또는 앞에서 언급한
플래그가 설정한 경계를 벗어나거나, 확인되지 않은 컨테이너에 대해 조치를 취한다.
일반적으로 가장 오래된 컨테이너가 먼저 제거된다. `MaxPerPodContainer` 와 `MaxContainer` 는
파드 당 최대
컨테이너 수(`MaxPerPodContainer`)가 허용 가능한 범위의
전체 죽은 컨테이너의 수(`MaxContainers`)를 벗어나는 상황에서 잠재적으로 서로 충돌할 수 있다.
다음의 상황에서 `MaxPerPodContainer` 가 조정된다.
최악의 시나리오는 `MaxPerPodContainer` 를 1로 다운그레이드하고
가장 오래된 컨테이너를 제거하는 것이다. 추가로, 삭제된 파드가 소유한 컨테이너는
`MinAge` 보다 오래되면 제거된다.
kubelet이 관리하지 않는 컨테이너는 컨테이너 가비지 수집 대상이 아니다.
@@ -40,9 +54,9 @@ kubelet이 관리하지 않는 컨테이너는 컨테이너 가비지 수집 대
여러분은 후술될 kubelet 플래그들을 통하여 이미지 가비지 수집을 조정하기 위하여 다음의 임계값을 조정할 수 있다.
1. `image-gc-high-threshold`, 이미지 가비지 수집을 발생시키는 디스크 사용량의 비율로
기본값은 85% 이다.
기본값은 85% 이다.
2. `image-gc-low-threshold`, 이미지 가비지 수집을 더 이상 시도하지 않는 디스크 사용량의 비율로
기본값은 80% 이다.
기본값은 80% 이다.
다음의 kubelet 플래그를 통해 가비지 수집 정책을 사용자 정의할 수 있다.
@@ -77,9 +91,7 @@ kubelet이 관리하지 않는 컨테이너는 컨테이너 가비지 수집 대
| `--low-diskspace-threshold-mb` | `--eviction-hard` or `eviction-soft` | 축출이 다른 리소스에 대한 디스크 임계값을 일반화 함 |
| `--outofdisk-transition-frequency` | `--eviction-pressure-transition-period` | 축출이 다른 리소스로의 디스크 압력전환을 일반화 함 |
## {{% heading "whatsnext" %}}
자세한 내용은 [리소스 부족 처리 구성](/docs/tasks/administer-cluster/out-of-resource/)를 본다.
자세한 내용은 [리소스 부족 처리 구성](/docs/concepts/scheduling-eviction/node-pressure-eviction/)를
본다.
content/ko/docs/concepts/cluster-administration/system-logs.md
+3 -3
View File
@@ -20,7 +20,7 @@ weight: 60
klog는 쿠버네티스의 로깅 라이브러리다. [klog](https://github.com/kubernetes/klog)
는 쿠버네티스 시스템 컴포넌트의 로그 메시지를 생성한다.
klog 설정에 대한 더 많은 정보는, [커맨드라인 툴](/docs/reference/command-line-tools-reference/)을 참고한다.
klog 설정에 대한 더 많은 정보는, [커맨드라인 툴](/ko/docs/reference/command-line-tools-reference/)을 참고한다.
klog 네이티브 형식 예 :
```
@@ -61,7 +61,7 @@ I1025 00:15:15.525108 1 controller_utils.go:116] "Pod status updated" pod=
{{<warning >}}
JSON 출력은 많은 표준 klog 플래그를 지원하지 않는다. 지원하지 않는 klog 플래그 목록은, [커맨드라인 툴](/docs/reference/command-line-tools-reference/)을 참고한다.
JSON 출력은 많은 표준 klog 플래그를 지원하지 않는다. 지원하지 않는 klog 플래그 목록은, [커맨드라인 툴](/ko/docs/reference/command-line-tools-reference/)을 참고한다.
모든 로그가 JSON 형식으로 작성되는 것은 아니다(예: 프로세스 시작 중). 로그를 파싱하려는 경우
JSON 형식이 아닌 로그 행을 처리할 수 있는지 확인해야 한다.
@@ -143,6 +143,6 @@ systemd를 사용하는 시스템에서는, kubelet과 컨테이너 런타임은
## {{% heading "whatsnext" %}}
* [쿠버네티스 로깅 아키텍처](/docs/concepts/cluster-administration/logging/) 알아보기
* [쿠버네티스 로깅 아키텍처](/ko/docs/concepts/cluster-administration/logging/) 알아보기
* [구조화된 로깅](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1602-structured-logging) 알아보기
* [로깅 심각도(serverity) 규칙](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md) 알아보기
content/ko/docs/concepts/configuration/_index.md
Executable → Regular
View File
content/ko/docs/concepts/configuration/secret.md
+6 -6
View File
@@ -31,7 +31,7 @@ weight: 30
시크릿을 안전하게 사용하려면 (최소한) 다음과 같이 하는 것이 좋다.
1. 시크릿에 대한 [암호화 활성화](/docs/tasks/administer-cluster/encrypt-data/).
2. 시크릿 읽기 및 쓰기를 제한하는 [RBAC 규칙 활성화 또는 구성](/docs/reference/access-authn-authz/authorization/). 파드를 만들 권한이 있는 모든 사용자는 시크릿을 암묵적으로 얻을 수 있다.
2. 시크릿 읽기 및 쓰기를 제한하는 [RBAC 규칙 활성화 또는 구성](/ko/docs/reference/access-authn-authz/authorization/). 파드를 만들 권한이 있는 모든 사용자는 시크릿을 암묵적으로 얻을 수 있다.
{{< /caution >}}
<!-- body -->
@@ -48,7 +48,7 @@ weight: 30
- 파드의 [이미지를 가져올 때 kubelet](#imagepullsecrets-사용하기)에 의해 사용.
시크릿 오브젝트의 이름은 유효한
[DNS 서브도메인 이름](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)이어야 한다.
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
사용자는 시크릿을 위한 파일을 구성할 때 `data` 및 (또는) `stringData` 필드를
명시할 수 있다. 해당 `data` 와 `stringData` 필드는 선택적으로 명시할 수 있다.
`data` 필드의 모든 키(key)에 해당하는 값(value)은 base64로 인코딩된 문자열이어야 한다.
@@ -1156,10 +1156,10 @@ HTTP 요청을 처리하고, 복잡한 비즈니스 로직을 수행한 다음,
### 시크릿 API를 사용하는 클라이언트
시크릿 API와 상호 작용하는 애플리케이션을 배포할 때, [RBAC](
/docs/reference/access-authn-authz/rbac/)과 같은 [인가 정책](
/docs/reference/access-authn-authz/authorization/)을
사용하여 접근를 제한해야 한다.
시크릿 API와 상호 작용하는 애플리케이션을 배포할 때,
[RBAC](/docs/reference/access-authn-authz/rbac/)과 같은
[인가 정책](/ko/docs/reference/access-authn-authz/authorization/)을
사용하여 접근을 제한해야 한다.
시크릿은 종종 다양한 중요도에 걸친 값을 보유하며, 이 중 많은 부분이
쿠버네티스(예: 서비스 어카운트 토큰)와 외부 시스템으로 단계적으로
content/ko/docs/concepts/containers/_index.md
Executable → Regular
View File
content/ko/docs/concepts/containers/runtime-class.md
+4 -4
View File
@@ -68,7 +68,7 @@ handler: myconfiguration # 상응하는 CRI 설정의 이름임
```
런타임클래스 오브젝트의 이름은 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)어이야 한다.
[DNS 레이블 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-레이블-이름)어이야 한다.
{{< note >}}
런타임클래스 쓰기 작업(create/update/patch/delete)은
@@ -132,7 +132,7 @@ https://github.com/containerd/cri/blob/master/docs/config.md
runtime_path = "${PATH_TO_BINARY}"
```
더 자세한 것은 CRI-O의 [설정 문서](https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md)를 본다.
더 자세한 것은 CRI-O의 [설정 문서](https://github.com/cri-o/cri-o/blob/master/docs/crio.conf.5.md)를 본다.
## 스케줄
@@ -175,5 +175,5 @@ PodOverhead를 사용하려면, PodOverhead [기능 게이트](/ko/docs/referenc
- [런타임클래스 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md)
- [런타임클래스 스케줄링 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md#runtimeclass-scheduling)
- [파드 오버헤드](/ko/docs/concepts/configuration/pod-overhead/) 개념에 대해 읽기
- [파드 오버헤드 기능 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)
- [파드 오버헤드](/ko/docs/concepts/scheduling-eviction/pod-overhead/) 개념에 대해 읽기
- [파드 오버헤드 기능 설계](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead)
content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
+1 -1
View File
@@ -128,7 +128,7 @@ CRD를 사용하면 다른 API 서버를 추가하지 않고도 새로운 타입
## 커스텀리소스데피니션
[커스텀리소스데피니션](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)
[커스텀리소스데피니션](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)
API 리소스를 사용하면 커스텀 리소스를 정의할 수 있다.
CRD 오브젝트를 정의하면 지정한 이름과 스키마를 사용하여 새 커스텀 리소스가 만들어진다.
쿠버네티스 API는 커스텀 리소스의 스토리지를 제공하고 처리한다.
content/ko/docs/concepts/overview/_index.md
Executable → Regular
View File
content/ko/docs/concepts/overview/kubernetes-api.md
+3 -3
View File
@@ -20,14 +20,14 @@ card:
쿠버네티스 API를 사용하면 쿠버네티스의 API 오브젝트(예:
파드(Pod), 네임스페이스(Namespace), 컨피그맵(ConfigMap) 그리고 이벤트(Event))를 질의(query)하고 조작할 수 있다.
대부분의 작업은 [kubectl](/docs/reference/kubectl/overview/)
대부분의 작업은 [kubectl](/ko/docs/reference/kubectl/overview/)
커맨드 라인 인터페이스 또는 API를 사용하는
[kubeadm](/ko/docs/reference/setup-tools/kubeadm/)과
같은 다른 커맨드 라인 도구를 통해 수행할 수 있다.
그러나, REST 호출을 사용하여 API에 직접 접근할 수도 있다.
쿠버네티스 API를 사용하여 애플리케이션을 작성하는 경우
[클라이언트 라이브러리](/docs/reference/using-api/client-libraries/) 중 하나를 사용하는 것이 좋다.
[클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/) 중 하나를 사용하는 것이 좋다.
<!-- body -->
@@ -130,7 +130,7 @@ API 리소스는 API 그룹, 리소스 유형, 네임스페이스
{{< /note >}}
API 버전 수준 정의에 대한 자세한 내용은
[API 버전 레퍼런스](/ko/docs/reference/using-api/api-overview/#api-버전-규칙)를 참조한다.
[API 버전 레퍼런스](/ko/docs/reference/using-api/#api-버전-규칙)를 참조한다.
content/ko/docs/concepts/policy/pod-security-policy.md
+6 -6
View File
@@ -464,12 +464,12 @@ podsecuritypolicy "example" deleted
예를 들면 다음과 같습니다.
```yaml
allowedHostPaths:
# 이 정책은 "/foo", "/foo/", "/foo/bar" 등을 허용하지만,
# "/fool", "/etc/foo" 등은 허용하지 않는다.
# "/foo/../" 는 절대 유효하지 않다.
- pathPrefix: "/foo"
readOnly: true # 읽기 전용 마운트만 허용
allowedHostPaths:
# 이 정책은 "/foo", "/foo/", "/foo/bar" 등을 허용하지만,
# "/fool", "/etc/foo" 등은 허용하지 않는다.
# "/foo/../" 는 절대 유효하지 않다.
- pathPrefix: "/foo"
readOnly: true # 읽기 전용 마운트만 허용
```
{{< warning >}}호스트 파일시스템에 제한없는 접근을 부여하며, 컨테이너가 특권을 에스컬레이션
content/ko/docs/concepts/policy/resource-quotas.md
+17 -11
View File
@@ -58,7 +58,8 @@ weight: 20
## 리소스 쿼터 활성화
많은 쿠버네티스 배포판에 기본적으로 리소스 쿼터 지원이 활성화되어 있다.
{{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}} `--enable-admission-plugins=` 플래그의 인수 중 하나로
{{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}}
`--enable-admission-plugins=` 플래그의 인수 중 하나로
`ResourceQuota`가 있는 경우 활성화된다.
해당 네임스페이스에 리소스쿼터가 있는 경우 특정 네임스페이스에
@@ -66,7 +67,9 @@ weight: 20
## 컴퓨트 리소스 쿼터
지정된 네임스페이스에서 요청할 수 있는 총 [컴퓨트 리소스](/ko/docs/concepts/configuration/manage-resources-containers/) 합을 제한할 수 있다.
지정된 네임스페이스에서 요청할 수 있는 총
[컴퓨트 리소스](/ko/docs/concepts/configuration/manage-resources-containers/)
합을 제한할 수 있다.
다음과 같은 리소스 유형이 지원된다.
@@ -125,7 +128,9 @@ GPU 리소스를 다음과 같이 쿼터를 정의할 수 있다.
| `ephemeral-storage` | `requests.ephemeral-storage` 와 같음. |
{{< note >}}
CRI 컨테이너 런타임을 사용할 때, 컨테이너 로그는 임시 스토리지 쿼터에 포함된다. 이로 인해 스토리지 쿼터를 소진한 파드가 예기치 않게 축출될 수 있다. 자세한 내용은 [로깅 아키텍처](/ko/docs/concepts/cluster-administration/logging/)를 참조한다.
CRI 컨테이너 런타임을 사용할 때, 컨테이너 로그는 임시 스토리지 쿼터에 포함된다.
이로 인해 스토리지 쿼터를 소진한 파드가 예기치 않게 축출될 수 있다.
자세한 내용은 [로깅 아키텍처](/ko/docs/concepts/cluster-administration/logging/)를 참조한다.
{{< /note >}}
## 오브젝트 수 쿼터
@@ -192,7 +197,7 @@ CRI 컨테이너 런타임을 사용할 때, 컨테이너 로그는 임시 스
| `NotTerminating` | `.spec.activeDeadlineSeconds is nil`에 일치하는 파드 |
| `BestEffort` | 최상의 서비스 품질을 제공하는 파드 |
| `NotBestEffort` | 서비스 품질이 나쁜 파드 |
| `PriorityClass` | 지정된 [프라이어리티 클래스](/ko/docs/concepts/configuration/pod-priority-preemption)를 참조하여 일치하는 파드. |
| `PriorityClass` | 지정된 [프라이어리티클래스](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)를 참조하여 일치하는 파드. |
| `CrossNamespacePodAffinity` | 크로스-네임스페이스 파드 [(안티)어피니티 용어]가 있는 파드 |
`BestEffort` 범위는 다음의 리소스를 추적하도록 쿼터를 제한한다.
@@ -248,13 +253,14 @@ CRI 컨테이너 런타임을 사용할 때, 컨테이너 로그는 임시 스
{{< feature-state for_k8s_version="v1.17" state="stable" >}}
특정 [우선 순위](/ko/docs/concepts/configuration/pod-priority-preemption/#파드-우선순위)로 파드를 생성할 수 있다.
특정 [우선 순위](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/#파드-우선순위)로 파드를 생성할 수 있다.
쿼터 스펙의 `scopeSelector` 필드를 사용하여 파드의 우선 순위에 따라 파드의 시스템 리소스 사용을
제어할 수 있다.
쿼터 스펙의 `scopeSelector`가 파드를 선택한 경우에만 쿼터가 일치하고 사용된다.
`scopeSelector` 필드를 사용하여 우선 순위 클래스의 쿼터 범위를 지정하면, 쿼터 오브젝트는 다음의 리소스만 추적하도록 제한된다.
`scopeSelector` 필드를 사용하여 우선 순위 클래스의 쿼터 범위를 지정하면,
쿼터 오브젝트는 다음의 리소스만 추적하도록 제한된다.
* `pods`
* `cpu`
@@ -554,7 +560,7 @@ kubectl create -f ./object-counts.yaml --namespace=myspace
kubectl get quota --namespace=myspace
```
```
```none
NAME AGE
compute-resources 30s
object-counts 32s
@@ -564,7 +570,7 @@ object-counts 32s
kubectl describe quota compute-resources --namespace=myspace
```
```
```none
Name: compute-resources
Namespace: myspace
Resource Used Hard
@@ -580,7 +586,7 @@ requests.nvidia.com/gpu 0 4
kubectl describe quota object-counts --namespace=myspace
```
```
```none
Name: object-counts
Namespace: myspace
Resource Used Hard
@@ -677,10 +683,10 @@ plugins:
{{< codenew file="policy/priority-class-resourcequota.yaml" >}}
```shell
$ kubectl apply -f https://k8s.io/examples/policy/priority-class-resourcequota.yaml -n kube-system
kubectl apply -f https://k8s.io/examples/policy/priority-class-resourcequota.yaml -n kube-system
```
```
```none
resourcequota/pods-cluster-services created
```
content/ko/docs/concepts/scheduling-eviction/_index.md
+2 -2
View File
@@ -32,6 +32,6 @@ no_list: true
{{<glossary_definition term_id="pod-disruption" length="all">}}
* [파드 우선순위와 선점](/docs/concepts/scheduling-eviction/pod-priority-preemption/)
* [파드 우선순위와 선점](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)
* [노드-압박 축출](/docs/concepts/scheduling-eviction/node-pressure-eviction/)
* [API를 이용한 축출](/docs/concepts/scheduling-eviction/api-eviction/)
* [API를 이용한 축출](/ko/docs/concepts/scheduling-eviction/api-eviction/)
content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md
+8 -8
View File
@@ -25,7 +25,7 @@ weight: 70
관리자는 리소스쿼터를 사용하여 사용자가 우선순위가 높은 파드를 생성하지
못하게 할 수 있다.
자세한 내용은 [기본적으로 프라이어리티 클래스(Priority Class) 소비 제한](/ko/docs/concepts/policy/resource-quotas/#기본적으로-우선-순위-클래스-소비-제한)을
자세한 내용은 [기본적으로 프라이어리티클래스(Priority Class) 소비 제한](/ko/docs/concepts/policy/resource-quotas/#기본적으로-우선-순위-클래스-소비-제한)을
참고한다.
{{< /warning >}}
@@ -50,7 +50,7 @@ weight: 70
## 프라이어리티클래스
프라이어리티클래스는 프라이어리티 클래스 이름에서 우선순위의 정수 값으로의 매핑을
프라이어리티클래스는 프라이어리티클래스 이름에서 우선순위의 정수 값으로의 매핑을
정의하는 네임스페이스가 아닌(non-namespaced) 오브젝트이다. 이름은
프라이어리티클래스 오브젝트의 메타데이터의 `name` 필드에 지정된다. 값은
필수 `value` 필드에 지정되어 있다. 값이 클수록, 우선순위가
@@ -96,7 +96,7 @@ metadata:
name: high-priority
value: 1000000
globalDefault: false
description: "이 프라이어리티 클래스는 XYZ 서비스 파드에만 사용해야 한다."
description: "이 프라이어리티클래스는 XYZ 서비스 파드에만 사용해야 한다."
```
## 비-선점 프라이어리티클래스 {#non-preempting-priority-class}
@@ -142,7 +142,7 @@ metadata:
value: 1000000
preemptionPolicy: Never
globalDefault: false
description: "이 프라이어리티 클래스는 다른 파드를 축출하지 않는다."
description: "이 프라이어리티클래스는 다른 파드를 축출하지 않는다."
```
## 파드 우선순위
@@ -150,7 +150,7 @@ description: "이 프라이어리티 클래스는 다른 파드를 축출하지
프라이어리티클래스가 하나 이상 있으면, 그것의 명세에서 이들 프라이어리티클래스 이름 중 하나를
지정하는 파드를 생성할 수 있다. 우선순위 어드미션
컨트롤러는 `priorityClassName` 필드를 사용하고 우선순위의 정수 값을
채운다. 프라이어리티 클래스를 찾을 수 없으면, 파드가 거부된다.
채운다. 프라이어리티클래스를 찾을 수 없으면, 파드가 거부된다.
다음의 YAML은 이전 예제에서 생성된 프라이어리티클래스를
사용하는 파드 구성의 예이다. 우선순위 어드미션 컨트롤러는
@@ -351,12 +351,12 @@ spec:
축출 대상으로 고려한다.
QoS와 파드 우선순위를 모두 고려하는 유일한 컴포넌트는
[kubelet 리소스 부족 축출](/docs/tasks/administer-cluster/out-of-resource/)이다.
[kubelet 리소스 부족 축출](/docs/concepts/scheduling-eviction/node-pressure-eviction/)이다.
kubelet은 부족한 리소스의 사용이 요청을 초과하는지 여부에 따라, 그런 다음 우선순위에 따라,
파드의 스케줄링 요청에 대한 부족한 컴퓨팅 리소스의 소비에 의해
먼저 축출 대상 파드의 순위를 매긴다.
더 자세한 내용은
[엔드유저 파드 축출](/docs/tasks/administer-cluster/out-of-resource/#evicting-end-user-pods)을
[엔드유저 파드 축출](/docs/concepts/scheduling-eviction/node-pressure-eviction/#evicting-end-user-pods)을
참조한다.
kubelet 리소스 부족 축출은 사용량이 요청을 초과하지 않는 경우
@@ -367,4 +367,4 @@ kubelet 리소스 부족 축출은 사용량이 요청을 초과하지 않는
## {{% heading "whatsnext" %}}
* 프라이어리티클래스와 관련하여 리소스쿼터 사용에 대해 [기본적으로 프라이어리티 클래스 소비 제한](/ko/docs/concepts/policy/resource-quotas/#기본적으로-우선-순위-클래스-소비-제한)을 읽어보자.
* 프라이어리티클래스와 관련하여 리소스쿼터 사용에 대해 [기본적으로 프라이어리티클래스 소비 제한](/ko/docs/concepts/policy/resource-quotas/#기본적으로-우선-순위-클래스-소비-제한)을 읽어보자.
content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md
+21 -19
View File
@@ -26,7 +26,7 @@ kube-scheduler를 미세 조정할 수 있다.
통해 사용자는 적절한 파라미터를 사용해서 확장된 리소스를 빈 팩으로 만들 수 있어
대규모의 클러스터에서 부족한 리소스의 활용도가 향상된다.
`RequestedToCapacityRatioResourceAllocation` 우선 순위 기능의
동작은 `requestedToCapacityRatioArguments`라는
동작은 `RequestedToCapacityRatioArgs`라는
구성 옵션으로 제어할 수 있다. 이 인수는 `shape`와 `resources`
두 개의 파라미터로 구성된다. `shape` 파라미터는 사용자가 `utilization`과
`score` 값을 기반으로 최소 요청 또는 최대 요청된 대로 기능을
@@ -39,27 +39,29 @@ kube-scheduler를 미세 조정할 수 있다.
설정하는 구성의 예시이다.
```yaml
apiVersion: v1
kind: Policy
apiVersion: kubescheduler.config.k8s.io/v1beta1
kind: KubeSchedulerConfiguration
profiles:
# ...
priorities:
# ...
- name: RequestedToCapacityRatioPriority
weight: 2
argument:
requestedToCapacityRatioArguments:
shape:
- utilization: 0
score: 0
- utilization: 100
score: 10
resources:
- name: intel.com/foo
weight: 3
- name: intel.com/bar
weight: 5
pluginConfig:
- name: RequestedToCapacityRatio
args:
shape:
- utilization: 0
score: 10
- utilization: 100
score: 0
resources:
- name: intel.com/foo
weight: 3
- name: intel.com/bar
weight: 5
```
kube-scheduler 플래그 `--config=/path/to/config/file` 을 사용하여
`KubeSchedulerConfiguration` 파일을 참조하면 구성이 스케줄러에
전달된다.
**이 기능은 기본적으로 비활성화되어 있다.**
### 우선 순위 기능 튜닝하기
content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md
+2 -2
View File
@@ -281,5 +281,5 @@ tolerations:
## {{% heading "whatsnext" %}}
* [리소스 부족 다루기](/docs/tasks/administer-cluster/out-of-resource/)와 어떻게 구성하는지에 대해 알아보기
* [파드 우선순위](/ko/docs/concepts/configuration/pod-priority-preemption/)에 대해 알아보기
* [리소스 부족 다루기](/docs/concepts/scheduling-eviction/node-pressure-eviction/)와 어떻게 구성하는지에 대해 알아보기
* [파드 우선순위](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)에 대해 알아보기
content/ko/docs/concepts/security/overview.md
+1 -1
View File
@@ -149,7 +149,7 @@ TLS를 통한 접근 | 코드가 TCP를 통해 통신해야 한다면, 미리
* [파드에 대한 네트워크 정책](/ko/docs/concepts/services-networking/network-policies/)
* [쿠버네티스 API 접근 제어하기](/ko/docs/concepts/security/controlling-access)
* [클러스터 보안](/docs/tasks/administer-cluster/securing-a-cluster/)
* 컨트롤 플레인을 위한 [전송 데이터 암호화](/docs/tasks/tls/managing-tls-in-a-cluster/)
* 컨트롤 플레인을 위한 [전송 데이터 암호화](/ko/docs/tasks/tls/managing-tls-in-a-cluster/)
* [Rest에서 데이터 암호화](/docs/tasks/administer-cluster/encrypt-data/)
* [쿠버네티스 시크릿](/ko/docs/concepts/configuration/secret/)
* [런타임 클래스](/ko/docs/concepts/containers/runtime-class)
content/ko/docs/concepts/services-networking/dns-pod-service.md
+3 -12
View File
@@ -7,6 +7,7 @@ content_type: concept
weight: 20
---
<!-- overview -->
쿠버네티스는 파드와 서비스를 위한 DNS 레코드를 생성한다. 사용자는 IP 주소 대신에
일관된 DNS 네임을 통해서 서비스에 접속할 수 있다.
@@ -261,6 +262,8 @@ spec:
### 파드의 DNS 설정 {#pod-dns-config}
{{< feature-state for_k8s_version="v1.14" state="stable" >}}
사용자들은 파드의 DNS 설정을 통해서 직접 파드의 DNS를 세팅할 수 있다.
`dnsConfig` 필드는 선택적이고, `dnsPolicy` 세팅과 함께 동작한다.
@@ -310,18 +313,6 @@ search default.svc.cluster-domain.example svc.cluster-domain.example cluster-dom
options ndots:5
```
### 기능 지원 여부
파드 DNS 구성 및 DNS 정책 "`None`"에 대한 지원 정보는 아래에서 확인 할 수 있다.
| k8s 버전 | 기능 지원 |
| :---------: |:-----------:|
| 1.14 | 안정 |
| 1.10 | 베타 (기본)|
| 1.9 | 알파 |
## {{% heading "whatsnext" %}}
content/ko/docs/concepts/services-networking/endpoint-slices.md
+4 -5
View File
@@ -154,7 +154,7 @@ v1beta1 API의 `topology` 필드에 있는 `"topology.kubernetes.io/zone"`
### 관리
대부분의 경우, 컨트롤 플레인(특히, 엔드포인트 슬라이스
대부분의 경우, 컨트롤 플레인(특히, 엔드포인트슬라이스
{{< glossary_tooltip text="컨트롤러" term_id="controller" >}})는
엔드포인트슬라이스 오브젝트를 생성하고 관리한다. 다른 엔티티나 컨트롤러가 추가
엔드포인트슬라이스 집합을 관리하게 할 수 있는 서비스 메시 구현과 같이
@@ -165,13 +165,13 @@ v1beta1 API의 `topology` 필드에 있는 `"topology.kubernetes.io/zone"`
엔티티를 나타내는 `endpointslice.kubernetes.io/managed-by`
{{< glossary_tooltip term_id="label" text="레이블" >}}을
정의한다.
엔드포인트 슬라이스 컨트롤러는 관리하는 모든 엔드포인트슬라이스에 레이블의 값으로
엔드포인트슬라이스 컨트롤러는 관리하는 모든 엔드포인트슬라이스에 레이블의 값으로
`endpointslice-controller.k8s.io` 를 설정한다. 엔드포인트슬라이스를
관리하는 다른 엔티티도 이 레이블에 고유한 값을 설정해야 한다.
### 소유권
대부분의 유스케이스에서, 엔드포인트 슬라이스 오브젝트가 엔드포인트를
대부분의 유스케이스에서, 엔드포인트슬라이스 오브젝트가 엔드포인트를
추적하는 서비스가 엔드포인트슬라이스를 소유한다. 이 소유권은 각 엔드포인트슬라이스의 소유자
참조와 서비스에 속한 모든 엔드포인트슬라이스의 간단한 조회를 가능하게 하는
`kubernetes.io/service-name` 레이블로 표시된다.
@@ -247,5 +247,4 @@ v1beta1 API의 `topology` 필드에 있는 `"topology.kubernetes.io/zone"`
## {{% heading "whatsnext" %}}
* [엔드포인트슬라이스 활성화하기](/docs/tasks/administer-cluster/enabling-endpointslices)에 대해 배우기
* [애플리케이션을 서비스와 함께 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 읽어보기
* [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 읽어보기
content/ko/docs/concepts/services-networking/service-traffic-policy.md
+2 -2
View File
@@ -21,7 +21,7 @@ _서비스 내부 트래픽 정책_ 을 사용하면 내부 트래픽 제한이
## 서비스 내부 트래픽 정책 사용
[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)에서
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)에서
`ServiceInternalTrafficPolicy`를 활성화한 후에
{{< glossary_tooltip text="서비스" term_id="service" >}}의
`.spec.internalTrafficPolicy`를 `Local`로 설정하여 내부 전용 트래픽 정책을 활성화 할 수 있다.
@@ -57,7 +57,7 @@ kube-proxy는 `spec.internalTrafficPolicy` 의 설정에 따라서 라우팅되
엔드포인트를 필터링한다.
이것을 `Local`로 설정하면, 노드 내부 엔드포인트만 고려한다.
이 설정이 `Cluster`이거나 누락되었다면 모든 엔드포인트를 고려한다.
[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)의
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)의
`ServiceInternalTrafficPolicy`를 활성화한다면, `spec.internalTrafficPolicy`는 기본값 "Cluster"로 설정된다.
## 제약조건
content/ko/docs/concepts/services-networking/service.md
+1 -1
View File
@@ -215,7 +215,7 @@ API 리소스이다. 개념적으로 엔드포인트와 매우 유사하지만,
오브젝트에 의해 미러링된다.
이 필드는 표준 쿠버네티스 레이블 구문을 따른다. 값은
[IANA 표준 서비스 이름](http://www.iana.org/assignments/service-names) 또는
[IANA 표준 서비스 이름](https://www.iana.org/assignments/service-names) 또는
`mycompany.com/my-custom-protocol`과 같은 도메인 접두사 이름 중 하나여야 한다.
## 가상 IP와 서비스 프록시
content/ko/docs/concepts/storage/volumes.md
+1 -1
View File
@@ -914,7 +914,7 @@ projected 볼륨 소스를 [`subPath`](#subpath-사용하기) 볼륨으로 마
### quobyte
`quobyte` 볼륨을 사용하면 기존 [Quobyte](http://www.quobyte.com) 볼륨을
`quobyte` 볼륨을 사용하면 기존 [Quobyte](https://www.quobyte.com) 볼륨을
파드에 마운트할 수 있다.
{{< note >}}
content/ko/docs/concepts/workloads/controllers/daemonset.md
+35 -18
View File
@@ -1,4 +1,10 @@
---
title: 데몬셋
content_type: concept
weight: 40
@@ -26,7 +32,8 @@ _데몬셋_ 은 모든(또는 일부) 노드가 파드의 사본을 실행하도
### 데몬셋 생성
YAML 파일로 데몬셋을 설명 할 수 있다. 예를 들어 아래 `daemonset.yaml` 파일은 fluentd-elasticsearch 도커 이미지를 실행하는 데몬셋을 설명한다.
YAML 파일에 데몬셋 명세를 작성할 수 있다. 예를 들어 아래 `daemonset.yaml` 파일은
fluentd-elasticsearch 도커 이미지를 실행하는 데몬셋을 설명한다.
{{< codenew file="controllers/daemonset.yaml" >}}
@@ -40,19 +47,23 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
다른 모든 쿠버네티스 설정과 마찬가지로 데몬셋에는 `apiVersion`, `kind` 그리고 `metadata` 필드가 필요하다.
일반적인 설정파일 작업에 대한 정보는
[스테이트리스 애플리케이션 실행하기](/docs/tasks/run-application/run-stateless-application-deployment/),
[컨테이너 구성하기](/ko/docs/tasks/) 그리고 [kubectl을 사용한 오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management/) 문서를 참고한다.
[스테이트리스 애플리케이션 실행하기](/docs/tasks/run-application/run-stateless-application-deployment/)와
[kubectl을 사용한 오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management/)를 참고한다.
데몬셋 오브젝트의 이름은 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
데몬셋에는 [`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) 섹션도 필요하다.
데몬셋에는
[`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)
섹션도 필요하다.
### 파드 템플릿
`.spec.template` 는 `.spec` 의 필수 필드 중 하나이다.
`.spec.template` 는 [파드 템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿)이다. 이것은 중첩되어 있다는 점과 `apiVersion` 또는 `kind` 를 가지지 않는 것을 제외하면 {{< glossary_tooltip text="파드" term_id="pod" >}}와 정확히 같은 스키마를 가진다.
`.spec.template` 는 [파드 템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿)이다.
이것은 중첩되어 있다는 점과 `apiVersion` 또는 `kind` 를 가지지 않는 것을 제외하면
{{< glossary_tooltip text="파드" term_id="pod" >}}와 정확히 같은 스키마를 가진다.
데몬셋의 파드 템플릿에는 파드의 필수 필드 외에도 적절한 레이블이 명시되어야
한다([파드 셀렉터](#파드-셀렉터)를 본다).
@@ -73,19 +84,22 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
`.spec.selector` 는 다음 2개의 필드로 구성된 오브젝트이다.
* `matchLabels` - [레플리케이션 컨트롤러](/ko/docs/concepts/workloads/controllers/replicationcontroller/)의 `.spec.selector` 와 동일하게 작동한다.
* `matchLabels` - [레플리케이션 컨트롤러](/ko/docs/concepts/workloads/controllers/replicationcontroller/)의
`.spec.selector` 와 동일하게 작동한다.
* `matchExpressions` - 키, 값 목록 그리고 키 및 값에 관련된 연산자를
명시해서 보다 정교한 셀렉터를 만들 수 있다.
2개의 필드가 명시되면 두 필드를 모두 만족하는 것(ANDed)이 결과가 된다.
만약 `.spec.selector` 를 명시하면, 이것은 `.spec.template.metadata.labels` 와 일치해야 한다. 일치하지 않는 구성은 API에 의해 거부된다.
만약 `.spec.selector` 를 명시하면, 이것은 `.spec.template.metadata.labels` 와 일치해야 한다.
일치하지 않는 구성은 API에 의해 거부된다.
### 오직 일부 노드에서만 파드 실행
만약 `.spec.template.spec.nodeSelector` 를 명시하면 데몬셋 컨트롤러는
[노드 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-셀렉터-nodeselector)와
일치하는 노드에 파드를 생성한다. 마찬가지로 `.spec.template.spec.affinity` 를 명시하면
일치하는 노드에 파드를 생성한다.
마찬가지로 `.spec.template.spec.affinity` 를 명시하면
데몬셋 컨트롤러는 [노드 어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-어피니티)와 일치하는 노드에 파드를 생성한다.
만약 둘 중 하나를 명시하지 않으면 데몬셋 컨트롤러는 모든 노드에서 파드를 생성한다.
@@ -100,18 +114,19 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
데몬셋 파드는 데몬셋 컨트롤러에 의해 생성되고 스케줄된다.
이에 대한 이슈를 소개한다.
* 파드 동작의 불일치: 스케줄 되기 위해서 대기 중인 일반 파드는 `Pending` 상태로 생성된다.
그러나 데몬셋 파드는 `Pending` 상태로 생성되지 않는다.
이것은 사용자에게 혼란을 준다.
* [파드 선점](/ko/docs/concepts/configuration/pod-priority-preemption/)은
기본 스케줄러에서 처리한다. 선점이 활성화되면 데몬셋 컨트롤러는
파드 우선순위와 선점을 고려하지 않고 스케줄 한다.
* 파드 동작의 불일치: 스케줄 되기 위해서 대기 중인 일반 파드는 `Pending` 상태로 생성된다.
그러나 데몬셋 파드는 `Pending` 상태로 생성되지 않는다.
이것은 사용자에게 혼란을 준다.
* [파드 선점](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)은
기본 스케줄러에서 처리한다. 선점이 활성화되면 데몬셋 컨트롤러는
파드 우선순위와 선점을 고려하지 않고 스케줄 한다.
`ScheduleDaemonSetPods` 로 데몬셋 파드에 `.spec.nodeName` 용어 대신
`NodeAffinity` 용어를 추가해서 데몬셋 컨트롤러 대신 기본
스케줄러를 사용해서 데몬셋을 스케줄할 수 있다. 이후에 기본
스케줄러를 사용해서 대상 호스트에 파드를 바인딩한다. 만약 데몬셋 파드에
이미 노드 선호도가 존재한다면 교체한다(대상 호스트를 선택하기 전에 원래 노드의 어피니티가 고려된다). 데몬셋 컨트롤러는
이미 노드 선호도가 존재한다면 교체한다(대상 호스트를 선택하기 전에
원래 노드의 어피니티가 고려된다). 데몬셋 컨트롤러는
데몬셋 파드를 만들거나 수정할 때만 이런 작업을 수행하며,
데몬셋의 `spec.template` 은 변경되지 않는다.
@@ -152,10 +167,12 @@ nodeAffinity:
- **푸시(Push)**: 데몬셋의 파드는 통계 데이터베이스와 같은 다른 서비스로 업데이트를 보내도록
구성되어있다. 그들은 클라이언트들을 가지지 않는다.
- **노드IP와 알려진 포트**: 데몬셋의 파드는 `호스트 포트`를 사용할 수 있으며, 노드IP를 통해 파드에 접근할 수 있다. 클라이언트는 노드IP를 어떻게든지 알고 있으며, 관례에 따라 포트를 알고 있다.
- **노드IP와 알려진 포트**: 데몬셋의 파드는 `호스트 포트`를 사용할 수 있으며,
노드IP를 통해 파드에 접근할 수 있다.
클라이언트는 노드IP를 어떻게든지 알고 있으며, 관례에 따라 포트를 알고 있다.
- **DNS**: 동일한 파드 셀렉터로 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)를 만들고,
그 다음에 `엔드포인트` 리소스를 사용해서 데몬셋을 찾거나 DNS에서 여러 A레코드를
검색한다.
그 다음에 `엔드포인트` 리소스를 사용해서 데몬셋을 찾거나
DNS에서 여러 A레코드를 검색한다.
- **서비스**: 동일한 파드 셀렉터로 서비스를 생성하고, 서비스를 사용해서
임의의 노드의 데몬에 도달한다(특정 노드에 도달할 방법이 없다).
content/ko/docs/concepts/workloads/controllers/job.md
+1 -6
View File
@@ -304,7 +304,7 @@ spec:
### 완료된 잡을 위한 TTL 메커니즘
{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
{{< feature-state for_k8s_version="v1.21" state="beta" >}}
완료된 잡 (`Complete` 또는 `Failed`)을 자동으로 정리하는 또 다른 방법은
잡의 `.spec.ttlSecondsAfterFinished` 필드를 지정해서 완료된 리소스에 대해
@@ -342,11 +342,6 @@ spec:
삭제되도록 할 수 있다. 만약 필드를 설정하지 않으면, 이 잡이 완료된
후에 TTL 컨트롤러에 의해 정리되지 않는다.
이 TTL 메커니즘은 기능 게이트 `TTLAfterFinished`와 함께 알파 단계이다. 더
자세한 정보는 완료된 리소스를 위한
[TTL 컨트롤러](/ko/docs/concepts/workloads/controllers/ttlafterfinished/)
문서를 본다.
## 잡 패턴
잡 오브젝트를 사용해서 신뢰할 수 있는 파드의 병렬 실행을 지원할 수 있다. 잡 오브젝트는 과학
content/ko/docs/concepts/workloads/pods/disruptions.md
+3 -3
View File
@@ -31,7 +31,7 @@ weight: 60
- 클라우드 공급자 또는 하이퍼바이저의 오류로 인한 VM 장애
- 커널 패닉
- 클러스터 네트워크 파티션의 발생으로 클러스터에서 노드가 사라짐
- 노드의 [리소스 부족](/docs/tasks/administer-cluster/out-of-resource/)으로 파드가 축출됨
- 노드의 [리소스 부족](/docs/concepts/scheduling-eviction/node-pressure-eviction/)으로 파드가 축출됨
리소스 부족을 제외한 나머지 조건은 대부분의 사용자가 익숙할 것이다.
왜냐하면
@@ -76,7 +76,7 @@ weight: 60
- 복제된 애플리케이션의 구동 시 훨씬 더 높은 가용성을 위해 랙 전체
([안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#파드간-어피니티와-안티-어피니티) 이용)
또는 영역 간
([다중 영역 클러스터](/docs/setup/multiple-zones)를 이용한다면)에
([다중 영역 클러스터](/ko/docs/setup/best-practices/multiple-zones/)를 이용한다면)에
애플리케이션을 분산해야 한다.
자발적 중단의 빈도는 다양하다. 기본적인 쿠버네티스 클러스터에서는 자동화된 자발적 중단은 발생하지 않는다(사용자가 지시한 자발적 중단만 발생한다).
@@ -86,7 +86,7 @@ weight: 60
단편화를 제거하고 노드의 효율을 높이는 과정에서 자발적 중단을 야기할 수 있다.
클러스터 관리자 또는 호스팅 공급자는
예측 가능한 자발적 중단 수준에 대해 문서화해야 한다.
파드 스펙 안에 [프라이어리티클래스 사용하기](/ko/docs/concepts/configuration/pod-priority-preemption/)와 같은 특정 환경설정 옵션
파드 스펙 안에 [프라이어리티클래스 사용하기](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)와 같은 특정 환경설정 옵션
또한 자발적(+ 비자발적) 중단을 유발할 수 있다.
content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
+1 -1
View File
@@ -15,7 +15,7 @@ obsolete -->
{{< note >}}
v1.18 이전 버전의 쿠버네티스에서는 파드 토폴로지 분배 제약조건을 사용하려면
[API 서버](/ko/docs/concepts/overview/components/#kube-apiserver)와
[스케줄러](/docs/reference/generated/kube-scheduler/)에서
[스케줄러](/docs/reference/command-line-tools-reference/kube-scheduler/)에서
`EvenPodsSpread`[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
활성화해야 한다
{{< /note >}}