diff --git a/content/ko/docs/concepts/architecture/controller.md b/content/ko/docs/concepts/architecture/controller.md
index e516dd9cc5..e4b18f0c5c 100644
--- a/content/ko/docs/concepts/architecture/controller.md
+++ b/content/ko/docs/concepts/architecture/controller.md
@@ -159,11 +159,12 @@ 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/#익스텐션-패턴)을
+ 본다.
+
diff --git a/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md b/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md
index 95ea899cbb..c64dd127b3 100644
--- a/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md
+++ b/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md
@@ -1,5 +1,4 @@
---
-
title: kubelet 가비지(Garbage) 수집 설정하기
content_type: concept
weight: 70
@@ -7,12 +6,13 @@ weight: 70
-가비지 수집은 사용되지 않는 [이미지](/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을 중단시킬 수도 있으므로 권장하지 않는다.
@@ -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/)를
+본다.
diff --git a/content/ko/docs/concepts/containers/runtime-class.md b/content/ko/docs/concepts/containers/runtime-class.md
index 2770b1e4b2..0e48c6f22e 100644
--- a/content/ko/docs/concepts/containers/runtime-class.md
+++ b/content/ko/docs/concepts/containers/runtime-class.md
@@ -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)를 본다.
## 스케줄
@@ -176,4 +176,4 @@ 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)
+- [파드 오버헤드 기능 설계](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead)
diff --git a/content/ko/docs/concepts/policy/pod-security-policy.md b/content/ko/docs/concepts/policy/pod-security-policy.md
index 8afee5760b..eae69022e6 100644
--- a/content/ko/docs/concepts/policy/pod-security-policy.md
+++ b/content/ko/docs/concepts/policy/pod-security-policy.md
@@ -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 >}}호스트 파일시스템에 제한없는 접근을 부여하며, 컨테이너가 특권을 에스컬레이션
diff --git a/content/ko/docs/concepts/policy/resource-quotas.md b/content/ko/docs/concepts/policy/resource-quotas.md
index 8e1d918ef4..3e1ce72ada 100644
--- a/content/ko/docs/concepts/policy/resource-quotas.md
+++ b/content/ko/docs/concepts/policy/resource-quotas.md
@@ -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
```
diff --git a/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md b/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md
index 34ff6f3108..1ac3b81262 100644
--- a/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md
+++ b/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md
@@ -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` 파일을 참조하면 구성이 스케줄러에
+전달된다.
+
**이 기능은 기본적으로 비활성화되어 있다.**
### 우선 순위 기능 튜닝하기
diff --git a/content/ko/docs/concepts/services-networking/dns-pod-service.md b/content/ko/docs/concepts/services-networking/dns-pod-service.md
index e3254d3ba8..8a35c2c6a3 100644
--- a/content/ko/docs/concepts/services-networking/dns-pod-service.md
+++ b/content/ko/docs/concepts/services-networking/dns-pod-service.md
@@ -7,6 +7,7 @@ content_type: concept
weight: 20
---
+
쿠버네티스는 파드와 서비스를 위한 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" %}}
diff --git a/content/ko/docs/concepts/services-networking/endpoint-slices.md b/content/ko/docs/concepts/services-networking/endpoint-slices.md
index 4e12cf9ff2..41b8baa05a 100644
--- a/content/ko/docs/concepts/services-networking/endpoint-slices.md
+++ b/content/ko/docs/concepts/services-networking/endpoint-slices.md
@@ -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/)를 읽어보기
diff --git a/content/ko/docs/concepts/services-networking/service.md b/content/ko/docs/concepts/services-networking/service.md
index 7bbb4f6f63..5c4b9edeee 100644
--- a/content/ko/docs/concepts/services-networking/service.md
+++ b/content/ko/docs/concepts/services-networking/service.md
@@ -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와 서비스 프록시