欧美一区二区在线激情免费播放,国产伦精品一区二区三区免费介绍,caoo操超碰久久

新聞中心

這里有您想知道的互聯網營銷解決方案

創(chuàng)新互聯kubernetes教程：Kubernetes卷

卷

Container 中的文件在磁盤上是臨時存放的，這給 Container 中運行的較重要的應用程序帶來一些問題。問題之一是當容器崩潰時文件丟失。 kubelet 會重新啟動容器，但容器會以干凈的狀態(tài)重啟。第二個問題會在同一 ?Pod ?中運行多個容器并共享文件時出現。 Kubernetes 卷（Volume）這一抽象概念能夠解決這兩個問題。

背景

Docker 也有卷（Volume）的概念，但對它只有少量且松散的管理。 Docker 卷是磁盤上或者另外一個容器內的一個目錄。 Docker 提供卷驅動程序，但是其功能非常有限。

Kubernetes 支持很多類型的卷。 Pod 可以同時使用任意數目的卷類型。臨時卷類型的生命周期與 Pod 相同，但持久卷可以比 Pod 的存活期長。當 Pod 不再存在時，Kubernetes 也會銷毀臨時卷；不過 Kubernetes 不會銷毀持久卷。對于給定 Pod 中任何類型的卷，在容器重啟期間數據都不會丟失。

卷的核心是一個目錄，其中可能存有數據，Pod 中的容器可以訪問該目錄中的數據。所采用的特定的卷類型將決定該目錄如何形成的、使用何種介質保存數據以及目錄中存放的內容。

使用卷時, 在 ?.spec.volumes? 字段中設置為 Pod 提供的卷，并在 ?.spec.containers[*].volumeMounts? 字段中聲明卷在容器中的掛載位置。容器中的進程看到的文件系統(tǒng)視圖是由它們的容器鏡像的初始內容以及掛載在容器中的卷（如果定義了的話）所組成的。其中根文件系統(tǒng)同容器鏡像的內容相吻合。任何在該文件系統(tǒng)下的寫入操作，如果被允許的話，都會影響接下來容器中進程訪問文件系統(tǒng)時所看到的內容。

卷掛載在鏡像中的指定路徑下。 Pod 配置中的每個容器必須獨立指定各個卷的掛載位置。

卷不能掛載到其他卷之上（不過存在一種使用 subPath 的相關機制），也不能與其他卷有硬鏈接。

卷類型

Kubernetes 支持下列類型的卷：

awsElasticBlockStore

?awsElasticBlockStore ?卷將 Amazon Web服務（AWS）EBS 卷掛載到你的 Pod 中。與 ?emptyDir ?在 Pod 被刪除時也被刪除不同，EBS 卷的內容在刪除 Pod 時會被保留，卷只是被卸載掉了。這意味著 EBS 卷可以預先填充數據，并且該數據可以在 Pod 之間共享。

你在使用 EBS 卷之前必須使用 ?aws ec2 create-volume? 命令或者 AWS API 創(chuàng)建該卷。

使用 ?awsElasticBlockStore ?卷時有一些限制：

Pod 運行所在的節(jié)點必須是 AWS EC2 實例。
這些實例需要與 EBS 卷在相同的地域（Region）和可用區(qū)（Availability-Zone）。
EBS 卷只支持被掛載到單個 EC2 實例上。

創(chuàng)建 EBS 卷

在將 EBS 卷用到 Pod 上之前，你首先要創(chuàng)建它。

aws ec2 create-volume --availability-zone=eu-west-1a --size=10 --volume-type=gp2

確保該區(qū)域與你的群集所在的區(qū)域相匹配。還要檢查卷的大小和 EBS 卷類型都適合你的用途。

AWS EBS 配置示例

apiVersion: v1
kind: Pod
metadata:
  name: test-ebs
spec:
  containers:
  - image: K8S.gcr.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /test-ebs
      name: test-volume
  volumes:
  - name: test-volume
    # 此 AWS EBS 卷必須已經存在
    awsElasticBlockStore:
      volumeID: ""
      fsType: ext4

如果 EBS 卷是分區(qū)的，你可以提供可選的字段 ?partition: ""? 來指定要掛載到哪個分區(qū)上。

AWS EBS CSI 卷遷移

FEATURE STATE: Kubernetes v1.17 [beta]

如果啟用了對 ?awsElasticBlockStore ?的 ?CSIMigration ?特性支持，所有插件操作都不再指向樹內插件（In-Tree Plugin），轉而指向 ?ebs.csi.aws.com? 容器存儲接口（Container Storage Interface，CSI）驅動。為了使用此特性，必須在集群中安裝 AWS EBS CSI 驅動，并確保 ?CSIMigration ?和 ?CSIMigrationAWS ?Beta 功能特性被啟用。

AWS EBS CSI 遷移結束

FEATURE STATE: Kubernetes v1.17 [alpha]

要禁止控制器管理器和 kubelet 加載 ?awsElasticBlockStore ?存儲插件，請將 ?InTreePluginAWSUnregister ?標志設置為 ?true?。

azureDisk

?azureDisk ?卷類型用來在 Pod 上掛載 Microsoft Azure 數據盤（Data Disk）。若需了解更多詳情，請參考 azureDisk 卷插件。

azureDisk 的 CSI 遷移

FEATURE STATE: Kubernetes v1.19 [beta]

啟用 ??azureDisk ??的 ??CSIMigration ??功能后，所有插件操作從現有的樹內插件重定向到 ?disk.csi.azure.com? 容器存儲接口（CSI）驅動程序。為了使用此功能，必須在集群中安裝 ?Azure 磁盤 CSI 驅動?程序，并且 ?CSIMigration ?和 ?CSIMigrationAzureDisk ?功能必須被啟用。

azureDisk CSI 遷移完成

FEATURE STATE: Kubernetes v1.21 [alpha]

要禁止控制器管理器和 kubelet 加載 ?azureDisk ?存儲插件，請將 ?InTreePluginAzureDiskUnregister ?標志設置為 ?true?。

azureFile

?azureFile ?卷類型用來在 Pod 上掛載 Microsoft Azure 文件卷（File Volume）（SMB 2.1 和 3.0）。更多詳情請參考 azureFile 卷插件。

azureFile CSI 遷移

FEATURE STATE: Kubernetes v1.21 [beta]

啟用 ?azureFile ?的 ?CSIMigration ?功能后，所有插件操作將從現有的樹內插件重定向到 ?file.csi.azure.com? 容器存儲接口（CSI）驅動程序。要使用此功能，必須在集群中安裝 Azure 文件 CSI 驅動程序，并且 ?CSIMigration ?和 ?CSIMigrationAzureFile ?特性門控必須被啟用。

Azure 文件 CSI 驅動尚不支持為同一卷設置不同的 fsgroup。如果 AzureFile CSI 遷移被啟用，用不同的 fsgroup 來使用同一卷也是不被支持的。

azureDisk CSI 遷移完成

FEATURE STATE: Kubernetes v1.21 [alpha]

要禁止控制器管理器和 kubelet 加載 ?azureDisk ?存儲插件，請將 ?InTreePluginAzureDiskUnregister ?標志設置為 ?true?。

cephfs

?cephfs ?卷允許你將現存的 CephFS 卷掛載到 Pod 中。不像 ?emptyDir ?那樣會在 Pod 被刪除的同時也會被刪除，?cephfs ?卷的內容在 Pod 被刪除時會被保留，只是卷被卸載了。這意味著 ?cephfs ?卷可以被預先填充數據，且這些數據可以在 Pod 之間共享。同一 ?cephfs ?卷可同時被多個寫者掛載。

在使用 Ceph 卷之前，你的 Ceph 服務器必須已經運行并將要使用的 share 導出（exported）。

更多信息請參考 CephFS 示例。

cinder

Kubernetes 必須配置了 OpenStack Cloud Provider。

?cinder ?卷類型用于將 OpenStack Cinder 卷掛載到 Pod 中。

Cinder 卷示例配置

apiVersion: v1
kind: Pod
metadata:
  name: test-cinder
spec:
  containers:
  - image: k8s.gcr.io/test-webserver
    name: test-cinder-container
    volumeMounts:
    - mountPath: /test-cinder
      name: test-volume
  volumes:
  - name: test-volume
    # 此 OpenStack 卷必須已經存在
    cinder:
      volumeID: ""
      fsType: ext4

OpenStack CSI 遷移

FEATURE STATE: Kubernetes v1.21 [beta]

Cinder 的 ?CSIMigration ?功能在 Kubernetes 1.21 版本中是默認被啟用的。此特性會將插件的所有操作從現有的樹內插件重定向到 ?cinder.csi.openstack.org? 容器存儲接口（CSI）驅動程序。為了使用此功能，必須在集群中安裝 OpenStack Cinder CSI 驅動程序，你可以通過設置 ?CSIMigrationOpenStack ?特性門控為 ?false ?來禁止 Cinder CSI 遷移。如果你禁用了 ?CSIMigrationOpenStack ?功能特性，則樹內的 Cinder 卷插件會負責 Cinder 卷存儲管理的方方面面。

configMap

?configMap ?卷提供了向 Pod 注入配置數據的方法。 ConfigMap 對象中存儲的數據可以被 ?configMap ?類型的卷引用，然后被 Pod 中運行的容器化應用使用。

引用 configMap 對象時，你可以在 volume 中通過它的名稱來引用。你可以自定義 ConfigMap 中特定條目所要使用的路徑。下面的配置顯示了如何將名為 ?log-config? 的 ConfigMap 掛載到名為 ?configmap-pod? 的 Pod 中：

apiVersion: v1
kind: Pod
metadata:
  name: configmap-pod
spec:
  containers:
    - name: test
      image: busybox:1.28
      volumeMounts:
        - name: config-vol
          mountPath: /etc/config
  volumes:
    - name: config-vol
      configMap:
        name: log-config
        items:
          - key: log_level
            path: log_level

?log-config? ConfigMap 以卷的形式掛載，并且存儲在 ?log_level ?條目中的所有內容都被掛載到 Pod 的 ?/etc/config/log_level? 路徑下。請注意，這個路徑來源于卷的 ?mountPath ?和 ?log_level ?鍵對應的 ?path?。

在使用 ConfigMap 之前你首先要創(chuàng)建它。

容器以 subPath 卷掛載方式使用 ConfigMap 時，將無法接收 ConfigMap 的更新。

文本數據掛載成文件時采用 UTF-8 字符編碼。如果使用其他字符編碼形式，可使用 ?binaryData ?字段。

downwardAPI

?downwardAPI ?卷用于使 downward API 數據對應用程序可用。這種卷類型掛載一個目錄并在純文本文件中寫入所請求的數據。

容器以 subPath 卷掛載方式使用 downwardAPI 時，將不能接收到它的更新。

emptyDir

當 Pod 分派到某個 Node 上時，?emptyDir ?卷會被創(chuàng)建，并且在 Pod 在該節(jié)點上運行期間，卷一直存在。就像其名稱表示的那樣，卷最初是空的。盡管 Pod 中的容器掛載 ?emptyDir ?卷的路徑可能相同也可能不同，這些容器都可以讀寫 ?emptyDir ?卷中相同的文件。當 Pod 因為某些原因被從節(jié)點上刪除時，?emptyDir ?卷中的數據也會被永久刪除。

容器崩潰并不會導致 Pod 被從節(jié)點上移除，因此容器崩潰期間 ?emptyDir ?卷中的數據是安全的。

?emptyDir ?的一些用途：

緩存空間，例如基于磁盤的歸并排序。
為耗時較長的計算任務提供檢查點，以便任務能方便地從崩潰前狀態(tài)恢復執(zhí)行。
在 Web 服務器容器服務數據時，保存內容管理器容器獲取的文件。

取決于你的環(huán)境，?emptyDir ?卷存儲在該節(jié)點所使用的介質上；這里的介質可以是磁盤或 SSD 或網絡存儲。但是，你可以將 ?emptyDir.medium? 字段設置為 ?"Memory"?，以告訴 Kubernetes 為你掛載 tmpfs（基于 RAM 的文件系統(tǒng)）。雖然 tmpfs 速度非常快，但是要注意它與磁盤不同。 tmpfs 在節(jié)點重啟時會被清除，并且你所寫入的所有文件都會計入容?的內存消耗，受容?內存限制約束。

當啟用 ?SizeMemoryBackedVolumes ?特性門控時，你可以為基于內存提供的卷指定大小。如果未指定大小，則基于內存的卷的大小為 Linux 主機上內存的 50％。

emptyDir 配置示例

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: k8s.gcr.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /cache
      name: cache-volume
  volumes:
  - name: cache-volume
    emptyDir: {}

fc (光纖通道)

?fc ?卷類型允許將現有的光纖通道塊存儲卷掛載到 Pod 中。可以使用卷配置中的參數 ?targetWWNs ?來指定單個或多個目標 WWN（World Wide Names）。如果指定了多個 WWN，targetWWNs 期望這些 WWN 來自多路徑連接。

你必須配置 FC SAN Zoning，以便預先向目標 WWN 分配和屏蔽這些 LUN（卷），這樣 Kubernetes 主機才可以訪問它們。

更多詳情請參考 FC 示例。

flocker （已棄用）

Flocker 是一個開源的、集群化的容?數據卷管理?。 Flocker 提供了由各種存儲后端所支持的數據卷的管理和編排。

使用 ?flocker ?卷可以將一個 Flocker 數據集掛載到 Pod 中。如果數據集在 Flocker 中不存在，則需要首先使用 Flocker CLI 或 Flocker API 創(chuàng)建數據集。如果數據集已經存在，那么 Flocker 將把它重新附加到 Pod 被調度的節(jié)點。這意味著數據可以根據需要在 Pod 之間共享。

在使用 Flocker 之前你必須先安裝運行自己的 Flocker。

更多詳情請參考 Flocker 示例。

gcePersistentDisk

?gcePersistentDisk ?卷能將谷歌計算引擎 (GCE) 持久盤（PD）掛載到你的 Pod 中。不像 ?emptyDir ?那樣會在 Pod 被刪除的同時也會被刪除，持久盤卷的內容在刪除 Pod 時會被保留，卷只是被卸載了。這意味著持久盤卷可以被預先填充數據，并且這些數據可以在 Pod 之間共享。

在使用 PD 前，你必須使用 ?gcloud ?或者 GCE API 或 UI 創(chuàng)建它。

使用 ?gcePersistentDisk ?時有一些限制：

運行 Pod 的節(jié)點必須是 GCE VM
這些 VM 必須和持久盤位于相同的 GCE 項目和區(qū)域（zone）

GCE PD 的一個特點是它們可以同時被多個消費者以只讀方式掛載。這意味著你可以用數據集預先填充 PD，然后根據需要并行地在盡可能多的 Pod 中提供該數據集。不幸的是，PD 只能由單個使用者以讀寫模式掛載 —— 即不允許同時寫入。

在由 ReplicationController 所管理的 Pod 上使用 GCE PD 將會失敗，除非 PD 是只讀模式或者副本的數量是 0 或 1。

創(chuàng)建 GCE 持久盤（PD）

在 Pod 中使用 GCE 持久盤之前，你首先要創(chuàng)建它。

gcloud compute disks create --size=500GB --zone=us-central1-a my-data-disk

GCE 持久盤配置示例

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: k8s.gcr.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /test-pd
      name: test-volume
  volumes:
  - name: test-volume
    # 此 GCE PD 必須已經存在
    gcePersistentDisk:
      pdName: my-data-disk
      fsType: ext4

區(qū)域持久盤

區(qū)域持久盤功能允許你創(chuàng)建能在同一區(qū)域的兩個可用區(qū)中使用的持久盤。要使用這個功能，必須以持久卷（PersistentVolume）的方式提供卷；直接從 Pod 引用這種卷是不可以的。

手動供應基于區(qū)域 PD 的 PersistentVolume

使用為 GCE PD 定義的存儲類可以實現動態(tài)供應。在創(chuàng)建 PersistentVolume 之前，你首先要創(chuàng)建 PD。

gcloud beta compute disks create --size=500GB my-data-disk
    --region us-central1
    --replica-zones us-central1-a,us-central1-b

PersistentVolume 示例：

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
  accessModes:
  - ReadWriteOnce
  gcePersistentDisk:
    pdName: my-data-disk
    fsType: ext4
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        # failure-domain.beta.kubernetes.io/zone 應在 1.21 之前使用
        - key: topology.kubernetes.io/zone
          operator: In
          values:
          - us-central1-a
          - us-central1-b

GCE CSI 遷移

FEATURE STATE: Kubernetes v1.17 [beta]

啟用 GCE PD 的 ?CSIMigration ?功能后，所有插件操作將從現有的樹內插件重定向到 ?pd.csi.storage.gke.io? 容器存儲接口（ CSI ）驅動程序。為了使用此功能，必須在集群中上安裝 GCE PD CSI驅動程序，并且 ?CSIMigration ?和 ?CSIMigrationGCE ?Beta 功能必須被啟用。

GCE CSI 遷移完成

FEATURE STATE: Kubernetes v1.21 [alpha]

要禁止控制器管理器和 kubelet 加載 ?gcePersistentDisk ?存儲插件，請將 ?InTreePluginGCEUnregister ?標志設置為 ?true?。

gitRepo (已棄用)

?gitRepo ?卷類型已經被廢棄。如果需要在容?中提供 git 倉庫，請將一個 EmptyDir 卷掛載到 InitContainer 中，使用 git 命令完成倉庫的克隆操作，然后將 EmptyDir 卷掛載到 Pod 的容器中。

?gitRepo ?卷是一個卷插件的例子。該查卷掛載一個空目錄，并將一個 Git 代碼倉庫克隆到這個目錄中供 Pod 使用。

下面給出一個 ?gitRepo ?卷的示例：

apiVersion: v1
kind: Pod
metadata:
  name: server
spec:
  containers:
  - image: nginx
    name: nginx
    volumeMounts:
    - mountPath: /mypath
      name: git-volume
  volumes:
  - name: git-volume
    gitRepo:
      repository: "git@somewhere:me/my-git-repository.git"
      revision: "22f1d8406d464b0c0874075539c1f2e96c253775"

glusterfs

?glusterfs ?卷能將 Glusterfs (一個開源的網絡文件系統(tǒng)) 掛載到你的 Pod 中。不像 ?emptyDir ?那樣會在刪除 Pod 的同時也會被刪除，?glusterfs ?卷的內容在刪除 Pod 時會被保存，卷只是被卸載。這意味著 ?glusterfs ?卷可以被預先填充數據，并且這些數據可以在 Pod 之間共享。 GlusterFS 可以被多個寫者同時掛載。

在使用前你必須先安裝運行自己的 GlusterFS。

更多詳情請參考 GlusterFS 示例。

hostPath

HostPath 卷存在許多安全風險，最佳做法是盡可能避免使用 HostPath。當必須使用 HostPath 卷時，它的范圍應僅限于所需的文件或目錄，并以只讀方式掛載。

如果通過 AdmissionPolicy 限制 HostPath 對特定目錄的訪問，則必須要求 ?
volumeMounts ?使用 ?
readOnly ?掛載以使策略生效。

?hostPath ?卷能將主機節(jié)點文件系統(tǒng)上的文件或目錄掛載到你的 Pod 中。雖然這不是大多數 Pod 需要的，但是它為一些應用程序提供了強大的逃生艙。

例如，?hostPath ?的一些用法有：

運行一個需要訪問 Docker 內部機制的容器；可使用 ?hostPath ?掛載 ?/var/lib/docker? 路徑。
在容器中運行 cAdvisor 時，以 ?hostPath ?方式掛載 ?/sys?。
允許 Pod 指定給定的 ?hostPath ?在運行 Pod 之前是否應該存在，是否應該創(chuàng)建以及應該以什么方式存在。

除了必需的 ?path ?屬性之外，用戶可以選擇性地為 ?hostPath ?卷指定 ?type?。

支持的 ?type ?值如下：

取值	行為
	空字符串（默認）用于向后兼容，這意味著在安裝 hostPath 卷之前不會執(zhí)行任何檢查。
`DirectoryOrCreate`	如果在給定路徑上什么都不存在，那么將根據需要創(chuàng)建空目錄，權限設置為 0755，具有與 kubelet 相同的組和屬主信息。
`Directory`	在給定路徑上必須存在的目錄。
`FileOrCreate`	如果在給定路徑上什么都不存在，那么將在那里根據需要創(chuàng)建空文件，權限設置為 0644，具有與 kubelet 相同的組和所有權。
`File`	在給定路徑上必須存在的文件。
`Socket`	在給定路徑上必須存在的 UNIX 套接字。
`CharDevice`	在給定路徑上必須存在的字符設備。
`BlockDevice`	在給定路徑上必須存在的塊設備。

當使用這種類型的卷時要小心，因為：

HostPath 卷可能會暴露特權系統(tǒng)憑據（例如 Kubelet）或特權 API（例如容器運行時套接字），可用于容器逃逸或攻擊集群的其他部分。
具有相同配置（例如基于同一 PodTemplate 創(chuàng)建）的多個 Pod 會由于節(jié)點上文件的不同而在不同節(jié)點上有不同的行為。
下層主機上創(chuàng)建的文件或目錄只能由 root 用戶寫入。你需要在特權容器中以 root 身份運行進程，或者修改主機上的文件權限以便容?能夠寫入 ?hostPath ?卷。

hostPath 配置示例：

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: k8s.gcr.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /test-pd
      name: test-volume
  volumes:
  - name: test-volume
    hostPath:
      # 宿主上目錄位置
      path: /data
      # 此字段為可選
      type: Directory

?FileOrCreate ?模式不會負責創(chuàng)建文件的父目錄。如果欲掛載的文件的父目錄不存在，Pod 啟動會失敗。為了確保這種模式能夠工作，可以嘗試把文件和它對應的目錄分開掛載，如 FileOrCreate 配置所示。

hostPath FileOrCreate 配置示例

apiVersion: v1
kind: Pod
metadata:
  name: test-webserver
spec:
  containers:
  - name: test-webserver
    image: k8s.gcr.io/test-webserver:latest
    volumeMounts:
    - mountPath: /var/local/aaa
      name: mydir
    - mountPath: /var/local/aaa/1.txt
      name: myfile
  volumes:
  - name: mydir
    hostPath:
      # 確保文件所在目錄成功創(chuàng)建。
      path: /var/local/aaa
      type: DirectoryOrCreate
  - name: myfile
    hostPath:
      path: /var/local/aaa/1.txt
      type: FileOrCreate

iscsi

?iscsi ?卷能將 iSCSI (基于 IP 的 SCSI) 卷掛載到你的 Pod 中。不像 ?emptyDir ?那樣會在刪除 Pod 的同時也會被刪除，?iscsi ?卷的內容在刪除 Pod 時會被保留，卷只是被卸載。這意味著 ?iscsi ?卷可以被預先填充數據，并且這些數據可以在 Pod 之間共享。

在使用 iSCSI 卷之前，你必須擁有自己的 iSCSI 服務器，并在上面創(chuàng)建卷。

iSCSI 的一個特點是它可以同時被多個用戶以只讀方式掛載。這意味著你可以用數據集預先填充卷，然后根據需要在盡可能多的 Pod 上使用它。不幸的是，iSCSI 卷只能由單個使用者以讀寫模式掛載。不允許同時寫入。

更多詳情請參考 iSCSI 示例。

local

?local ?卷所代表的是某個被掛載的本地存儲設備，例如磁盤、分區(qū)或者目錄。

?local ?卷只能用作靜態(tài)創(chuàng)建的持久卷。尚不支持動態(tài)配置。

與 ?hostPath ?卷相比，?local ?卷能夠以持久和可移植的方式使用，而無需手動將 Pod 調度到節(jié)點。系統(tǒng)通過查看 PersistentVolume 的節(jié)點親和性配置，就能了解卷的節(jié)點約束。

然而，?local ?卷仍然取決于底層節(jié)點的可用性，并不適合所有應用程序。如果節(jié)點變得不健康，那么 ?local ?卷也將變得不可被 Pod 訪問。使用它的 Pod 將不能運行。使用 ?local ?卷的應用程序必須能夠容忍這種可用性的降低，以及因底層磁盤的耐用性特征而帶來的潛在的數據丟失風險。

下面是一個使用 ?local ?卷和 ?nodeAffinity ?的持久卷示例：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: example-pv
spec:
  capacity:
    storage: 100Gi
  volumeMode: Filesystem
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Delete
  storageClassName: local-storage
  local:
    path: /mnt/disks/ssd1
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - example-node

使用 ?local ?卷時，你需要設置 PersistentVolume 對象的 ?nodeAffinity ?字段。 Kubernetes 調度?使用 PersistentVolume 的 ?nodeAffinity ?信息來將使用 ?local ?卷的 Pod 調度到正確的節(jié)點。

PersistentVolume 對象的 ?volumeMode ?字段可被設置為 "Block" （而不是默認值 "Filesystem"），以將 ?local ?卷作為原始塊設備暴露出來。

使用 ?local ?卷時，建議創(chuàng)建一個 StorageClass 并將其 ?volumeBindingMode ?設置為 ?WaitForFirstConsumer?。要了解更多詳細信息，請參考 local StorageClass 示例。延遲卷綁定的操作可以確保 Kubernetes 在為 PersistentVolumeClaim 作出綁定決策時，會評估 Pod 可能具有的其他節(jié)點約束，例如：如節(jié)點資源需求、節(jié)點選擇?、Pod親和性和 Pod 反親和性。

你可以在 Kubernetes 之外單獨運行靜態(tài)驅動以改進對 local 卷的生命周期管理。請注意，此驅動尚不支持動態(tài)配置。有關如何運行外部 ?local ?卷驅動，請參考 local 卷驅動用戶指南。

如果不使用外部靜態(tài)驅動來管理卷的生命周期，用戶需要手動清理和刪除 local 類型的持久卷。

nfs

?nfs ?卷能將 NFS (網絡文件系統(tǒng)) 掛載到你的 Pod 中。不像 ?emptyDir ?那樣會在刪除 Pod 的同時也會被刪除，?nfs ?卷的內容在刪除 Pod 時會被保存，卷只是被卸載。這意味著 ?nfs ?卷可以被預先填充數據，并且這些數據可以在 Pod 之間共享。

在使用 NFS 卷之前，你必須運行自己的 NFS 服務?并將目標 share 導出備用。

要了解更多詳情請參考 NFS 示例。

persistentVolumeClaim

?persistentVolumeClaim ?卷用來將持久卷（PersistentVolume）掛載到 Pod 中。持久卷申領（PersistentVolumeClaim）是用戶在不知道特定云環(huán)境細節(jié)的情況下“申領”持久存儲（例如 GCE PersistentDisk 或者 iSCSI 卷）的一種方法。

portworxVolume

?portworxVolume ?是一個可伸縮的塊存儲層，能夠以超融合（hyperconverged）的方式與 Kubernetes 一起運行。 Portworx 支持對服務?上存儲的指紋處理、基于存儲能力進行分層以及跨多個服務?整合存儲容量。 Portworx 可以以 in-guest 方式在虛擬機中運行，也可以在裸金屬 Linux 節(jié)點上運行。

?portworxVolume ?類型的卷可以通過 Kubernetes 動態(tài)創(chuàng)建，也可以預先配備并在 Kubernetes Pod 內引用。下面是一個引用預先配備的 PortworxVolume 的示例 Pod：

apiVersion: v1
kind: Pod
metadata:
  name: test-portworx-volume-pod
spec:
  containers:
  - image: k8s.gcr.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /mnt
      name: pxvol
  volumes:
  - name: pxvol
    # 此 Portworx 卷必須已經存在
    portworxVolume:
      volumeID: "pxvol"
      fsType: ""

在 Pod 中使用 portworxVolume 之前，你要確保有一個名為 ?pxvol ?的 PortworxVolume 存在。

更多詳情可以參考 Portworx 卷。

projected （投射）

投射卷能將若干現有的卷來源映射到同一目錄上。

quobyte (已棄用)

?quobyte ?卷允許將現有的 Quobyte 卷掛載到你的 Pod 中。

在使用 Quobyte 卷之前，你首先要進行安裝 Quobyte 并創(chuàng)建好卷。

Quobyte 支持容器存儲接口（CSI）。推薦使用 CSI 插件以在 Kubernetes 中使用 Quobyte 卷。 Quobyte 的 GitHub 項目包含以 CSI 形式部署 Quobyte 的說明及使用示例。

rbd

?rbd ?卷允許將 Rados 塊設備卷掛載到你的 Pod 中。不像 ?emptyDir ?那樣會在刪除 Pod 的同時也會被刪除，?rbd ?卷的內容在刪除 Pod 時會被保存，卷只是被卸載。這意味著 ?rbd ?卷可以被預先填充數據，并且這些數據可以在 Pod 之間共享。

在使用 RBD 之前，你必須安裝運行 Ceph。

RBD 的一個特性是它可以同時被多個用戶以只讀方式掛載。這意味著你可以用數據集預先填充卷，然后根據需要在盡可能多的 Pod 中并行地使用卷。不幸的是，RBD 卷只能由單個使用者以讀寫模式安裝。不允許同時寫入。

更多詳情請參考 RBD 示例。

RBD CSI 遷移

FEATURE STATE: Kubernetes v1.23 [alpha]

啟用 RBD 的 ?CSIMigration ?功能后，所有插件操作從現有的樹內插件重定向到 ?rbd.csi.ceph.com? CSI 驅動程序。要使用該功能，必須在集群內安裝 Ceph CSI 驅動，并啟用 ?CSIMigration ?和 ?csiMigrationRBD ?特性門控。

作為一位管理存儲的 Kubernetes 集群操作者，在嘗試遷移到 RBD CSI 驅動前，你必須完成下列先決事項：

你必須在集群中安裝 v3.5.0 或更高版本的 Ceph CSI 驅動（?rbd.csi.ceph.com?）。

因為 ?clusterID ?是 CSI 驅動程序必需的參數，而樹內存儲類又將 ?monitors ?作為一個必需的參數，所以 Kubernetes 存儲管理者需要根據 ?monitors ?的哈希值（例：?#echo -n '' | md5sum?）來創(chuàng)建 ?clusterID?，并保持該 ?monitors ?存在于該 ?clusterID ?的配置中。

同時，如果樹內存儲類的 ?adminId ?的值不是 ?admin?，那么其 ?adminSecretName ?就需要被修改成 ?adminId ?參數的 base64 編碼值。

secret

?secret ?卷用來給 Pod 傳遞敏感信息，例如密碼。你可以將 Secret 存儲在 Kubernetes API 服務器上，然后以文件的形式掛在到 Pod 中，無需直接與 Kubernetes 耦合。 ?secret ?卷由 tmpfs（基于 RAM 的文件系統(tǒng)）提供存儲，因此它們永遠不會被寫入非易失性（持久化的）存儲器。

使用前你必須在 Kubernetes API 中創(chuàng)建 secret。

容器以 subPath 卷掛載方式掛載 Secret 時，將感知不到 Secret 的更新。

storageOS (已棄用)

?storageos ?卷允許將現有的 StorageOS 卷掛載到你的 Pod 中。

StorageOS 在 Kubernetes 環(huán)境中以容?的形式運行，這使得應用能夠從 Kubernetes 集群中的任何節(jié)點訪問本地的或掛接的存儲。為應對節(jié)點失效狀況，可以復制數據。若需提高利用率和降低成本，可以考慮瘦配置（Thin Provisioning）和數據壓縮。

作為其核心能力之一，StorageOS 為容?提供了可以通過文件系統(tǒng)訪問的塊存儲。

StorageOS 容器需要 64 位的 Linux，并且沒有其他的依賴關系。 StorageOS 提供免費的開發(fā)者授權許可。

你必須在每個希望訪問 StorageOS 卷的或者將向存儲資源池貢獻存儲容量的節(jié)點上運行 StorageOS 容器。有關安裝說明，請參閱 StorageOS 文檔。

apiVersion: v1
kind: Pod
metadata:
  labels:
    name: redis
    role: master
  name: test-storageos-redis
spec:
  containers:
    - name: master
      image: kubernetes/redis:v1
      env:
        - name: MASTER
          value: "true"
      ports:
        - containerPort: 6379
      volumeMounts:
        - mountPath: /redis-master-data
          name: redis-data
  volumes:
    - name: redis-data
      storageos:
        # `redis-vol01` 卷必須在 StorageOS 中存在，并位于 `default` 名字空間內
        volumeName: redis-vol01
        fsType: ext4

關于 StorageOS 的進一步信息、動態(tài)供應和持久卷申領等等，請參考 StorageOS 示例。

vsphereVolume

你必須配置 Kubernetes 的 vSphere 云驅動。云驅動的配置方法請參考 vSphere 使用指南。

?vsphereVolume ?用來將 vSphere VMDK 卷掛載到你的 Pod 中。在卸載卷時，卷的內容會被保留。 vSphereVolume 卷類型支持 VMFS 和 VSAN 數據倉庫。

在掛載到 Pod 之前，你必須用下列方式之一創(chuàng)建 VMDK。

創(chuàng)建 VMDK 卷

選擇下列方式之一創(chuàng)建 VMDK。

使用 vmkfstools 創(chuàng)建

首先 ssh 到 ESX，然后使用下面的命令來創(chuàng)建 VMDK：

vmkfstools -c 2G /vmfs/volumes/DatastoreName/volumes/myDisk.vmdk

使用 vmware-vdiskmanager 創(chuàng)建

使用下面的命令創(chuàng)建 VMDK：

vmware-vdiskmanager -c -t 0 -s 40GB -a lsilogic myDisk.vmdk

vSphere VMDK 配置示例

apiVersion: v1
kind: Pod
metadata:
  name: test-vmdk
spec:
  containers:
  - image: k8s.gcr.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /test-vmdk
      name: test-volume
  volumes:
  - name: test-volume
    # 此 VMDK 卷必須已經存在
    vsphereVolume:
      volumePath: "[DatastoreName] volumes/myDisk"
      fsType: ext4

進一步信息可參考 vSphere 卷。

vSphere CSI 遷移

FEATURE STATE: Kubernetes v1.19 [beta]

當 ?vsphereVolume ?的 ?CSIMigration ?特性被啟用時，所有插件操作都被從樹內插件重定向到 ?csi.vsphere.vmware.com? CSI 驅動。為了使用此功能特性，必須在集群中安裝 vSphere CSI 驅動，并啟用 ?CSIMigration ?和 ?CSIMigrationvSphere ?特性門控。

此特性還要求 vSphere vCenter/ESXi 的版本至少為 7.0u1，且 HW 版本至少為 VM version 15。

vSphere CSI 驅動不支持內置 ?
vsphereVolume ?的以下 StorageClass 參數：

?diskformat?

?hostfailurestotolerate?

?forceprovisioning?

?cachereservation?

?diskstripes?

?objectspacereservation?

?iopslimit?

使用這些參數創(chuàng)建的現有卷將被遷移到 vSphere CSI 驅動，不過使用 vSphere CSI 驅動所創(chuàng)建的新卷都不會理會這些參數。

vSphere CSI 遷移完成

FEATURE STATE: Kubernetes v1.19 [beta]

為了避免控制器管理器和 kubelet 加載 ?vsphereVolume ?插件，你需要將 ?InTreePluginvSphereUnregister ?特性設置為 ?true?。你還必須在所有工作節(jié)點上安裝 ?csi.vsphere.vmware.com? CSI 驅動。

Portworx CSI 遷移

FEATURE STATE: Kubernetes v1.23 [alpha]

Kubernetes 1.23 中加入了 Portworx 的 ?CSIMigration ?功能，但默認不會啟用，因為該功能仍處于 alpha 階段。該功能會將所有的插件操作從現有的樹內插件重定向到 ?pxd.portworx.com? 容器存儲接口（Container Storage Interface, CSI）驅動程序。集群中必須安裝 Portworx CSI 驅動。要啟用此功能，請在 kube-controller-manager 和 kubelet 中設置 ?CSIMigrationPortworx=true?。

使用 subPath

有時，在單個 Pod 中共享卷以供多方使用是很有用的。 ?volumeMounts.subPath? 屬性可用于指定所引用的卷內的子路徑，而不是其根路徑。

下面例子展示了如何配置某包含 LAMP 堆棧（Linux Apache MySQL PHP）的 Pod 使用同一共享卷。此示例中的 ?subPath ?配置不建議在生產環(huán)境中使用。 PHP 應用的代碼和相關數據映射到卷的 ?html ?文件夾，MySQL 數據庫存儲在卷的 ?mysql ?文件夾中：

apiVersion: v1
kind: Pod
metadata:
  name: my-lamp-site
spec:
    containers:
    - name: mysql
      image: mysql
      env:
      - name: MYSQL_ROOT_PASSWORD
        value: "rootpasswd"
      volumeMounts:
      - mountPath: /var/lib/mysql
        name: site-data
        subPath: mysql
    - name: php
      image: php:7.0-apache
      volumeMounts:
      - mountPath: /var/www/html
        name: site-data
        subPath: html
    volumes:
    - name: site-data
      persistentVolumeClaim:
        claimName: my-lamp-site-data

使用帶有擴展環(huán)境變量的 subPath

FEATURE STATE: Kubernetes v1.17 [stable]

使用 ?subPathExpr ?字段可以基于 Downward API 環(huán)境變量來構造 ?subPath ?目錄名。 ?subPath ?和 ?subPathExpr ?屬性是互斥的。

在這個示例中，Pod 使用 ?subPathExpr ?來 hostPath 卷 ?/var/log/pods? 中創(chuàng)建目錄 ?pod1?。 ?hostPath ?卷采用來自 ?downwardAPI ?的 Pod 名稱生成目錄名。宿主目錄 ?/var/log/pods/pod1? 被掛載到容器的 ?/logs? 中。

apiVersion: v1
kind: Pod
metadata:
  name: pod1
spec:
  containers:
  - name: container1
    env:
    - name: POD_NAME
      valueFrom:
        fieldRef:
          apiVersion: v1
          fieldPath: metadata.name
    image: busybox:1.28
    command: [ "sh", "-c", "while [ true ]; do echo 'Hello'; sleep 10; done | tee -a /logs/hello.txt" ]
    volumeMounts:
    - name: workdir1
      mountPath: /logs
      # 包裹變量名的是小括號，而不是大括號
      subPathExpr: $(POD_NAME)
  restartPolicy: Never
  volumes:
  - name: workdir1
    hostPath:
      path: /var/log/pods

資源

?emptyDir ?卷的存儲介質（磁盤、SSD 等）是由保存 kubelet 數據的根目錄（通常是 ?/var/lib/kubelet?）的文件系統(tǒng)的介質確定。 Kubernetes 對 ?emptyDir ?卷或者 ?hostPath ?卷可以消耗的空間沒有限制，容器之間或 Pod 之間也沒有隔離。

樹外（Out-of-Tree）卷插件

Out-of-Tree 卷插件包括容器存儲接口（CSI）和 FlexVolume（已棄用）。它們使存儲供應商能夠創(chuàng)建自定義存儲插件，而無需將插件源碼添加到 Kubernetes 代碼倉庫。

以前，所有卷插件（如上面列出的卷類型）都是“樹內（In-Tree）”的。 “樹內”插件是與 Kubernetes 的核心組件一同構建、鏈接、編譯和交付的。這意味著向 Kubernetes 添加新的存儲系統(tǒng)（卷插件）需要將代碼合并到 Kubernetes 核心代碼庫中。

CSI 和 FlexVolume 都允許獨立于 Kubernetes 代碼庫開發(fā)卷插件，并作為擴展部署（安裝）在 Kubernetes 集群上。

對于希望創(chuàng)建樹外（Out-Of-Tree）卷插件的存儲供應商，請參考卷插件常見問題。

CSI

容器存儲接口 (CSI) 為容器編排系統(tǒng)（如 Kubernetes）定義標準接口，以將任意存儲系統(tǒng)暴露給它們的容器工作負載。

更多詳情請閱讀 CSI 設計方案。

Kubernetes v1.13 廢棄了對 CSI 規(guī)范版本 0.2 和 0.3 的支持，并將在以后的版本中刪除。

CSI 驅動可能并非兼容所有的 Kubernetes 版本。請查看特定 CSI 驅動的文檔，以了解各個 Kubernetes 版本所支持的部署步驟以及兼容性列表。

一旦在 Kubernetes 集群上部署了 CSI 兼容卷驅動程序，用戶就可以使用 ?csi ?卷類型來掛接、掛載 CSI 驅動所提供的卷。

?csi ?卷可以在 Pod 中以三種方式使用：

通過 PersistentVolumeClaim(#persistentvolumeclaim) 對象引用
使用一般性的臨時卷（Alpha 特性）
使用 CSI 臨時卷，前提是驅動支持這種用法（Beta 特性）

存儲管理員可以使用以下字段來配置 CSI 持久卷：

?driver?：指定要使用的卷驅動名稱的字符串值。這個值必須與 CSI 驅動程序在 ?GetPluginInfoResponse ?中返回的值相對應；該接口定義在 CSI 規(guī)范中。 Kubernetes 使用所給的值來標識要調用的 CSI 驅動程序；CSI 驅動程序也使用該值來辨識哪些 PV 對象屬于該 CSI 驅動程序。
?volumeHandle?：唯一標識卷的字符串值。該值必須與 CSI 驅動在 ?CreateVolumeResponse ?的 ?volume_id ?字段中返回的值相對應；接口定義在 CSI 規(guī)范中。在所有對 CSI 卷驅動程序的調用中，引用該 CSI 卷時都使用此值作為 ?volume_id ?參數。
?readOnly?：一個可選的布爾值，指示通過 ?ControllerPublished ?關聯該卷時是否設置該卷為只讀。默認值是 false。該值通過 ?ControllerPublishVolumeRequest ?中的 ?readonly ?字段傳遞給 CSI 驅動。
?fsType?：如果 PV 的 ?VolumeMode ?為 ?Filesystem?，那么此字段指定掛載卷時應該使用的文件系統(tǒng)。如果卷尚未格式化，并且支持格式化，此值將用于格式化卷。此值可以通過 ?ControllerPublishVolumeRequest?、?NodeStageVolumeRequest ?和 ?NodePublishVolumeRequest ?的 ?VolumeCapability ?字段傳遞給 CSI 驅動。
?volumeAttributes?：一個字符串到字符串的映射表，用來設置卷的靜態(tài)屬性。該映射必須與 CSI 驅動程序返回的 ?CreateVolumeResponse ?中的 ?volume.attributes? 字段的映射相對應； CSI 規(guī)范中有相應的定義。該映射通過?ControllerPublishVolumeRequest?、?NodeStageVolumeRequest?、和 ?NodePublishVolumeRequest ?中的 ?volume_attributes ?字段傳遞給 CSI 驅動。
?controllerPublishSecretRef?：對包含?感信息的 Secret 對象的引用；該?感信息會被傳遞給 CSI 驅動來完成 CSI ?ControllerPublishVolume ?和 ?ControllerUnpublishVolume ?調用。此字段是可選的；在不需要 Secret 時可以是空的。如果 Secret 對象包含多個 Secret 條目，則所有的 Secret 條目都會被傳遞。
?nodeStageSecretRef?：對包含敏感信息的 Secret 對象的引用。該信息會傳遞給 CSI 驅動來完成 CSI ?NodeStageVolume ?調用。此字段是可選的，如果不需要 Secret，則可能是空的。如果 Secret 對象包含多個 Secret 條目，則傳遞所有 Secret 條目。
?nodePublishSecretRef?：對包含敏感信息的 Secret 對象的引用。該信息傳遞給 CSI 驅動來完成 CSI ?NodePublishVolume ?調用。此字段是可選的，如果不需要 Secret，則可能是空的。如果 Secret 對象包含多個 Secret 條目，則傳遞所有 Secret 條目。

CSI 原始塊卷支持

FEATURE STATE: Kubernetes v1.18 [stable]

具有外部 CSI 驅動程序的供應商能夠在 Kubernetes 工作負載中實現原始塊卷支持。

你可以和以前一樣，安裝自己的帶有原始塊卷支持的 PV/PVC，采用 CSI 對此過程沒有影響。

CSI 臨時卷

FEATURE STATE: Kubernetes v1.16 [beta]

你可以直接在 Pod 規(guī)約中配置 CSI 卷。采用這種方式配置的卷都是臨時卷，無法在 Pod 重新啟動后繼續(xù)存在。進一步的信息可參閱臨時卷。

有關如何開發(fā) CSI 驅動的更多信息，請參考 kubernetes-csi 文檔。

從樹內插件遷移到 CSI 驅動程序

FEATURE STATE: Kubernetes v1.17 [beta]

啟用 ?CSIMigration ?功能后，針對現有樹內插件的操作會被重定向到相應的 CSI 插件（應已安裝和配置）。因此，操作員在過渡到取代樹內插件的 CSI 驅動時，無需對現有存儲類、PV 或 PVC（指樹內插件）進行任何配置更改。

所支持的操作和功能包括：配備（Provisioning）/刪除、掛接（Attach）/解掛（Detach）、掛載（Mount）/卸載（Unmount）和調整卷大小。

上面的卷類型節(jié)列出了支持 ?CSIMigration ?并已實現相應 CSI 驅動程序的樹內插件。

flexVolume

FEATURE STATE: Kubernetes v1.23 [deprecated]

FlexVolume 是一個使用基于 exec 的模型來與驅動程序對接的樹外插件接口。用戶必須在每個節(jié)點上的預定義卷插件路徑中安裝 FlexVolume 驅動程序可執(zhí)行文件，在某些情況下，控制平面節(jié)點中也要安裝。

Pod 通過 ?flexvolume ?樹內插件與 FlexVolume 驅動程序交互。更多詳情請參考 FlexVolume README 文檔。

FlexVolume 已棄用。推薦使用樹外 CSI 驅動來將外部存儲整合進 Kubernetes。

FlexVolume 驅動的維護者應開發(fā)一個 CSI 驅動并幫助用戶從 FlexVolume 驅動遷移到 CSI。 FlexVolume 用戶應遷移工作負載以使用對等的 CSI 驅動。

掛載卷的傳播

掛載卷的傳播能力允許將容器安裝的卷共享到同一 Pod 中的其他容器，甚至共享到同一節(jié)點上的其他 Pod。

卷的掛載傳播特性由 ?Container.volumeMounts? 中的 ?mountPropagation ?字段控制。它的值包括：

?None ?- 此卷掛載將不會感知到主機后續(xù)在此卷或其任何子目錄上執(zhí)行的掛載變化。類似的，容?所創(chuàng)建的卷掛載在主機上是不可見的。這是默認模式。

該模式等同于 Linux 內核文檔中描述的 ?
private ?掛載傳播選項。

?HostToContainer ?- 此卷掛載將會感知到主機后續(xù)針對此卷或其任何子目錄的掛載操作。

換句話說，如果主機在此掛載卷中掛載任何內容，容器將能看到它被掛載在那里。類似的，配置了 ?
Bidirectional ?掛載傳播選項的 Pod 如果在同一卷上掛載了內容，掛載傳播設置為 ?
HostToContainer ?的容?都將能看到這一變化。該模式等同于 Linux 內核文檔中描述的 rslave 掛載傳播選項。

?Bidirectional ?- 這種卷掛載和 ?HostToContainer ?掛載表現相同。另外，容?創(chuàng)建的卷掛載將被傳播回至主機和使用同一卷的所有 Pod 的所有容?。

該模式等同于 Linux 內核文檔中描述的 ?
rshared ?掛載傳播選項。

?Bidirectional ?形式的掛載傳播可能比較危險。它可以破壞主機操作系統(tǒng)，因此它只被允許在特權容器中使用。強烈建議你熟悉 Linux 內核行為。此外，由 Pod 中的容器創(chuàng)建的任何卷掛載必須在終止時由容器銷毀（卸載）。

配置

在某些部署環(huán)境中，掛載傳播正常工作前，必須在 Docker 中正確配置掛載共享（mount share），如下所示。

編輯你的 Docker ?systemd ?服務文件，按下面的方法設置 ?MountFlags?：

MountFlags=shared

或者，如果存在 ?MountFlags=slave? 就刪除掉。然后重啟 Docker 守護進程：

sudo systemctl daemon-reload
sudo systemctl restart docker

分享題目：創(chuàng)新互聯kubernetes教程：Kubernetes卷
文章分享：http://www.dlmjj.cn/article/dheihgg.html

日本综合一区二区|亚洲中文天堂综合|日韩欧美自拍一区|男女精品天堂一区|欧美自拍第6页亚洲成人精品一区|亚洲黄色天堂一区二区成人|超碰91偷拍第一页|日韩av夜夜嗨中文字幕|久久蜜综合视频官网|精美人妻一区二区三区

新聞中心

卷

背景

卷類型

awsElasticBlockStore

創(chuàng)建 EBS 卷

AWS EBS 配置示例

AWS EBS CSI 卷遷移

AWS EBS CSI 遷移結束

azureDisk

azureDisk 的 CSI 遷移

azureDisk CSI 遷移完成

azureFile

azureFile CSI 遷移

azureDisk CSI 遷移完成

cephfs

cinder

Cinder 卷示例配置

OpenStack CSI 遷移

configMap

downwardAPI

emptyDir

emptyDir 配置示例

fc (光纖通道)

flocker （已棄用）

gcePersistentDisk

創(chuàng)建 GCE 持久盤（PD）

GCE 持久盤配置示例

區(qū)域持久盤

手動供應基于區(qū)域 PD 的 PersistentVolume

GCE CSI 遷移

GCE CSI 遷移完成

gitRepo (已棄用)

glusterfs

hostPath

hostPath 配置示例：

hostPath FileOrCreate 配置示例

iscsi

local

nfs

persistentVolumeClaim

portworxVolume

projected （投射）

quobyte (已棄用)

rbd

RBD CSI 遷移

secret

storageOS (已棄用)

vsphereVolume

創(chuàng)建 VMDK 卷

vSphere VMDK 配置示例

vSphere CSI 遷移

vSphere CSI 遷移完成

Portworx CSI 遷移

使用 subPath

使用帶有擴展環(huán)境變量的 subPath

資源

樹外（Out-of-Tree）卷插件

CSI

CSI 原始塊卷支持

CSI 臨時卷

從樹內插件遷移到 CSI 驅動程序

flexVolume

掛載卷的傳播

配置

其他資訊