kubernetes · k8s-ci-robot · Mar 31, 2022 · Feb 16, 2022
diff --git 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가 클러스터 내부 트래픽을 위해 노드 내부 엔드포인트로만 사용하도록 한다.

diff --git 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` 유형의 서비스는 클라우드 공급자의 기본 로드 밸런서 구현을 사용한다.

diff --git 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`
 
 마운트 옵션의 유효성이 검사되지 않는다. 마운트 옵션이 유효하지 않으면, 마운트가 실패한다.
 

diff --git 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
 ```
 

diff --git 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

diff --git 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:

diff --git 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(초)이다.
 미래에 자동화된 롤백이 구현된다면 디플로이먼트 컨트롤러는 상태를 관찰하고,

diff --git 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)를 이용한 잡 추적
 

diff --git a/content/ko/docs/contribute/advanced.md b/content/ko/docs/contribute/advanced.md
@@ -110,22 +110,22 @@ 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),
   [k/test-infra](https://github.com/kubernetes/test-infra/)의 플러그인 및
   [SIG 아키텍처](https://github.com/kubernetes/community/tree/master/sig-architecture)의
   역할을 포함하여 다른 쿠버네티스 SIG와 리포지터리가 SIG Docs 워크플로에 미치는
   영향을 이해한다.
+  추가로, [쿠버네티스 문서 릴리스 프로세스](/ko/docs/contribute/advanced/#쿠버네티스-릴리스를-위한-문서-조정)가 어떻게 동작하는지 이해한다.
+- SIG Docs 커뮤니티에 이해 직접적으로 또는 lazy consensus(특정 기간 내에 아무런 의견이 없으면 통과)를 통해 승인된다.
 - 최소 6개월 동안 일주일에 5시간 이상(대부분 더)을 역할에 책임진다.
 
 ### 책임