From a9d321f74528cfbeaeb1c27e36af05c08953183b Mon Sep 17 00:00:00 2001 From: mocha-123 Date: Sat, 25 Feb 2023 19:22:42 +0900 Subject: [PATCH] [ko] Update outdated files in dev-1.26-ko.1 (M70-M81) --- .../concepts/storage/dynamic-provisioning.md | 9 +- .../concepts/storage/persistent-volumes.md | 83 ++++++++-- .../concepts/storage/projected-volumes.md | 18 ++- .../docs/concepts/storage/storage-capacity.md | 2 +- .../docs/concepts/storage/storage-classes.md | 85 +---------- .../docs/concepts/storage/storage-limits.md | 1 + .../storage/volume-health-monitoring.md | 1 + .../concepts/storage/volume-pvc-datasource.md | 2 +- .../storage/volume-snapshot-classes.md | 2 +- .../docs/concepts/storage/volume-snapshots.md | 142 ++++++++++++------ content/ko/docs/concepts/storage/volumes.md | 89 ++++++----- .../docs/concepts/storage/windows-storage.md | 7 +- 12 files changed, 256 insertions(+), 185 deletions(-) diff --git a/content/ko/docs/concepts/storage/dynamic-provisioning.md b/content/ko/docs/concepts/storage/dynamic-provisioning.md index e6898ebc66aa2..f4c5fa97dfa86 100644 --- a/content/ko/docs/concepts/storage/dynamic-provisioning.md +++ b/content/ko/docs/concepts/storage/dynamic-provisioning.md @@ -6,7 +6,7 @@ # - msau42 title: 동적 볼륨 프로비저닝 content_type: concept -weight: 40 +weight: 50 --- @@ -19,9 +19,6 @@ weight: 40 스토리지를 사전 프로비저닝 할 필요가 없다. 대신 사용자가 스토리지를 요청하면 자동으로 프로비저닝 한다. - - - ## 배경 @@ -115,8 +112,8 @@ spec: - API 서버에서 [`DefaultStorageClass` 어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)를 사용하도록 설정한다. -관리자는 `storageclass.kubernetes.io/is-default-class` [어노테이션](/ko/docs/reference/labels-annotations-taints/#storageclass-kubernetes-io-is-default-class)을 -추가해서 특정 `StorageClass` 를 기본으로 표시할 수 있다. +관리자는 [`storageclass.kubernetes.io/is-default-class` 어노테이션](/ko/docs/reference/labels-annotations-taints/#storageclass-kubernetes-io-is-default-class)을 +추가하여 특정 `StorageClass` 를 기본으로 표시할 수 있다. 기본 `StorageClass` 가 클러스터에 존재하고 사용자가 `storageClassName` 를 지정하지 않은 `PersistentVolumeClaim` 을 작성하면, `DefaultStorageClass` 어드미션 컨트롤러가 디폴트 diff --git a/content/ko/docs/concepts/storage/persistent-volumes.md b/content/ko/docs/concepts/storage/persistent-volumes.md index e66e4fe6175d6..dcf730e12dfe7 100644 --- a/content/ko/docs/concepts/storage/persistent-volumes.md +++ b/content/ko/docs/concepts/storage/persistent-volumes.md @@ -297,18 +297,17 @@ spec: * {{< glossary_tooltip text="csi" term_id="csi" >}} * flexVolume (deprecated) * gcePersistentDisk -* glusterfs * rbd * portworxVolume 스토리지 클래스의 `allowVolumeExpansion` 필드가 true로 설정된 경우에만 PVC를 확장할 수 있다. -``` yaml +```yaml apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: - name: gluster-vol-default -provisioner: kubernetes.io/glusterfs + name: example-vol-default +provisioner: vendor-name.example/magicstorage parameters: resturl: "http://192.168.10.100:8080" restuser: "" @@ -333,7 +332,7 @@ PVC에 대해 더 큰 볼륨을 요청하려면 PVC 오브젝트를 수정하여 #### CSI 볼륨 확장 -{{< feature-state for_k8s_version="v1.16" state="beta" >}} +{{< feature-state for_k8s_version="v1.24" state="stable" >}} CSI 볼륨 확장 지원은 기본적으로 활성화되어 있지만 볼륨 확장을 지원하려면 특정 CSI 드라이버도 필요하다. 자세한 내용은 특정 CSI 드라이버 문서를 참고한다. @@ -438,8 +437,6 @@ PVC 확장 실패의 사용자에 의한 복구는 쿠버네티스 1.23부터 (v1.23에서 **사용 중단**) * [`gcePersistentDisk`](/ko/docs/concepts/storage/volumes/#gcepersistentdisk) - GCE Persistent Disk (v1.17에서 **사용 중단**) -* [`glusterfs`](/ko/docs/concepts/storage/volumes/#glusterfs) - Glusterfs 볼륨 - (v1.25에서 **사용 중단**) * [`portworxVolume`](/ko/docs/concepts/storage/volumes/#portworxvolume) - Portworx 볼륨 (v1.25에서 **사용 중단**) * [`vsphereVolume`](/ko/docs/concepts/storage/volumes/#vspherevolume) - vSphere VMDK 볼륨 @@ -616,7 +613,6 @@ PV는 `storageClassName` 속성을 * `cephfs` * `cinder` (v1.18에서 **사용 중단됨**) * `gcePersistentDisk` -* `glusterfs` * `iscsi` * `nfs` * `rbd` @@ -745,10 +741,9 @@ AND 조건으로 동작한다. 요청된 클래스와 요청된 레이블이 있 #### 기본 스토리지클래스 할당 소급 적용하기 {#retroactive-default-storageclass-assignment} -{{< feature-state for_k8s_version="v1.25" state="alpha" >}} +{{< feature-state for_k8s_version="v1.26" state="beta" >}} 새로운 PVC를 위한 `storageClassName`을 설정하지 않고 퍼시스턴트볼륨클레임을 생성할 수 있으며, 이는 클러스터에 기본 스토리지클래스가 존재하지 않을 때에도 가능하다. 이 경우, 새로운 PVC는 정의된 대로 생성되며, 해당 PVC의 `storageClassName`은 기본값이 사용 가능해질 때까지 미설정 상태로 남는다. -하지만, [`RetroactiveDefaultStorageClass` 기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화하면 쿠버네티스는 다르게 동작하여, 기존에 존재하는 PVC 중 `storageClassName`가 설정되지 않은 PVC는 새로운 기본 스토리지클래스를 사용하도록 갱신된다. 기본 스토리지클래스가 사용 가능해지면, 컨트롤플레인은 `storageClassName`가 없는 PVC를 찾는다. `storageClassName`의 값이 비어있거나 해당 키 자체가 없는 PVC라면, 컨트롤플레인은 해당 PVC의 `storageClassName`가 새로운 기본 스토리지클래스와 일치하도록 설정하여 갱신한다. `storageClassName`가 `""`인 PVC가 있고, 기본 스토리지클래스를 설정한다면, 해당 PVC는 갱신되지 않는다. @@ -953,6 +948,25 @@ kube-apiserver와 kube-controller-manager에 대해 `AnyVolumeDataSource` 어떠한 오브젝트에 대한 참조도 명시할 수 있다(단, PVC 외의 다른 코어 오브젝트는 제외). 기능 게이트가 활성화된 클러스터에서는 `dataSource`보다 `dataSourceRef`를 사용하는 것을 권장한다. +## 네임스페이스를 교차하는 데이터 소스 +{{< feature-state for_k8s_version="v1.26" state="alpha" >}} + +쿠버네티스는 네임스페이스를 교차하는 볼륨 데이터 소스를 지원한다. +네임스페이스를 교차하는 볼륨 데이터 소스를 사용하기 위해서는, kube-apiserver, kube-controller-manager에 대해서 `AnyVolumeDataSource`와 `CrossNamespaceVolumeDataSource` +[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 +활성화해야 한다. +또한, csi-provisioner에 대한 `CrossNamespaceVolumeDataSource` 기능 게이트도 활성화해야 한다. + +`CrossNamespaceVolumeDataSource` 기능 게이트를 활성화하면 dataSourceRef 필드에 네임스페이스를 명시할 수 있다. +{{< note >}} +볼륨 데이터 소스의 네임스페이스를 명시하면, 쿠버네티스는 +참조를 받아들이기 전에 다른 네임스페이스의 레퍼런스그랜트를 확인한다. +레퍼런스그랜트는 `gateway.networking.k8s.io` 확장 API에 속한다. +자세한 정보는 게이트웨이 API 문서의 [레퍼런스그랜트](https://gateway-api.sigs.k8s.io/api-types/referencegrant/)를 참고하라. +즉 이 방법을 사용하려면 우선 게이트웨이 API에서 최소한 레퍼런스그랜트 이상을 사용하여 +쿠버네티스 클러스터를 확장해야 한다는 것을 의미한다. +{{< /note >}} + ## 데이터 소스 참조 `dataSourceRef` 필드는 `dataSource` 필드와 거의 동일하게 동작한다. @@ -970,6 +984,11 @@ kube-apiserver와 kube-controller-manager에 대해 `AnyVolumeDataSource` * `dataSourceRef` 필드는 여러 타입의 오브젝트를 포함할 수 있지만, `dataSource` 필드는 PVC와 VolumeSnapshot만 포함할 수 있다. +`CrossNamespaceVolumeDataSource` 기능이 활성화되어 있을 때, 추가적인 차이점이 존재한다: + +* `dataSource` 필드는 로컬 오브젝트만을 허용하지만, `dataSourceRef` 필드는 모든 네임스페이스의 오브젝트를 허용한다. +* 네임스페이스가 명시되어 있을 때, `dataSource`와 `dataSourceRef`는 동기화되지 않는다. + 기능 게이트가 활성화된 클러스터에서는 `dataSourceRef`를 사용해야 하고, 그렇지 않은 클러스터에서는 `dataSource`를 사용해야 한다. 어떤 경우에서든 두 필드 모두를 확인해야 할 필요는 없다. 이렇게 약간의 차이만 있는 중복된 값은 이전 버전 호환성을 위해서만 @@ -1010,6 +1029,50 @@ PVC 생성 상태에 대한 피드백을 제공하기 위해, PVC에 대한 이 PVC를 위한 적절한 파퓰레이터가 설치되어 있다면, 볼륨 생성과 그 과정에서 발생하는 이슈에 대한 이벤트를 생성하는 것은 파퓰레이터 컨트롤러의 몫이다. +### 네임스페이스를 교차하는 볼륨 데이터 소스 사용하기 +{{< feature-state for_k8s_version="v1.26" state="alpha" >}} + +네임스페이스 소유자가 참조를 받아들일 수 있도록 레퍼런스그랜트를 생성한다. +`dataSourceRef` 필드를 사용하여 네임스페이스를 교차하는 볼륨 데이터 소스를 명시해서 파퓰레이트된 볼륨을 정의한다. 이 때, 원천 네임스페이스에 유효한 레퍼런스그랜트를 보유하고 있어야 한다: + + ```yaml + apiVersion: gateway.networking.k8s.io/v1beta1 + kind: ReferenceGrant + metadata: + name: allow-ns1-pvc + namespace: default + spec: + from: + - group: "" + kind: PersistentVolumeClaim + namespace: ns1 + to: + - group: snapshot.storage.k8s.io + kind: VolumeSnapshot + name: new-snapshot-demo + ``` + + ```yaml + apiVersion: v1 + kind: PersistentVolumeClaim + metadata: + name: foo-pvc + namespace: ns1 + spec: + storageClassName: example + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + dataSourceRef: + apiGroup: snapshot.storage.k8s.io + kind: VolumeSnapshot + name: new-snapshot-demo + namespace: default + volumeMode: Filesystem + ``` + ## 포터블 구성 작성 광범위한 클러스터에서 실행되고 퍼시스턴트 스토리지가 필요한 diff --git a/content/ko/docs/concepts/storage/projected-volumes.md b/content/ko/docs/concepts/storage/projected-volumes.md index 7fb83d1a2a4aa..62d05dcde8c41 100644 --- a/content/ko/docs/concepts/storage/projected-volumes.md +++ b/content/ko/docs/concepts/storage/projected-volumes.md @@ -46,7 +46,6 @@ weight: 21 # just after persistent volumes `mode`를 명시적으로 지정할 수 있다. ## 서비스어카운트토큰 프로젝티드 볼륨 {#serviceaccounttoken} -`TokenRequestProjection` 기능이 활성화 된 경우 파드의 지정된 경로에 [서비스어카운트토큰](/docs/reference/access-authn-authz/authentication/#service-account-tokens)을 주입할 수 있다. @@ -82,6 +81,23 @@ weight: 21 # just after persistent volumes `RunAsUser`가 설정된 리눅스 파드에서는 프로젝티드파일이 컨테이너 사용자 소유권을 포함한 올바른 소유권 집합을 가진다. +파드의 모든 컨테이너의 +[`PodSecurityContext`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context)나 +컨테이너 +[`SecurityContext`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context-1)의 `runAsUser` 설정이 동일하다면, +kubelet은 `serviceAccountToken` 볼륨의 내용이 해당 사용자의 소유이며, +토큰 파일의 권한 모드는 `0600`로 설정됨을 보장한다. + +{{< note >}} +생성된 후 파드에 추가되는 {{< glossary_tooltip text="임시 컨테이너" term_id="ephemeral-container" >}}는 +파드 생성 시 설정된 볼륨 권한을 +변경하지 *않는다*. + +파드 내 그 외의 모든 컨테이너의 `runAsUser`가 동일하여 +파드의 `serviceAccountToken` 볼륨 권한이 `0600`으로 설정되어 있다면, 임시 +컨테이너는 토큰을 읽을 수 있도록 동일한 `runAsUser`를 사용해야 한다. +{{< /note >}} + ### 윈도우 윈도우 파드에서 프로젝티드 볼륨과 파드 `SecurityContext`에 `RunAsUsername`이 설정된 경우, diff --git a/content/ko/docs/concepts/storage/storage-capacity.md b/content/ko/docs/concepts/storage/storage-capacity.md index ee0460c129425..3f83dc551bc46 100644 --- a/content/ko/docs/concepts/storage/storage-capacity.md +++ b/content/ko/docs/concepts/storage/storage-capacity.md @@ -7,7 +7,7 @@ # - pohly title: 스토리지 용량 content_type: concept -weight: 70 +weight: 80 --- diff --git a/content/ko/docs/concepts/storage/storage-classes.md b/content/ko/docs/concepts/storage/storage-classes.md index e7190fd7d0eb3..b97b89b38d5cc 100644 --- a/content/ko/docs/concepts/storage/storage-classes.md +++ b/content/ko/docs/concepts/storage/storage-classes.md @@ -6,7 +6,7 @@ # - msau42 title: 스토리지 클래스 content_type: concept -weight: 30 +weight: 40 --- @@ -72,7 +72,6 @@ volumeBindingMode: Immediate | FC | - | - | | FlexVolume | - | - | | GCEPersistentDisk | ✓ | [GCE PD](#gce-pd) | -| Glusterfs | ✓ | [Glusterfs](#glusterfs) | | iSCSI | - | - | | NFS | - | [NFS](#nfs) | | RBD | ✓ | [Ceph RBD](#ceph-rbd) | @@ -123,7 +122,6 @@ true로 설정된 경우 볼륨 확장을 지원한다. gcePersistentDisk | 1.11 awsElasticBlockStore | 1.11 Cinder | 1.11 -glusterfs | 1.11 rbd | 1.11 Azure File | 1.11 Azure Disk | 1.11 @@ -338,87 +336,6 @@ parameters: [allowedTopologies](#allowed-topologies)로 대체되었다. {{< /note >}} -### Glusterfs - -```yaml -apiVersion: storage.k8s.io/v1 -kind: StorageClass -metadata: - name: slow -provisioner: kubernetes.io/glusterfs -parameters: - resturl: "http://127.0.0.1:8081" - clusterid: "630372ccdc720a92c681fb928f27b53f" - restauthenabled: "true" - restuser: "admin" - secretNamespace: "default" - secretName: "heketi-secret" - gidMin: "40000" - gidMax: "50000" - volumetype: "replicate:3" -``` - -* `resturl`: 필요에 따라 gluster 볼륨을 프로비전하는 Gluster REST 서비스/Heketi - 서비스 url 이다. 일반적인 형식은 `IPaddress:Port` 이어야 하며 이는 GlusterFS - 동적 프로비저너의 필수 파라미터이다. Heketi 서비스가 openshift/kubernetes - 설정에서 라우팅이 가능한 서비스로 노출이 되는 경우 이것은 fqdn이 해석할 수 있는 - Heketi 서비스 url인 `http://heketi-storage-project.cloudapps.mystorage.com` 과 - 유사한 형식을 가질 수 있다. -* `restauthenabled` : REST 서버에 대한 인증을 가능하게 하는 Gluster REST 서비스 - 인증 부울이다. 이 값이 `"true"` 이면, `restuser` 와 `restuserkey` - 또는 `secretNamespace` + `secretName` 을 채워야 한다. 이 옵션은 - 사용 중단이며, `restuser`, `restuserkey`, `secretName` 또는 - `secretNamespace` 중 하나를 지정하면 인증이 활성화된다. -* `restuser` : Gluster REST 서비스/Heketi 사용자로 Gluster Trusted Pool에서 - 볼륨을 생성할 수 있다. -* `restuserkey` : REST 서버에 대한 인증에 사용될 Gluster REST 서비스/Heketi - 사용자의 암호이다. 이 파라미터는 `secretNamespace` + `secretName` 을 위해 - 사용 중단 되었다. -* `secretNamespace`, `secretName` : Gluster REST 서비스와 통신할 때 사용할 - 사용자 암호가 포함된 시크릿 인스턴스를 식별한다. 이 파라미터는 - 선택 사항으로 `secretNamespace` 와 `secretName` 을 모두 생략하면 - 빈 암호가 사용된다. 제공된 시크릿은 `"kubernetes.io/glusterfs"` 유형이어야 - 하며, 예를 들어 다음과 같이 생성한다. - - ``` - kubectl create secret generic heketi-secret \ - --type="kubernetes.io/glusterfs" --from-literal=key='opensesame' \ - --namespace=default - ``` - - 시크릿의 예시는 - [glusterfs-provisioning-secret.yaml](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/glusterfs/glusterfs-secret.yaml)에서 찾을 수 있다. - -* `clusterid`: `630372ccdc720a92c681fb928f27b53f` 는 볼륨을 프로비저닝할 - 때 Heketi가 사용할 클러스터의 ID이다. 또한, 예시와 같이 클러스터 - ID 목록이 될 수 있다. 예: - `"8452344e2becec931ece4e33c4674e4e,42982310de6c63381718ccfa6d8cf397"`. 이것은 - 선택적 파라미터이다. -* `gidMin`, `gidMax` : 스토리지클래스에 대한 GID 범위의 최소값과 - 최대값이다. 이 범위( gidMin-gidMax )의 고유한 값(GID)은 동적으로 - 프로비전된 볼륨에 사용된다. 이것은 선택적인 값이다. 지정하지 않으면, - 볼륨은 각각 gidMin과 gidMax의 기본값인 2000-2147483647 - 사이의 값으로 프로비전된다. -* `volumetype` : 볼륨 유형과 파라미터는 이 선택적 값으로 구성할 - 수 있다. 볼륨 유형을 언급하지 않는 경우, 볼륨 유형을 결정하는 것은 - 프로비저너의 책임이다. - - 예를 들어: - * 레플리카 볼륨: `volumetype: replicate:3` 여기서 '3'은 레플리카의 수이다. - * Disperse/EC 볼륨: `volumetype: disperse:4:2` 여기서 '4'는 데이터이고 '2'는 중복 횟수이다. - * Distribute 볼륨: `volumetype: none` - - 사용 가능한 볼륨 유형과 관리 옵션에 대해서는 - [관리 가이드](https://access.redhat.com/documentation/en-us/red_hat_gluster_storage/)를 참조한다. - - 자세한 정보는 - [Heketi 구성 방법](https://github.com/heketi/heketi/wiki/Setting-up-the-topology)을 참조한다. - - 퍼시스턴트 볼륨이 동적으로 프로비전되면 Gluster 플러그인은 - `gluster-dynamic-` 이라는 이름으로 엔드포인트와 - 헤드리스 서비스를 자동으로 생성한다. 퍼시스턴트 볼륨 클레임을 - 삭제하면 동적 엔드포인트와 서비스가 자동으로 삭제된다. - ### NFS ```yaml diff --git a/content/ko/docs/concepts/storage/storage-limits.md b/content/ko/docs/concepts/storage/storage-limits.md index e4a9759d463ea..326cd84069d32 100644 --- a/content/ko/docs/concepts/storage/storage-limits.md +++ b/content/ko/docs/concepts/storage/storage-limits.md @@ -6,6 +6,7 @@ # - msau42 title: 노드 별 볼륨 한도 content_type: concept +weight: 90 --- diff --git a/content/ko/docs/concepts/storage/volume-health-monitoring.md b/content/ko/docs/concepts/storage/volume-health-monitoring.md index 75c0a8507891d..298f545f92b59 100644 --- a/content/ko/docs/concepts/storage/volume-health-monitoring.md +++ b/content/ko/docs/concepts/storage/volume-health-monitoring.md @@ -6,6 +6,7 @@ # - xing-yang title: 볼륨 헬스 모니터링 content_type: concept +weight: 100 --- diff --git a/content/ko/docs/concepts/storage/volume-pvc-datasource.md b/content/ko/docs/concepts/storage/volume-pvc-datasource.md index f887f6e4a6b4c..239df4c3864f7 100644 --- a/content/ko/docs/concepts/storage/volume-pvc-datasource.md +++ b/content/ko/docs/concepts/storage/volume-pvc-datasource.md @@ -6,7 +6,7 @@ # - msau42 title: CSI 볼륨 복제하기 content_type: concept -weight: 60 +weight: 70 --- diff --git a/content/ko/docs/concepts/storage/volume-snapshot-classes.md b/content/ko/docs/concepts/storage/volume-snapshot-classes.md index 6ff624d65ecd0..e08ffe438150d 100644 --- a/content/ko/docs/concepts/storage/volume-snapshot-classes.md +++ b/content/ko/docs/concepts/storage/volume-snapshot-classes.md @@ -8,7 +8,7 @@ # - yuxiangqian title: 볼륨 스냅샷 클래스 content_type: concept -weight: 41 # just after volume snapshots +weight: 61 # just after volume snapshots --- diff --git a/content/ko/docs/concepts/storage/volume-snapshots.md b/content/ko/docs/concepts/storage/volume-snapshots.md index a47246872e8d5..8d594171492ac 100644 --- a/content/ko/docs/concepts/storage/volume-snapshots.md +++ b/content/ko/docs/concepts/storage/volume-snapshots.md @@ -8,70 +8,112 @@ # - yuxiangqian title: 볼륨 스냅샷 content_type: concept -weight: 40 +weight: 60 --- -쿠버네티스에서 스토리지 시스템 볼륨 스냅샷은 _VolumeSnapshot_ 을 나타낸다. 이 문서는 이미 쿠버네티스 [퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/)에 대해 잘 알고 있다고 가정한다. - - - +쿠버네티스에서 _VolumeSnapshot_ 은 스토리지 시스템 볼륨 스냅샷을 +나타낸다. 이 문서는 이미 쿠버네티스 +[퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/)에 대해 잘 알고 있다고 가정한다. ## 소개 -API 리소스 `PersistentVolume` 및 `PersistentVolumeClaim` 가 사용자 및 관리자가 볼륨을 프로비전할 때의 방법과 유사하게, `VolumeSnapshotContent` 및 `VolumeSnapshot` API 리소스는 볼륨 스냅샷을 생성하기 위해 제공된다. +API 리소스 `PersistentVolume` 및 `PersistentVolumeClaim` 가 +사용자와 관리자를 위해 볼륨을 프로비전할 때 사용되는 것과 유사하게, `VolumeSnapshotContent` +및 `VolumeSnapshot` API 리소스는 사용자와 관리자를 위한 볼륨 스냅샷을 생성하기 위해 +제공된다. -`VolumeSnapshotContent` 는 관리자가 프로버져닝한 클러스터 볼륨에서의 스냅샷이다. 퍼시스턴트볼륨이 클러스터 리소스인 것처럼 이것 또한 클러스터 리소스이다. +`VolumeSnapshotContent` 는 관리자가 +프로비져닝한 클러스터 내 볼륨의 스냅샷이다. 퍼시스턴트볼륨이 +클러스터 리소스인 것처럼 이것 또한 클러스터 리소스이다. -`VolumeSnapshot` 은 사용자가 볼륨의 스냅샷을 요청할 수 있는 방법이다. 이는 퍼시스턴트볼륨클레임과 유사하다. +`VolumeSnapshot` 은 사용자가 볼륨의 스냅샷을 요청할 수 있는 방법이다. 이는 +퍼시스턴트볼륨클레임과 유사하다. -`VolumeSnapshotClass` 을 사용하면 `VolumeSnapshot` 에 속한 다른 속성을 지정할 수 있다. 이러한 속성은 스토리지 시스템에의 동일한 볼륨에서 가져온 스냅샷마다 다를 수 있으므로 `PersistentVolumeClaim` 의 `StorageClass` 를 사용하여 표현할 수는 없다. +`VolumeSnapshotClass` 을 사용하면 +`VolumeSnapshot` 에 속한 다른 속성을 지정할 수 있다. 이러한 속성은 스토리지 시스템에의 동일한 +볼륨에서 가져온 스냅샷마다 다를 수 있으므로 +`PersistentVolumeClaim` 의 동일한 `StorageClass` 를 사용하여 표현할 수는 없다. -볼륨 스냅샷은 쿠버네티스 사용자에게 완전히 새로운 볼륨을 생성하지 않고도 특정 시점에 볼륨의 콘텐츠를 복사하는 표준화된 방법을 제공한다. 예를 들어, 데이터베이스 관리자는 이 기능을 사용하여 수정 사항을 편집 또는 삭제하기 전에 데이터베이스를 백업할 수 있다. +볼륨 스냅샷은 쿠버네티스 사용자에게 완전히 새로운 볼륨을 생성하지 않고도 특정 시점에 볼륨의 콘텐츠를 복사하는 +표준화된 방법을 제공한다. +예를 들어, 데이터베이스 관리자는 이 기능을 사용하여 +수정 사항을 편집 또는 삭제하기 전에 데이터베이스를 백업할 수 있다. 사용자는 이 기능을 사용할 때 다음 사항을 알고 있어야 한다. -* API 오브젝트인 `VolumeSnapshot`, `VolumeSnapshotContent`, `VolumeSnapshotClass` 는 핵심 API가 아닌, {{< glossary_tooltip term_id="CustomResourceDefinition" text="CRDs" >}}이다. -* `VolumeSnapshot` 은 CSI 드라이버에서만 사용할 수 있다. -* 쿠버네티스 팀은 `VolumeSnapshot` 의 배포 프로세스 일부로써, 컨트롤 플레인에 배포할 스냅샷 컨트롤러와 CSI 드라이버와 함께 배포할 csi-snapshotter라는 사이드카 헬퍼(helper) 컨테이너를 제공한다. 스냅샷 컨트롤러는 `VolumeSnapshot` 및 `VolumeSnapshotContent` 오브젝트를 관찰하고 동적 프로비저닝에서 `VolumeSnapshotContent` 오브젝트의 생성 및 삭제를 할 수 있다.사이드카 csi-snapshotter는 `VolumeSnapshotContent` 오브젝트를 관찰하고 CSI 엔드포인트에 대해 `CreateSnapshot` 및 `DeleteSnapshot` 을 트리거(trigger)한다. -* 스냅샷 오브젝트에 대한 강화된 검증을 제공하는 검증 웹훅 서버도 있다. 이는 CSI 드라이버가 아닌 스냅샷 컨트롤러 및 CRD와 함께 쿠버네티스 배포판에 의해 설치되어야 한다. 스냅샷 기능이 활성화된 모든 쿠버네티스 클러스터에 설치해야 한다. -* CSI 드라이버에서의 볼륨 스냅샷 기능 유무는 확실하지 않다. 볼륨 스냅샷 서포트를 제공하는 CSI 드라이버는 csi-snapshotter를 사용할 가능성이 높다. 자세한 사항은 [CSI 드라이버 문서](https://kubernetes-csi.github.io/docs/)를 확인하면 된다. -* CRDs 및 스냅샷 컨트롤러는 쿠버네티스 배포 시 설치된다. +- API 오브젝트인 `VolumeSnapshot`, `VolumeSnapshotContent`, `VolumeSnapshotClass` + 는 핵심 API가 아닌, {{< glossary_tooltip term_id="CustomResourceDefinition" text="CRDs" >}} + 이다. +- `VolumeSnapshot` 은 CSI 드라이버에서만 사용할 수 있다. +- 쿠버네티스 팀은 `VolumeSnapshot` 의 배포 프로세스 일부로써, + 컨트롤 플레인에 배포할 스냅샷 컨트롤러와 CSI 드라이버와 함께 배포할 + csi-snapshotter라는 사이드카 헬퍼(helper) 컨테이너를 제공한다. + 스냅샷 컨트롤러는 `VolumeSnapshot` 및 `VolumeSnapshotContent` 오브젝트를 관찰하고 + `VolumeSnapshotContent` 오브젝트의 생성 및 삭제에 대한 책임을 진다. + 사이드카 csi-snapshotter는 `VolumeSnapshotContent` 오브젝트를 관찰하고 + CSI 엔드포인트에 대해 `CreateSnapshot` 및 `DeleteSnapshot` 을 트리거(trigger)한다. +- 스냅샷 오브젝트에 대한 강화된 검증을 제공하는 검증 웹훅 + 서버도 있다. 이는 + CSI 드라이버가 아닌 스냅샷 컨트롤러 및 CRD와 함께 쿠버네티스 배포판에 의해 설치되어야 한다. 스냅샷 기능이 + 활성화된 모든 쿠버네티스 클러스터에 설치해야 한다. +- CSI 드라이버에서의 볼륨 스냅샷 기능 유무는 확실하지 않다. + 볼륨 스냅샷 서포트를 제공하는 CSI 드라이버는 + csi-snapshotter를 사용할 가능성이 높다. 자세한 사항은 [CSI 드라이버 문서](https://kubernetes-csi.github.io/docs/)를 확인하면 된다. +- CRDs 및 스냅샷 컨트롤러는 쿠버네티스 배포 시 설치된다. ## 볼륨 스냅샷 및 볼륨 스냅샷 컨텐츠의 라이프사이클 -`VolumeSnapshotContents` 은 클러스터 리소스이다. `VolumeSnapshots` 은 이러한 리소스의 요청이다. `VolumeSnapshotContents` 과 `VolumeSnapshots`의 상호 작용은 다음과 같은 라이프사이클을 따른다. +`VolumeSnapshotContents` 은 클러스터 리소스이다. `VolumeSnapshots` 은 +이러한 리소스의 요청이다. `VolumeSnapshotContents` 과 `VolumeSnapshots`의 상호 작용은 +다음과 같은 라이프사이클을 따른다. ### 프로비저닝 볼륨 스냅샷 스냅샷을 프로비저닝할 수 있는 방법에는 사전 프로비저닝 혹은 동적 프로비저닝의 두 가지가 있다: . #### 사전 프로비전 {#static} -클러스터 관리자는 많은 `VolumeSnapshotContents` 을 생성한다. 그들은 클러스터 사용자들이 사용 가능한 스토리지 시스템의 실제 볼륨 스냅샷 세부 정보를 제공한다. 이것은 쿠버네티스 API에 있고 사용 가능하다. + +클러스터 관리자는 많은 `VolumeSnapshotContents` 을 생성한다. 그들은 +클러스터 사용자들이 사용 가능한 스토리지 시스템의 실제 볼륨 스냅샷 세부 정보를 제공한다. +이것은 쿠버네티스 API에 있고 사용 가능하다. #### 동적 -사전 프로비저닝을 사용하는 대신 퍼시스턴트볼륨클레임에서 스냅샷을 동적으로 가져오도록 요청할 수 있다. [볼륨스냅샷클래스](/ko/docs/concepts/storage/volume-snapshot-classes/)는 스냅샷 사용 시 스토리지 제공자의 특정 파라미터를 명세한다. + +사전 프로비저닝을 사용하는 대신 퍼시스턴트볼륨클레임에서 스냅샷을 동적으로 +가져오도록 요청할 수 있다. [볼륨스냅샷클래스](/ko/docs/concepts/storage/volume-snapshot-classes/)는 +스냅샷 실행 시 스토리지 제공자의 특정 파라미터를 명세한다. ### 바인딩 -스냅샷 컨트롤러는 사전 프로비저닝과 동적 프로비저닝된 시나리오에서 `VolumeSnapshot` 오브젝트와 적절한 `VolumeSnapshotContent` 오브젝트와의 바인딩을 처리한다. 바인딩은 1:1 매핑이다. +스냅샷 컨트롤러는 사전 프로비저닝과 동적 프로비저닝된 시나리오에서 `VolumeSnapshot` 오브젝트와 적절한 +`VolumeSnapshotContent` 오브젝트와의 바인딩을 처리한다. +바인딩은 1:1 매핑이다. -사전 프로비저닝된 경우, 볼륨스냅샷은 볼륨스냅샷컨텐츠 오브젝트 생성이 요청될 때까지 바인드되지 않은 상태로 유지된다. +사전 프로비저닝된 경우, 볼륨스냅샷은 요청된 볼륨스냅샷컨텐츠 오브젝트가 생성될 때까지 +바인드되지 않은 상태로 유지된다. ### 스냅샷 소스 보호로서의 퍼시스턴트 볼륨 클레임 이 보호의 목적은 스냅샷이 생성되는 동안 사용 중인 {{< glossary_tooltip text="퍼시스턴트볼륨클레임" term_id="persistent-volume-claim" >}} -API 오브젝트가 시스템에서 지워지지 않게 하는 것이다(데이터 손실이 발생할 수 있기 때문에). +API 오브젝트가 시스템에서 지워지지 않게 하는 것이다 +(데이터 손실이 발생할 수 있기 때문에). -퍼시스턴트볼륨클레임이 스냅샷을 생성할 동안에는 해당 퍼시스턴트볼륨클레임은 사용 중인 상태이다. 스냅샷 소스로 사용 중인 퍼시스턴트볼륨클레임 API 오브젝트를 삭제한다면, 퍼시스턴트볼륨클레임 오브젝트는 즉시 삭제되지 않는다. 대신, 퍼시스턴트볼륨클레임 오브젝트 삭제는 스냅샷이 준비(readyToUse) 혹은 중단(aborted) 상태가 될 때까지 연기된다. +퍼시스턴트볼륨클레임이 스냅샷을 생성할 동안에는 해당 퍼시스턴트볼륨클레임은 +사용 중인 상태이다. 스냅샷 소스로 사용 중인 퍼시스턴트볼륨클레임 API 오브젝트를 +삭제한다면, 퍼시스턴트볼륨클레임 오브젝트는 즉시 삭제되지 않는다. 대신, +퍼시스턴트볼륨클레임 오브젝트 삭제는 스냅샷이 준비(readyToUse) 혹은 중단(aborted) 상태가 될 때까지 연기된다. ### 삭제 -삭제는 `VolumeSnapshot` 를 삭제 시 트리거로 `DeletionPolicy` 가 실행된다. `DeletionPolicy` 가 `Delete` 라면, 기본 스토리지 스냅샷이 `VolumeSnapshotContent` 오브젝트와 함께 삭제될 것이다. `DeletionPolicy` 이 `Retain` 이라면, 기본 스트리지 스냅샷과 `VolumeSnapshotContent` 둘 다 유지된다. +`VolumeSnapshot` 를 삭제하면 삭제 과정이 트리거되고, `DeletionPolicy` 가 +이어서 실행된다. `DeletionPolicy` 가 `Delete` 라면, 기본 스토리지 스냅샷이 +`VolumeSnapshotContent` 오브젝트와 함께 삭제될 것이다. `DeletionPolicy` 가 +`Retain` 이라면, 기본 스트리지 스냅샷과 `VolumeSnapshotContent` 둘 다 유지된다. ## 볼륨 스냅샷 @@ -88,13 +130,17 @@ spec: persistentVolumeClaimName: pvc-test ``` -`persistentVolumeClaimName` 은 스냅샷을 위한 퍼시스턴트볼륨클레임 데이터 소스의 이름이다. 이 필드는 동적 프로비저닝 스냅샷이 필요하다. +`persistentVolumeClaimName` 은 스냅샷을 위한 퍼시스턴트볼륨클레임 데이터 소스의 +이름이다. 이 필드는 동적 프로비저닝 스냅샷이 필요하다. 볼륨 스냅샷은 `volumeSnapshotClassName` 속성을 사용하여 [볼륨스냅샷클래스](/ko/docs/concepts/storage/volume-snapshot-classes/)의 이름을 지정하여 -특정 클래스를 요청할 수 있다. 아무것도 설정하지 않으면, 사용 가능한 경우 기본 클래스가 사용될 것이다. +특정 클래스를 요청할 수 있다. 아무것도 설정하지 않으면, 사용 가능한 경우 +기본 클래스가 사용될 것이다. -사전 프로비저닝된 스냅샷의 경우, 다음 예와 같이 `volumeSnapshotContentName`을 스냅샷 소스로 지정해야 한다. 사전 프로비저닝된 스냅샷에는 `volumeSnapshotContentName` 소스 필드가 필요하다. +사전 프로비저닝된 스냅샷의 경우, 다음 예와 같이 `volumeSnapshotContentName`을 +스냅샷 소스로 지정해야 한다. 사전 프로비저닝된 스냅샷에는 +`volumeSnapshotContentName` 소스 필드가 필요하다. ```yaml apiVersion: snapshot.storage.k8s.io/v1 @@ -108,7 +154,8 @@ spec: ## 볼륨 스냅샷 컨텐츠 -각각의 볼륨스냅샷컨텐츠는 스펙과 상태를 포함한다. 동적 프로비저닝에서는, 스냅샷 공통 컨트롤러는 `VolumeSnapshotContent` 오브젝트를 생성한다. 예시는 다음과 같다. +각각의 볼륨스냅샷컨텐츠는 스펙과 상태를 포함한다. 동적 프로비저닝에서는, +스냅샷 공통 컨트롤러는 `VolumeSnapshotContent` 오브젝트를 생성한다. 예시는 다음과 같다. ```yaml apiVersion: snapshot.storage.k8s.io/v1beta1 @@ -128,9 +175,13 @@ spec: uid: 72d9a349-aacd-42d2-a240-d775650d2455 ``` -`volumeHandle` 은 스토리지 백엔드에서 생성되고 볼륨 생성 중에 CSI 드라이버가 반환하는 볼륨의 고유 식별자이다. 이 필드는 스냅샷을 동적 프로비저닝하는 데 필요하다. 이것은 스냅샷의 볼륨 소스를 지정한다. +`volumeHandle` 은 스토리지 백엔드에서 생성되고 +볼륨 생성 중에 CSI 드라이버가 반환하는 볼륨의 고유 식별자이다. 이 필드는 +스냅샷을 동적 프로비저닝하는 데 필요하다. +이것은 스냅샷의 볼륨 소스를 지정한다. -사전 프로비저닝된 스냅샷의 경우, (클러스터 관리자로서) 다음과 같이 `VolumeSnapshotContent` 오브젝트를 작성해야 한다. +사전 프로비저닝된 스냅샷의 경우, (클러스터 관리자로서) 다음과 같이 +`VolumeSnapshotContent` 오브젝트를 생성해야 한다. ```yaml apiVersion: snapshot.storage.k8s.io/v1 @@ -148,19 +199,24 @@ spec: namespace: default ``` -`snapshotHandle` 은 스토리지 백엔드에서 생성된 볼륨 스냅샷의 고유 식별자이다. 이 필드는 사전 프로비저닝된 스냅샷에 필요하다. `VolumeSnapshotContent` 가 나타내는 스토리지 시스템의 CSI 스냅샷 id를 지정한다. +`snapshotHandle` 은 스토리지 백엔드에서 생성된 볼륨 스냅샷의 +고유 식별자이다. 이 필드는 사전 프로비저닝된 스냅샷에 필요하다. +`VolumeSnapshotContent` 가 나타내는 스토리지 시스템의 CSI 스냅샷 id를 +지정한다. -`sourceVolumeMode` 은 스냅샷이 생성된 볼륨의 모드를 나타낸다. -`sourceVolumeMode` 필드의 값은 `Filesystem` 또는 `Block` 일 수 있다. -소스 볼륨 모드가 명시되어 있지 않으면, +`sourceVolumeMode` 은 스냅샷이 생성된 볼륨의 모드를 나타낸다. +`sourceVolumeMode` 필드의 값은 `Filesystem` 또는 `Block` 일 수 있다. +소스 볼륨 모드가 명시되어 있지 않으면, 쿠버네티스는 해당 스냅샷의 소스 볼륨 모드를 알려지지 않은 상태(unknown)로 간주하여 스냅샷을 처리한다. -`volumeSnapshotRef`은 상응하는 `VolumeSnapshot`의 참조이다. `VolumeSnapshotContent`이 이전에 프로비전된 스냅샷으로 생성된 경우, `volumeSnapshotRef`에서 참조하는 `VolumeSnapshot`은 아직 존재하지 않을 수도 있음에 주의한다. +`volumeSnapshotRef`은 상응하는 `VolumeSnapshot`의 참조이다. +`VolumeSnapshotContent`이 이전에 프로비전된 스냅샷으로 생성된 경우, +`volumeSnapshotRef`에서 참조하는 `VolumeSnapshot`은 아직 존재하지 않을 수도 있음에 주의한다. ## 스냅샷의 볼륨 모드 변환하기 {#convert-volume-mode} -클러스터에 설치된 `VolumeSnapshots` API가 `sourceVolumeMode` 필드를 지원한다면, -인증되지 않은 사용자가 볼륨의 모드를 변경하는 것을 금지하는 기능이 +클러스터에 설치된 `VolumeSnapshots` API가 `sourceVolumeMode` 필드를 지원한다면, +인증되지 않은 사용자가 볼륨의 모드를 변경하는 것을 금지하는 기능이 API에 있는 것이다. 클러스터가 이 기능을 지원하는지 확인하려면, 다음 명령어를 실행한다. @@ -169,13 +225,13 @@ API에 있는 것이다. $ kubectl get crd volumesnapshotcontent -o yaml ``` -사용자가 기존 `VolumeSnapshot`으로부터 `PersistentVolumeClaim`을 생성할 때 -기존 소스와 다른 볼륨 모드를 지정할 수 있도록 하려면, -`VolumeSnapshot`와 연관된 `VolumeSnapshotContent`에 +사용자가 기존 `VolumeSnapshot`으로부터 `PersistentVolumeClaim`을 생성할 때 +기존 소스와 다른 볼륨 모드를 지정할 수 있도록 하려면, +`VolumeSnapshot`와 연관된 `VolumeSnapshotContent`에 `snapshot.storage.kubernetes.io/allowVolumeModeChange: "true"` 어노테이션을 추가해야 한다. -이전에 프로비전된 스냅샷의 경우에는, -클러스터 관리자가 `Spec.SourceVolumeMode`를 추가해야 한다. +이전에 프로비전된 스냅샷의 경우에는, 클러스터 관리자가 `spec.sourceVolumeMode`를 +추가해야 한다. 이 기능이 활성화된 예시 `VolumeSnapshotContent` 리소스는 다음과 같을 것이다. @@ -199,7 +255,7 @@ spec: ## 스냅샷을 위한 프로비저닝 볼륨 -`PersistentVolumeClaim` 오브젝트의 *dataSource* 필드를 사용하여 +`PersistentVolumeClaim` 오브젝트의 _dataSource_ 필드를 사용하여 스냅샷 데이터로 미리 채워진 새 볼륨을 프로비저닝할 수 있다. 보다 자세한 사항은 diff --git a/content/ko/docs/concepts/storage/volumes.md b/content/ko/docs/concepts/storage/volumes.md index aa12838fa0ba9..0338e15613977 100644 --- a/content/ko/docs/concepts/storage/volumes.md +++ b/content/ko/docs/concepts/storage/volumes.md @@ -172,7 +172,7 @@ EBS 볼륨이 파티션된 경우, 선택적 필드인 `partition: "}} +{{< feature-state for_k8s_version="v1.26" state="stable" >}} `azureFile` 의 `CSIMigration` 기능이 활성화된 경우, 기존 트리 내 플러그인에서 `file.csi.azure.com` 컨테이너 스토리지 인터페이스(CSI) @@ -335,12 +335,20 @@ spec: * 웹 서버 컨테이너가 데이터를 처리하는 동안 컨텐츠 매니저 컨테이너가 가져오는 파일을 보관 -환경에 따라, `emptyDir` 볼륨은 디스크, SSD 또는 네트워크 스토리지와 -같이 노드를 지원하는 모든 매체에 저장된다. 그러나, `emptyDir.medium` 필드를 -`"Memory"`로 설정하면, 쿠버네티스에 tmpfs(RAM 기반 파일시스템)를 마운트하도록 할 수 있다. -tmpfs는 매우 빠르지만, 디스크와 다르게 노드 재부팅시 tmpfs가 지워지고, -작성하는 모든 파일이 컨테이너 메모리 -제한에 포함된다. +`emptyDir.medium` 필드는 `emptyDir` 볼륨이 저장되는 곳을 제어한다. +기본 `emptyDir` 볼륨은 환경에 따라 +디스크, SSD 또는 네트워크 스토리지와 같이 노드를 지원하는 모든 매체에 저장된다. +`emptyDir.medium` 필드를 `"Memory"`로 설정하면, 쿠버네티스는 tmpfs(RAM 기반 파일시스템)를 대신 +마운트한다. tmpfs는 매우 빠르지만, 디스크와 다르게 +노드 재부팅시 tmpfs는 마운트 해제되고, 작성하는 모든 파일이 +컨테이너 메모리 제한에 포함된다. + + +`emptyDir` 볼륨의 용량을 제한하는 기본 medium을 위해, +크기 제한을 명시할 수 있다. 스토리지는 [노드 임시 +스토리지](/ko/docs/concepts/configuration/manage-resources-containers/#로컬-임시-스토리지에-대한-요청-및-제한-설정)로부터 할당된다. +만약 해당 공간이 다른 소스(예를 들어, 로그 파일이나 이미지 오버레이)에 의해 +채워져있다면, `emptyDir`는 지정된 제한 이전에 용량을 다 쓰게 될 수 있다. {{< note >}} `SizeMemoryBackedVolumes` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화된 경우, @@ -364,7 +372,8 @@ spec: name: cache-volume volumes: - name: cache-volume - emptyDir: {} + emptyDir: + sizeLimit: 500Mi ``` ### fc (파이버 채널) {#fc} @@ -533,24 +542,15 @@ spec: repository: "git@somewhere:me/my-git-repository.git" revision: "22f1d8406d464b0c0874075539c1f2e96c253775" ``` +### glusterfs (제거됨) {#glusterfs} -### glusterfs (사용 중단됨) - -{{< feature-state for_k8s_version="v1.25" state="deprecated" >}} - -`glusterfs` 볼륨을 사용하면 [Glusterfs](https://www.gluster.org) (오픈 -소스 네트워크 파일시스템) 볼륨을 파드에 마운트할 수 있다. 파드를 -제거할 때 지워지는 `emptyDir` 와는 다르게 `glusterfs` -볼륨의 내용은 유지되고, 볼륨은 마운트 해제만 된다. 이 의미는 -glusterfs 볼륨에 데이터를 미리 채울 수 있으며, 파드 간에 데이터를 -공유할 수 있다. GlusterFS는 여러 작성자가 동시에 -마운트할 수 있다. - -{{< note >}} -사용하려면 먼저 GlusterFS를 설치하고 실행해야 한다. -{{< /note >}} + +- +쿠버네티스 {{< skew currentVersion >}} 는 `glusterfs` 볼륨 타입을 포함하지 않는다. -더 자세한 내용은 [GlusterFS 예시](https://github.com/kubernetes/examples/tree/master/volumes/glusterfs)를 본다. +GlusterFS 인-트리 스토리지 드라이버는 쿠버네티스 1.25에서 사용 중단되었고 +v1.26 릴리즈에서 완전히 제거되었다. ### hostPath {#hostpath} @@ -762,11 +762,33 @@ local [스토리지클래스(StorageClas)](/ko/docs/concepts/storage/storage-cla 파드 간에 데이터를 공유할 수 있다는 뜻이다. NFS는 여러 작성자가 동시에 마운트할 수 있다. +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-pd +spec: + containers: + - image: registry.k8s.io/test-webserver + name: test-container + volumeMounts: + - mountPath: /my-nfs-data + name: test-volume + volumes: + - name: test-volume + nfs: + server: my-nfs-server.example.com + path: /my-nfs-volume + readOnly: true +``` + {{< note >}} 사용하려면 먼저 NFS 서버를 실행하고 공유를 내보내야 한다. + +또한 파드 스펙에 NFS 마운트 옵션을 명시할 수 없음을 기억하라. 마운트 옵션을 서버에서 설정하거나, [/etc/nfsmount.conf](https://man7.org/linux/man-pages/man5/nfsmount.conf.5.html)를 사용해야 한다. 마운트 옵션을 설정할 수 있게 허용하는 퍼시스턴트볼륨을 통해 NFS 볼륨을 마운트할 수도 있다. {{< /note >}} -더 자세한 내용은 [NFS 예시](https://github.com/kubernetes/examples/tree/master/staging/volumes/nfs)를 본다. +퍼시스턴트볼륨을 사용하여 NFS 볼륨을 마운트하는 예제는 [NFS 예시](https://github.com/kubernetes/examples/tree/master/staging/volumes/nfs)를 본다. ### persistentVolumeClaim {#persistentvolumeclaim} @@ -921,20 +943,17 @@ tmpfs(RAM 기반 파일시스템)로 지원되기 때문에 비 휘발성 스토 #### vSphere CSI 마이그레이션 {#vsphere-csi-migration} -{{< feature-state for_k8s_version="v1.19" state="beta" >}} - -`vsphereVolume` 용 `CSIMigrationvSphere` 기능은 쿠버네티스 v1.25부터 기본적으로 활성화되어 있다. -인-트리 `vspherevolume`의 모든 플러그인 작업은 `CSIMigrationvSphere` 기능 게이트가 비활성화된 경우를 제외하고 `csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}}로 리다이렉트된다. +{{< feature-state for_k8s_version="v1.26" state="stable" >}} +쿠버네티스 {{< skew currentVersion >}}에서, 인-트리 `vsphereVolume` 타입을 위한 모든 작업은 +`csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 드라이버로 리다이렉트된다. [vSphere CSI 드라이버](https://github.com/kubernetes-sigs/vsphere-csi-driver)가 -클러스터에 설치되어 있어야 한다. 인-트리 `vsphereVolume` 마이그레이션에 대한 추가 조언은 VMware의 문서 페이지 +클러스터에 설치되어 있어야 한다. 인-트리 `vsphereVolume` 마이그레이션에 대한 추가 조언은 VMware의 문서 페이지 [인-트리 vSphere 볼륨을 vSphere 컨테이너 스토리지 플러그인으로 마이그레이션하기](https://docs.vmware.com/en/VMware-vSphere-Container-Storage-Plug-in/2.0/vmware-vsphere-csp-getting-started/GUID-968D421F-D464-4E22-8127-6CB9FF54423F.html)를 참고한다. +vSphere CSI 드라이버가 설치되어있지 않다면 볼륨 작업은 인-트리 `vsphereVolume` 타입으로 생성된 PV에서 수행될 수 없다. -쿠버네티스 v1.25 현재, 7.0u2 이하의 vSphere는 -(사용 중단된) 인-트리 vSphere 스토리지 드라이버가 지원되지 않는다. -사용 중단된 드라이버를 계속 사용하거나, 교체된 CSI 드라이버로 -마이그레이션하기 위해서는 vSphere 7.0u2 이상을 사용해야 한다. +vSphere CSI 드라이버로 마이그레이션하기 위해서는 vSphere 7.0u2 이상을 사용해야 한다. v{{< skew currentVersion >}} 외의 쿠버네티스 버전을 사용 중인 경우, 해당 쿠버네티스 버전의 문서를 참고한다. @@ -1220,7 +1239,7 @@ CSI 드라이버로 전환할 때 기존 스토리지 클래스, 퍼시스턴트 * [`gcePersistentDisk`](#gcepersistentdisk) * [`vsphereVolume`](#vspherevolume) -### flexVolume (사용 중단됨) {#flexvolume-deprecated} +### flexVolume (사용 중단됨) {#flexvolume} {{< feature-state for_k8s_version="v1.23" state="deprecated" >}} diff --git a/content/ko/docs/concepts/storage/windows-storage.md b/content/ko/docs/concepts/storage/windows-storage.md index 9dae4c3271c63..f5add4af56384 100644 --- a/content/ko/docs/concepts/storage/windows-storage.md +++ b/content/ko/docs/concepts/storage/windows-storage.md @@ -8,6 +8,7 @@ # - aravindhp title: 윈도우 스토리지 content_type: concept +weight: 110 --- @@ -56,9 +57,9 @@ content_type: concept [플러그인](/ko/docs/concepts/storage/volumes/#volume-types) 형태로 제공된다. 윈도우는 다음의 광역 쿠버네티스 볼륨 플러그인 클래스를 지원한다. -* [`FlexVolume 플러그인`](/ko/docs/concepts/storage/volumes/#flexvolume-deprecated) - * FlexVolumes은 1.23부터 사용 중단되었음에 유의한다. -* [`CSI 플러그인`](/ko/docs/concepts/storage/volumes/#csi) +* [`FlexVolume` 플러그인](/ko/docs/concepts/storage/volumes/#flexvolume) + * FlexVolume은 1.23부터 사용 중단되었음에 유의한다. +* [`CSI` 플러그인](/ko/docs/concepts/storage/volumes/#csi) ##### 인-트리(In-tree) 볼륨 플러그인