임시 스토리지 유형은 포드가 사라진 후에는 지속되지 않습니다. 구성 정보를 위해 임시 스토리지를 사용하고 애플리케이션을 위해 스토리지를 캐시합니다.
임시 스토리지 유형은 노드의 부팅 디스크에서 리소스를 공유하고 소비합니다.
CPU 및 메모리 리소스 관리와 동일한 방식으로 로컬 임시 스토리지 리소스를 관리할 수 있습니다.
PersistentVolume 리소스를 사용하는 영구 스토리지
Kubernetes PersistentVolume은 Pod가 내구성 있는 스토리지에 사용할 수 있는 리소스입니다. 영구 볼륨의 수명은 pod의 수명과 별개입니다. 따라서 영구 볼륨의 디스크와 데이터는 클러스터가 변경되고 포드가 삭제되고 다시 생성되어도 계속 존재합니다. PersistentVolumeClaims API를 통해 PersistentVolume 리소스를 동적으로 프로비저닝하거나 클러스터 관리자가 리소스를 명시적으로 만들 수 있습니다.
Google Distributed Cloud는 컨테이너 스토리지 인터페이스(CSI) 드라이버 및 로컬 볼륨을 포함한 다양한 스토리지 시스템을 사용하여 영구 스토리지를 지원할 수 있습니다.
컨테이너 스토리지 인터페이스(CSI) 드라이버
Google Distributed Cloud는 CSI v1.0 드라이버와 호환됩니다.
CSI는 많은 주요 스토리지 공급업체가 지원하는 개방형 표준 인터페이스입니다. 프로덕션 스토리지의 경우 GDC Ready 스토리지 파트너의 CSI 드라이버를 설치합니다.
GDC Ready 스토리지 파트너의 전체 목록은 GDC Ready 스토리지 파트너를 참조하세요.
Google Distributed Cloud 클러스터는 로컬 볼륨 프로비저닝 도구(LVP)를 사용하여 로컬 영구 볼륨을 관리합니다. Google Distributed Cloud 클러스터에는 세 가지 유형의 로컬 영구 볼륨 스토리지 클래스가 있습니다.
LVP 공유
LVP 노드 마운트
Anthos 시스템
LVP 공유
이 옵션은 로컬 및 공유 파일 시스템의 하위 디렉터리가 지원하는 로컬 영구 볼륨을 만듭니다. 클러스터를 만들면 이러한 하위 디렉터리가 자동으로 생성됩니다. 이 스토리지 클래스를 사용하는 워크로드는 동일한 공유 파일 시스템이 영구 볼륨을 지원하기 때문에 용량 및 초당 입출력 작업 수(IOPS)를 공유합니다. 더 나은 격리를 위해 LVP 노드 마운트를 통해 디스크를 구성합니다.
이 스토리지 클래스는 클러스터를 만드는 동안 Anthos 시스템 pod가 사용하는 사전 구성된 로컬 영구 볼륨을 만듭니다. 스토리지 클래스 이름은 anthos-system입니다. 이 스토리지 클래스를 변경 또는 삭제하지 말고 스테이트풀(Stateful) 워크로드에 이 스토리지 클래스를 사용하지 마세요.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-01(UTC)"],[],[],null,["Google Distributed Cloud can use several storage configurations, and provides interfaces\nfor block and file storage management through the following Kubernetes objects:\n\n- [Volumes](https://kubernetes.io/docs/concepts/storage/volumes/)\n- [Persistent volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/)\n- [Storage classes](https://kubernetes.io/docs/concepts/storage/storage-classes/)\n- [Volume snapshots](https://kubernetes.io/docs/concepts/storage/volume-snapshots/)\n\n| **Warning:** Google Distributed Cloud doesn't include a persistent storage provider. You must provide and configure a persistent storage system for your stateful workloads.\n\nEphemeral Storage through Kubernetes volumes\n\nKubernetes `Volume` resources are storage units accessible to containers in a\n`Pod`. Ephemeral storage backs the following volume types:\n\n- [`emptyDir`](https://kubernetes.io/docs/concepts/storage/volumes/#emptydir)\n\n- [`ConfigMap`](https://kubernetes.io/docs/concepts/configuration/configmap/)\n\n- [`Secrets`](https://kubernetes.io/docs/concepts/configuration/secret/)\n\nEphemeral storage types don't persist after a pod ceases to exist. Use\nephemeral storage for configuration information and to cache storage for\napplications.\n\nEphemeral storage types share and consume resources from the node's boot disk.\nYou can [manage your local ephemeral storage resources](/kubernetes-engine/docs/concepts/cluster-architecture#local_ephemeral_storage)\nin the same way that you manage CPU and memory resources.\n\nPersistent Storage using `PersistentVolume` resources\n\nA Kubernetes `PersistentVolume` is a resource that a `Pod` can use for durable\nstorage. The lifetime of persistent volumes is independent from the lifetime of\na pod. Thus, the disk and data in a persistent volume continue to exist as the\ncluster changes and as pods are deleted and recreated. You can provision\n`PersistentVolume` resources dynamically through the `PersistentVolumeClaims`\nAPI, or a cluster administrator can create them explicitly.\n\nGoogle Distributed Cloud can back persistent storage by using a variety of storage\nsystems, including [Container Storage Interface (CSI)](https://kubernetes.io/docs/reference/glossary/?all=true#term-csi)\ndrivers and local volumes.\n\nContainer Storage Interface (CSI) drivers\n\nGoogle Distributed Cloud is compatible with [CSI v1.0 drivers](https://github.com/container-storage-interface/spec).\nCSI is an open standard interface that many major storage vendors\nsupport. For production storage, [install a CSI driver](/kubernetes-engine/distributed-cloud/bare-metal/docs/installing/install-csi-driver)\nfrom a GDC Ready storage partner.\nFor the full list of GDC Ready storage partners, see\n[GDC Ready Storage Partners](/kubernetes-engine/enterprise/docs/resources/partner-storage).\n\nTo use CSI in your cluster, deploy the CSI driver that your storage vendor\nprovided to your clusters. Then, configure workloads to\n[use the CSI driver with the `StorageClass` API](/kubernetes-engine/distributed-cloud/bare-metal/docs/installing/install-csi-driver#using_csi_driver),\nor set `StorageClass` as the [default API](/kubernetes-engine/distributed-cloud/bare-metal/docs/installing/default-storage-class).\n\nLocal volumes\n\nFor proof of concept and advanced use cases, you can use\n[local PersistentVolume resources](https://kubernetes.io/docs/concepts/storage/volumes/#local).\nGoogle Distributed Cloud bundles the\n[sig-storage-local-static-provisioner](https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner),\nwhich discovers mount points on each node and creates a local persistent volume\nfor each mount point.\n| **Caution:** Using a local persistent volume binds the pods to a specific disk and node. If that disk or node becomes unavailable, then the pods also become unavailable. Workloads using local PersistentVolume resources need to be resilient to this kind of failure, and may require additional orchestration to release the persistent volume claims of the pods and find a new and empty disk on another node.\n\nGoogle Distributed Cloud clusters use the local volume provisioner (LVP) to manage local\npersistent volumes. There are three types of storage classes for local\npersistent volumes in a Google Distributed Cloud cluster:\n\n- LVP share\n- LVP node mounts\n- Anthos system\n\nLVP share\n\nThis option creates a local persistent volume that subdirectories in a local and\nshared file system are backing. Cluster creation automatically generates these\nsubdirectories. Workloads using this storage class share capacity and\ninput/output operations per second (IOPS) because the same shared file system\nbacks the persistent volumes. To have better isolation, configure disks through\nLVP node mounts.\n\nFor more information, see\n[Configuring an LVP Share](/kubernetes-engine/distributed-cloud/bare-metal/docs/installing/configure-local-storage#configuring_an_lvp_share).\n\nLVP node mounts\n\nThis option creates a local persistent volume for each mounted disk in the configured\ndirectory. You must format and mount each disk before or after cluster creation.\n\nFor more information, see\n[Configuring LVP node mounts](/kubernetes-engine/distributed-cloud/bare-metal/docs/installing/configure-local-storage#configuring_lvp_node_mounts).\n\nAnthos system\n\nThis storage class creates preconfigured local persistent volumes during cluster\ncreation that the Anthos system pods use. The storage class name is\n`anthos-system`. Don't change or delete this storage class and don't use this\nstorage class for stateful workloads.\n\nWhat's next\n\n- Learn more about [volumes](/kubernetes-engine/docs/concepts/volumes).\n- Learn more about [Container Storage Interface](https://kubernetes.io/blog/2019/01/15/container-storage-interface-ga/) in Kubernetes.\n- Learn how to [take volume snapshots](/kubernetes-engine/docs/how-to/persistent-volumes/volume-snapshots).\n- Learn how to [increase the capacity of persistent volumes](/kubernetes-engine/docs/how-to/persistent-volumes/volume-expansion)."]]
