Merge pull request kubernetes#28470 from kubernetes/dev-1.21-ko.4

[ko] 4th Korean localization work for v1.21

content/ko/docs/concepts/extend-kubernetes/_index.md

@@ -21,7 +21,7 @@ no_list: true
 조정하는 방법을 이해하려는 {{< glossary_tooltip text="클러스터 운영자" term_id="cluster-operator" >}}를 대상으로 한다.
 잠재적인 {{< glossary_tooltip text="플랫폼 개발자" term_id="platform-developer" >}} 또는 쿠버네티스 프로젝트 {{< glossary_tooltip text="컨트리뷰터" term_id="contributor" >}}인 개발자에게도
 어떤 익스텐션(extension) 포인트와 패턴이 있는지,
-그리고 그것들의 트레이드오프와 제약에 대한 소개 자료로 유용할 것이다.
+그리고 그것의 트레이드오프와 제약을 이해하는 데 도움이 될 것이다.
 
 <!-- body -->
 
@@ -143,7 +143,7 @@ API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치
 
 ### 인가
 
-[인가](/docs/reference/access-authn-authz/webhook/)은 특정 사용자가 API 리소스에서 읽고, 쓰고, 다른 작업을 수행할 수 있는지를 결정한다. 전체 리소스 레벨에서 작동하며 임의의 오브젝트 필드를 기준으로 구별하지 않는다. 빌트인 인증 옵션이 사용자의 요구를 충족시키지 못하면 [인가 웹훅](/docs/reference/access-authn-authz/webhook/)을 통해 사용자가 제공한 코드를 호출하여 인증 결정을 내릴 수 있다.
+[인가](/docs/reference/access-authn-authz/webhook/)는 특정 사용자가 API 리소스에서 읽고, 쓰고, 다른 작업을 수행할 수 있는지를 결정한다. 전체 리소스 레벨에서 작동하며 임의의 오브젝트 필드를 기준으로 구별하지 않는다. 빌트인 인증 옵션이 사용자의 요구를 충족시키지 못하면 [인가 웹훅](/docs/reference/access-authn-authz/webhook/)을 통해 사용자가 제공한 코드를 호출하여 인증 결정을 내릴 수 있다.
 
 
 ### 동적 어드미션 컨트롤

content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md

@@ -192,6 +192,7 @@ kubelet은 gRPC 서비스를 제공하여 사용 중인 장치를 검색하고,
 // PodResourcesLister는 kubelet에서 제공하는 서비스로, 노드의 포드 및 컨테이너가
 // 사용한 노드 리소스에 대한 정보를 제공한다.
 service PodResourcesLister {
+    rpc List(ListPodResourcesRequest) returns (ListPodResourcesResponse) {}
     rpc GetAllocatableResources(AllocatableResourcesRequest) returns (AllocatableResourcesResponse) {}
 }
 ```
@@ -252,7 +253,7 @@ message AllocatableResourcesResponse {
 
 `ContainerDevices` 는 장치가 어떤 NUMA 셀과 연관되는지를 선언하는 토폴로지 정보를 노출한다.
 NUMA 셀은 불분명한(opaque) 정수 ID를 사용하여 식별되며, 이 값은
-[kubelet에 등록할 때](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-integration-with-the-topology-manager) 장치 플러그인이 보고하는 것과 일치한다.
+[kubelet에 등록할 때](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#토폴로지-관리자로-장치-플러그인-통합) 장치 플러그인이 보고하는 것과 일치한다.
 
 
 gRPC 서비스는 `/var/lib/kubelet/pod-resources/kubelet.sock` 의 유닉스 소켓을 통해 제공된다.
@@ -264,8 +265,9 @@ gRPC 서비스는 `/var/lib/kubelet/pod-resources/kubelet.sock` 의 유닉스 
 {{< glossary_tooltip text="볼륨" term_id="volume" >}}으로 마운트해야 한다.
 
 `PodResourcesLister service` 를 지원하려면 `KubeletPodResources` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
+이것은 쿠버네티스 1.15부터 기본으로 활성화되어 있으며, 쿠버네티스 1.20부터는 v1 상태이다.
 
-## 토폴로지 관리자와 장치 플러그인 통합
+## 토폴로지 관리자로 장치 플러그인 통합
 
 {{< feature-state for_k8s_version="v1.18" state="beta" >}}
 

content/ko/docs/concepts/policy/node-resource-managers.md

@@ -0,0 +1,22 @@
+---
+
+
+
+title: 노드 리소스 매니저 
+content_type: 개념
+weight: 50
+---
+
+<!-- overview -->
+
+쿠버네티스는 지연 시간에 민감하고 처리량이 많은 워크로드를 지원하기 위해 리소스 매니저 세트를 제공한다. 매니저는 CPU, 장치 및 메모리 (hugepages) 리소스와 같은 특정한 요구 사항으로 구성된 파드를 위해 노드의 리소스 할당을 조정하고 최적화하는 것을 목표로 한다. 
+
+<!-- body -->
+
+주 매니저인 토폴로지 매니저는 [정책](/docs/tasks/administer-cluster/topology-manager/)을 통해 전체 리소스 관리 프로세스를 조정하는 Kubelet 컴포넌트이다.
+
+개별 매니저의 구성은 다음의 문서에 자세히 기술되어 있다.
+
+- [CPU 관리 정책](/docs/tasks/administer-cluster/cpu-management-policies/)
+- [장치 매니저](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#토폴로지-관리자와-장치-플러그인-통합)
+- [메모리 관리 정책](/docs/tasks/administer-cluster/memory-manager/)

content/ko/docs/concepts/scheduling-eviction/api-eviction.md

@@ -0,0 +1,18 @@
+---
+title: API를 이용한 축출(Eviction)
+content_type: concept
+weight: 70
+---
+
+{{< glossary_definition term_id="api-eviction" length="short" >}} </br>
+
+`kubectl drain` 명령과 같은 kube-apiserver의 클라이언트를 사용하여,
+축출 API를 직접 호출해 축출 요청을 할 수 있다.
+그러면 API 서버가 파드를 종료하는 `Eviction` 오브젝트가 생성된다.
+
+API를 이용한 축출은 구성된 [`PodDisruptionBudgets`](/docs/tasks/run-application/configure-pdb/) 및 [`terminationGracePeriodSeconds`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)를 준수한다.
+
+## {{% heading "whatsnext" %}}
+
+- [노드-압박 축출](/docs/concepts/scheduling-eviction/node-pressure-eviction/)에 대해 더 배우기
+- [파드 우선순위와 선점](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)에 대해 더 배우기

content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md

@@ -402,7 +402,7 @@ web-server-1287567482-s330j    1/1       Running   0          7m        10.192.3
 `nodeName` 은 PodSpec의 필드이다. 만약 비어있지 않으면, 스케줄러는
 파드를 무시하고 명명된 노드에서 실행 중인 kubelet이
 파드를 실행하려고 한다. 따라서 만약 PodSpec에 `nodeName` 가
-제공된 경우, 노드 선텍을 위해 위의 방법보다 우선한다.
+제공된 경우, 노드 선택을 위해 위의 방법보다 우선한다.
 
 `nodeName` 을 사용해서 노드를 선택할 때의 몇 가지 제한은 다음과 같다.
 

content/ko/docs/concepts/services-networking/network-policies.md

@@ -212,9 +212,10 @@ __ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP C
 
 ## SCTP 지원
 
-{{< feature-state for_k8s_version="v1.19" state="beta" >}}
+{{< feature-state for_k8s_version="v1.20" state="stable" >}}
 
-베타 기능으로, 기본 활성화되어 있다. 클러스터 수준에서 SCTP를 비활성화하려면, 사용자(또는 클러스터 관리자)가 API 서버에 `--feature-gates=SCTPSupport=false,…` 를 사용해서 `SCTPSupport` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 비활성화해야 한다.
+안정된 기능으로, 기본 활성화되어 있다. 클러스터 수준에서 SCTP를 비활성화하려면, 사용자(또는 클러스터 관리자)가 API 서버에 `--feature-gates=SCTPSupport=false,…` 를 사용해서 `SCTPSupport` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 비활성화해야 한다.
+해당 기능 게이트가 활성화되어 있는 경우, 네트워크폴리시의 `protocol` 필드를 `SCTP`로 지정할 수 있다.
 
 {{< note >}}
 SCTP 프로토콜 네트워크폴리시를 지원하는 {{< glossary_tooltip text="CNI" term_id="cni" >}} 플러그인을 사용하고 있어야 한다.

content/ko/docs/concepts/services-networking/service-traffic-policy.md

@@ -0,0 +1,73 @@
+---
+
+
+title: 서비스 내부 트래픽 정책
+content_type: concept
+weight: 45
+---
+
+
+<!-- overview -->
+
+{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+
+_서비스 내부 트래픽 정책_ 을 사용하면 내부 트래픽 제한이 트래픽이 시작된 
+노드 내의 엔드포인트로만 내부 트래픽을 라우팅하도록 한다. 
+여기서 "내부" 트래픽은 현재 클러스터의 파드로부터 시작된 트래픽을 지칭한다.
+이를 통해 비용을 절감하고 성능을 개선할 수 있다.
+
+<!-- body -->
+
+## 서비스 내부 트래픽 정책 사용
+
+
+[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)에서 
+`ServiceInternalTrafficPolicy`를 활성화한 후에 
+{{< glossary_tooltip text="서비스" term_id="service" >}}의 
+`.spec.internalTrafficPolicy`를 `Local`로 설정하여 내부 전용 트래픽 정책을 활성화 할 수 있다.
+이것은 kube-proxy가 클러스터 내부 트래픽을 위해 노드 내부 엔드포인트로만 사용하도록 한다.
+
+{{< note >}}
+지정된 서비스에 대한 엔드포인트가 없는 노드의 파드인 경우에 
+서비스는 다른 노드에 엔드포인트가 있더라도 엔드포인트가 없는 것처럼 작동한다. 
+(이 노드의 파드에 대해서)
+{{< /note >}}
+
+다음 예제는 서비스의 `.spec.internalTrafficPolicy`를 `Local`로 
+설정하는 것을 보여 준다:
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: my-service
+spec:
+  selector:
+    app: MyApp
+  ports:
+    - protocol: TCP
+      port: 80
+      targetPort: 9376
+  internalTrafficPolicy: Local
+```
+
+## 작동 방식
+
+kube-proxy는 `spec.internalTrafficPolicy` 의 설정에 따라서 라우팅되는 
+엔드포인트를 필터링한다. 
+이것을 `Local`로 설정하면, 노드 내부 엔드포인트만 고려한다. 
+이 설정이 `Cluster`이거나 누락되었다면 모든 엔드포인트를 고려한다.
+[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)의 
+`ServiceInternalTrafficPolicy`를 활성화한다면, `spec.internalTrafficPolicy`는 기본값 "Cluster"로 설정된다.
+
+## 제약조건
+
+* 같은 서비스에서 `externalTrafficPolicy` 가 `Local`로 설정된 경우 
+서비스 내부 트래픽 정책이 사용되지 않는다. 
+클러스터에서 동일하지 않은 다른 서비스에서 이 두 가지 기능은 동시에 사용할 수 있다.
+
+## {{% heading "whatsnext" %}}
+
+* [토폴로지 인식 힌트 활성화](/docs/tasks/administer-cluster/enabling-topology-aware-hints)에 대해서 읽기
+* [서비스 외부 트래픽 정책](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)에 대해서 읽기
+* [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/) 읽기

content/ko/docs/concepts/workloads/pods/disruptions.md

@@ -89,6 +89,7 @@ weight: 60
 파드 스펙 안에 [프라이어리티클래스 사용하기](/ko/docs/concepts/configuration/pod-priority-preemption/)와 같은 특정 환경설정 옵션
 또한 자발적(+ 비자발적) 중단을 유발할 수 있다.
 
+
 ## 파드 disruption budgets
 
 {{< feature-state for_k8s_version="v1.21" state="stable" >}}

content/ko/docs/reference/command-line-tools-reference/kube-proxy.md

@@ -424,7 +424,7 @@ kube-proxy [flags]
 <td colspan="2">--show-hidden-metrics-for-version string</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>숨겨진 메트릭을 표시할 이전 버전. 이전 마이너 버전만 인식하며, 다른 값은 허용하지 않는다. '1.16' 형태로 사용한다. 이 옵션의 존재 목적은, 다음 릴리스에서 추가적인 메트릭을 숨기는지에 대한 여부를 사용자가 알게 하여, 그 이후 릴리스에서 메트릭이 영구적으로 삭제됐을 때 사용자가 놀라지 않도록 하기 위함이다.</p></td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>숨겨진 메트릭을 표시하려는 이전 버전. 이전 마이너 버전만 인식하며, 다른 값은 허용하지 않는다. 포멧은 &lt;메이저&gt;.&lt;마이너&gt; 와 같으며, 예를 들면 '1.16' 과 같다. 이 포멧의 목적은, 다음 릴리스가 숨길 추가적인 메트릭을 사용자에게 공지하여, 그 이후 릴리스에서 메트릭이 영구적으로 삭제됐을 때 사용자가 놀라지 않도록 하기 위함이다.</p></td>
 </tr>
 
 <tr>

content/ko/docs/reference/glossary/api-eviction.md

@@ -0,0 +1,23 @@
+---
+title: API를 이용한 축출(Eviction)
+id: api-eviction
+date: 2021-04-27
+full_link: /docs/concepts/scheduling-eviction/pod-eviction/#api-eviction
+short_description: >
+  API를 이용한 축출은 축출 API를 사용하여 파드의 정상 종료를 트리거하는
+  축출 오브젝트를 만드는 프로세스이다
+aka:
+tags:
+  - operation
+---
+
+API를 이용한 축출은 [축출 API](/docs/reference/generated/kubernetes-api/{{<param "version">}}/#create-eviction-pod-v1-core)를 사용하여
+생성된 `Eviction` 오브젝트로 파드를 정상 종료한다.
+
+<!--more-->
+
+`kubectl drain` 명령과 같은 kube-apiserver의 클라이언트를 사용하여
+축출 API를 직접 호출해 축출 요청을 할 수 있다.
+`Eviction` 오브젝트가 생성되면, API 서버가 파드를 종료한다.
+
+API를 이용한 축출은 [노드-압박 축출](/docs/concepts/scheduling-eviction/eviction/#kubelet-eviction)과 동일하지 않다.

content/ko/docs/reference/scheduling/config.md

@@ -18,9 +18,9 @@ weight: 20
 각 단계는 익스텐션 포인트(extension point)를 통해 노출된다. 플러그인은 이러한
 익스텐션 포인트 중 하나 이상을 구현하여 스케줄링 동작을 제공한다.
 
-[KubeSchedulerConfiguration (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) 
-구조에 맞게 파일을 작성하고, 
-`kube-scheduler --config <filename>`을 실행하여 
+[KubeSchedulerConfiguration (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/)
+구조에 맞게 파일을 작성하고,
+`kube-scheduler --config <filename>`을 실행하여
 스케줄링 프로파일을 지정할 수 있다.
 
 최소 구성은 다음과 같다.
@@ -149,8 +149,8 @@ profiles:
   또는 바인딩할 수 있는지 확인한다.
   익스텐션 포인트: `PreFilter`, `Filter`, `Reserve`, `PreBind`, `Score`.
   {{< note >}}
-  `Score` 익스텐션 포인트는 `VolumeCapacityPriority` 기능이 
-  활성화되어 있어야 활성화되며, 
+  `Score` 익스텐션 포인트는 `VolumeCapacityPriority` 기능이
+  활성화되어 있어야 활성화되며,
   요청된 볼륨 사이즈를 만족하는 가장 작은 PV들을 우선순위 매긴다.
   {{< /note >}}
 - `VolumeRestrictions`: 노드에 마운트된 볼륨이 볼륨 제공자에 특정한
@@ -250,6 +250,6 @@ profiles:
 
 ## {{% heading "whatsnext" %}}
 
-* [kube-scheduler 레퍼런스](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/) 읽어보기
+* [kube-scheduler 레퍼런스](/docs/reference/command-line-tools-reference/kube-scheduler/) 읽어보기
 * [스케줄링](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 알아보기
 * [kube-scheduler configuration (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) 레퍼런스 읽어보기

content/ko/docs/setup/best-practices/certificates.md

@@ -1,23 +1,23 @@
 ---
-title: PKI 인증서 및 요구 조건
+title: PKI 인증서 및 요구 사항
 content_type: concept
 weight: 40
 ---
 
 <!-- overview -->
 
-쿠버네티스는 TLS 위에 인증을 위해 PKI 인증서가 필요하다.
-만약 [kubeadm](/ko/docs/reference/setup-tools/kubeadm/)으로 쿠버네티스를 설치했다면, 클러스터에 필요한 인증서는 자동으로 생성된다.
+쿠버네티스는 TLS를 통한 인증을 위해서 PKI 인증서가 필요하다.
+만약 [kubeadm](/ko/docs/reference/setup-tools/kubeadm/)으로 쿠버네티스를 설치한다면, 클러스터에 필요한 인증서는 자동으로 생성된다.
 또한 더 안전하게 자신이 소유한 인증서를 생성할 수 있다. 이를 테면, 개인키를 API 서버에 저장하지 않으므로 더 안전하게 보관할 수 있다.
-이 페이지는 클러스터에 필요한 인증서를 설명한다.
+이 페이지는 클러스터가 필요로 하는 인증서에 대해서 설명한다.
 
 
 
 <!-- body -->
 
-## 클러스터에서 인증서는 어떻게 이용되나?
+## 클러스터에서 인증서가 이용되는 방식
 
-쿠버네티스는 다음 작업에서 PKI가 필요하다.
+쿠버네티스는 다음 작업에서 PKI를 필요로 한다.
 
 * kubelet에서 API 서버 인증서를 인증시 사용하는 클라이언트 인증서
 * API 서버 엔드포인트를 위한 서버 인증서

content/ko/docs/setup/production-environment/container-runtimes.md

@@ -97,7 +97,10 @@ containerd를 설치한다.
 {{< tabs name="tab-cri-containerd-installation" >}}
 {{% tab name="Linux" %}}
 
-1. 공식 도커 리포지터리에서 `containerd.io` 패키지를 설치한다. 각 리눅스 배포한에 대한 도커 리포지터리를 설정하고 `containerd.io` 패키지를 설치하는 방법은 [도커 엔진 설치](https://docs.docker.com/engine/install/#server)에서 찾을 수 있다.
+1. 공식 도커 리포지터리에서 `containerd.io` 패키지를 설치한다.
+각 리눅스 배포판에 대한 도커 리포지터리를 설정하고
+`containerd.io` 패키지를 설치하는 방법은
+[도커 엔진 설치](https://docs.docker.com/engine/install/#server)에서 찾을 수 있다.
 
 2. containerd 설정
 
@@ -115,7 +118,8 @@ containerd를 설치한다.
 {{% /tab %}}
 {{% tab name="Windows (PowerShell)" %}}
 
-PowerShell 세션을 시작하고 `$Version`을 원하는 버전(예: `$Version:1.4.3`)으로 설정한 후 다음 명령을 실행한다.
+PowerShell 세션을 시작하고 `$Version`을 원하는 버전으로
+설정(예: `$Version:1.4.3`)한 후 다음 명령을 실행한다.
 
 1. containerd 다운로드
 
@@ -242,7 +246,8 @@ sudo apt-get install cri-o cri-o-runc
 
 {{% tab name="Ubuntu" %}}
 
-다음의 운영 체제에서 CRI-O를 설치하려면, 환경 변수 `OS` 를 아래의 표에서 적절한 필드로 설정한다.
+다음의 운영 체제에서 CRI-O를 설치하려면, 환경 변수 `OS` 를
+아래의 표에서 적절한 필드로 설정한다.
 
 | 운영 체제          | `$OS`             |
 | ---------------- | ----------------- |
@@ -277,7 +282,8 @@ apt-get install cri-o cri-o-runc
 
 {{% tab name="CentOS" %}}
 
-다음의 운영 체제에서 CRI-O를 설치하려면, 환경 변수 `OS` 를 아래의 표에서 적절한 필드로 설정한다.
+다음의 운영 체제에서 CRI-O를 설치하려면, 환경 변수 `OS` 를
+아래의 표에서 적절한 필드로 설정한다.
 
 | 운영 체제          | `$OS`             |
 | ---------------- | ----------------- |
@@ -357,7 +363,10 @@ CRI-O의 cgroup 드라이버 구성을 동기화 상태로
 
 ### 도커
 
-1. 각 노드에서 [도커 엔진 설치](https://docs.docker.com/engine/install/#server)에 따라 리눅스 배포판용 도커를 설치한다. 이 [의존성 파일](https://git.k8s.io/kubernetes/build/dependencies.yaml)에서 검증된 최신 버전의 도커를 찾을 수 있다.
+1. 각 노드에서 [도커 엔진 설치](https://docs.docker.com/engine/install/#server)에 따라
+리눅스 배포판용 도커를 설치한다.
+이 [의존성 파일](https://git.k8s.io/kubernetes/build/dependencies.yaml)에서
+검증된 최신 버전의 도커를 찾을 수 있다.
 
 2. 특히 컨테이너의 cgroup 관리에 systemd를 사용하도록 도커 데몬을 구성한다.
 
@@ -376,7 +385,8 @@ CRI-O의 cgroup 드라이버 구성을 동기화 상태로
    ```
 
    {{< note >}}
-   `overlay2`는 리눅스 커널 4.0 이상 또는 3.10.0-514 버전 이상을 사용하는 RHEL 또는 CentOS를 구동하는 시스템에서 선호하는 스토리지 드라이버이다.
+   `overlay2`는 리눅스 커널 4.0 이상 또는 3.10.0-514 버전 이상을 사용하는 RHEL
+   또는 CentOS를 구동하는 시스템에서 선호하는 스토리지 드라이버이다.
    {{< /note >}}
 
 3. 도커 재시작과 부팅시 실행되게 설정

content/ko/docs/setup/production-environment/turnkey-solutions.md

@@ -0,0 +1,14 @@
+---
+title: 턴키 클라우드 솔루션
+content_type: concept
+weight: 30
+---
+<!-- overview -->
+
+이 페이지는 인증된 쿠버네티스 솔루션 제공자 목록을 제공한다. 각 제공자
+페이지를 통해서, 프로덕션에 준비된 클러스터를 설치 및 설정하는 방법을
+학습할 수 있다.
+
+<!-- body -->
+
+{{< cncf-landscape helpers=true category="certified-kubernetes-hosted" >}}