參考：https://kubernetes.io/docs/concepts/storage/volumes/

一個執行中的容器，預設情況下，對檔案系統的寫入，都是發生在其分層檔案系統的可寫層的，一旦容器執行結束，所有寫入都會被丟棄。因此需要對持久化支援。

Kubernetes 中通過 Volume 的方式提供對儲存的支援。下面對一些常見的儲存概念進行一點簡要的說明。

EmptyDir

顧名思義，EmptyDir是一個空目錄，他的生命週期和所屬的 Pod 是完全一致的，可能讀者會奇怪，那還要他做什麼？EmptyDir的用處是，可以在同一 Pod 內的不同容器之間共享工作過程中產生的檔案。

預設情況下，EmptyDir 是使用主機磁碟進行

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

HostPath

這種會把宿主機上的指定卷載入到容器之中，當然，如果 Pod 發生跨主機的重建，其內容就難保證了。

這種卷一般和DaemonSet搭配使用，用來操作主機檔案，例如進行日誌採集的 FLK 中的 FluentD 就採用這種方式，載入主機的容器日誌目錄，達到收集本主機所有日誌的目的。

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: gcr.io/google_containers/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /test-pd
      name: test-volume
  volumes:
  - name: test-volume
    hostPath:
      # directory location on host
      path: /data

NFS/GlusterFS/CephFS/AWS/GCE 等等

作為一個容器叢集，支援網路儲存自然是重中之重了，Kubernetes 支援為數眾多的雲提供商和網路儲存方案。

各種支援的方式不盡相同，例如 GlusterFS 需要建立 Endpoint，Ceph/NFS 之流就沒這麼麻煩了。

各種個性配置可移步參考文件。

ConfigMap 和 Secret

映象使用的過程中，經常需要利用配置檔案、啟動指令碼等方式來影響容器的執行方式，如果僅有少量配置，我們可以使用環境變數的方式來進行配置。然而對於一些較為複雜的配置，例如 Apache 之類，就很難用這種方式進行控制了。另外一些敏感資訊暴露在 YAML 中也是不合適的。

ConfigMap 和 Secret 除了使用檔案方式進行應用之外，還有其他的應用方式；這裡僅就檔案方式做一點說明。

例如下面的 ConfigMap，將一個儲存在 ConfigMap 中的配置目錄載入到卷中。

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "-c", "ls /etc/config/" ]
      volumeMounts:
      - name: config-volume
        mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
        # Provide the name of the ConfigMap containing the files you want
        # to add to the container
        name: special-config
  restartPolicy: Never

注意，這裡的 ConfigMap 會對映為一個目錄，ConfigMap 的 Key 就是檔名，每個 Value 就是檔案內容，比如下面命令用一個目錄建立一個 ConfigMap：

kubectl create configmap \
    game-config \
    --from-file=docs/user-guide/configmap/kubectl

建立一個 Secret：

kubectl create secret generic \
    db-user-pass --from-file=./username.txt \
    --from-file=./password.txt

使用 Volume 載入 Secret：

apiVersion: v1
kind: Pod
metadata:
  name: mypod
  namespace: myns
spec:
  containers:
    - name: mypod
      image: redis
      volumeMounts:
        - name: foo
          mountPath: /etc/foo
          readOnly: true
  volumes:
    - name: foo
      secret:
        secretName: mysecret

可以看到 Secret 和 ConfigMap 的建立和使用是很相似的。在 RBAC 中，Secret 和 ConfigMap 可以進行分別賦權，以此限定操作人員的可見、可控許可權。

PV & PVC

PersistentVolume 和 PersistentVolumeClaim 提供了對儲存支援的抽象，也提供了基礎設施和應用之間的分界，管理員建立一系列的 PV 提供儲存，然後為應用提供 PVC，應用程式僅需要載入一個 PVC，就可以進行訪問。

而 1.5 之後又提供了 PV 的動態供應。可以不經 PV 步驟直接建立 PVC。

參考：http://blog.fleeto.us/translation/dynamic-provisioning-and-storage-classes-kubernetes-0