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

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

Author: k8s-ci-robot

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)과 동일하지 않다.