從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
將宿主機對應目錄直接掛載到運行在該節點的容器中。使用該類型的卷，需要注意以下幾個方面：
- 使用同一個模板創建的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）就能很好的解決此類問題。
更多關於Kubernetes系列的文章：
- 從0到1使用Kubernetes系列（五）：Kubernetes Scheduling
- 從0到1使用Kubernetes系列（四）：搭建第一個應用程序
- 從0到1使用Kubernetes系列（三）：使用Ansible安裝Kubernetes集群
- 從0到1使用Kubernetes系列（二）——安裝工具介紹
- 從0到1使用Kubernetes系列——Kubernetes入門
關於Choerodon豬齒魚
Choerodon豬齒魚是一個開源企業服務平台，基於Kubernetes的容器編排和管理能力，整合DevOps工具鏈、微服務和移動應用框架，來幫助企業實現敏捷化的應用交付和自動化的運營管理的開源平台，同時提供IoT、支付、數據、智能洞察、企業應用市場等業務組件，致力幫助企業聚焦於業務，加速數字化轉型。
大家也可以通過以下社區途徑了解豬齒魚的最新動態、產品特性，以及參與社區貢獻：
- 官網：http://choerodon.io
- 論壇：http://forum.choerodon.io
- Github：https://github.com/choerodon
- 微信：Choerodon豬齒魚
- 微博：Choerodon豬齒魚
推薦閱讀：
