kubernetes對象之Volume

系列目錄

概述

Volume是對各類存儲資源的抽象、虛擬化。爲管理、控制、使用存儲資源提供統一接口。Openstack中的volume爲虛擬機提供存儲，Docker中的volume爲容器提供存儲。由於在kubernetes中可部署運行最小單位是pod ,因此kubernetes的volume爲pod提供存儲。固然在部署pod時能夠不爲其提供volume，pod中的容器使用所在節點的硬盤，能同時讀寫數據的地方稱爲可讀寫層。這種存儲是容器級的臨時存儲，不是pod級。其生命週期與容器相同，若是容器crash後被重啓，也就是舊容器被刪除而新容器啓動，則舊容器的可讀寫層與容器一塊兒被刪除，其上數據丟失。同理若是pod在節點之間遷移調度，容器的可讀寫層並不會遷移調度。所以，kubernetes須要提供pod級volume，本文中的volume特指kubernetes。

Volume類型
Volume是抽象概念，有不少種具體實現，每種實現各具目的、特色、特性。差很少什麼東西均可以當成volume，類型以下：

• awsElasticBlockStore
• azureDisk
• azureFile
• cephfs
• configMap
• csi
• downwardAPI
• emptyDir
• fc (fibre channel)
• flocker
• gcePersistentDisk
• gitRepo (deprecated)
• glusterfs
• hostPath
• iscsi
• local
• nfs
• persistentVolumeClaim
• projected
• portworxVolume
• quobyte
• rbd
• scaleIO
• secret
• storageos
• vsphereVolume

這裏不對以上全部類型一一介紹,只對目前可能會用到的本地磁盤存儲和分佈式存儲作簡單介紹說明

常見存儲類型說明及示例

cephfs

cephfs是一款優秀、流行的雲環境存儲解決方案，緣由是它開源、高可用、彈性伸縮，對操做系統、硬件無特殊要求，用戶很容易搭建，使用它的節點也無特別要求。它具有awsElasticBlockStore陳述之全部特色，而且單個voluem能夠被多個節點同時使用。用戶首先搭建本身的cephfs環境，而後配置kubernetes集羣與其對接，最後在pod中使用其提供的volume，詳細參考這裏。

configMap

用戶首先建立configＭap並建立數據保存其中，此時數據保存在kubernetes的etcd數據庫中，volume還不存在。當用戶在pod中引用建立的configMap時，系統首先在節點上建立volume並將數據保存其中，這個volume佔用的是節佔的存儲空間。此後就能夠像使用普通volume同樣使用它。

configMap是kubernetes中的一種對象類型，核心本質是以volume的方式將單獨管理的配置信息傳遞給pod中的容器，並不是用來存儲持久化數據。詳細參考這裏。

downwardAPI

與configＭap相似，以volume的方式向pod中的容器傳遞信息。configMap中的信息由用戶在建立對象時傳遞，而downwardAPI的信息就來自pod對象自己，downwardAPI不須要建立，它是pod Spec中的一個字段，內容指向pod對象自己的其它字段，如pod的metadata、image等信息。在建立pod時系統首先將指向的字段提取出來，而後建立volume並保存提取出來的字段並掛載，容器就能夠讀取這些字段了。

downwardAPI的目的是爲將pod自己的字段信息如label、annotation等傳遞給容器的一種手段。詳細參考這裏。

emptyDir

在節點上運行pod實例時纔會建立emptyDir volume。它首先是節點上的一個空目錄，pod中的任何容器均可以用volume的形式掛載使用它。若是容器由於某種緣由被刪除並從新啓動，建立的emptyDir不會刪除也不會被清空。當pod實例離開節點調度到其它節點或由於縮容被刪除時，emptyDir被刪除，至關於pod還在但數據丟了。示例：

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: k8s.gcr.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /cache
      name: cache-volume
  volumes:
  - name: cache-volume
    emptyDir: {}

glusterfs

與cephfs同樣，流行的雲環境下的存儲解決方案，詳細參考這裏，示例參考這裏。

hostPath

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: k8s.gcr.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /test-pd
      name: test-volume
  volumes:
  - name: test-volume
    hostPath:
      # directory location on host
      path: /data
      # this field is optional
      type: Directory

iscsi

互聯網小型計算機系統接口，其特色是便宜。示例參考這裏。

local

與emptyDir類似，它也佔用節點的存儲空間。不一樣點是它是kubernetes中的一種對象類型，用戶能夠像管理普通對象同樣管理它。emptyDir在pod實例開時運行時分配，當pod離節點時刪除。local類型的volume則由用戶建立，系統在合適的節點上爲其分配資源，調度到這個節點上的pod能夠掛載它，pod離開時它也不會消失，除非用戶刪除。示例：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: example-pv
spec:
  capacity:
    storage: 100Gi
  # volumeMode field requires BlockVolume Alpha feature gate to be enabled.
  volumeMode: Filesystem
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Delete
  storageClassName: local-storage
  local:
    path: /mnt/disks/ssd1
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - example-node

nfs

nfs
網絡文件系統，詳細參考這裏。

persistentVolumeClaim

與flocker類似，用來屏蔽不一樣雲環境，詳細參考這裏。

projected

若是一個容器須要掛開多個已經存在的volume好比Secret、ConfigMap、DownwardAPI等，本來每一個這種類型的volume須要各自佔用一個掛載目錄，而projected能將它們整合在一塊兒，並只掛開到一個目錄下，示例：

apiVersion: v1
kind: Pod
metadata:
  name: volume-test
spec:
  containers:
  - name: container-test
    image: busybox
    volumeMounts:
    - name: all-in-one
      mountPath: "/projected-volume"
      readOnly: true
  volumes:
  - name: all-in-one
    projected:
      sources:
      - secret:
          name: mysecret
          items:
            - key: username
              path: my-group/my-username
      - downwardAPI:
          items:
            - path: "labels"
              fieldRef:
                fieldPath: metadata.labels
            - path: "cpu_limit"
              resourceFieldRef:
                containerName: container-test
                resource: limits.cpu
      - configMap:
          name: myconfigmap
          items:
            - key: config
              path: my-group/my-config