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

Choerodon豬齒魚發表於2019-04-10
持久化

本文是從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）就能很好的解決此類問題。

更多關於Kubernetes系列的文章：

關於Choerodon豬齒魚

Choerodon豬齒魚是一個開源企業服務平臺，基於Kubernetes的容器編排和管理能力，整合DevOps工具鏈、微服務和移動應用框架，來幫助企業實現敏捷化的應用交付和自動化的運營管理的開源平臺，同時提供IoT、支付、資料、智慧洞察、企業應用市場等業務元件，致力幫助企業聚焦於業務，加速數字化轉型。

大家也可以通過以下社群途徑瞭解豬齒魚的最新動態、產品特性，以及參與社群貢獻：

相關文章