Kubernetes中的常用儲存類型有哪些

今天就跟大家聊聊有關Kubernetes中的常用儲存類型有哪些，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

下面將為大家介紹幾種常用儲存類型。

默認情況下Pod掛載在磁盤上的文件生命周期與Pod生命周期是一致的，若Pod出現崩潰的情況，kubelet 將會重啟它，這將會造成Pod中的文件將丟失，因為Pod會以鏡像最初的狀態重新啟動。在實際應用當中，開發者有很多時候需要將容器中的數據保留下來，比如在Kubernetes中部署了MySql，不能因為MySql容器掛掉重啟而上面的數據全部丟失；其次，在 Pod 中同時運行多個容器時，這些容器之間可能需要共享文件。也有的時候，開發者需要預置配置文件，使其在容器中生效，例如自定義了mysql.cnf文件在MySql啟動時就需要加載此配置文件。這些都將是今天將要實戰解決的問題。

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

使用configMap對redis進行緩存配置，這樣即使redis容器掛掉重啟configMap中的配置依然會生效。接著又使用emptyDir來使得同一Pod中多個容器的目錄共享，在實際應用中開發者通常使用initContainers來進行預處理文件，然后通過emptyDir傳遞給Containers。然后再使用hostPath來訪問宿主機的資源，當網路io達不到文件讀寫要求時，可考慮固定應用只運行在一個節點上然后使用hostPath來解決文件讀寫速度的要求。

NFS和PersistentVolumeClaim的例子實質上都是試容器掛載的nfs服務器共享目錄，但這些資源一般都只掌握在了管理員手中，開發人員想要獲取這部分資源那么就不是這么友好了，動態存儲類（StorageClass）就能很好的解決此類問題。

看完上述內容，你們對Kubernetes中的常用儲存類型有哪些有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。