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

阿新 • • 發佈：2021-11-08

上一篇介紹了 Kubernetes 排程器如何進行資源排程，本文將為大家介紹幾種常用儲存型別：secret、configMap、emptyDir、hostPath、nfs、persistentVolumeClaim。

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

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

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

SECRET

ConfigMap

EmptyDir

HostPath

NFS 儲存卷

PersistentVolumeClaim

總結

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

Redis系列（六）：資料結構List雙向連結串列LPUSH、LPOP、RPUSH、RPOP、LLEN命令

Redis系列（六）：資料結構QuickList（快速列表）原始碼解析

Redis系列（八）：資料結構List雙向連結串列中阻塞版本之BLPOP、BRPOP和LINDEX、LINSERT、LRANGE命令詳解

Redis系列（九）：資料結構Hash原始碼解析和HSET、HGET命令

Redis系列（九）：資料結構Hash之HDEL、HEXISTS、HGETALL、HKEYS、HLEN、HVALS命令

Redis系列（十）：資料結構Set原始碼解析和SADD、SINTER、SDIFF、SUNION、SPOP命令

Docker 系列（六）：公有倉庫與私有倉庫

Kubernetes 系列（六）：kubectl 命令

機器學習sklearn（六）：資料處理（三）數值型資料處理（一）歸一化( MinMaxScaler/MaxAbsScaler)

從零寫一個編譯器（六）：語法分析之表驅動語法分析

C#資料結構與算法系列（十）：中綴表示式轉字尾表示式

大資料實戰（六）：flink（六）電商使用者行為分析（六）惡意登入監控

Docker 系列（四）：Docker 容器資料卷簡單使用

儲存引擎系列（四）：不同型別的查詢語句如何設定索引（上）—— 資料表初始化

儲存引擎系列（二）：資料庫索引底層資料結構 —— B+ 樹

Spark專案實戰從0到1之（20）企業級資料倉庫構建（三）：資料採集模組環境搭建（1）

程式設計師的自我修養（六）：保護執行緒間的共享資料轉載

從0到1使用Kubernetes系列（四）：搭建第一個應用程式

Python從零開始（三）：變數與基本資料型別

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

SECRET

ConfigMap

EmptyDir

HostPath

NFS 儲存卷

PersistentVolumeClaim

總結

相關推薦