Merge pull request #32004 from jihoon-seo/220302_Translate_ephemeral-volumes

[ko] Translate 'Ephemeral Volumes'

Author: k8s-ci-robot

content/ko/docs/concepts/storage/ephemeral-volumes.md

@@ -0,0 +1,272 @@
+---
+
+
+
+
+
+
+title: 임시 볼륨
+content_type: concept
+weight: 30
+---
+
+<!-- overview -->
+
+이 문서는 쿠버네티스의 _임시(ephemeral) 볼륨_ 에 대해 설명한다. 
+쿠버네티스 [볼륨](/ko/docs/concepts/storage/volumes/), 
+특히 퍼시스턴트볼륨클레임(PersistentVolumeClaim) 및 퍼시스턴트볼륨(PersistentVolume)에 대해 잘 알고 있는 것이 좋다.
+
+<!-- body -->
+
+일부 애플리케이션은 추가적인 저장소를 필요로 하면서도 
+재시작 시 데이터의 영구적 보존 여부는 신경쓰지 않을 수도 있다. 
+예를 들어, 캐싱 서비스는 종종 메모리 사이즈에 제약을 받으며 
+이에 따라 전반적인 성능에 적은 영향을 미치면서도 
+사용 데이터를 메모리보다는 느린 저장소에 간헐적으로 옮길 수도 있다.
+
+또 다른 애플리케이션은 읽기 전용 입력 데이터를 파일에서 읽도록 되어 있으며, 
+이러한 데이터의 예시로는 구성 데이터 또는 비밀 키 등이 있다.
+
+_임시 볼륨_ 은 이러한 사용 사례를 위해 설계되었다. 
+임시 볼륨은 파드의 수명을 따르며 파드와 함께 생성 및 삭제되기 때문에, 
+일부 퍼시스턴트 볼륨이 어디에서 사용 가능한지에 제약되는 일 없이 
+파드가 중지 및 재시작될 수 있다.
+
+임시 볼륨은 파드 명세에 _인라인_ 으로 명시되며, 
+이로 인해 애플리케이션 배포 및 관리가 간편해진다.
+
+### 임시 볼륨의 종류
+
+쿠버네티스는 각 목적에 맞는 
+몇 가지의 임시 볼륨을 지원한다.
+- [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)를 참고한다.