從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

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

使用同一個模板建立的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）就能很好的解決此類問題。

關於Choerodon豬齒魚

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

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

官網：choerodon.io
論壇：forum.choerodon.io
Github：github.com/choerodon
微信公眾號：Choerodon豬齒魚
微博：Choerodon豬齒魚

從0到1使用Kubernetes系列——Kubernetes入門
2018-08-29
從0到1使用Kubernetes系列（二）——安裝工具介紹
2018-09-17
從0到1使用Kubernetes系列（三）——使用Ansible安裝Kubernetes叢集
2018-11-05
node專案從0到1實戰
2022-02-15
Kafka實戰－資料持久化
2016-04-25
Kafka持久化
從0到1使用Kubernetes系列（四）：搭建第一個應用程式
2018-12-04
從0到1使用VUE-CLI3開發實戰(五):模組化VUEX及使用vuetify
2019-01-25
Vue
CocoaPods 系列之六 Private Pods 製作私有庫從0到1
2018-04-27
阿波羅JDFlutter實戰系列1：從0-1整合元件
2021-08-18
Flutter元件
QQ日跡Omi實戰開發，從0到1
2017-07-17
從0到1，資料治理一週年大紀實
2022-07-25
從0到1實現Promise
2018-09-28
Promise
RocketMQ實戰系列從理論到實戰
2019-04-23
MQ
Kubernetes 持久化資料儲存 StorageClass
2021-09-08
持久化
汽車之家資料庫服務化平臺從0到1的實踐過程
2018-08-23
資料庫
webpack從0到1使用指南
2018-05-19
Web
前端大資料視覺化從入門到實戰
2021-01-19
前端大資料視覺化
從0到1完成nutch分散式爬蟲專案實戰
2019-01-08
分散式爬蟲
selenium 資料驅動框架自動化從0到1--3
2020-11-13
框架
手把手從0到1：搭建Kubernetes叢集
2021-11-09
從0到1使用VUE-CLI3開發實戰（四）: Axios封裝
2019-02-16
VueiOS封裝
Kubernetes持久化儲存1——示例
2017-03-27
持久化
從 0 到 1 實現 React 系列 —— 5.PureComponent 實現 && HOC 探幽
2019-02-28
React
Express 實戰（八）：利用 MongoDB 進行資料持久化
2017-09-16
ExpressMongoDB持久化
從0到1使用VUE-CLI3開發實戰(六)：這是一個有程式碼潔癖的專案
2019-01-26
Vue
《SpringBoot實戰：從0到1》第1章SpringBoot簡介
2017-08-03
Spring Boot
從0到1使用kubebuiler開發operator
2022-05-19
UI
Flutter入門實戰：從0到1仿寫web版掘金App
2018-12-13
FlutterWebAPP
從0到1實現VueUI庫思路
2018-11-25
VueUI
Docker最全教程——從理論到實戰（六）
2018-12-07
Docker
Angular 從 0 到 1 (六）史上最簡單的 Angular 教程
2016-12-26
Angular
《從 0 到 1：搭建一個完整的 Kubernetes 叢集》實踐踩坑
2019-12-13
【許曉笛】EOS 資料庫與持久化 API —— 實戰
2018-11-20
資料庫持久化API
2020實戰覆盤：如何從0到1搭建資料傳輸平臺產品DTS？
2021-01-05
回顧·大資料平臺從0到1之後
2019-03-03
大資料
從0到1，成為大資料行業領袖
2018-03-26
大資料行業
Vue3 全家桶，從 0 到 1 實戰專案，新手有福了
2021-12-23
Vue
【React 實戰教程】從0到1 構建 github star管理工具
2018-11-09
ReactGithub

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

SECRET

ConfigMap

EmptyDir

HostPath

NFS儲存卷

PersistentVolumeClaim

總結

更多關於Kubernetes系列的文章：

關於Choerodon豬齒魚

相關文章