From cc8e3c58970c93964916135ae1ddd4aaf3dd1389 Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Wed, 2 Mar 2022 17:35:03 +0900 Subject: [PATCH] [ko] Translate 'Ephemeral Volumes' --- .../concepts/storage/ephemeral-volumes.md | 272 ++++++++++++++++++ 1 file changed, 272 insertions(+) create mode 100644 content/ko/docs/concepts/storage/ephemeral-volumes.md diff --git a/content/ko/docs/concepts/storage/ephemeral-volumes.md b/content/ko/docs/concepts/storage/ephemeral-volumes.md new file mode 100644 index 0000000000..ea3a05d74b --- /dev/null +++ b/content/ko/docs/concepts/storage/ephemeral-volumes.md @@ -0,0 +1,272 @@ +--- + + + + + + +title: 임시 볼륨 +content_type: concept +weight: 30 +--- + + + +이 문서는 쿠버네티스의 _임시(ephemeral) 볼륨_ 에 대해 설명한다. +쿠버네티스 [볼륨](/ko/docs/concepts/storage/volumes/), +특히 퍼시스턴트볼륨클레임(PersistentVolumeClaim) 및 퍼시스턴트볼륨(PersistentVolume)에 대해 잘 알고 있는 것이 좋다. + + + +일부 애플리케이션은 추가적인 저장소를 필요로 하면서도 +재시작 시 데이터의 영구적 보존 여부는 신경쓰지 않을 수도 있다. +예를 들어, 캐싱 서비스는 종종 메모리 사이즈에 제약을 받으며 +이에 따라 전반적인 성능에 적은 영향을 미치면서도 +사용 데이터를 메모리보다는 느린 저장소에 간헐적으로 옮길 수도 있다. + +또 다른 애플리케이션은 읽기 전용 입력 데이터를 파일에서 읽도록 되어 있으며, +이러한 데이터의 예시로는 구성 데이터 또는 비밀 키 등이 있다. + +_임시 볼륨_ 은 이러한 사용 사례를 위해 설계되었다. +임시 볼륨은 파드의 수명을 따르며 파드와 함께 생성 및 삭제되기 때문에, +일부 퍼시스턴트 볼륨이 어디에서 사용 가능한지에 제약되는 일 없이 +파드가 중지 및 재시작될 수 있다. + +임시 볼륨은 파드 명세에 _인라인_ 으로 명시되며, +이로 인해 애플리케이션 배포 및 관리가 간편해진다. + +### 임시 볼륨의 종류 + +쿠버네티스는 각 목적에 맞는 +몇 가지의 임시 볼륨을 지원한다. +- [emptyDir](/ko/docs/concepts/storage/volumes/#emptydir): + 파드가 시작될 때 빈 상태로 시작되며, + 저장소는 로컬의 kubelet 베이스 디렉터리(보통 루트 디스크) 또는 램에서 제공된다 +- [configMap](/ko/docs/concepts/storage/volumes/#configmap), + [downwardAPI](/ko/docs/concepts/storage/volumes/#downwardapi), + [secret](/ko/docs/concepts/storage/volumes/#secret): + 각 종류의 쿠버네티스 데이터를 파드에 주입한다 +- [CSI 임시 볼륨](#csi-ephemeral-volumes): + 앞의 볼륨 종류와 비슷하지만, + 특히 [이 기능을 지원](https://kubernetes-csi.github.io/docs/drivers.html)하는 특수한 + [CSI 드라이버](https://github.com/container-storage-interface/spec/blob/master/spec.md)에 의해 제공된다 +- [일반(generic) 임시 볼륨](#generic-ephemeral-volumes): + 퍼시스턴트 볼륨도 지원하는 모든 스토리지 드라이버에 의해 제공될 수 있다 + +`emptyDir`, `configMap`, `downwardAPI`, `secret`은 +[로컬 임시 스토리지](/ko/docs/concepts/configuration/manage-resources-containers/#로컬-임시-ephemeral-스토리지)로서 +제공된다. +이들은 각 노드의 kubelet에 의해 관리된다. + +CSI 임시 볼륨은 +써드파티 CSI 스토리지 드라이버에 의해 제공 *되어야 한다*. + +일반 임시 볼륨은 써드파티 CSI 스토리지 드라이버에 의해 제공 *될 수 있지만*, +동적 프로비저닝을 지원하는 다른 스토리지 드라이버에 의해서도 제공될 수 있다. +일부 CSI 드라이버는 특히 CSI 임시 볼륨을 위해 만들어져서 +동적 프로비저닝을 지원하지 않는데, +이러한 경우에는 일반 임시 볼륨 용으로는 사용할 수 없다. + +써드파티 드라이버 사용의 장점은 +쿠버네티스 자체적으로는 지원하지 않는 기능(예: +kubelet에서 관리하는 디스크와 성능 특성이 다른 스토리지, 또는 다른 데이터 주입)을 +제공할 수 있다는 것이다. + +### CSI 임시 볼륨 {#csi-ephemeral-volumes} + +{{< feature-state for_k8s_version="v1.16" state="beta" >}} + +이 기능을 사용하려면 `CSIInlineVolume` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다. +쿠버네티스 1.16부터는 기본적으로 활성화되어 있다. + +{{< note >}} +CSI 드라이버 중 일부만 CSI 임시 볼륨을 지원한다. +쿠버네티스 CSI [드라이버 목록](https://kubernetes-csi.github.io/docs/drivers.html)에서 +어떤 드라이버가 임시 볼륨을 지원하는지 보여 준다. +{{< /note >}} + +개념적으로, CSI 임시 볼륨은 `configMap`, `downwardAPI`, `secret` 볼륨 유형과 비슷하다. +즉, 스토리지는 각 노드에서 로컬하게 관리되며, +파드가 노드에 스케줄링된 이후에 다른 로컬 리소스와 함께 생성된다. +쿠버네티스에는 지금 단계에서는 파드를 재스케줄링하는 개념이 없다. +볼륨 생성은 실패하는 일이 거의 없어야 하며, +만약 실패할 경우 파드 시작 과정이 중단될 것이다. +특히, [스토리지 용량 인지 파드 스케줄링](/ko/docs/concepts/storage/storage-capacity/)은 +이러한 볼륨에 대해서는 지원되지 *않는다*. +또한 이러한 볼륨은 파드의 스토리지 자원 사용 상한에 제한받지 않는데, +이는 kubelet 자신이 관리하는 스토리지에만 강제할 수 있는 것이기 때문이다. + + +다음은 CSI 임시 스토리지를 사용하는 파드에 대한 예시 매니페스트이다. + +```yaml +kind: Pod +apiVersion: v1 +metadata: + name: my-csi-app +spec: + containers: + - name: my-frontend + image: busybox + volumeMounts: + - mountPath: "/data" + name: my-csi-inline-vol + command: [ "sleep", "1000000" ] + volumes: + - name: my-csi-inline-vol + csi: + driver: inline.storage.kubernetes.io + volumeAttributes: + foo: bar +``` + +`volumeAttributes`은 드라이버에 의해 어떤 볼륨이 준비되는지를 결정한다. +이러한 속성은 각 드라이버별로 다르며 표준화되지 않았다. +더 자세한 사항은 각 CSI 드라이버 문서를 +참고한다. + +클러스터 관리자는, [파드시큐리티폴리시(PodSecurityPolicy)](/ko/docs/concepts/policy/pod-security-policy/)를 사용하여 파드 내에서 어떤 CSI 드라이버가 사용될 수 있는지를 제어할 수 있으며, +[`allowedCSIDrivers` 필드](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicyspec-v1beta1-policy)에 기재하면 된다. + +### 일반 임시 볼륨 {#generic-ephemeral-volumes} + +{{< feature-state for_k8s_version="v1.23" state="stable" >}} + +일반 임시 볼륨은 +프로비저닝 후 일반적으로 비어 있는 스크래치 데이터에 대해 파드 별 디렉터리를 제공한다는 점에서 +`emptyDir` 볼륨과 유사하다. +하지만 다음과 같은 추가 기능도 제공한다. + +- 스토리지는 로컬이거나 네트워크 연결형(network-attached)일 수 있다. +- 볼륨의 크기를 고정할 수 있으며 파드는 이 크기를 초과할 수 없다. +- 드라이버와 파라미터에 따라 + 볼륨이 초기 데이터를 가질 수도 있다. +- 볼륨에 대한 일반적인 작업은 드라이버가 지원하는 범위 내에서 지원된다. + 이와 같은 작업은 다음을 포함한다. + [스냅샷](/ko/docs/concepts/storage/volume-snapshots/), + [복제](/ko/docs/concepts/storage/volume-pvc-datasource/), + [크기 조정](/ko/docs/concepts/storage/persistent-volumes/#퍼시스턴트-볼륨-클레임-확장), + 및 [스토리지 용량 추적](/ko/docs/concepts/storage/storage-capacity/). + +다음은 예시이다. + +```yaml +kind: Pod +apiVersion: v1 +metadata: + name: my-app +spec: + containers: + - name: my-frontend + image: busybox + volumeMounts: + - mountPath: "/scratch" + name: scratch-volume + command: [ "sleep", "1000000" ] + volumes: + - name: scratch-volume + ephemeral: + volumeClaimTemplate: + metadata: + labels: + type: my-frontend-volume + spec: + accessModes: [ "ReadWriteOnce" ] + storageClassName: "scratch-storage-class" + resources: + requests: + storage: 1Gi +``` + +### 라이프사이클 및 퍼시스턴트볼륨클레임 + +핵심 설계 아이디어는 +[볼륨 클레임을 위한 파라미터](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ephemeralvolumesource-v1alpha1-core)는 +파드의 볼륨 소스 내부에서 허용된다는 점이다. +레이블, 어노테이션 및 퍼시스턴트볼륨클레임을 위한 모든 필드가 지원된다. +이러한 파드가 생성되면, 임시 볼륨 컨트롤러는 파드가 속한 동일한 네임스페이스에 +퍼시스턴트볼륨클레임 오브젝트를 생성하고 +파드가 삭제될 때에는 퍼시스턴트볼륨클레임도 삭제되도록 만든다. + +이는 볼륨 바인딩 및/또는 프로비저닝을 유발하는데, +{{< glossary_tooltip text="스토리지클래스" term_id="storage-class" >}}가 +즉각적인(immediate) 볼륨 바인딩을 사용하는 경우에는 즉시, +또는 파드가 노드에 잠정적으로 스케줄링되었을 때 발생한다(`WaitForFirstConsumer` 볼륨 바인딩 모드). +일반 임시 볼륨에는 후자가 추천되는데, 이 경우 스케줄러가 파드를 할당하기에 적합한 노드를 선택하기가 쉬워지기 때문이다. +즉각적인 바인딩을 사용하는 경우, +스케줄러는 볼륨이 사용 가능해지는 즉시 해당 볼륨에 접근 가능한 노드를 선택하도록 강요받는다. + +[리소스 소유권](/ko/docs/concepts/workloads/controllers/garbage-collection/#소유자-owner-와-종속-dependent) 관점에서, +일반 임시 스토리지를 갖는 파드는 +해당 임시 스토리지를 제공하는 퍼시스턴트볼륨클레임의 소유자이다. +파드가 삭제되면, 쿠버네티스 가비지 콜렉터는 해당 PVC를 삭제하는데, +스토리지 클래스의 기본 회수 정책이 볼륨을 삭제하는 것이기 때문에 PVC의 삭제는 보통 볼륨의 삭제를 유발한다. +회수 정책을 `retain`으로 설정한 스토리지클래스를 사용하여 준 임시(quasi-ephemeral) 로컬 스토리지를 생성할 수도 있는데, +이렇게 하면 스토리지의 수명이 파드의 수명보다 길어지며, +이러한 경우 볼륨 정리를 별도로 수행해야 함을 명심해야 한다. + +이러한 PVC가 존재하는 동안은, 다른 PVC와 동일하게 사용될 수 있다. +특히, 볼륨 복제 또는 스냅샷 시에 데이터 소스로 참조될 수 있다. +또한 해당 PVC 오브젝트는 해당 볼륨의 현재 상태도 +가지고 있다. + +### 퍼시스턴트볼륨클레임 이름 정하기 + +자동으로 생성된 PVC의 이름은 규칙에 따라 정해진다. +PVC의 이름은 파드 이름과 볼륨 이름의 사이를 하이픈(`-`)으로 결합한 형태이다. +위의 예시에서, PVC 이름은 `my-app-scratch-volume`가 된다. +이렇게 규칙에 의해 정해진 이름은 PVC와의 상호작용을 더 쉽게 만드는데, +이는 파드 이름과 볼륨 이름을 알면 +PVC 이름을 별도로 검색할 필요가 없기 때문이다. + +PVC 이름 규칙에 따라 서로 다른 파드 간 이름 충돌이 발생할 수 +있으며("pod-a" 파드 + "scratch" 볼륨 vs. "pod" 파드 + "a-scratch" 볼륨 - +두 경우 모두 PVC 이름은 "pod-a-scratch") +또한 파드와 수동으로 생성한 PVC 간에도 이름 충돌이 발생할 수 있다. + +이러한 충돌은 감지될 수 있는데, 이는 PVC가 파드를 위해 생성된 경우에만 임시 볼륨으로 사용되기 때문이다. +이러한 체크는 소유권 관계를 기반으로 한다. +기존에 존재하던 PVC는 덮어써지거나 수정되지 않는다. +대신에 충돌을 해결해주지는 않는데, +이는 적합한 PVC가 없이는 파드가 시작될 수 없기 때문이다. + +{{< caution >}} +이러한 충돌이 발생하지 않도록 +동일한 네임스페이스 내에서는 파드와 볼륨의 이름을 정할 때 주의해야 한다. +{{< /caution >}} + +### 보안 + +GenericEphemeralVolume 기능을 활성화하면 +사용자가 파드를 생성할 수 있는 경우 PVC를 간접적으로 생성할 수 있도록 허용하며, +심지어 사용자가 PVC를 직접적으로 만들 수 있는 권한이 없는 경우에도 이를 허용한다. +클러스터 관리자는 이를 명심해야 한다. +이것이 보안 모델에 부합하지 않는다면, 다음의 두 가지 선택지가 있다. +- `volumes`의 목록 중에 `ephemeral` 볼륨 타입이 없는 경우, + [파드시큐리티폴리시](/ko/docs/concepts/policy/pod-security-policy/)를 + 사용한다(쿠버네티스 + 1.21에서 사용 중단됨). +- 일반 임시 볼륨을 갖는 파드와 같은 오브젝트를 거부하는 + [어드미션 웹훅](/docs/reference/access-authn-authz/extensible-admission-controllers/)을 + 사용한다. + +일반적인 [PVC의 네임스페이스 쿼터](/ko/docs/concepts/policy/resource-quotas/#스토리지-리소스-쿼터)는 여전히 적용되므로, +사용자가 이 새로운 메카니즘을 사용할 수 있도록 허용되었어도, +다른 정책을 우회하는 데에는 사용할 수 없다. + +## {{% heading "whatsnext" %}} + +### kubelet이 관리하는 임시 볼륨 + +[로컬 임시 스토리지](/ko/docs/concepts/configuration/manage-resources-containers/#로컬-임시-ephemeral-스토리지)를 참고한다. + +### CSI 임시 볼륨 + +- 설계에 대한 더 자세한 정보는 + [임시 인라인 CSI 볼륨 KEP](https://github.com/kubernetes/enhancements/blob/ad6021b3d61a49040a3f835e12c8bb5424db2bbb/keps/sig-storage/20190122-csi-inline-volumes.md)를 참고한다. +- 이 기능의 추가 개발에 대한 자세한 정보는 [enhancement 저장소의 이슈 #596](https://github.com/kubernetes/enhancements/issues/596)을 참고한다. + +### 일반 임시 볼륨 + +- 설계에 대한 더 자세한 정보는 + [일반 임시 인라인 볼륨 KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/1698-generic-ephemeral-volumes/README.md)를 참고한다.