Merge pull request #27901 from jihoon-seo/210507_Update_outdated_files_in_dev-1.20-ko.8_p3

[ko] Update outdated files in dev-1.20-ko.8 (p3)
2021-05-11 03:53:36 -07:00
parent 318ae0b7fe d1751c8101
commit 628b9d2115
28 changed files with 98 additions and 86 deletions
@@ -8,14 +8,14 @@ aliases:

 <!-- overview -->

-이 문서는 컨트롤 플레인(실제로는 API 서버)과 쿠버네티스 클러스터 사이에 대한 통신 경로의 목록을 작성한다. 이는 사용자가 신뢰할 수 없는 네트워크(또는 클라우드 공급자의 완전한 퍼블릭 IP)에서 클러스터를 실행할 수 있도록 네트워크 구성을 강화하기 위한 맞춤 설치를 할 수 있도록 한다.
+이 문서는 컨트롤 플레인(API 서버)과 쿠버네티스 클러스터 사이에 대한 통신 경로의 목록을 작성한다. 이는 사용자가 신뢰할 수 없는 네트워크(또는 클라우드 공급자의 완전한 퍼블릭 IP)에서 클러스터를 실행할 수 있도록 네트워크 구성을 강화하기 위한 맞춤 설치를 할 수 있도록 한다.



 <!-- body -->

 ## 노드에서 컨트롤 플레인으로의 통신
-쿠버네티스에는 "허브 앤 스포크(hub-and-spoke)" API 패턴을 가지고 있다. 노드(또는 노드에서 실행되는 파드들)의 모든 API 사용은 API 서버에서 종료된다(다른 컨트롤 플레인 컴포넌트 중 어느 것도 원격 서비스를 노출하도록 설계되지 않았다). API 서버는 하나 이상의 클라이언트 [인증](/docs/reference/access-authn-authz/authentication/) 형식이 활성화된 보안 HTTPS 포트(일반적으로 443)에서 원격 연결을 수신하도록 구성된다.
+쿠버네티스에는 "허브 앤 스포크(hub-and-spoke)" API 패턴을 가지고 있다. 노드(또는 노드에서 실행되는 파드들)의 모든 API 사용은 API 서버에서 종료된다. 다른 컨트롤 플레인 컴포넌트 중 어느 것도 원격 서비스를 노출하도록 설계되지 않았다. API 서버는 하나 이상의 클라이언트 [인증](/docs/reference/access-authn-authz/authentication/) 형식이 활성화된 보안 HTTPS 포트(일반적으로 443)에서 원격 연결을 수신하도록 구성된다.
 특히 [익명의 요청](/docs/reference/access-authn-authz/authentication/#anonymous-requests) 또는 [서비스 어카운트 토큰](/docs/reference/access-authn-authz/authentication/#service-account-tokens)이 허용되는 경우, 하나 이상의 [권한 부여](/ko/docs/reference/access-authn-authz/authorization/) 형식을 사용해야 한다.

 노드는 유효한 클라이언트 자격 증명과 함께 API 서버에 안전하게 연결할 수 있도록 클러스터에 대한 공개 루트 인증서로 프로비전해야 한다. 예를 들어, 기본 GKE 배포에서, kubelet에 제공되는 클라이언트 자격 증명은 클라이언트 인증서 형식이다. kubelet 클라이언트 인증서의 자동 프로비저닝은 [kubelet TLS 부트스트랩](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)을 참고한다.
@@ -50,20 +50,20 @@ API 서버에서 kubelet으로의 연결은 다음의 용도로 사용된다.

 ### API 서버에서 노드, 파드 및 서비스로의 통신

-API 서버에서 노드, 파드 또는 서비스로의 연결은 기본적으로 일반 HTTP 연결로 연결되므로 인증되거나 암호화되지 않는다. API URL에서 노드, 파드 또는 서비스 이름을 접두어 `https:` 로 사용하여 보안 HTTPS 연결을 통해 실행될 수 있지만, HTTPS 엔드포인트가 제공한 인증서의 유효성을 검증하지 않거나 클라이언트 자격 증명을 제공하지 않으므로 연결이 암호화되는 동안 무결성을 보장하지 않는다. 이러한 연결은 신뢰할 수 없는 네트워크 및/또는 공용 네트워크에서 실행하기에 **현재는 안전하지 않다** .
+API 서버에서 노드, 파드 또는 서비스로의 연결은 기본적으로 일반 HTTP 연결로 연결되므로 인증되거나 암호화되지 않는다. API URL에서 노드, 파드 또는 서비스 이름을 접두어 `https:` 로 사용하여 보안 HTTPS 연결을 통해 실행될 수 있지만, HTTPS 엔드포인트가 제공한 인증서의 유효성을 검증하지 않거나 클라이언트 자격 증명을 제공하지 않는다. 그래서 연결이 암호화되는 동안 무결성을 보장하지 않는다. 이러한 연결은 신뢰할 수 없는 네트워크 및/또는 공용 네트워크에서 실행하기에 **현재는 안전하지 않다** .

 ### SSH 터널

 쿠버네티스는 SSH 터널을 지원하여 컨트롤 플레인에서 노드로의 통신 경로를 보호한다. 이 구성에서, API 서버는 클러스터의 각 노드에 SSH 터널을 시작하고(포트 22에서 수신 대기하는 ssh 서버에 연결) 터널을 통해 kubelet, 노드, 파드 또는 서비스로 향하는 모든 트래픽을 전달한다.
 이 터널은 트래픽이 노드가 실행 중인 네트워크 외부에 노출되지 않도록 한다.

-SSH 터널은 현재 더 이상 사용되지 않으므로 수행 중인 작업이 어떤 것인지 모른다면 사용하면 안된다. Konnectivity 서비스는 이 통신 채널을 대체한다.
+SSH 터널은 현재 더 이상 사용되지 않으므로, 수행 중인 작업이 어떤 것인지 모른다면 사용하면 안된다. Konnectivity 서비스는 이 통신 채널을 대체한다.

 ### Konnectivity 서비스

 {{< feature-state for_k8s_version="v1.18" state="beta" >}}

-SSH 터널을 대체하는 Konnectivity 서비스는 컨트롤 플레인에서 클러스터 통신에 TCP 레벨 프록시를 제공한다. Konnectivity 서비스는 컨트롤 플레인 네트워크와 노드 네트워크에서 각각 실행되는 Konnectivity 서버와 Konnectivity 에이전트의 두 부분으로 구성된다. Konnectivity 에이전트는 Konnectivity 서버에 대한 연결을 시작하고 네트워크 연결을 유지한다.
+SSH 터널을 대체하는 Konnectivity 서비스는 컨트롤 플레인에서 클러스터 통신에 TCP 레벨 프록시를 제공한다. Konnectivity 서비스는 컨트롤 플레인 네트워크의 Konnectivity 서버와 노드 네트워크의 Konnectivity 에이전트, 두 부분으로 구성된다. Konnectivity 에이전트는 Konnectivity 서버에 대한 연결을 시작하고 네트워크 연결을 유지한다.
 Konnectivity 서비스를 활성화한 후, 모든 컨트롤 플레인에서 노드로의 트래픽은 이 연결을 통과한다.

 [Konnectivity 서비스 태스크](/docs/tasks/extend-kubernetes/setup-konnectivity/)에 따라 클러스터에서 Konnectivity 서비스를 설정한다.
@@ -63,6 +63,16 @@ kubelet이 노드의 `metadata.name` 필드와 일치하는 API 서버에 등록
 노드 오브젝트의 이름은 유효한
 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.

+### 노드 이름 고유성
+
+[이름](/ko/docs/concepts/overview/working-with-objects/names#names)은 노드를 식별한다. 두 노드는
+동시에 같은 이름을 가질 수 없다. 쿠버네티스는 또한 같은 이름의 리소스가
+동일한 오브젝트라고 가정한다. 노드의 경우, 동일한 이름을 사용하는 인스턴스가 동일한
+상태(예: 네트워크 설정, 루트 디스크 내용)를 갖는다고 암시적으로 가정한다. 인스턴스가
+이름을 변경하지 않고 수정된 경우 이로 인해 불일치가 발생할 수 있다. 노드를 대폭 교체하거나
+업데이트해야 하는 경우, 기존 노드 오브젝트를 먼저 API 서버에서 제거하고
+업데이트 후 다시 추가해야 한다.
+
 ### 노드에 대한 자체-등록

 kubelet 플래그 `--register-node`는 참(기본값)일 경우, kubelet 은 API 서버에
@@ -233,6 +243,7 @@ apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳
 - 노드가 계속 접근 불가할 경우 나중에 노드로부터 정상적인 종료를 이용해서 모든 파드를 축출 한다.
  ConditionUnknown을 알리기 시작하는 기본 타임아웃 값은 40초 이고,
  파드를 축출하기 시작하는 값은 5분이다.
+
 노드 컨트롤러는 매 `--node-monitor-period` 초 마다 각 노드의 상태를 체크한다.

 #### 하트비트
@@ -273,6 +284,7 @@ ConditionFalse 다.).
 - 클러스터가 작으면 (즉 `--large-cluster-size-threshold`
  노드 이하면 - 기본값 50) 축출은 중지되고, 그렇지 않으면 축출 비율은 초당
  `--secondary-node-eviction-rate`(기본값 0.01)로 감소된다.
+
 이 정책들이 가용성 영역 단위로 실행되어지는 이유는 나머지가 연결되어 있는 동안
 하나의 가용성 영역이 마스터로부터 분할되어 질 수도 있기 때문이다.
 만약 클러스터가 여러 클라우드 제공사업자의 가용성 영역에 걸쳐 있지 않으면,
@@ -16,6 +16,7 @@ content_type: concept
 ## 네트워킹과 네트워크 폴리시

 * [ACI](https://www.github.com/noironetworks/aci-containers)는 Cisco ACI로 통합 컨테이너 네트워킹 및 네트워크 보안을 제공한다.
+* [Antrea](https://antrea.io/)는 레이어 3/4에서 작동하여 쿠버네티스를 위한 네트워킹 및 보안 서비스를 제공하며, Open vSwitch를 네트워킹 데이터 플레인으로 활용한다.
 * [Calico](https://docs.projectcalico.org/latest/introduction/)는 네트워킹 및 네트워크 폴리시 제공자이다. Calico는 유연한 네트워킹 옵션을 지원하므로 BGP 유무에 관계없이 비-오버레이 및 오버레이 네트워크를 포함하여 가장 상황에 맞는 옵션을 선택할 수 있다. Calico는 동일한 엔진을 사용하여 서비스 메시 계층(service mesh layer)에서 호스트, 파드 및 (이스티오(istio)와 Envoy를 사용하는 경우) 애플리케이션에 대한 네트워크 폴리시를 적용한다.
 * [Canal](https://github.com/tigera/canal/tree/master/k8s-install)은 Flannel과 Calico를 통합하여 네트워킹 및 네트워크 폴리시를 제공한다.
 * [Cilium](https://github.com/cilium/cilium)은 L3 네트워크 및 네트워크 폴리시 플러그인으로 HTTP/API/L7 폴리시를 투명하게 시행할 수 있다. 라우팅 및 오버레이/캡슐화 모드를 모두 지원하며, 다른 CNI 플러그인 위에서 작동할 수 있다.
@@ -278,7 +278,7 @@ pod/my-nginx-2035384211-u3t6x labeled
 ```

 먼저 "app=nginx" 레이블이 있는 모든 파드를 필터링한 다음, "tier=fe" 레이블을 지정한다.
-방금 레이블을 지정한 파드를 보려면, 다음을 실행한다.
+레이블을 지정한 파드를 보려면, 다음을 실행한다.

 ```shell
 kubectl get pods -l app=nginx -L tier
@@ -30,7 +30,7 @@ weight: 90
    - API 서버 프로세스에서 실행한다.
    - 클라이언트로 프락시는 HTTPS(또는 API서버에서 HTTP로 구성된 경우는 HTTP)를 사용한다.
    - 사용 가능한 정보를 이용하여 프락시에 의해 선택한 HTTP나 HTTPS를 사용할 수 있는 대상이다.
-    - 노드, 파드, 서비스에 도달하는데 사용할 수 있다.
+    - 노드, 파드, 서비스에 도달하는 데에 사용할 수 있다.
    - 서비스에 도달할 때에는 로드 밸런싱을 수행한다.

 1.  [kube proxy](/ko/docs/concepts/services-networking/service/#ips-and-vips):
@@ -39,7 +39,7 @@ weight: 90
    - UDP, TCP, SCTP를 이용하여 프락시 한다.
    - HTTP는 이해하지 못한다.
    - 로드 밸런싱을 제공한다.
-    - 단지 서비스에 도달하는데 사용한다.
+    - 서비스에 도달하는 데에만 사용한다.

 1.  API 서버 앞단의 프락시/로드밸런서

@@ -61,7 +61,3 @@ weight: 90
 ## 요청을 리다이렉트하기

 프락시는 리다이렉트 기능을 대체했다. 리다이렉트는 더 이상 사용하지 않는다.
-
-
-
-
@@ -223,7 +223,7 @@ spec:
 현재 볼륨에서 사용된 컨피그맵이 업데이트되면, 프로젝션된 키도 마찬가지로 업데이트된다.
 kubelet은 모든 주기적인 동기화에서 마운트된 컨피그맵이 최신 상태인지 확인한다.
 그러나, kubelet은 로컬 캐시를 사용해서 컨피그맵의 현재 값을 가져온다.
-캐시 유형은 [KubeletConfiguration 구조체](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go)의
+캐시 유형은 [KubeletConfiguration 구조체](/docs/reference/config-api/kubelet-config.v1beta1/)의
 `ConfigMapAndSecretChangeDetectionStrategy` 필드를 사용해서 구성할 수 있다.
 컨피그맵은 watch(기본값), ttl 기반 또는 API 서버로 직접
 모든 요청을 리디렉션할 수 있다.
@@ -233,6 +233,7 @@ kubelet은 모든 주기적인 동기화에서 마운트된 컨피그맵이 최
 지연을 지켜보거나, 캐시의 ttl 또는 0에 상응함).

 환경 변수로 사용되는 컨피그맵은 자동으로 업데이트되지 않으며 파드를 다시 시작해야 한다.
+
 ## 변경할 수 없는(immutable) 컨피그맵 {#configmap-immutable}

 {{< feature-state for_k8s_version="v1.19" state="beta" >}}
@@ -21,9 +21,6 @@ feature:
 컨테이너가 사용할 수 있도록 해당 시스템 리소스의 최소 _요청_ 량을
 예약한다.

-
-
-
 <!-- body -->

 ## 요청 및 제한
@@ -72,7 +69,7 @@ Huge page는 노드 커널이 기본 페이지 크기보다 훨씬 큰 메모리
 이것은 `memory` 및 `cpu` 리소스와는 다르다.
 {{< /note >}}

-CPU와 메모리를 통칭하여 *컴퓨트 리소스* 또는 그냥 *리소스* 라고 한다. 컴퓨트
+CPU와 메모리를 통칭하여 *컴퓨트 리소스* 또는 *리소스* 라고 한다. 컴퓨트
 리소스는 요청, 할당 및 소비될 수 있는 측정 가능한
 수량이다. 이것은
 [API 리소스](/ko/docs/concepts/overview/kubernetes-api/)와는 다르다. 파드 및
@@ -441,7 +438,9 @@ kubelet은 각 `emptyDir` 볼륨, 컨테이너 로그 디렉터리 및 쓰기

 프로젝트 쿼터를 사용하려면, 다음을 수행해야 한다.

-* kubelet 구성에서 `LocalStorageCapacityIsolationFSQuotaMonitoring=true`
+* [kubelet 구성](/docs/reference/config-api/kubelet-config.v1beta1/)의
+  `featureGates` 필드 또는 `--feature-gates` 커맨드 라인 플래그를 사용하여
+  `LocalStorageCapacityIsolationFSQuotaMonitoring=true`
  [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
  활성화한다.

@@ -449,6 +448,7 @@ kubelet은 각 `emptyDir` 볼륨, 컨테이너 로그 디렉터리 및 쓰기
  프로젝트 쿼터가 활성화되어 있는지 확인한다. 모든 XFS 파일시스템은 프로젝트 쿼터를 지원한다.
  ext4 파일시스템의 경우, 파일시스템이 마운트되지 않은 상태에서 프로젝트 쿼터
  추적 기능을 활성화해야 한다.
+
  ```bash
  # ext4인 /dev/block-device가 마운트되지 않은 경우
  sudo tune2fs -O project -Q prjquota /dev/block-device
@@ -518,9 +518,8 @@ JSON-Pointer로 해석된다. 더 자세한 내용은,
 클러스터-레벨의 확장된 리소스는 노드에 연결되지 않는다. 이들은 일반적으로
 리소스 소비와 리소스 쿼터를 처리하는 스케줄러 익스텐더(extender)에 의해 관리된다.

-[스케줄러 정책 구성](https://github.com/kubernetes/kubernetes/blob/release-1.10/pkg/scheduler/api/v1/types.go#L31)에서
-스케줄러 익스텐더가
-처리하는 확장된 리소스를 지정할 수 있다.
+[스케줄러 정책 구성](/docs/reference/config-api/kube-scheduler-policy-config.v1/)에서
+스케줄러 익스텐더가 처리하는 확장된 리소스를 지정할 수 있다.

 **예제:**

@@ -743,23 +742,13 @@ LastState: map[terminated:map[exitCode:137 reason:OOM Killed startedAt:2015-07-0

 컨테이너가 `reason:OOM Killed`(`OOM` 은 메모리 부족(Out Of Memory)의 약자) 때문에 종료된 것을 알 수 있다.

-
-
-
-
-
 ## {{% heading "whatsnext" %}}

-
 * [컨테이너와 파드에 메모리 리소스를 할당](/ko/docs/tasks/configure-pod-container/assign-memory-resource/)하는 핸즈온 경험을 해보자.
-
 * [컨테이너와 파드에 CPU 리소스를 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/)하는 핸즈온 경험을 해보자.
-
 * 요청과 제한의 차이점에 대한 자세한 내용은,
  [리소스 QoS](https://git.k8s.io/community/contributors/design-proposals/node/resource-qos.md)를 참조한다.
-
 * [컨테이너](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) API 레퍼런스 읽어보기
-
 * [ResourceRequirements](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcerequirements-v1-core) API 레퍼런스 읽어보기
-
 * XFS의 [프로젝트 쿼터](https://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html)에 대해 읽어보기
+* [kube-scheduler 정책 레퍼런스 (v1)](/docs/reference/config-api/kube-scheduler-policy-config.v1/)에 대해 더 읽어보기
@@ -109,7 +109,7 @@ empty-secret   Opaque   0      2m6s
 ```

 해당 `DATA` 열은 시크릿에 저장된 데이터 아이템의 수를 보여준다.
-이 경우, `0` 은 비어 있는 시크릿을 방금 하나 생성하였다는 것을 의미한다.
+이 경우, `0` 은 비어 있는 시크릿을 하나 생성하였다는 것을 의미한다.

 ###  서비스 어카운트 토큰 시크릿

@@ -667,7 +667,7 @@ cat /etc/foo/password
 볼륨에서 현재 사용되는 시크릿이 업데이트되면, 투영된 키도 결국 업데이트된다.
 kubelet은 마운트된 시크릿이 모든 주기적인 동기화에서 최신 상태인지 여부를 확인한다.
 그러나, kubelet은 시크릿의 현재 값을 가져 오기 위해 로컬 캐시를 사용한다.
-캐시의 유형은 [KubeletConfiguration 구조체](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go)의
+캐시의 유형은 [KubeletConfiguration 구조체](/docs/reference/config-api/kubelet-config.v1beta1/)의
 `ConfigMapAndSecretChangeDetectionStrategy` 필드를 사용하여 구성할 수 있다.
 시크릿은 watch(기본값), ttl 기반 또는 API 서버로 모든 요청을 직접
 리디렉션하여 전파할 수 있다.
@@ -760,8 +760,8 @@ echo $SECRET_PASSWORD
 - immutable로 표시된 시크릿에 대한 감시를 중단하여, kube-apiserver의 부하를
 크게 줄임으로써 클러스터의 성능을 향상시킴

-이 기능은 v1.19부터 기본적으로 활성화된 `ImmutableEphemeralVolumes` [기능
-게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)에
+이 기능은 v1.19부터 기본적으로 활성화된 `ImmutableEphemeralVolumes`
+[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)에
 의해 제어된다. `immutable` 필드를 `true` 로 설정하여
 변경할 수 없는 시크릿을 생성할 수 있다. 다음은 예시이다.
 ```yaml
@@ -865,6 +865,7 @@ LASTSEEN   FIRSTSEEN   COUNT     NAME            KIND      SUBOBJECT
 ### 사용 사례: 컨테이너 환경 변수로 사용하기

 시크릿 정의를 작성한다.
+
 ```yaml
 apiVersion: v1
 kind: Secret
@@ -877,6 +878,7 @@ data:
 ```

 시크릿을 생성한다.
+
 ```shell
 kubectl apply -f mysecret.yaml
 ```
@@ -1173,14 +1175,12 @@ HTTP 요청을 처리하고, 복잡한 비즈니스 로직을 수행한 다음,

 시크릿 API에 접근해야 하는 애플리케이션은 필요한 시크릿에 대한 `get` 요청을
 수행해야 한다. 이를 통해 관리자는 앱에 필요한
-[개별 인스턴스에 대한 접근을 허용 목록에 추가](
-/docs/reference/access-authn-authz/rbac/#referring-to-resources)하면서 모든 시크릿에 대한 접근을
+[개별 인스턴스에 대한 접근을 허용 목록에 추가](/docs/reference/access-authn-authz/rbac/#referring-to-resources)하면서 모든 시크릿에 대한 접근을
 제한할 수 있다.

 `get` 반복을 통한 성능 향상을 위해, 클라이언트는 시크릿을
 참조한 다음 리소스를 감시(`watch`)하고, 참조가 변경되면 시크릿을 다시 요청하는 리소스를
-설계할 수 있다. 덧붙여, 클라이언트에게 개별 리소스를 감시(`watch`)하도록 하는 ["대량 감시" API](
-https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/bulk_watch.md)도
+설계할 수 있다. 덧붙여, 클라이언트에게 개별 리소스를 감시(`watch`)하도록 하는 ["대량 감시" API](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/bulk_watch.md)도
 제안되었으며, 쿠버네티스의 후속 릴리스에서 사용할 수
 있을 것이다.

@@ -50,10 +50,11 @@ terminated 또는 completed 상태인 경우에는 `PreStop` 훅 요청이 실
 ### 훅 핸들러 구현

 컨테이너는 훅의 핸들러를 구현하고 등록함으로써 해당 훅에 접근할 수 있다.
-구현될 수 있는 컨테이너의 훅 핸들러에는 두 가지 유형이 있다.
+구현될 수 있는 컨테이너의 훅 핸들러에는 세 가지 유형이 있다.

 * Exec - 컨테이너의 cgroups와 네임스페이스 안에서, `pre-stop.sh`와 같은, 특정 커맨드를 실행.
 커맨드에 의해 소비된 리소스는 해당 컨테이너에 대해 계산된다.
+* TCP - 컨테이너의 특정 포트에 대한 TCP 연결을 연다.
 * HTTP - 컨테이너의 특정 엔드포인트에 대해서 HTTP 요청을 실행.

 ### 훅 핸들러 실행
@@ -135,7 +135,7 @@ kubelet 프로세스의 환경 변수에서 `HOME=/root` 를 명시적으로 설
 예제의 경우, 사용자의 데스크탑/랩탑에서 아래 내용을 실행한다.

   1. 사용하고 싶은 각 자격 증명 세트에 대해서 `docker login [서버]`를 실행한다. 이것은 여러분 PC의 `$HOME/.docker/config.json`를 업데이트한다.
-   1. 편집기에서 `$HOME/.docker/config.json`를 보고 사용하고 싶은 자격 증명만 포함하고 있는지 확인한다.
+   1. 편집기로 `$HOME/.docker/config.json`를 열여서 사용하고 싶은 자격 증명만 포함하고 있는지 확인한다.
   1. 노드의 리스트를 구한다. 예를 들면 다음과 같다.
      - 이름을 원하는 경우: `nodes=$( kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}' )`
      - IP를 원하는 경우: `nodes=$( kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}' )`
@@ -44,7 +44,7 @@ _선언_ 하거나 지정할 수 있게 해주며 쿠버네티스 오브젝트
 클러스터 라이프사이클과 관계없이 실행 중인 클러스터에 커스텀 컨트롤러를 배포하고
 업데이트할 수 있다. 커스텀 컨트롤러는 모든 종류의 리소스와 함께 작동할 수 있지만
 커스텀 리소스와 결합할 때 특히 효과적이다.
-[오퍼레이터 패턴](https://coreos.com/blog/introducing-operators.html)은 사용자 정의
+[오퍼레이터 패턴](/ko/docs/concepts/extend-kubernetes/operator/)은 사용자 정의
 리소스와 커스텀 컨트롤러를 결합한다. 커스텀 컨트롤러를 사용하여 특정 애플리케이션에 대한 도메인 지식을
 쿠버네티스 API의 익스텐션으로 인코딩할 수 있다.

@@ -140,9 +140,9 @@ API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치
 쿠버네티스는 몇 가지 빌트인 인증 방법과 필요에 맞지 않는 경우 [인증 웹훅](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) 방법을 제공한다.


-### 승인
+### 인가

-[승인](/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/)을 통해 사용자가 제공한 코드를 호출하여 인증 결정을 내릴 수 있다.


 ### 동적 어드미션 컨트롤
@@ -30,8 +30,9 @@ card:

 컨트롤 플레인 컴포넌트는 클러스터 내 어떠한 머신에서든지 동작할 수 있다. 그러나
 간결성을 위하여, 구성 스크립트는 보통 동일 머신 상에 모든 컨트롤 플레인 컴포넌트를 구동시키고,
-사용자 컨테이너는 해당 머신 상에 동작시키지 않는다. 다중-마스터-VM 설치 예제를 보려면
-[고가용성 클러스터 구성하기](/docs/admin/high-availability/)를 확인해본다.
+사용자 컨테이너는 해당 머신 상에 동작시키지 않는다. 여러 VM에서
+실행되는 컨트롤 플레인 설정의 예제를 보려면
+[kubeadm을 사용하여 고가용성 클러스터 만들기](/docs/setup/production-environment/tools/kubeadm/high-availability/)를 확인해본다.

 ### kube-apiserver

@@ -21,11 +21,15 @@ weight: 20

 {{< glossary_definition term_id="name" length="all" >}}

+{{< note >}}
+물리적 호스트를 나타내는 노드와 같이 오브젝트가 물리적 엔티티를 나타내는 경우, 노드를 삭제한 후 다시 생성하지 않은 채 동일한 이름으로 호스트를 다시 생성하면, 쿠버네티스는 새 호스트를 불일치로 이어질 수 있는 이전 호스트로 취급한다.
+{{< /note >}}
+
 다음은 리소스에 일반적으로 사용되는 세 가지 유형의 이름 제한 조건이다.

 ### DNS 서브도메인 이름

-대부분의 리소스 유형에는 [RFC 1123](https://tools.ietf.org/html/rfc1123)에 정의된 대로 
+대부분의 리소스 유형에는 [RFC 1123](https://tools.ietf.org/html/rfc1123)에 정의된 대로
 DNS 서브도메인 이름으로 사용할 수 있는 이름이 필요하다.
 이것은 이름이 다음을 충족해야 한다는 것을 의미한다.

@@ -83,4 +87,3 @@ UUID는 ISO/IEC 9834-8 과 ITU-T X.667 로 표준화 되어 있다.

 * 쿠버네티스의 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)에 대해 읽기.
 * [쿠버네티스의 식별자와 이름](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md) 디자인 문서 읽기.
-
@@ -11,18 +11,17 @@ weight: 20

 <!-- overview -->

-{{< glossary_tooltip text="파드" term_id="pod" >}}를 특정한 {{< glossary_tooltip text="노드(들)" term_id="node" >}}에서만 동작하도록 하거나,
-특정 노드들을 선호하도록 제한할 수 있다.
-이를 수행하는 방법에는 여러 가지가 있으며, 권장되는 접근 방식은 모두
-[레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/)를 사용하여 선택한다.
-보통 스케줄러가 자동으로 합리적인 배치(예: 노드들에 걸쳐 파드를 분배하거나,
-자원이 부족한 노드에 파드를 배치하지 않는 등)를 수행하기에 이런 제약 조건은 필요하지 않지만
-간혹 파드가 배치되는 노드에 대해 더 많은 제어를 원할 수 있는 상황이 있다.
+특정한 {{< glossary_tooltip text="노드(들)" term_id="node" >}} 집합에서만 동작하도록
+{{< glossary_tooltip text="파드" term_id="pod" >}}를 제한할 수 있다.
+이를 수행하는 방법에는 여러 가지가 있으며 권장되는 접근 방식은 모두
+[레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/)를 사용하여 선택을 용이하게 한다.
+보통 스케줄러가 자동으로 합리적인 배치(예: 자원이 부족한 노드에 파드를 배치하지 않도록
+노드 간에 파드를 분배하는 등)를 수행하기에 이러한 제약 조건은 필요하지 않지만
+간혹 파드가 배포할 노드를 제어해야 하는 경우가 있다.
 예를 들어 SSD가 장착된 머신에 파드가 연결되도록 하거나 또는 동일한 가용성 영역(availability zone)에서
 많은 것을 통신하는 두 개의 서로 다른 서비스의 파드를 같이 배치할 수 있다.


-
 <!-- body -->

 ## 노드 셀렉터(nodeSelector)
@@ -120,13 +119,13 @@ spec:

 여기에 현재 `requiredDuringSchedulingIgnoredDuringExecution` 와 `preferredDuringSchedulingIgnoredDuringExecution` 로 부르는
 두 가지 종류의 노드 어피니티가 있다. 전자는 파드가 노드에 스케줄되도록 *반드시*
-규칙을 만족해야 하는 것(`nodeSelector` 와 같으나 보다 표현적인 구문을 사용해서)을 지정하고,
+규칙을 만족해야 하는 것(`nodeSelector` 와 비슷하나 보다 표현적인 구문을 사용해서)을 지정하고,
 후자는 스케줄러가 시도하려고는 하지만, 보증하지 않는 *선호(preferences)* 를 지정한다는 점에서
 이를 각각 "엄격함(hard)" 과 "유연함(soft)" 으로 생각할 수 있다.
 이름의 "IgnoredDuringExecution" 부분은 `nodeSelector` 작동 방식과 유사하게 노드의
-레이블이 런타임 중에 변경되어 파드의 어피니티 규칙이 더 이상 충족되지 않으면 파드가 여전히 그 노드에서
+레이블이 런타임 중에 변경되어 파드의 어피니티 규칙이 더 이상 충족되지 않으면 파드가 그 노드에서
 동작한다는 의미이다. 향후에는 파드의 노드 어피니티 요구 사항을 충족하지 않는 노드에서 파드를 제거한다는
-점을 제외하고는 `preferredDuringSchedulingIgnoredDuringExecution` 와 같은 `requiredDuringSchedulingIgnoredDuringExecution` 를 제공할 계획이다.
+점을 제외하고는 `preferredDuringSchedulingIgnoredDuringExecution` 와 동일한 `requiredDuringSchedulingIgnoredDuringExecution` 를 제공할 계획이다.

 따라서 `requiredDuringSchedulingIgnoredDuringExecution` 의 예로는 "인텔 CPU가 있는 노드에서만 파드 실행"이
 될 수 있고, `preferredDuringSchedulingIgnoredDuringExecution` 의 예로는 "장애 조치 영역 XYZ에 파드 집합을 실행하려고
@@ -86,6 +86,7 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순
 * [스케줄러 성능 튜닝](/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)에 대해 읽기
 * [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)에 대해 읽기
 * kube-scheduler의 [레퍼런스 문서](/docs/reference/command-line-tools-reference/kube-scheduler/) 읽기
+* [kube-scheduler 구성(v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) 레퍼런스 읽기
 * [멀티 스케줄러 구성하기](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)에 대해 배우기
 * [토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)에 대해 배우기
 * [파드 오버헤드](/ko/docs/concepts/scheduling-eviction/pod-overhead/)에 대해 배우기
@@ -24,8 +24,6 @@ API 서버에 해당 결정을 통지한다.
 본 페이지에서는 상대적으로 큰 규모의 쿠버네티스 클러스터에 대한 성능 튜닝
 최적화에 대해 설명한다.

-
-
 <!-- body -->

 큰 규모의 클러스터에서는 스케줄러의 동작을 튜닝하여 응답 시간
@@ -44,8 +42,10 @@ kube-scheduler 의 `percentageOfNodesToScore` 설정을 통해
 `percentageOfNodesToScore` 를 100 보다 높게 설정해도 kube-scheduler는
 마치 100을 설정한 것처럼 작동한다.

-값을 변경하려면, kube-scheduler 구성 파일(이 파일은 `/etc/kubernetes/config/kube-scheduler.yaml`
-일 수 있다)을 편집한 다음 스케줄러를 재시작 한다.
+값을 변경하려면,
+[kube-scheduler 구성 파일](/docs/reference/config-api/kube-scheduler-config.v1beta1/)을
+편집한 다음 스케줄러를 재시작한다.
+대부분의 경우, 구성 파일은 `/etc/kubernetes/config/kube-scheduler.yaml` 에서 찾을 수 있다.

 이를 변경한 후에 다음을 실행해서

@@ -99,7 +99,6 @@ algorithmSource:
 percentageOfNodesToScore: 50
 ```

-
 ### percentageOfNodesToScore 튜닝

 `percentageOfNodesToScore`는 1과 100 사이의 값이어야 하며
@@ -159,3 +158,7 @@ percentageOfNodesToScore: 50
 ```

 모든 노드를 검토한 후, 노드 1로 돌아간다.
+
+## {{% heading "whatsnext" %}}
+
+* [kube-scheduler 구성 레퍼런스(v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) 확인
@@ -38,7 +38,7 @@ API 서버가 하나 이상의 인증기 모듈을 실행하도록 구성한다.
 인증기는 [여기](/docs/reference/access-authn-authz/authentication/)에서 더 자세히 서술한다.

 인증 단계로 들어가는 것은 온전한 HTTP 요청이지만
-일반적으로 헤더 그리고/또는 클라이언트 인증서만 검사한다.
+일반적으로 헤더 그리고/또는 클라이언트 인증서를 검사한다.

 인증 모듈은 클라이언트 인증서, 암호 및 일반 토큰, 부트스트랩 토큰,
 JWT 토큰(서비스 어카운트에 사용됨)을 포함한다.
@@ -383,7 +383,7 @@ $ curl https://<EXTERNAL-IP>:<NODE-PORT> -k
 <h1>Welcome to nginx!</h1>
 ```

-이제 클라우드 로드 밸런서를 사용하도록 서비스를 재생성하고, `my-nginx` 서비스의 `Type` 을  `NodePort` 에서 `LoadBalancer` 로 변경한다.
+이제 클라우드 로드 밸런서를 사용하도록 서비스를 재생성한다. `my-nginx` 서비스의 `Type` 을 `NodePort` 에서 `LoadBalancer` 로 변경한다.

 ```shell
 kubectl edit svc my-nginx
@@ -218,7 +218,7 @@ Events:       <none>
 {{< codenew file="service/networking/external-lb.yaml" >}}

 IngressClass 리소스에는 선택적인 파라미터 필드가 있다. 이 클래스에 대한
-추가 구성을 참조하는데 사용할 수 있다.
+추가 구성을 참조하는 데에 사용할 수 있다.

 ### 사용중단(Deprecated) 어노테이션

@@ -257,8 +257,8 @@ IngressClass 리소스에는 선택적인 파라미터 필드가 있다. 이 클

 {{< codenew file="service/networking/test-ingress.yaml" >}}

-만약 `kubectl apply -f` 를 사용해서 생성한다면 방금 추가한 인그레스의
-상태를 볼 수 있어야 한다.
+만약 `kubectl apply -f` 를 사용해서 생성했다면 생성한 인그레스의
+상태를 볼 수 있을 것이다.

 ```bash
 kubectl get ingress test-ingress
@@ -54,7 +54,7 @@ _서비스 토폴로지_ 기능은 서비스 생성자가 발신 노드와 수
 백엔드가 없는 경우, 두 번째 레이블을 그리고 더 이상의
 레이블이 남지 않을 때까지 고려한다.

-만약 일치하는 것을 못찾는 경우에는, 서비스에 대한 백엔드가 없었던 것처럼
+만약 일치하는 것을 찾지 못한 경우에는, 마치 서비스에 대한 백엔드가 없는 것처럼
 트래픽이 거부될 것이다. 즉, 엔드포인트는 사용 가능한 백엔드가 있는 첫 번째
 토폴로지 키를 기반으로 선택된다. 만약 이 필드가 지정되고 모든 항목에
 클라이언트의 토폴로지와 일치하는 백엔드가 없는 경우, 서비스에는 해당 클라이언트에
@@ -513,8 +513,12 @@ API에서 `엔드포인트` 레코드를 생성하고, DNS 구성을 수정하
 각 노드는 해당 포트 (모든 노드에서 동일한 포트 번호)를 서비스로 프록시한다.
 서비스는 할당된 포트를 `.spec.ports[*].nodePort` 필드에 나타낸다.

-포트를 프록시하기 위해 특정 IP를 지정하려면 kube-proxy의 `--nodeport-addresses` 플래그를 특정 IP 블록으로 설정할 수 있다. 이것은 쿠버네티스 v1.10부터 지원된다.
-이 플래그는 쉼표로 구분된 IP 블록 목록 (예: 10.0.0.0/8, 192.0.2.0/25)을 사용하여 kube-proxy가 로컬 노드로 고려해야 하는 IP 주소 범위를 지정한다.
+포트를 프록시하기 위해 특정 IP를 지정하려면, kube-proxy에 대한
+`--nodeport-addresses` 플래그 또는
+[kube-proxy 구성 파일](/docs/reference/config-api/kube-proxy-config.v1alpha1/)의
+동등한 `nodePortAddresses` 필드를
+특정 IP 블록으로 설정할 수 있다.
+이 플래그는 쉼표로 구분된 IP 블록 목록(예: `10.0.0.0/8`, `192.0.2.0/25`)을 사용하여 kube-proxy가 로컬 노드로 고려해야 하는 IP 주소 범위를 지정한다.

 예를 들어, `--nodeport-addresses=127.0.0.0/8` 플래그로 kube-proxy를 시작하면, kube-proxy는 NodePort 서비스에 대하여 루프백(loopback) 인터페이스만 선택한다. `--nodeport-addresses`의 기본 값은 비어있는 목록이다. 이것은 kube-proxy가 NodePort에 대해 사용 가능한 모든 네트워크 인터페이스를 고려해야 한다는 것을 의미한다. (이는 이전 쿠버네티스 릴리스와도 호환된다).

@@ -526,11 +530,13 @@ API에서 `엔드포인트` 레코드를 생성하고, DNS 구성을 수정하
 사용해야 한다.

 NodePort를 사용하면 자유롭게 자체 로드 밸런싱 솔루션을 설정하거나,
-쿠버네티스가 완벽하게 지원하지 않는 환경을 구성하거나,
+쿠버네티스가 완벽하게 지원하지 못하는 환경을 구성하거나,
 하나 이상의 노드 IP를 직접 노출시킬 수 있다.

 이 서비스는 `<NodeIP>:spec.ports[*].nodePort`와
-`.spec.clusterIP:spec.ports[*].port`로 표기된다. (kube-proxy에서 `--nodeport-addresses` 플래그가 설정되면, <NodeIP>는 NodeIP를 필터링한다.)
+`.spec.clusterIP:spec.ports[*].port`로 표기된다.
+kube-proxy에 대한 `--nodeport-addresses` 플래그 또는 kube-proxy 구성 파일의
+동등한 필드가 설정된 경우, `<NodeIP>` 는 노드 IP를 필터링한다.

 예를 들면

@@ -785,8 +791,7 @@ TCP 및 SSL은 4 계층 프록시를 선택한다. ELB는 헤더를 수정하지
 ```

 위의 예에서, 서비스에 `80`, `443`, `8443`의 3개 포트가 포함된 경우,
-`443`, `8443`은 SSL 인증서를 사용하지만, `80`은 단순히
-프록시만 하는 HTTP이다.
+`443`, `8443`은 SSL 인증서를 사용하지만, `80`은 프록시하는 HTTP이다.

 쿠버네티스 v1.9부터는 서비스에 대한 HTTPS 또는 SSL 리스너와 함께 [사전에 정의된 AWS SSL 정책](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html)을 사용할 수 있다.
 사용 가능한 정책을 확인하려면, `aws` 커맨드라인 툴을 사용한다.
@@ -958,7 +963,7 @@ NLB는 특정 인스턴스 클래스에서만 작동한다. 지원되는 인스

 | 규칙 | 프로토콜 | 포트 | IP 범위 | IP 범위 설명 |
 |------|----------|---------|------------|---------------------|
-| 헬스 체크 | TCP | NodePort(s) (`.spec.healthCheckNodePort` for `.spec.externalTrafficPolicy = Local`) | VPC CIDR | kubernetes.io/rule/nlb/health=\<loadBalancerName\> |
+| 헬스 체크 | TCP | NodePort(s) (`.spec.healthCheckNodePort` for `.spec.externalTrafficPolicy = Local`) | Subnet CIDR | kubernetes.io/rule/nlb/health=\<loadBalancerName\> |
 | 클라이언트 트래픽 | TCP | NodePort(s) | `.spec.loadBalancerSourceRanges` (defaults to `0.0.0.0/0`) | kubernetes.io/rule/nlb/client=\<loadBalancerName\> |
 | MTU 탐색 | ICMP | 3,4 | `.spec.loadBalancerSourceRanges` (defaults to `0.0.0.0/0`) | kubernetes.io/rule/nlb/mtu=\<loadBalancerName\> |

@@ -29,7 +29,7 @@ _퍼시스턴트볼륨_ (PV)은 관리자가 프로비저닝하거나 [스토리

 _퍼시스턴트볼륨클레임_ (PVC)은 사용자의 스토리지에 대한 요청이다. 파드와 비슷하다. 파드는 노드 리소스를 사용하고 PVC는 PV 리소스를 사용한다. 파드는 특정 수준의 리소스(CPU 및 메모리)를 요청할 수 있다. 클레임은 특정 크기 및 접근 모드를 요청할 수 있다(예: ReadWriteOnce, ReadOnlyMany 또는 ReadWriteMany로 마운트 할 수 있음. [AccessModes](#접근-모드) 참고).

-퍼시스턴트볼륨클레임을 사용하면 사용자가 추상화된 스토리지 리소스를 사용할 수 있지만, 다른 문제들 때문에 성능과 같은 다양한 속성을 가진 퍼시스턴트볼륨이 필요한 경우가 일반적이다. 클러스터 관리자는 사용자에게 해당 볼륨의 구현 방법에 대한 세부 정보를 제공하지 않고 단순히 크기와 접근 모드와는 다른 방식으로 다양한 퍼시스턴트볼륨을 제공할 수 있어야 한다. 이러한 요구에는 _스토리지클래스_ 리소스가 있다.
+퍼시스턴트볼륨클레임을 사용하면 사용자가 추상화된 스토리지 리소스를 사용할 수 있지만, 다른 문제들 때문에 성능과 같은 다양한 속성을 가진 퍼시스턴트볼륨이 필요한 경우가 일반적이다. 클러스터 관리자는 사용자에게 해당 볼륨의 구현 방법에 대한 세부 정보를 제공하지 않고 크기와 접근 모드와는 다른 방식으로 다양한 퍼시스턴트볼륨을 제공할 수 있어야 한다. 이러한 요구에는 _스토리지클래스_ 리소스가 있다.

 [실습 예제와 함께 상세한 내용](/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage/)을 참고하길 바란다.

@@ -563,8 +563,8 @@ parameters:
 * `quobyteAPIServer`: `"http(s)://api-server:7860"` 형식의
  Quobyte의 API 서버이다.
 * `registry`: 볼륨을 마운트하는 데 사용할 Quobyte 레지스트리이다. 레지스트리를
-  ``<host>:<port>`` 의 쌍으로 지정하거나 여러 레지스트리를
-  지정하려면 쉼표만 있으면 된다.
+  ``<host>:<port>`` 의 쌍으로 지정할 수 있으며, 여러 레지스트리를
+  지정하려면 각 쌍을 쉼표로 구분하면 된다.
  예: ``<host1>:<port>,<host2>:<port>,<host3>:<port>``
  호스트는 IP 주소이거나 DNS가 작동 중인 경우
  DNS 이름을 제공할 수도 있다.
@@ -34,7 +34,7 @@ weight: 10
 더 이상 존재하지 않으면, 쿠버네티스는 임시(ephemeral) 볼륨을 삭제하지만,
 퍼시스턴트(persistent) 볼륨은 삭제하지 않는다.

-기본적으로 볼륨은 디렉터리일 뿐이며, 일부 데이터가 있을 수 있으며, 파드
+기본적으로 볼륨은 디렉터리이며, 일부 데이터가 있을 수 있으며, 파드
 내 컨테이너에서 접근할 수 있다. 디렉터리의 생성 방식, 이를 지원하는
 매체와 내용은 사용된 특정 볼륨의 유형에 따라
 결정된다.
@@ -706,7 +706,7 @@ nginx-deployment-618515232    11        11        11        7m
 하나 이상의 업데이트를 트리거하기 전에 디플로이먼트를 일시 중지한 다음 다시 시작할 수 있다.
 이렇게 하면 불필요한 롤아웃을 트리거하지 않고 일시 중지와 재개 사이에 여러 수정 사항을 적용할 수 있다.

-* 예를 들어, 방금 생성된 디플로이먼트의 경우
+* 예를 들어, 생성된 디플로이먼트의 경우
  디플로이먼트 상세 정보를 가져온다.
  ```shell
  kubectl get deploy
@@ -98,8 +98,8 @@ echo $pods
 pi-5rwd7
 ```

-여기서 셀렉터는 잡의 셀렉터와 동일하다.  `--output=jsonpath` 옵션은 반환된 목록의
-각각의 파드에서 이름을 가져와서 표현하는 방식을 지정한다.
+여기서 셀렉터는 잡의 셀렉터와 동일하다.  `--output=jsonpath` 는
+반환된 목록의 각 파드 이름을 출력하도록 하는 옵션이다.

 파드 중 하나를 표준 출력으로 본다.

@@ -115,7 +115,7 @@ nginx-3ntk0 nginx-4ok8v nginx-qrm3m
 ```

 여기서 셀렉터는 레플리케이션컨트롤러(`kubectl describe` 의 출력에서 보인)의 셀렉터와 같고,
-다른 형식의 파일인 `replication.yaml` 의 것과 동일하다. `--output=jsonpath` 은
+다른 형식의 파일인 `replication.yaml` 의 것과 동일하다. `--output=jsonpath` 는
 반환된 목록의 각 파드 이름을 출력하도록 하는 옵션이다.