Skip to content

Commit ce19161

Browse files
jihoon-seojihoon-seo
committed
[ko] Update outdated files in dev-1.23-ko.2 M25-39
1 parent b7e6cf5 commit ce19161

File tree

12 files changed

+103
-56
lines changed

12 files changed

+103
-56
lines changed

‎content/ko/docs/concepts/services-networking/service-traffic-policy.md

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -9,7 +9,7 @@ weight: 45
99

1010
<!-- overview -->
1111

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

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

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

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

‎content/ko/docs/concepts/services-networking/service.md

Lines changed: 17 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -449,11 +449,8 @@ kube-proxy는 마치 외부 트래픽 정책이 `Cluster`로 설정되어 있는
449449

450450
### 환경 변수
451451

452-
파드가 노드에서 실행될 때, kubelet은 각 활성화된 서비스에 대해
453-
환경 변수 세트를 추가한다. [도커 링크
454-
호환](https://docs.docker.com/userguide/dockerlinks/) 변수 ([makeLinkVariables](https://github.com/kubernetes/kubernetes/blob/dd2d12f6dc0e654c15d5db57a5f9f6ba61192726/pkg/kubelet/envvars/envvars.go#L72) 참조)와
455-
보다 간단한 `{SVCNAME}_SERVICE_HOST` 및 `{SVCNAME}_SERVICE_PORT` 변수를 지원하고,
456-
이때 서비스 이름은 대문자이고 대시는 밑줄로 변환된다.
452+
파드가 노드에서 실행될 때, kubelet은 각 활성화된 서비스에 대해 환경 변수 세트를 추가한다.
453+
`{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) 참조)도 지원한다.
457454

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

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

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

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

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

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

704-
`spec.loadBalancerClass` 필드를 설정하여 클라우드 제공자가 설정한 기본값 이외의 로드 밸런서 구현을 사용할 수 있다. 이 기능은 v1.21부터 사용할 수 있으며, v1.21에서는 이 필드를 사용하기 위해 `ServiceLoadBalancerClass` 기능 게이트를 활성화해야 하지만, v1.22부터는 해당 기능 게이트가 기본적으로 활성화되어 있다.
706+
`spec.loadBalancerClass` 필드를 설정하여 클라우드 제공자가 설정한 기본값 이외의 로드 밸런서 구현을 사용할 수 있다.
707+
이 필드를 사용하기 위해서는 클러스터에 `ServiceLoadBalancerClass` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있어야 한다.
708+
쿠버네티스 v{{< skew currentVersion >}}에서, 이 기능 게이트는 기본적으로 활성화되어 있다. 다른 버전의 쿠버네티스를 실행하는 클러스터에 대해서는, 해당 릴리스의 문서를 참조한다.
705709
기본적으로, `spec.loadBalancerClass` 는 `nil` 이고,
706710
클러스터가 클라우드 제공자의 로드밸런서를 이용하도록 `--cloud-provider` 컴포넌트 플래그를 이용하여 설정되어 있으면
707711
`LoadBalancer` 유형의 서비스는 클라우드 공급자의 기본 로드 밸런서 구현을 사용한다.

‎content/ko/docs/concepts/storage/persistent-volumes.md

Lines changed: 24 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -254,6 +254,16 @@ PVC에 대해 더 큰 볼륨을 요청하려면 PVC 오브젝트를 수정하여
254254
지정한다. 이는 기본 퍼시스턴트볼륨을 지원하는 볼륨의 확장을 트리거한다. 클레임을 만족시키기 위해
255255
새로운 퍼시스턴트볼륨이 생성되지 않고 기존 볼륨의 크기가 조정된다.
256256

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

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

413423
### 용량
414424

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

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

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

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

528-
* AWSElasticBlockStore
529-
* AzureDisk
530-
* AzureFile
531-
* CephFS
532-
* Cinder (OpenStack 블록 스토리지)
533-
* GCEPersistentDisk
534-
* Glusterfs
535-
* NFS
536-
* Quobyte Volumes
537-
* RBD (Ceph Block Device)
538-
* StorageOS
539-
* VsphereVolume
540-
* iSCSI
538+
* `awsElasticBlockStore`
539+
* `azureDisk`
540+
* `azureFile`
541+
* `cephfs`
542+
* `cinder` (v1.18에서 **사용 중단됨**)
543+
* `gcePersistentDisk`
544+
* `glusterfs`
545+
* `iscsi`
546+
* `nfs`
547+
* `quobyte` (v1.22에서 **사용 중단됨**)
548+
* `rbd`
549+
* `storageos` (v1.22에서 **사용 중단됨**)
550+
* `vsphereVolume`
541551

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

‎content/ko/docs/concepts/storage/storage-classes.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -434,7 +434,7 @@ provisioner: example.com/external-nfs
434434
parameters:
435435
server: nfs-server.example.com
436436
path: /share
437-
readOnly: false
437+
readOnly: "false"
438438
```
439439

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

‎content/ko/docs/concepts/storage/volume-snapshot-classes.md

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -39,6 +39,10 @@ weight: 41 # just after volume snapshots
3939
처음 생성할 때 클래스의 이름과 기타 파라미터를 설정하고, 오브젝트가
4040
생성된 이후에는 업데이트할 수 없다.
4141

42+
{{< note >}}
43+
CRD의 설치는 쿠버네티스 배포판의 책임이다. 필요한 CRD가 존재하지 않는다면, 볼륨스냅샷클래스 생성이 실패할 것이다.
44+
{{< /note >}}
45+
4246
```yaml
4347
apiVersion: snapshot.storage.k8s.io/v1
4448
kind: VolumeSnapshotClass

‎content/ko/docs/concepts/storage/volumes.md

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -859,7 +859,7 @@ RBD는 읽기-쓰기 모드에서 단일 고객만 마운트할 수 있다.
859859
드라이버로 리다이렉트한다.
860860
이 기능을 사용하려면, 클러스터에
861861
[Ceph CSI 드라이버](https://github.com/ceph/ceph-csi)가 설치되어 있고
862-
`CSIMigration`, `CSIMigrationRBD`
862+
`CSIMigration`, `csiMigrationRBD`
863863
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있어야 한다.
864864

865865
{{< note >}}
@@ -1133,6 +1133,7 @@ spec:
11331133
volumeMounts:
11341134
- name: workdir1
11351135
mountPath: /logs
1136+
# 변수 확장에는 괄호를 사용한다(중괄호 아님).
11361137
subPathExpr: $(POD_NAME)
11371138
restartPolicy: Never
11381139
volumes:

‎content/ko/docs/concepts/workloads/controllers/deployment.md

Lines changed: 32 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -842,6 +842,13 @@ nginx-deployment-618515232 11 11 11 7m
842842
* 디플로이먼트로 기존 레플리카셋을 스케일 다운.
843843
* 새 파드가 준비되거나 이용할 수 있음(최소 [준비 시간(초)](#최소-대기-시간-초) 동안 준비됨).
844844

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

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

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

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

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

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

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

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

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

9891010
```
9901011
Conditions:
@@ -994,11 +1015,11 @@ Conditions:
9941015
Progressing True NewReplicaSetAvailable
9951016
```
9961017

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

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

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

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

‎content/ko/docs/concepts/workloads/controllers/job.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -615,8 +615,8 @@ spec:
615615
```
616616

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

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

‎content/ko/docs/contribute/advanced.md

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -110,22 +110,22 @@ SIG Docs [리뷰어](/ko/docs/contribute/participate/roles-and-responsibilities/
110110

111111
## SIG 공동 의장으로 봉사
112112

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

116116
### 전제 조건
117117

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

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

131131
### 책임

0 commit comments

Comments
 (0)