[ko] Update outdated files in dev-1.23-ko.2 M25-39

2022-02-16 12:05:47 +09:00 · 2022-02-16 12:05:47 +09:00 · ce19161d60
parent b7e6cf5d55
commit ce19161d60
12 changed files with 103 additions and 56 deletions
--- a/content/ko/docs/concepts/services-networking/service-traffic-policy.md
+++ b/content/ko/docs/concepts/services-networking/service-traffic-policy.md
@ -9,7 +9,7 @@ weight: 45

 <!-- overview -->

-{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.23" state="beta" >}}

 _서비스 내부 트래픽 정책_ 을 사용하면 내부 트래픽 제한이 트래픽이 시작된 
 노드 내의 엔드포인트로만 내부 트래픽을 라우팅하도록 한다. 
@ -20,9 +20,9 @@ _서비스 내부 트래픽 정책_ 을 사용하면 내부 트래픽 제한이

 ## 서비스 내부 트래픽 정책 사용

-
-[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)에서 
-`ServiceInternalTrafficPolicy`를 활성화한 후에 
+`ServiceInternalTrafficPolicy` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)는 
+베타 기능이며 기본적으로 활성화되어 있다. 
+이 기능이 활성화되어 있으면, 
 {{< glossary_tooltip text="서비스" term_id="service" >}}의 
 `.spec.internalTrafficPolicy`를 `Local`로 설정하여 내부 전용 트래픽 정책을 활성화 할 수 있다.
 이것은 kube-proxy가 클러스터 내부 트래픽을 위해 노드 내부 엔드포인트로만 사용하도록 한다.
--- a/content/ko/docs/concepts/services-networking/service.md
+++ b/content/ko/docs/concepts/services-networking/service.md
@ -449,11 +449,8 @@ kube-proxy는 마치 외부 트래픽 정책이 `Cluster`로 설정되어 있는

 ### 환경 변수

-파드가 노드에서 실행될 때, kubelet은 각 활성화된 서비스에 대해
-환경 변수 세트를 추가한다. [도커 링크
-호환](https://docs.docker.com/userguide/dockerlinks/) 변수 ([makeLinkVariables](https://github.com/kubernetes/kubernetes/blob/dd2d12f6dc0e654c15d5db57a5f9f6ba61192726/pkg/kubelet/envvars/envvars.go#L72) 참조)와
-보다 간단한 `{SVCNAME}_SERVICE_HOST` 및 `{SVCNAME}_SERVICE_PORT` 변수를 지원하고,
-이때 서비스 이름은 대문자이고 대시는 밑줄로 변환된다.
+파드가 노드에서 실행될 때, kubelet은 각 활성화된 서비스에 대해 환경 변수 세트를 추가한다. 
+`{SVCNAME}_SERVICE_HOST` 및 `{SVCNAME}_SERVICE_PORT` 환경 변수가 추가되는데, 이 때 서비스 이름은 대문자로, 하이픈(`-`)은 언더스코어(`_`)로 변환하여 사용한다. 또한 도커 엔진의 "_[레거시 컨테이너 연결](https://docs.docker.com/network/links/)_" 기능과 호환되는 변수([makeLinkVariables](https://github.com/kubernetes/kubernetes/blob/dd2d12f6dc0e654c15d5db57a5f9f6ba61192726/pkg/kubelet/envvars/envvars.go#L72) 참조)도 지원한다.

 예를 들어, TCP 포트 6379를 개방하고
 클러스터 IP 주소 10.0.0.11이 할당된 서비스 `redis-master`는,
@ -687,21 +684,28 @@ kube-apiserver에 대해 기능 게이트 `MixedProtocolLBService`가 활성화

 #### 로드밸런서 NodePort 할당 비활성화

-{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.22" state="beta" >}}

-v1.20부터는 `spec.allocateLoadBalancerNodePorts` 필드를 `false`로 설정하여 서비스 Type=LoadBalancer에
-대한 노드 포트 할당을 선택적으로 비활성화 할 수 있다.
-노드 포트를 사용하는 대신 트래픽을 파드로 직접 라우팅하는 로드 밸런서 구현에만 사용해야 한다.
-기본적으로 `spec.allocateLoadBalancerNodePorts`는 `true`이며 로드밸런서 서비스 유형은 계속해서 노드 포트를 할당한다.
-노드 포트가 할당된 기존 서비스에서 `spec.allocateLoadBalancerNodePorts`가 `false`로 설정된 경우 해당 노드 포트는 자동으로 할당 해제되지 않는다.
+`type=LoadBalancer` 서비스에 대한 노드 포트 할당을 선택적으로 비활성화할 수 있으며, 
+이는 `spec.allocateLoadBalancerNodePorts` 필드를 `false`로 설정하면 된다. 
+노드 포트를 사용하지 않고 트래픽을 파드로 직접 라우팅하는 로드 밸런서 구현에만 사용해야 한다.
+기본적으로 `spec.allocateLoadBalancerNodePorts`는 `true`이며 로드밸런서 서비스 유형은 계속해서 노드 포트를 할당할 것이다.
+노드 포트가 할당된 기존 서비스에서 `spec.allocateLoadBalancerNodePorts`가 `false`로 설정된 경우 
+해당 노드 포트는 자동으로 할당 해제되지 **않는다**.
 이러한 노드 포트를 할당 해제하려면 모든 서비스 포트에서 `nodePorts` 항목을 명시적으로 제거해야 한다.
-이 필드를 사용하려면 `ServiceLBNodePortControl` 기능 게이트를 활성화해야 한다.
+이 필드를 사용하려면 클러스터에 `ServiceLBNodePortControl` 
+[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있어야 한다.
+쿠버네티스 v{{< skew currentVersion >}}에서, 이 기능 게이트는 기본적으로 활성화되어 있으므로, 
+`spec.allocateLoadBalancerNodePorts` 필드를 사용할 수 있다. 
+다른 버전의 쿠버네티스를 실행하는 클러스터에 대해서는, 해당 릴리스의 문서를 참조한다.

 #### 로드 밸런서 구현 클래스 지정 {#load-balancer-class}

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

-`spec.loadBalancerClass` 필드를 설정하여 클라우드 제공자가 설정한 기본값 이외의 로드 밸런서 구현을 사용할 수 있다. 이 기능은 v1.21부터 사용할 수 있으며, v1.21에서는 이 필드를 사용하기 위해 `ServiceLoadBalancerClass` 기능 게이트를 활성화해야 하지만, v1.22부터는 해당 기능 게이트가 기본적으로 활성화되어 있다.
+`spec.loadBalancerClass` 필드를 설정하여 클라우드 제공자가 설정한 기본값 이외의 로드 밸런서 구현을 사용할 수 있다. 
+이 필드를 사용하기 위해서는 클러스터에 `ServiceLoadBalancerClass` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있어야 한다. 
+쿠버네티스 v{{< skew currentVersion >}}에서, 이 기능 게이트는 기본적으로 활성화되어 있다. 다른 버전의 쿠버네티스를 실행하는 클러스터에 대해서는, 해당 릴리스의 문서를 참조한다.
 기본적으로, `spec.loadBalancerClass` 는 `nil` 이고, 
 클러스터가 클라우드 제공자의 로드밸런서를 이용하도록 `--cloud-provider` 컴포넌트 플래그를 이용하여 설정되어 있으면 
 `LoadBalancer` 유형의 서비스는 클라우드 공급자의 기본 로드 밸런서 구현을 사용한다.
--- a/content/ko/docs/concepts/storage/persistent-volumes.md
+++ b/content/ko/docs/concepts/storage/persistent-volumes.md
@ -254,6 +254,16 @@ PVC에 대해 더 큰 볼륨을 요청하려면 PVC 오브젝트를 수정하여
 지정한다. 이는 기본 퍼시스턴트볼륨을 지원하는 볼륨의 확장을 트리거한다. 클레임을 만족시키기 위해
 새로운 퍼시스턴트볼륨이 생성되지 않고 기존 볼륨의 크기가 조정된다.

+{{< warning >}}
+퍼시스턴트볼륨의 크기를 직접 변경하면 자동 볼륨 리사이즈 기능을 이용할 수 없게 된다. 
+퍼시스턴트볼륨의 크기를 변경하고, 
+퍼시스턴트볼륨에 해당되는 퍼시스턴트볼륨클레임의 `.spec`에 적혀 있는 크기를 동일하게 변경하면, 
+스토리지 리사이즈가 발생하지 않는다.
+쿠버네티스 컨트롤 플레인은 
+두 리소스의 목표 상태(desired state)가 일치하는 것을 확인하고, 
+배후(backing) 볼륨 크기가 수동으로 증가되어 리사이즈가 필요하지 않다고 판단할 것이다.
+{{< /warning >}}
+
 #### CSI 볼륨 확장

 {{< feature-state for_k8s_version="v1.16" state="beta" >}}
@ -412,7 +422,7 @@ spec:

 ### 용량

-일반적으로 PV는 특정 저장 용량을 가진다. 이것은 PV의 `capacity` 속성을 사용하여 설정된다. `capacity`가 사용하는 단위를 이해하려면 쿠버네티스 [리소스 모델](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md)을 참고한다.
+일반적으로 PV는 특정 저장 용량을 가진다. 이것은 PV의 `capacity` 속성을 사용하여 설정된다. `capacity`가 사용하는 단위를 이해하려면 용어집에 있는 [수량](/ko/docs/reference/glossary/?all=true#term-quantity) 항목을 참고한다.

 현재 스토리지 용량 크기는 설정하거나 요청할 수 있는 유일한 리소스이다. 향후 속성에 IOPS, 처리량 등이 포함될 수 있다.

@ -525,19 +535,19 @@ PV는 `storageClassName` 속성을

 다음 볼륨 유형은 마운트 옵션을 지원한다.

-* AWSElasticBlockStore
-* AzureDisk
-* AzureFile
-* CephFS
-* Cinder (OpenStack 블록 스토리지)
-* GCEPersistentDisk
-* Glusterfs
-* NFS
-* Quobyte Volumes
-* RBD (Ceph Block Device)
-* StorageOS
-* VsphereVolume
-* iSCSI
+* `awsElasticBlockStore`
+* `azureDisk`
+* `azureFile`
+* `cephfs`
+* `cinder` (v1.18에서 **사용 중단됨**)
+* `gcePersistentDisk`
+* `glusterfs`
+* `iscsi`
+* `nfs`
+* `quobyte` (v1.22에서 **사용 중단됨**)
+* `rbd`
+* `storageos` (v1.22에서 **사용 중단됨**)
+* `vsphereVolume`

 마운트 옵션의 유효성이 검사되지 않는다. 마운트 옵션이 유효하지 않으면, 마운트가 실패한다.

--- a/content/ko/docs/concepts/storage/storage-classes.md
+++ b/content/ko/docs/concepts/storage/storage-classes.md
@ -434,7 +434,7 @@ provisioner: example.com/external-nfs
 parameters:
  server: nfs-server.example.com
  path: /share
-  readOnly: false
+  readOnly: "false"
 ```

 * `server`: NFS 서버의 호스트네임 또는 IP 주소.
@ -797,7 +797,7 @@ parameters:
  storagePool: sp1
  storageMode: ThinProvisioned
  secretRef: sio-secret
-  readOnly: false
+  readOnly: "false"
  fsType: xfs
 ```

--- a/content/ko/docs/concepts/storage/volume-snapshot-classes.md
+++ b/content/ko/docs/concepts/storage/volume-snapshot-classes.md
@ -39,6 +39,10 @@ weight: 41 # just after volume snapshots
 처음 생성할 때 클래스의 이름과 기타 파라미터를 설정하고, 오브젝트가
 생성된 이후에는 업데이트할 수 없다.

+{{< note >}}
+CRD의 설치는 쿠버네티스 배포판의 책임이다. 필요한 CRD가 존재하지 않는다면, 볼륨스냅샷클래스 생성이 실패할 것이다.
+{{< /note >}}
+
 ```yaml
 apiVersion: snapshot.storage.k8s.io/v1
 kind: VolumeSnapshotClass
--- a/content/ko/docs/concepts/storage/volumes.md
+++ b/content/ko/docs/concepts/storage/volumes.md
@ -859,7 +859,7 @@ RBD는 읽기-쓰기 모드에서 단일 고객만 마운트할 수 있다.
 드라이버로 리다이렉트한다. 
 이 기능을 사용하려면, 클러스터에 
 [Ceph CSI 드라이버](https://github.com/ceph/ceph-csi)가 설치되어 있고 
-`CSIMigration`, `CSIMigrationRBD` 
+`CSIMigration`, `csiMigrationRBD` 
 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있어야 한다.

 {{< note >}}
@ -1133,6 +1133,7 @@ spec:
    volumeMounts:
    - name: workdir1
      mountPath: /logs
+      # 변수 확장에는 괄호를 사용한다(중괄호 아님).
      subPathExpr: $(POD_NAME)
  restartPolicy: Never
  volumes:
--- a/content/ko/docs/concepts/workloads/controllers/deployment.md
+++ b/content/ko/docs/concepts/workloads/controllers/deployment.md
@ -842,6 +842,13 @@ nginx-deployment-618515232    11        11        11        7m
 * 디플로이먼트로 기존 레플리카셋을 스케일 다운.
 * 새 파드가 준비되거나 이용할 수 있음(최소 [준비 시간(초)](#최소-대기-시간-초) 동안 준비됨).

+롤아웃이 "진행 중" 상태가 되면, 
+디플로이먼트 컨트롤러는 디플로이먼트의 `.status.conditions`에 다음 속성을 포함하는 컨디션을 추가한다.
+
+* `type: Progressing`
+* `status: "True"`
+* `reason: NewReplicaSetCreated` | `reason: FoundNewReplicaSet` | `reason: ReplicaSetUpdated`
+
 `kubectl rollout status` 를 사용해서 디플로이먼트의 진행사황을 모니터할 수 있다.

 ### 디플로이먼트 완료
@ -853,6 +860,17 @@ nginx-deployment-618515232    11        11        11        7m
 * 디플로이먼트와 관련한 모든 레플리카를 사용할 수 있을 때.
 * 디플로이먼트에 대해 이전 복제본이 실행되고 있지 않을 때.

+롤아웃이 "완료" 상태가 되면, 
+디플로이먼트 컨트롤러는 디플로이먼트의 `.status.conditions`에 다음 속성을 포함하는 컨디션을 추가한다.
+
+* `type: Progressing`
+* `status: "True"`
+* `reason: NewReplicaSetAvailable`
+
+이 `Progressing` 컨디션은 새로운 롤아웃이 시작되기 전까지는 `"True"` 상태값을 유지할 것이다. 
+레플리카의 가용성이 변경되는 경우에도(이 경우 `Available` 컨디션에 영향을 미침) 
+컨디션은 유지된다.
+
 `kubectl rollout status` 를 사용해서 디플로이먼트가 완료되었는지 확인할 수 있다.
 만약 롤아웃이 성공적으로 완료되면 `kubectl rollout status` 는 종료 코드로 0이 반환된다.

@ -890,7 +908,7 @@ echo $?
 대기하는 시간(초)를 나타낸다.

 다음 `kubectl` 명령어로 `progressDeadlineSeconds` 를 설정해서 컨트롤러가
-10분 후 디플로이먼트에 대한 진행 상태의 부족에 대한 리포트를 수행하게 한다.
+10분 후 디플로이먼트 롤아웃에 대한 진행 상태의 부족에 대한 리포트를 수행하게 한다.

 ```shell
 kubectl patch deployment/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}'
@ -902,14 +920,17 @@ deployment.apps/nginx-deployment patched
 만약 데드라인을 넘어서면 디플로이먼트 컨트롤러는 디플로이먼트의 `.status.conditions` 속성에 다음의
 디플로이먼트 컨디션(DeploymentCondition)을 추가한다.

-* Type=Progressing
-* Status=False
-* Reason=ProgressDeadlineExceeded
+* `type: Progressing`
+* `status: "False"`
+* `reason: ProgressDeadlineExceeded`
+
+이 컨디션은 일찍 실패할 수도 있으며 이러한 경우 `ReplicaSetCreateError`를 이유로 상태값을 `"False"`로 설정한다.
+또한, 디플로이먼트 롤아웃이 완료되면 데드라인은 더 이상 고려되지 않는다.

 컨디션 상태에 대한 자세한 내용은 [쿠버네티스 API 규칙](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties)을 참고한다.

 {{< note >}}
-쿠버네티스는 `Reason=ProgressDeadlineExceeded` 과 같은 상태 조건을
+쿠버네티스는 `reason: ProgressDeadlineExceeded` 과 같은 상태 조건을
 보고하는 것 이외에 정지된 디플로이먼트에 대해 조치를 취하지 않는다. 더 높은 수준의 오케스트레이터는 이를 활용할 수 있으며,
 예를 들어 디플로이먼트를 이전 버전으로 롤백할 수 있다.
 {{< /note >}}
@ -984,7 +1005,7 @@ Conditions:
 디플로이먼트를 스케일 다운하거나, 실행 중인 다른 컨트롤러를 스케일 다운하거나,
 네임스페이스에서 할당량을 늘려서 할당량이 부족한 문제를 해결할 수 있다.
 만약 할당량 컨디션과 디플로이먼트 롤아웃이 완료되어 디플로이먼트 컨트롤러를 만족한다면
-성공한 컨디션의 디플로이먼트 상태가 업데이트를 볼 수 있다(`Status=True` 와 `Reason=NewReplicaSetAvailable`).
+성공한 컨디션의 디플로이먼트 상태가 업데이트를 볼 수 있다(`status: "True"` 와 `reason: NewReplicaSetAvailable`).

 ```
 Conditions:
@ -994,11 +1015,11 @@ Conditions:
  Progressing   True    NewReplicaSetAvailable
 ```

-`Type=Available` 과 `Status=True` 는 디플로이먼트가 최소한의 가용성을 가지고 있는 것을 의미한다.
-최소한의 가용성은 디플로이먼트 계획에 명시된 파라미터에 의해 결정된다. `Type=Progressing` 과 `Status=True` 는 디플로이먼트가
+`type: Available` 과 `status: "True"` 는 디플로이먼트가 최소한의 가용성을 가지고 있는 것을 의미한다.
+최소한의 가용성은 디플로이먼트 계획에 명시된 파라미터에 의해 결정된다. `type: Progressing` 과 `status: "True"` 는 디플로이먼트가
 롤아웃 도중에 진행 중 이거나, 성공적으로 완료되었으며, 진행 중 최소한으로 필요한 새로운 레플리카를 이용 가능하다는 것이다.
 (자세한 내용은 특정 조건의 이유를 참조한다.
-이 경우 `Reason=NewReplicaSetAvailable` 는 배포가 완료되었음을 의미한다.)
+이 경우 `reason: NewReplicaSetAvailable` 는 배포가 완료되었음을 의미한다.)

 `kubectl rollout status` 를 사용해서 디플로이먼트의 진행이 실패되었는지 확인할 수 있다.
 `kubectl rollout status` 는 디플로이먼트의 진행 데드라인을 초과하면 0이 아닌 종료 코드를 반환한다.
@ -1153,8 +1174,8 @@ API 버전 `apps/v1` 에서는 `.spec.selector` 와 `.metadata.labels` 이 설

 ### 진행 기한 시간(초)

-`.spec.progressDeadlineSeconds` 는 디플로어먼트가 표면적으로 `Type=Progressing`, `Status=False`의
-상태 그리고 리소스가 `Reason=ProgressDeadlineExceeded` 상태로 [진행 실패](#디플로이먼트-실패)를 보고하기 전에
+`.spec.progressDeadlineSeconds` 는 디플로어먼트가 표면적으로 `type: Progressing`, `status: "False"`의
+상태 그리고 리소스가 `reason: ProgressDeadlineExceeded` 상태로 [진행 실패](#디플로이먼트-실패)를 보고하기 전에
 디플로이먼트가 진행되는 것을 대기시키는 시간(초)를 명시하는 선택적 필드이다.
 디플로이먼트 컨트롤러는 디플로이먼트를 계속 재시도 한다. 기본값은 600(초)이다.
 미래에 자동화된 롤백이 구현된다면 디플로이먼트 컨트롤러는 상태를 관찰하고,
--- a/content/ko/docs/concepts/workloads/controllers/job.md
+++ b/content/ko/docs/concepts/workloads/controllers/job.md
@ -615,8 +615,8 @@ spec:
 ```

 새 잡 자체는 `a8f3d00d-c6d2-11e5-9f87-42010af00002` 와 다른 uid 를 가지게 될 것이다.
-`manualSelector: true` 를 설정하면 시스템에게 사용자가 무엇을 하는지 알고 있음을 알리고, 이런
-불일치를 허용한다.
+`manualSelector: true` 를 설정하면 시스템에게 사용자가 무엇을 하는지 알고 있으며 
+이런 불일치를 허용한다고 알릴 수 있다.

 ### 종료자(finalizers)를 이용한 잡 추적

--- a/content/ko/docs/contribute/advanced.md
+++ b/content/ko/docs/contribute/advanced.md
@ -110,15 +110,13 @@ SIG Docs [리뷰어](/ko/docs/contribute/participate/roles-and-responsibilities/

 ## SIG 공동 의장으로 봉사

-SIG Docs [승인자](/ko/docs/contribute/participate/roles-and-responsibilities/#승인자)는
+SIG Docs [멤버](/ko/docs/contribute/participate/roles-and-responsibilities/#멤버)는
 SIG Docs의 공동 의장 역할을 할 수 있다.

 ### 전제 조건

-승인자는 공동 의장이 되려면 다음의 요구 사항을 충족해야 한다.
+쿠버네티스 멤버가 공동 의장이 되려면 다음의 요구 사항을 충족해야 한다.

- 6개월 이상 SIG Docs 승인자로 활동한다.
- [쿠버네티스 문서 릴리스 주도](/ko/docs/contribute/advanced/#쿠버네티스-릴리스를-위한-문서-조정) 또는 두 개의 릴리스에서 섀도잉을 수행한다.
 - SIG Docs 워크플로와 툴링을 이해한다(git, Hugo, 현지화, 블로그 하위 프로젝트).
 - [k/org의 팀](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml),
  [k/community의 프로세스](https://github.com/kubernetes/community/tree/master/sig-docs),
@ -126,6 +124,8 @@ SIG Docs의 공동 의장 역할을 할 수 있다.
  [SIG 아키텍처](https://github.com/kubernetes/community/tree/master/sig-architecture)의
  역할을 포함하여 다른 쿠버네티스 SIG와 리포지터리가 SIG Docs 워크플로에 미치는
  영향을 이해한다.
+  추가로, [쿠버네티스 문서 릴리스 프로세스](/ko/docs/contribute/advanced/#쿠버네티스-릴리스를-위한-문서-조정)가 어떻게 동작하는지 이해한다.
+- SIG Docs 커뮤니티에 이해 직접적으로 또는 lazy consensus(특정 기간 내에 아무런 의견이 없으면 통과)를 통해 승인된다.
 - 최소 6개월 동안 일주일에 5시간 이상(대부분 더)을 역할에 책임진다.

 ### 책임
--- a/content/ko/docs/contribute/participate/roles-and-responsibilities.md
+++ b/content/ko/docs/contribute/participate/roles-and-responsibilities.md
@ -51,7 +51,8 @@ GitHub 계정을 가진 누구나 쿠버네티스에 기여할 수 있다. SIG D
 - 풀 리퀘스트에 `/lgtm` 코멘트를 사용하여 LGTM(looks good to me) 레이블을 추가한다.

  {{< note >}}
-  `/lgtm` 사용은 자동화를 트리거한다. 만약 구속력 없는 승인을 제공하려면, "LGTM" 코멘트를 남기는 것도 좋다!
+  `/lgtm` 사용은 자동화를 트리거한다. 만약 구속력 없는 승인을 제공하려면, 
+  "LGTM" 코멘트를 남기는 것도 좋다!
  {{< /note >}}

 - `/hold` 코멘트를 사용하여 풀 리퀘스트에 대한 병합을 차단한다.
@ -89,7 +90,8 @@ GitHub 계정을 가진 누구나 쿠버네티스에 기여할 수 있다. SIG D
     쿠버네티스 GitHub 관리자가 여러분을 멤버로 추가한다.
     축하한다!

-     만약 멤버십이 수락되지 않으면 피드백을 받게 될 것이다. 피드백의 내용을 해결한 후, 다시 지원하자.
+     만약 멤버십이 수락되지 않으면 피드백을 받게 될 것이다. 
+     피드백의 내용을 해결한 후, 다시 지원하자.

 1. 여러분의 이메일 계정으로 수신된 쿠버네티스 GitHub 조직으로의 초대를 수락한다.

@ -138,7 +140,8 @@ LGTM은 "Looks good to me"의 약자이며 풀 리퀘스트가 기술적으로
 ### 리뷰어 되기

 [요건](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer)을
-충족하면, SIG Docs 리뷰어가 될 수 있다. 다른 SIG의 리뷰어는 SIG Docs의 리뷰어 자격에
+충족하면, SIG Docs 리뷰어가 될 수 있다. 
+다른 SIG의 리뷰어는 SIG Docs의 리뷰어 자격에
 반드시 별도로 지원해야 한다.

 지원하려면, 다음을 수행한다.
--- a/content/ko/docs/contribute/review/for-approvers.md
+++ b/content/ko/docs/contribute/review/for-approvers.md
@ -79,7 +79,7 @@ PR 코멘트를 남기는 것이 도움이 되지만, 대신 다른 사람의 PR
 {{< table caption="리뷰를 위한 Prow 명령" >}}
 Prow 명령     | 역할 제한           | 설명
 :------------|:------------------|:-----------
-`/lgtm` | 누구나, 리뷰어나 승인자가 사용한다면 자동화를 트리거한다. | PR 리뷰를 마치고 변경 사항에 만족했음을 나타낸다.
+`/lgtm` | 조직 멤버 | PR 리뷰를 마치고 변경 사항에 만족했음을 나타낸다.
 `/approve` | 승인자 | PR을 병합(merge)하기 위해 승인한다.
 `/assign` | 리뷰어 또는 승인자 | PR을 리뷰하거나 승인할 사람을 지정한다.
 `/close` | 리뷰어 또는 승인자 | 이슈 또는 PR을 닫는다.
--- a/content/ko/docs/contribute/review/reviewing-prs.md
+++ b/content/ko/docs/contribute/review/reviewing-prs.md
@ -85,7 +85,11 @@ class third,fourth white
    - PR 설명을 통해 변경 사항을 이해하고, 연결된 이슈 읽기
    - 다른 리뷰어의 의견 읽기
    - **Files changed** 탭을 클릭하여 변경된 파일과 행 보기
-    - **Conversation** 탭의 맨 아래에 있는 PR의 빌드 확인 섹션으로 스크롤하여 **deploy/netlify** 행의 **Details** 링크를 클릭하고 Netlify 미리보기 빌드의 변경 사항을 확인
+    - **Conversation** 탭의 맨 아래에 있는 PR의 빌드 확인 섹션으로 스크롤하여 Netlify 미리보기 빌드의 변경 사항을 확인. 
+      다음은 스크린샷이다(GitHub 데스크탑 사이트이며, 
+      태블릿 또는 스마트폰 장치에서 리뷰하는 경우 GitHub 웹 UI가 약간 다르다).
+      {{< figure src="/images/docs/github_netlify_deploy_preview.png" alt="Netlify 미리보기 링크를 포함하는 GitHub PR 상세 사항" >}}
+      미리보기를 열려면, 체크 목록의 **deploy/netlify** 행의 **Details** 링크를 클릭한다.

 4.  **Files changed** 탭으로 이동하여 리뷰를 시작한다.
    1. 코멘트을 달려는 줄 옆에 있는 `+` 기호를 클릭한다.