From ce19161d60bb5b206f74a582fd90b2b7ccf161ae Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Wed, 16 Feb 2022 12:05:47 +0900 Subject: [PATCH] [ko] Update outdated files in dev-1.23-ko.2 M25-39 --- .../service-traffic-policy.md | 8 ++-- .../concepts/services-networking/service.md | 30 +++++++------ .../concepts/storage/persistent-volumes.md | 38 ++++++++++------ .../docs/concepts/storage/storage-classes.md | 4 +- .../storage/volume-snapshot-classes.md | 4 ++ content/ko/docs/concepts/storage/volumes.md | 3 +- .../workloads/controllers/deployment.md | 43 ++++++++++++++----- .../concepts/workloads/controllers/job.md | 4 +- content/ko/docs/contribute/advanced.md | 8 ++-- .../participate/roles-and-responsibilities.md | 9 ++-- .../docs/contribute/review/for-approvers.md | 2 +- .../docs/contribute/review/reviewing-prs.md | 6 ++- 12 files changed, 103 insertions(+), 56 deletions(-) diff --git a/content/ko/docs/concepts/services-networking/service-traffic-policy.md b/content/ko/docs/concepts/services-networking/service-traffic-policy.md index 8088d05366..34e6b3df39 100644 --- 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 -{{< 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 index db1c510ed0..e69f7ac48e 100644 --- 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 index e8d9e083e4..6dc8f17dcc 100644 --- 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 index c47f053a31..4fff50dced 100644 --- 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 index 594d100772..849a83a98e 100644 --- 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 index a4245a7daa..afa53d1950 100644 --- 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 index e9725d2eea..f4b1aca642 100644 --- 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 index b71a4b5934..f8b311e0f3 100644 --- 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 index fc2e9c5230..9b4f8835e3 100644 --- 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시간 이상(대부분 더)을 역할에 책임진다. ### 책임 diff --git a/content/ko/docs/contribute/participate/roles-and-responsibilities.md b/content/ko/docs/contribute/participate/roles-and-responsibilities.md index 8306f824e9..091dac7059 100644 --- 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의 리뷰어 자격에 반드시 별도로 지원해야 한다. 지원하려면, 다음을 수행한다. diff --git a/content/ko/docs/contribute/review/for-approvers.md b/content/ko/docs/contribute/review/for-approvers.md index 691530b98e..401f9c2572 100644 --- 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을 닫는다. diff --git a/content/ko/docs/contribute/review/reviewing-prs.md b/content/ko/docs/contribute/review/reviewing-prs.md index 83710d2a88..e6bb3dc84c 100644 --- 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. 코멘트을 달려는 줄 옆에 있는 `+` 기호를 클릭한다.