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

本文是從 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

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

1. 使用同一個模板創建的 Pod，由於不同的節點有不同的目錄信息，可能會導致不同的結果
2. 如果 kubernetes 增加了已知資源的調度，該調度不會考慮 hostPath 使用的資源
3. 如果宿主機目錄上已經存在的目錄，只可以被 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）就能很好的解決此類問題。

---

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