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

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

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

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

SECRET

Secret對象允許您存儲和管理敏感信息，例如密碼，OAuth令牌和ssh密鑰。將此類信息放入一個secret中可以更好地控制它的用途，并降低意外暴露的風(fēng)險。

▌使用場景

鑒權(quán)配置文件掛載

▌使用示例

在CI中push構(gòu)建好的鏡像就可以將docker鑒權(quán)的config.json文件存入secret對象中，再掛載到CI的Pod中，從而進(jìn)行權(quán)限認(rèn)證。

• 首先創(chuàng)建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="}}}

• 清理環(huán)境

$ kubectl delete pod docker
$ kubectl delete secret docker-config

ConfigMap

許多應(yīng)用程序會從配置文件、命令行參數(shù)或環(huán)境變量中讀取配置信息。這些配置信息需要與docker image解耦ConfigMap API給我們提供了向容器中注入配置信息的機制，ConfigMap可以被用來保存單個屬性，也可以用來保存整個配置文件。

▌使用場景

配置信息文件掛載

▌使用示例

使用ConfigMap中的數(shù)據(jù)來配置Redis緩存

• 創(chuàng)建example-redis-config.yaml文件，粘貼以下信息：

apiVersion: v1
kind: ConfigMap
metadata:
  name: example-redis-config
data:
  redis-config: |
    maxmemory 2b
    maxmemory-policy allkeys-lru

• 創(chuàng)建ConfigMap

$ kubectl apply -f example-redis-config.yaml
configmap/example-redis-config created

• 創(chuàng)建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"

• 清理環(huán)境

$ kubectl delete pod redis
$ kubectl delete configmap example-redis-config

EmptyDir

當(dāng)使用emptyDir卷的Pod在節(jié)點創(chuàng)建時，會在該節(jié)點創(chuàng)建一個新的空目錄，只要該Pod運行在該節(jié)點，該目錄會一直存在，Pod內(nèi)的所有容器可以將改目錄掛載到不同的掛載點，但都可以讀寫emptyDir內(nèi)的文件。當(dāng)Pod不論什么原因被刪除，emptyDir的數(shù)據(jù)都會永遠(yuǎn)被刪除（一個Container Crash 并不會在該節(jié)點刪除Pod，因此在Container crash時，數(shù)據(jù)不會丟失）。默認(rèn)情況下，emptyDir支持任何類型的后端存儲：disk、ssd、網(wǎng)絡(luò)存儲。也可以通過設(shè)置 emptyDir.medium 為Memory，kubernetes會默認(rèn)mount一個tmpfs（RAM-backed filesystem），因為是RAM Backed,因此 tmpfs 通常很快。但是會在容器重啟或者crash時，數(shù)據(jù)丟失。

▌使用場景

同一Pod內(nèi)各容器共享存儲

▌使用示例

在容器a中生成hello文件，通過容器b輸出文件內(nèi)容

• 創(chuàng)建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: {}

• 創(chuàng)建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

• 清理環(huán)境

$ kubectl delete pod test-emptydir

HostPath

將宿主機對應(yīng)目錄直接掛載到運行在該節(jié)點的容器中。使用該類型的卷，需要注意以下幾個方面：

1. 使用同一個模板創(chuàng)建的Pod，由于不同的節(jié)點有不同的目錄信息，可能會導(dǎo)致不同的結(jié)果

2. 如果kubernetes增加了已知資源的調(diào)度，該調(diào)度不會考慮hostPath使用的資源

3. 如果宿主機目錄上已經(jīng)存在的目錄，只可以被root可以寫，所以容器需要root權(quán)限訪問該目錄，或者修改目錄權(quán)限

▌使用場景

運行的容器需要訪問宿主機的信息，比如Docker內(nèi)部信息/var/lib/docker目錄，容器內(nèi)運行cadvisor，需要訪問/dev/cgroups

▌使用示例

使用Docker socket binding模式在列出宿主機鏡像列表。

• 創(chuàng)建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

• 創(chuàng)建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 卷允許將現(xiàn)有的 NFS（網(wǎng)絡(luò)文件系統(tǒng)）共享掛載到您的容器中。不像 emptyDir，當(dāng)刪除 Pod 時，nfs 卷的內(nèi)容被保留，卷僅僅是被卸載。這意味著 nfs 卷可以預(yù)填充數(shù)據(jù)，并且可以在 pod 之間共享數(shù)據(jù)。 NFS 可以被多個寫入者同時掛載。

• 重要提示：您必須先擁有自己的 NFS 服務(wù)器然后才能使用它。

▌使用場景

不同節(jié)點Pod使用統(tǒng)一nfs共享目錄

▌使用示例

• 創(chuàng)建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

• 創(chuàng)建測試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>

• 進(jìn)入Pod中進(jìn)行測試

# 進(jìn)入uat05節(jié)點的pod中
$ kubectl exec -it test-nfs-859ccfdf55-kkgxj sh
# 創(chuàng)建文件
$ echo "uat05" > /data/uat05
# 退出uat05節(jié)點的pod
$ edit
# 進(jìn)入uat06節(jié)點的pod中
$ kubectl exec -it test-nfs-859ccfdf55-aewf8 sh
# 查看文件內(nèi)容
$ cat /data/uat05
uat05

• 清理環(huán)境

$ kubectl delete deployment test-nfs

PersistentVolumeClaim

上面所有例子中我們都是直接將存儲掛載到的pod中，那么在kubernetes中如何管理這些存儲資源呢？這就是Persistent Volume和Persistent Volume Claims所提供的功能。

● PersistentVolume 子系統(tǒng)為用戶和管理員提供了一個 API，該 API 將如何提供存儲的細(xì)節(jié)抽象了出來。為此，我們引入兩個新的 API 資源：PersistentVolume 和 PersistentVolumeClaim。

• PersistentVolume（PV）是由管理員設(shè)置的存儲，它是群集的一部分。就像節(jié)點是集群中的資源一樣，PV 也是集群中的資源。 PV 是 Volume 之類的卷插件，但具有獨立于使用 PV 的 Pod 的生命周期。此 API 對象包含 Volume 的實現(xiàn)，即 NFS、iSCSI 或特定于云供應(yīng)商的存儲系統(tǒng)。

• PersistentVolumeClaim（PVC）是用戶存儲的請求。它與 Pod 相似。Pod 消耗節(jié)點資源，PVC 消耗 PV 資源。Pod 可以請求特定級別的資源（CPU 和內(nèi)存）。聲明可以請求特定的大小和訪問模式（例如，可以以讀/寫一次或 只讀多次模式掛載）。雖然 PersistentVolumeClaims 允許用戶使用抽象存儲資源，但用戶需要具有不同性質(zhì)（例如性能）的 PersistentVolume 來解決不同的問題。集群管理員需要能夠提供各種各樣的 PersistentVolume，這些PersistentVolume 的大小和訪問模式可以各有不同，但不需要向用戶公開實現(xiàn)這些卷的細(xì)節(jié)。對于這些需求，StorageClass 資源可以實現(xiàn)。

● 在實際使用場景里，PV 的創(chuàng)建和使用通常不是同一個人。這里有一個典型的應(yīng)用場景：管理員創(chuàng)建一個 PV 池，開發(fā)人員創(chuàng)建 Pod 和 PVC，PVC 里定義了Pod所需存儲的大小和訪問模式，然后 PVC 會到 PV 池里自動匹配最合適的 PV 給 Pod 使用。

▌使用示例

• 創(chuàng)建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

• 創(chuàng)建PersistentVolumeClaim

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: myclaim
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 5Gi
  volumeName: mypv

• 創(chuàng)建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運行情況驗證綁定結(jié)果

$ 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

• 清理環(huán)境

$ kubectl delete pv mypv
$ kubectl delete pvc myclaim
$ kubectl delete po mypod

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

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

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