本文是從 0 到 1 使用 Kubernetes 系列第六篇，上一篇《從 0 到 1 使用 Kubernetes 系列（五）：Kubernetes Scheduling》介紹了 Kubernetes 調度器如何進行資源調度，本文將為大家介紹幾種常用儲存型別，

默認情況下 Pod 掛載在磁盤上的檔案生命周期與 Pod 生命周期是一致的，若 Pod 出現崩潰的情況，kubelet 將會重啟它，這將會造成 Pod 中的檔案將丟失，因為 Pod 會以鏡像最初的狀態重新啟動，在實際應用當中，開發者有很多時候需要將容器中的資料保留下來，比如在 Kubernetes 中部署了 MySql，不能因為 MySql 容器掛掉重啟而上面的資料全部丟失；其次，在 Pod 中同時運行多個容器時，這些容器之間可能需要共享檔案，也有的時候，開發者需要預置組態檔，使其在容器中生效，例如自定義了 mysql.cnf 檔案在 MySql 啟動時就需要加載此組態檔，這些都將是今天將要實戰解決的問題，

今天這篇文將講解下面幾種常用存盤型別：

secret
configMap
emptyDir
hostPath
nfs
persistentVolumeClaim

SECRET

Secret 物件允許記憶體儲和管理敏感資訊，例如密碼，OAuth 令牌和 ssh 密鑰，將此類資訊放入一個 secret 中可以更好地控制它的用途，并降低意外暴露的風險，

▌ 使用場景

鑒權組態檔掛載

▌ 使用示例

在 CI 中 push 構建好的鏡像就可以將 docker 鑒權的 config.json 檔案存入 secret 物件中，再掛載到 CI 的 Pod 中，從而進行權限認證，

首先創建 secret

$ kubectl create secret docker-registry docker-config  --docker-server=https://hub.docker.com --docker-username=username --docker-password=password
secret/docker-config created

新建 docker-pod.yaml 檔案，粘貼以下資訊：

apiVersion: v1
kind: Pod
metadata:
  name: docker
spec:
  containers:
  - name: docker
    image: docker
    command:
      - sleep
      - "3600"
    volumeMounts:
    - name: config
      mountPath: /root/.docker/
  volumes:
  - name: config
    secret:
      secretName: docker-config
      items:
      - key: .dockerconfigjson
        path: config.json
        mode: 0644

Docker Pod 掛載 secret

$ kubectl apply -f docker-pod.yaml
pod/docker created

查看掛載效果

$ kubectl exec docker -- cat /root/.docker/config.json
{"auths":{"https://hub.docker.com":{"username":"username","password":"password","auth":"dXNlcm5hbWU6cGFzc3dvcmQ="}}}

清理環境

$ kubectl delete pod docker
$ kubectl delete secret docker-config

ConfigMap

許多應用程式會從組態檔、命令列引數或環境變數中讀取配置資訊，這些配置資訊需要與 docker image 解耦 ConfigMap API 給我們提供了向容器中注入配置資訊的機制，ConfigMap 可以被用來保存單個屬性，也可以用來保存整個組態檔，

▌ 使用場景

配置資訊檔案掛載

▌ 使用示例

使用 ConfigMap 中的資料來配置 Redis 快取

創建 example-redis-config.yaml 檔案，粘貼以下資訊：

apiVersion: v1
kind: ConfigMap
metadata:
  name: example-redis-config
data:
  redis-config: |
    maxmemory 2b
    maxmemory-policy allkeys-lru

創建 ConfigMap

$ kubectl apply -f example-redis-config.yaml
configmap/example-redis-config created

創建 example-redis.yaml 檔案，粘貼以下資訊：

apiVersion: v1
kind: Pod
metadata:
  name: redis
spec:
  containers:
  - name: redis
    image: kubernetes/redis:v1
    env:
    - name: MASTER
      value: "true"
    ports:
    - containerPort: 6379
    resources:
      limits:
        cpu: "0.1"
    volumeMounts:
    - mountPath: /redis-master-data
      name: data
    - mountPath: /redis-master
      name: config
  volumes:
    - name: data
      emptyDir: {}
    - name: config
      configMap:
        name: example-redis-config
        items:
        - key: redis-config
          path: redis.conf

Redis Pod 掛載 ConfigMap 測驗

$ kubectl apply -f example-redis.yaml
pod/redis created

查看掛載效果

$ kubectl exec -it redis redis-cli
$ 127.0.0.1:6379> CONFIG GET maxmemory
1) "maxmemory"
2) "2097152"
$ 127.0.0.1:6379> CONFIG GET maxmemory-policy
1) "maxmemory-policy"
2) "allkeys-lru"

清理環境

$ kubectl delete pod redis
$ kubectl delete configmap example-redis-config

EmptyDir

當使用 emptyDir 卷的 Pod 在節點創建時，會在該節點創建一個新的空目錄，只要該 Pod 運行在該節點，該目錄會一直存在，Pod 內的所有容器可以將改目錄掛載到不同的掛載點，但都可以讀寫 emptyDir 內的檔案，當 Pod 不論什么原因被洗掉，emptyDir 的資料都會永遠被洗掉（一個 Container Crash 并不會在該節點洗掉 Pod，因此在 Container crash 時，資料不會丟失），默認情況下，emptyDir 支持任何型別的后端存盤：disk、ssd、網路存盤，也可以通過設定 emptyDir.medium 為 Memory，kubernetes 會默認 mount 一個 tmpfs（RAM-backed filesystem），因為是 RAM Backed,因此 tmpfs 通常很快，但是會在容器重啟或者 crash 時，資料丟失，

▌ 使用場景

同一 Pod 內各容器共享存盤

▌ 使用示例

在容器 a 中生成 hello 檔案，通過容器 b 輸出檔案內容

創建 test-emptydir.yaml 檔案，粘貼以下資訊：

apiVersion: v1
kind: Pod
metadata:
  name: test-emptydir
spec:
  containers:
  - image: alpine
    name: container-a
    command:
      - /bin/sh
    args:
      - -c
      - echo 'I am container-a' >> /cache-a/hello && sleep 3600
    volumeMounts:
    - mountPath: /cache-a
      name: cache-volume
  - image: alpine
    name: container-b
    command:
      - sleep
      - "3600"
    volumeMounts:
    - mountPath: /cache-b
      name: cache-volume
  volumes:
  - name: cache-volume
    emptyDir: {}

創建 Pod

kubectl apply -f test-emptydir.yaml
pod/test-emptydir created

測驗

$ kubectl exec test-emptydir -c container-b -- cat /cache-b/hello
I am container-a

清理環境

$ kubectl delete pod test-emptydir

HostPath

將宿主機對應目錄直接掛載到運行在該節點的容器中，使用該型別的卷，需要注意以下幾個方面：

使用同一個模板創建的 Pod，由于不同的節點有不同的目錄資訊，可能會導致不同的結果
如果 kubernetes 增加了已知資源的調度，該調度不會考慮 hostPath 使用的資源
如果宿主機目錄上已經存在的目錄，只可以被 root 可以寫，所以容器需要 root 權限訪問該目錄，或者修改目錄權限

▌ 使用場景

運行的容器需要訪問宿主機的資訊，比如 Docker 內部資訊/var/lib/docker 目錄，容器內運行 cadvisor，需要訪問/dev/cgroups

▌ 使用示例

使用 Docker socket binding 模式在列出宿主機鏡像串列，

創建 test-hostpath.yaml 檔案，粘貼以下資訊：

apiVersion: v1
kind: Pod
metadata:
  name: test-hostpath
spec:
  containers:
  - image: docker
    name: test-hostpath
    command:
      - sleep
      - "3600"
    volumeMounts:
    - mountPath: /var/run/docker.sock
      name: docker-sock
  volumes:
  - name: docker-sock
    hostPath:
      path: /var/run/docker.sock
      type: Socket

創建 test-hostpath Pod

$ kubectl apply -f test-hostpath.yaml
pod/test-hostpath created

測驗是否成功

$ kubectl exec test-hostpath docker images
REPOSITORY      IMAGE ID        CREATED         SIZE
docker          639de9917ae1    13 days ago     171MB
...

NFS 存盤卷

NFS 卷允許將現有的 NFS（網路檔案系統）共享掛載到您的容器中，不像 emptyDir，當洗掉 Pod 時，nfs 卷的內容被保留，卷僅僅是被卸載，這意味著 nfs 卷可以預填充資料，并且可以在 pod 之間共享資料， NFS 可以被多個寫入者同時掛載，

重要提示：您必須先擁有自己的 NFS 服務器然后才能使用它，

▌ 使用場景

不同節點 Pod 使用統一 nfs 共享目錄

▌ 使用示例

創建 test-nfs.yaml 檔案，粘貼以下資訊：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-nfs
spec:
  selector:
    matchLabels:
      app: store
  replicas: 2
  template:
    metadata:
      labels:
        app: store
    spec:
      volumes:
      - name: data
        nfs:
          server: nfs.server.com
          path: /
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - store
            topologyKey: "kubernetes.io/hostname"
      containers:
      - name: alpine
        image: alpine
        command:
          - sleep
          - "3600"
        volumeMounts:
        - mountPath: /data
          name: data

創建測驗 deployment

$ kubectl apply -f test-nfs.yaml
deployment/test-nfs created

查看 pod 運行情況

$ kubectl get po -o wide
NAME                        READY     STATUS    RESTARTS   AGE       IP              NODE      NOMINATED NODE
test-nfs-859ccfdf55-kkgxj   1/1       Running   0          1m        10.233.68.245   uat05     <none>
test-nfs-859ccfdf55-aewf8   1/1       Running   0          1m        10.233.67.209   uat06     <none>

進入 Pod 中進行測驗

# 進入uat05節點的pod中
$ kubectl exec -it test-nfs-859ccfdf55-kkgxj sh
# 創建檔案
$ echo "uat05" > /data/uat05
# 退出uat05節點的pod
$ edit
# 進入uat06節點的pod中
$ kubectl exec -it test-nfs-859ccfdf55-aewf8 sh
# 查看檔案內容
$ cat /data/uat05
uat05

清理環境

$ kubectl delete deployment test-nfs

PersistentVolumeClaim

上面所有例子中我們都是直接將存盤掛載到的 pod 中，那么在 kubernetes 中如何管理這些存盤資源呢？這就是 Persistent Volume 和 Persistent Volume Claims 所提供的功能，

● PersistentVolume 子系統為用戶和管理員提供了一個 API，該 API 將如何提供存盤的細節抽象了出來，為此，我們引入兩個新的 API 資源：PersistentVolume 和 PersistentVolumeClaim，

PersistentVolume（PV）是由管理員設定的存盤，它是群集的一部分，就像節點是集群中的資源一樣，PV 也是集群中的資源， PV 是 Volume 之類的卷插件，但具有獨立于使用 PV 的 Pod 的生命周期，此 API 物件包含 Volume 的實作，即 NFS、iSCSI 或特定于云供應商的存盤系統，
PersistentVolumeClaim（PVC）是用戶存盤的請求，它與 Pod 相似，Pod 消耗節點資源，PVC 消耗 PV 資源，Pod 可以請求特定級別的資源（CPU 和記憶體），宣告可以請求特定的大小和訪問模式（例如，可以以讀/寫一次或只讀多次模式掛載），雖然 PersistentVolumeClaims 允許用戶使用抽象存盤資源，但用戶需要具有不同性質（例如性能）的 PersistentVolume 來解決不同的問題，集群管理員需要能夠提供各種各樣的 PersistentVolume，這些 PersistentVolume 的大小和訪問模式可以各有不同，但不需要向用戶公開實作這些卷的細節，對于這些需求，StorageClass 資源可以實作，

● 在實際使用場景里，PV 的創建和使用通常不是同一個人，這里有一個典型的應用場景：管理員創建一個 PV 池，開發人員創建 Pod 和 PVC，PVC 里定義了 Pod 所需存盤的大小和訪問模式，然后 PVC 會到 PV 池里自動匹配最合適的 PV 給 Pod 使用，

▌ 使用示例

創建 PersistentVolume

apiVersion: v1
kind: PersistentVolume
metadata:
  name: mypv
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Recycle
  storageClassName: slow
  mountOptions:
    - hard
    - nfsvers=4.0
  nfs:
    path: /tmp
    server: 172.17.0.2

創建 PersistentVolumeClaim

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: myclaim
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 5Gi
  volumeName: mypv

創建 Pod 系結 PVC

kind: Pod
apiVersion: v1
metadata:
  name: mypod
spec:
  containers:
    - name: myfrontend
      image: nginx
      volumeMounts:
      - mountPath: "/var/www/html"
        name: mypd
  volumes:
    - name: mypd
      persistentVolumeClaim:
        claimName: myclaim

查看 pod 運行情況驗證系結結果

$ kubectl get po -o wide
NAME    READY     STATUS    RESTARTS   AGE       IP              NODE      NOMINATED NODE
mypod   1/1       Running   0          1m        10.233.68.249   uat05     <none>
$ kubectl exec -it mypod sh
$ ls /var/www/html

清理環境

$ kubectl delete pv mypv
$ kubectl delete pvc myclaim
$ kubectl delete po mypod

總結

本次實戰中使用了 secret 存盤 docker 認證憑據，更好地控制它的用途，并降低意外暴露的風險，

使用 configMap 對 redis 進行快取配置，這樣即使 redis 容器掛掉重啟 configMap 中的配置依然會生效，接著又使用 emptyDir 來使得同一 Pod 中多個容器的目錄共享，在實際應用中開發者通常使用 initContainers 來進行預處理檔案，然后通過 emptyDir 傳遞給 Containers，然后再使用 hostPath 來訪問宿主機的資源，當網路 io 達不到檔案讀寫要求時，可考慮固定應用只運行在一個節點上然后使用 hostPath 來解決檔案讀寫速度的要求，

NFS 和 PersistentVolumeClaim 的例子實質上都是試容器掛載的 nfs 服務器共享目錄，但這些資源一般都只掌握在了管理員手中，開發人員想要獲取這部分資源那么就不是這么友好了，動態存盤類（StorageClass）就能很好的解決此類問題，

本文由豬齒魚技術團隊原創，轉載請注明出處

轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/353166.html

標籤：其他

上一篇：資料結構與演算法之【合并有序鏈表】詳解

下一篇：如何在ISE14.7中進行Spartan-3E的固化

從0到1使用Kubernetes系列（六）：資料持久化實戰

SECRET

ConfigMap

EmptyDir

HostPath

NFS 存盤卷

PersistentVolumeClaim

總結