Sixth Korean l10n work for release 1.18

- Update outdated files in dev-1.18-ko.6 partly (#21714) - Translate StorageClass to Korean word (#21805) - Translate StatefulSet to Korean word in pods.md (#21794) - Translate tasks/run-application/delete-stateful-set/ in Korean (#21686) - Translate tasks/administer-cluster/change-default-storage-class in Korean (#21801) - update outdated docs (#21940) - Modify spacing term StatefulSet in Korean (#21871) - Translate /tasks/administer-cluster/coredns in Korean (#21876) - Fix typo in k8s.io/ko/docs/contribute/new-content/new-content/ (#21975) - Translation error correction in /concepts/containers/runtime-class.md (#21868) - Translate tasks/tls/certificate-rotation/ in Korean (#21838) - Translate /tasks/configure-pod-container/static-pod in Korean (#21798) - Update to Outdated files in the dev-1.18-ko.6 branch - (1/4) (#21911) - Fix English bugs in Korean documentation (#21994) - Update outdated dev-1.18-ko.6 partly (#22067) Co-authored-by: Jerry Park <jaehwa@gmail.com> Co-authored-by: PyungHo Yoon <learder@gmail.com> Co-authored-by: Yuk, Yongsu <ysyukr@gmail.com> Co-authored-by: Jerry Park <jaehwa@gmail.com> Co-authored-by: Seokho Son <shsongist@gmail.com> Co-authored-by: Jordy Ruiter <jordy.ruiter@gmail.com> Co-authored-by: bluefriday <bluefriday86@gmail.com> Co-authored-by: Dajin Gwon <d.gweon@samsung.com> Co-authored-by: Hyungseok Lee <hs0426.lee@samsung.com> Co-authored-by: Jihoon Seo <jihoon.seo@etri.re.kr> Co-authored-by: coolguyhong <podolsmith@naver.com> Co-authored-by: jmyung <jesang.myung@gmail.com> Co-authored-by: June Yi <june.yi@samsung.com>
2020-06-14 01:11:06 +09:00
parent a78456d87c
commit 34be3c1d39
133 changed files with 2074 additions and 1226 deletions
@@ -29,19 +29,19 @@ API 오브젝트를 기반으로 한다. 클러스터 관리자는 볼륨을 프
 클러스터 관리자는 클러스터 내에서 사용자 정의 파라미터 집합을
 사용해서 여러 가지 유형의 스토리지 (같거나 다른 스토리지 시스템들)를
 정의하고 노출시킬 수 있다. 또한 이 디자인을 통해 최종 사용자는
-스토리지 프로비전 방식의 복잡성과 뉘앙스에 대해 걱정할 필요가 없다. 하지만, 
+스토리지 프로비전 방식의 복잡성과 뉘앙스에 대해 걱정할 필요가 없다. 하지만,
 여전히 여러 스토리지 옵션들을 선택할 수 있다.

-스토리지 클래스에 대한 자세한 정보는 
-[여기](/docs/concepts/storage/storage-classes/)에서 찾을 수 있다.
+스토리지 클래스에 대한 자세한 정보는
+[여기](/ko/docs/concepts/storage/storage-classes/)에서 찾을 수 있다.

 ## 동적 프로비저닝 활성화하기

-동적 프로비저닝을 활성화하려면 클러스터 관리자가 사용자를 위해 하나 이상의 StorageClass
+동적 프로비저닝을 활성화하려면 클러스터 관리자가 사용자를 위해 하나 이상의 스토리지클래스(StorageClass)
 오브젝트를 사전 생성해야 한다.
-StorageClass 오브젝트는 동적 프로비저닝이 호출될 때 사용할 프로비저너와
+스토리지클래스 오브젝트는 동적 프로비저닝이 호출될 때 사용할 프로비저너와
 해당 프로비저너에게 전달할 파라미터를 정의한다.
-StorageClass 오브젝트의 이름은 유효한
+스토리지클래스 오브젝트의 이름은 유효한
 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.

 다음 매니페스트는 표준 디스크와 같은 퍼시스턴트 디스크를 프로비전하는
@@ -117,7 +117,7 @@ spec:
 작성하면, `DefaultStorageClass` 어드미션 컨트롤러가 디폴트
 스토리지 클래스를 가리키는 `storageClassName` 필드를 자동으로 추가한다.

-클러스터에는 최대 하나의 *default* 스토리지 클래스가 있을 수 있다. 그렇지 않은 경우 
+클러스터에는 최대 하나의 *default* 스토리지 클래스가 있을 수 있다. 그렇지 않은 경우
 `storageClassName` 을 명시적으로 지정하지 않은 `PersistentVolumeClaim` 을
 생성할 수 없다.

@@ -125,7 +125,6 @@ spec:

 [다중 영역](/ko/docs/setup/best-practices/multiple-zones/) 클러스터에서 파드는 한 지역 내
 여러 영역에 걸쳐 분산될 수 있다. 파드가 예약된 영역에서 단일 영역 스토리지 백엔드를
-프로비전 해야 한다. [볼륨 바인딩 모드](/docs/concepts/storage/storage-classes/#volume-binding-mode)를
+프로비전해야 한다. [볼륨 바인딩 모드](/ko/docs/concepts/storage/storage-classes/#볼륨-바인딩-모드)를
 설정해서 수행할 수 있다.

-
@@ -22,7 +22,7 @@ weight: 20

 스토리지 관리는 컴퓨트 인스턴스 관리와는 별개의 문제다. 퍼시스턴트볼륨 서브시스템은 사용자 및 관리자에게 스토리지 사용 방법에서부터 스토리지가 제공되는 방법에 대한 세부 사항을 추상화하는 API를 제공한다. 이를 위해 퍼시스턴트볼륨 및 퍼시스턴트볼륨클레임이라는 두 가지 새로운 API 리소스를 소개한다.

-_퍼시스턴트볼륨_ (PV)은 관리자가 프로비저닝하거나 [스토리지 클래스](/docs/concepts/storage/storage-classes/)를 사용하여 동적으로 프로비저닝한 클러스터의 스토리지이다. 노드가 클러스터 리소스인 것처럼 PV는 클러스터 리소스이다. PV는 Volumes와 같은 볼륨 플러그인이지만, PV를 사용하는 개별 파드와는 별개의 라이프사이클을 가진다. 이 API 오브젝트는 NFS, iSCSI 또는 클라우드 공급자별 스토리지 시스템 등 스토리지 구현에 대한 세부 정보를 담아낸다.
+_퍼시스턴트볼륨_ (PV)은 관리자가 프로비저닝하거나 [스토리지 클래스](/ko/docs/concepts/storage/storage-classes/)를 사용하여 동적으로 프로비저닝한 클러스터의 스토리지이다. 노드가 클러스터 리소스인 것처럼 PV는 클러스터 리소스이다. PV는 Volumes와 같은 볼륨 플러그인이지만, PV를 사용하는 개별 파드와는 별개의 라이프사이클을 가진다. 이 API 오브젝트는 NFS, iSCSI 또는 클라우드 공급자별 스토리지 시스템 등 스토리지 구현에 대한 세부 정보를 담아낸다.

 _퍼시스턴트볼륨클레임_ (PVC)은 사용자의 스토리지에 대한 요청이다. 파드와 비슷하다. 파드는 노드 리소스를 사용하고 PVC는 PV 리소스를 사용한다. 파드는 특정 수준의 리소스(CPU 및 메모리)를 요청할 수 있다. 클레임은 특정 크기 및 접근 모드를 요청할 수 있다(예: 한 번 읽기/쓰기 또는 여러 번 읽기 전용으로 마운트 할 수 있음).

@@ -47,7 +47,7 @@ PV를 프로비저닝 할 수 있는 두 가지 방법이 있다: 정적(static)
 관리자가 생성한 정적 PV가 사용자의 퍼시스턴트볼륨클레임과 일치하지 않으면
 클러스터는 PVC를 위해 특별히 볼륨을 동적으로 프로비저닝 하려고 시도할 수 있다.
 이 프로비저닝은 스토리지클래스를 기반으로 한다. PVC는
-[스토리지 클래스](/docs/concepts/storage/storage-classes/)를
+[스토리지 클래스](/ko/docs/concepts/storage/storage-classes/)를
 요청해야 하며 관리자는 동적 프로비저닝이 발생하도록 해당 클래스를 생성하고 구성해야 한다.
 `""` 클래스를 요청하는 클레임은 동적 프로비저닝을 효과적으로
 비활성화한다.
@@ -244,7 +244,7 @@ FlexVolume의 크기 조정은 기본 드라이버가 크기 조정을 지원하
 {{< /note >}}

 {{< note >}}
-EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마다 한 번의 수정을 할 수 있는 볼륨별 쿼터(quota)가 있다.
+EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마다 한 번의 수정을 할 수 있는 볼륨별 쿼터가 있다.
 {{< /note >}}


@@ -376,7 +376,7 @@ CLI에서 접근 모드는 다음과 같이 약어로 표시된다.
 ### 클래스

 PV는 `storageClassName` 속성을
-[스토리지클래스](/docs/concepts/storage/storage-classes/)의
+[스토리지클래스](/ko/docs/concepts/storage/storage-classes/)의
 이름으로 설정하여 지정하는 클래스를 가질 수 있다.
 특정 클래스의 PV는 해당 클래스를 요청하는 PVC에만 바인딩될 수 있다.
 `storageClassName`이 없는 PV에는 클래스가 없으며 특정 클래스를 요청하지 않는 PVC에만
@@ -449,8 +449,7 @@ CLI는 PV에 바인딩된 PVC의 이름을 표시한다.

 각 PVC에는 스펙과 상태(클레임의 명세와 상태)가 포함된다.
 퍼시스턴트볼륨클레임 오브젝트의 이름은 유효한
-[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야
-한다.
+[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.

 ```yaml
 apiVersion: v1
@@ -496,7 +495,7 @@ spec:
 ### 클래스

 클레임은 `storageClassName` 속성을 사용하여
-[스토리지클래스](/docs/concepts/storage/storage-classes/)의 이름을 지정하여
+[스토리지클래스](/ko/docs/concepts/storage/storage-classes/)의 이름을 지정하여
 특정 클래스를 요청할 수 있다.
 요청된 클래스의 PV(PVC와 동일한 `storageClassName`을 갖는 PV)만 PVC에
 바인딩될 수 있다.
@@ -747,7 +746,7 @@ spec:

 * [퍼시스턴트볼륨 생성](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume)에 대해 자세히 알아보기
 * [퍼시스턴트볼륨클레임 생성](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolumeclaim)에 대해 자세히 알아보기
-* [퍼시스턴트 스토리지 설계 문서](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md) 읽기
+* [퍼시스턴트 스토리지 설계 문서](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md) 읽어보기

 ### 참고

@@ -755,4 +754,3 @@ spec:
 * [PersistentVolumeSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumespec-v1-core)
 * [퍼시스턴트볼륨클레임](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core)
 * [PersistentVolumeClaimSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaimspec-v1-core)
-
@@ -162,8 +162,8 @@ CSI | 1.14 (alpha), 1.16 (beta)
 클러스터 관리자는 `WaitForFirstConsumer` 모드를 지정해서 이 문제를 해결할 수 있는데
 이 모드는 퍼시스턴트볼륨클레임을 사용하는 파드가 생성될 때까지 퍼시스턴트볼륨의 바인딩과 프로비저닝을 지연시킨다.
 퍼시스턴트볼륨은 파드의 스케줄링 제약 조건에 의해 지정된 토폴로지에
-따라 선택되거나 프로비전된다. 여기에는 [리소스
-요구 사항](/docs/concepts/configuration/manage-compute-resources-container/),
+따라 선택되거나 프로비전된다. 여기에는
+[리소스 요구 사항](/ko/docs/concepts/configuration/manage-resources-containers/),
 [노드 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-셀렉터-nodeselector),
 [파드 어피니티(affinity)와
 안티-어피니티(anti-affinity)](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity)
@@ -816,4 +816,3 @@ volumeBindingMode: WaitForFirstConsumer
 적절한 퍼시스턴트볼륨을 선택할 때 파드의 모든 스케줄링
 제약 조건을 고려할 수 있다.

-
@@ -6,8 +6,7 @@ weight: 30

 <!-- overview -->

-이 문서에서는 쿠버네티스의 기존 CSI 볼륨 복제의 개념을 설명한다.  [볼륨]
-(/ko/docs/concepts/storage/volumes)을 숙지하는 것을 추천한다.
+이 문서에서는 쿠버네티스의 기존 CSI 볼륨 복제의 개념을 설명한다. [볼륨](/ko/docs/concepts/storage/volumes)을 숙지하는 것을 추천한다.



@@ -7,8 +7,8 @@ weight: 30
 <!-- overview -->

 이 문서는 쿠버네티스의 `VolumeSnapshotClass` 개요를 설명한다.
-[볼륨 스냅샷](/docs/concepts/storage/volume-snapshots/)과
-[스토리지 클래스](/docs/concepts/storage/storage-classes)의 숙지를 추천한다.
+[볼륨 스냅샷](/ko/docs/concepts/storage/volume-snapshots/)과
+[스토리지 클래스](/ko/docs/concepts/storage/storage-classes)의 숙지를 추천한다.



@@ -32,7 +32,7 @@ weight: 30
 처음 생성할 때 클래스의 이름과 기타 파라미터를 설정하고, 오브젝트가
 생성된 이후에는 업데이트할 수 없다.

-관리자는 특정 클래스의 바인딩을 요청하지 않는 VolumeSnapshots에만
+관리자는 특정 클래스의 바인딩을 요청하지 않는 볼륨스냅샷에만
 기본 `VolumeSnapshotClass` 를 지정할 수 있다.

 ```yaml
@@ -40,14 +40,14 @@ apiVersion: snapshot.storage.k8s.io/v1beta1
 kind: VolumeSnapshotClass
 metadata:
  name: csi-hostpath-snapclass
-driver: hostpath.csi.k8s.io 
+driver: hostpath.csi.k8s.io
 deletionPolicy: Delete
 parameters:
 ```

 ### 드라이버

-볼륨 스냅샷 클래스에는 VolumeSnapshots의 프로비저닝에 사용되는 CSI 볼륨 플러그인을
+볼륨 스냅샷 클래스에는 볼륨스냅샷의 프로비저닝에 사용되는 CSI 볼륨 플러그인을
 결정하는 드라이버를 가지고 있다. 이 필드는 반드시 지정해야한다.

 ### 삭제정책(DeletionPolicy)
@@ -61,5 +61,3 @@ parameters:
 볼륨 스냅샷 클래스에는 볼륨 스냅샷 클래스에 속하는 볼륨 스냅샷을
 설명하는 파라미터를 가지고 있다. `driver` 에 따라 다른 파라미터를 사용할
 수 있다.
-
-
@@ -41,8 +41,7 @@ API 리소스 `PersistentVolume` 및 `PersistentVolumeClaim` 가 사용자 및
 스냅샷을 프로비저닝할 수 있는 방법에는 사전 프로비저닝 혹은 동적 프로비저닝의 두 가지가 있다: .

 #### 사전 프로비전 {#static}
-클러스터 관리자는 많은 `VolumeSnapshotContents` 을 생성한다. 그들은 클러스터 사용자들이 사용 가능한 스토리지 시스템의 실제 볼륨 스냅샷 세부 정보를 제공한다.
-이것은 쿠버네티스 API에 있고 사용 가능하다.
+클러스터 관리자는 많은 `VolumeSnapshotContents` 을 생성한다. 그들은 클러스터 사용자들이 사용 가능한 스토리지 시스템의 실제 볼륨 스냅샷 세부 정보를 제공한다. 이것은 쿠버네티스 API에 있고 사용 가능하다.

 #### 동적
 사전 프로비저닝을 사용하는 대신 퍼시스턴트볼륨클레임에서 스냅샷을 동적으로 가져오도록 요청할 수 있다. [볼륨스냅샷클래스](/docs/concepts/storage/volume-snapshot-classes/)는 스냅샷 사용 시 스토리지 제공자의 특정 파라미터를 명세한다.
@@ -451,15 +451,13 @@ spec:
 ```

 #### 지역(Regional) 퍼시스턴트 디스크
-{{< feature-state for_k8s_version="v1.10" state="beta" >}}
-
 [지역(Regional) 퍼시스턴트 디스크](https://cloud.google.com/compute/docs/disks/#repds) 기능을 사용하면 동일한 영역 내의 두 영역에서 사용할 수 있는 퍼시스턴트 디스크를 생성할 수 있다. 이 기능을 사용하려면 볼륨을 퍼시스턴트볼륨으로 프로비저닝 해야 한다. 파드에서 직접 볼륨을 참조하는 것은 지원되지 않는다.

 #### 지역(Regional) PD 퍼시스턴트볼륨을 수동으로 프로비저닝하기
-[GCE PD 용 StorageClass](/docs/concepts/storage/storage-classes/#gce) 를 사용해서 동적 프로비저닝이 가능하다.
+[GCE PD용 스토리지클래스](/ko/docs/concepts/storage/storage-classes/#gce-pd)를 사용해서 동적 프로비저닝이 가능하다.
 PersistentVolume을 생성하기 전에 PD를 생성해야만 한다.
 ```shell
-gcloud beta compute disks create --size=500GB my-data-disk
+gcloud compute disks create --size=500GB my-data-disk
    --region us-central1
    --replica-zones us-central1-a,us-central1-b
 ```
@@ -470,8 +468,6 @@ apiVersion: v1
 kind: PersistentVolume
 metadata:
  name: test-volume
-  labels:
-    failure-domain.beta.kubernetes.io/zone: us-central1-a__us-central1-b
 spec:
  capacity:
    storage: 400Gi
@@ -480,6 +476,15 @@ spec:
  gcePersistentDisk:
    pdName: my-data-disk
    fsType: ext4
+      nodeAffinity:
+    required:
+      nodeSelectorTerms:
+      - matchExpressions:
+        - key: failure-domain.beta.kubernetes.io/zone
+          operator: In
+          values:
+          - us-central1-a
+          - us-central1-b
 ```

 #### CSI 마이그레이션
@@ -574,12 +579,13 @@ glusterfs 볼륨에 데이터를 미리 채울 수 있으며, 파드간에 데
 다음과 같은 이유로 이 유형의 볼륨 사용시 주의해야 한다.

 * 동일한 구성(파드템플릿으로 생성한 것과 같은)을
-  가진 파드는 노드에 있는 파일이 다르기 때문에 노드마다 다르게 동작할 수 있음
+  가진 파드는 노드에 있는 파일이 다르기 때문에 노드마다 다르게 동작할 수 있다.
 * 쿠버네티스가 계획한 대로 리소스 인식 스케줄링을 추가하면 `hostPath` 에서
-  사용되는 리소스를 설명할 수 없음
-* 기본 호스트에 생성된 파일 또는 디렉터리는 root만 쓸 수 있다. 프로세스를
-  [특권 컨테이너](/docs/user-guide/security-context) 에서 루트로 실행하거나
-  `hostPath` 볼륨에 쓸 수 있도록 호스트의 파일 권한을 수정해야 함
+  사용되는 리소스를 설명할 수 없다.
+* 기본 호스트에 생성된 파일 또는 디렉터리는 root만 쓸 수 있다.
+  프로세스를 [특권을 가진(privileged) 컨테이너](/docs/user-guide/security-context)에서
+  루트로 실행하거나
+  `hostPath` 볼륨에 쓸 수 있도록 호스트의 파일 권한을 수정해야 한다.

 #### 파드 예시

@@ -714,7 +720,7 @@ spec:

 로컬 볼륨을 사용할 때는 `volumeBindingMode` 가 `WaitForFirstConsumer` 로 설정된
 스토리지클래스(StorageClass)를 생성하는 것을 권장한다.
-[예시](/docs/concepts/storage/storage-classes/#local)를 본다. 볼륨 바인딩을 지연시키는 것은
+[예시](/ko/docs/concepts/storage/storage-classes/#local)를 본다. 볼륨 바인딩을 지연시키는 것은
 퍼시스턴트볼륨클래임 바인딩 결정도 노드 리소스 요구사항, 노드 셀렉터,
 파드 어피니티 그리고 파드 안티 어피니티와
 같이 파드가 가질 수 있는 다른 노드 제약 조건으로 평가되도록 만든다.
@@ -1473,4 +1479,3 @@ sudo systemctl restart docker
 ## {{% heading "whatsnext" %}}

 * [퍼시스턴트 볼륨과 함께 워드프레스와 MySQL 배포하기](/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/)의 예시를 따른다.
-