摘要：如果我們的容器使用，文件如下在這個例子中，我們可以重復創建和銷毀，同一個持久存儲會被提供給新的，無論容器位于哪個節點上。

臨時性存儲是容器的一個很大的買點?！案鶕粋€鏡像啟動容器，隨意變更，然后停止變更重啟一個容器。你看，一個全新的文件系統又誕生了。”

在docker的語境下：

# docker run -it centos
[root@d42876f95c6a /]# echo "Hello world" > /hello-file
[root@d42876f95c6a /]# exit
exit
# docker run -it centos
[root@a0a93816fcfe /]# cat /hello-file
cat: /hello-file: No such file or directory

當我們圍繞容器構建應用程序時，這個臨時性存儲非常有用。它便于水平擴展：我們只是從同一個鏡像創建多個容器實例，每個實例都有自己獨立的文件系統。它也易于升級：我們只是創建了一個新版本的映像，我們不必擔心從現有容器實例中保留任何內容。它可以輕松地從單個系統移動到群集，或從內部部署移動到云：我們只需要確保集群或云可以訪問registry中的鏡像。而且它易于恢復：無論我們的程序崩潰對文件系統造成了什么損壞，我們只需要從鏡像重新啟動一個容器實例，之后就像從未發生過故障一樣。

因此，我們希望容器引擎依然提供臨時存儲。但是從教程示例轉換到實際應用程序時，我們確實會遇到問題。真實的應用必修在某個地方存儲數據。通常，我們將狀態保存到某個數據存儲中（SQL或是NOSQL）。這也引來了同樣的問題。數據存儲也是位于容器中嗎？理想情況下，答案是肯定的，這樣我們可以利用和應用層相同的滾動升級，冗余和故障轉移機制。但是，要在容器中運行我們的數據存儲，我們再也不能滿足于臨時存儲。容器實例需要能夠訪問持久存儲。

如果使用docker管理持久性存儲，有兩種主流方案：我們可以在宿主機文件系統上指定一個目錄，或者是由Docker管理存儲：

# docker volume create data
data
# docker run -it -v data:/data centos
[root@5238393087ae /]# echo "Hello world" > /data/hello-file
[root@5238393087ae /]# exit
exit
# docker run -it -v data:/data centos
[root@e62608823cd0 /]# cat /data/hello-file
Hello world

Docker并不會保留第一個容器的根目錄，但是它會保留“data”卷。而該卷會被再次掛載到第二個容器上。所以該卷是持久存儲。

在單節點系統上這樣的方法是ok的。但是在一個容器集群環境下如Kubernetes或是Docker Swarm，情況會變得復雜。如果我們的數據存儲容器可能在上百個節點中的任意一個上啟動，而且可能從一個節點隨時遷移到另一個節點，我們無法依賴于單一的文件系統來存儲數據，我們需要一個能夠感知到容器的分部署存儲的方案，從而無縫集成。

在深入容器持久化的方案之前，我們應該先了解一下這個方案應該滿足什么特性，從而更好的理解各種容器持久化方案的設計思路。

將應用移動到容器中并且將容器部署到一個編排環境的原因在于我們可以有更多的物理節點，從而可以支持部分節點當掉。同理，我們也希望持久化存儲能夠容忍磁盤和節點的崩潰并且繼續支持應用運行。在持久化的場景下，冗余的需求更加重要了，因為我們無法忍受任何數據的丟失。

冗余的持久化驅動我們使用某種分布式策略，至少在磁盤層面上。但是我們還希望通過分布式存儲來提高性能。當我們將容器水平擴展到成百上千個節點上是，我們不希望這些節點競爭位于同一個磁盤上的數據。所以當我們將服務部署到各個區域的環境上來減少用戶延時時，我們還希望將存儲也同時分布式部署。

容器架構持續變更。新版本不斷的被構建，更新，應用被添加或是移除。測試用例被創建并啟動，然后被刪除。在這個架構下，需要能夠動態的配置和釋放存儲。事實上，配置存儲應當和我們聲明容器實例，服務和網絡連通性一樣通過聲明來實現。

容器技術在飛速發展，我們需要能夠引入新的存儲策略，并且將應用移植到新的存儲架構上。我們的存儲策略需要能夠支持任何底層架構，從開發人員用于測試的單節點到一個開放的云環境。

我們需要為各種類型的應用提供村塾，而且我們需要持續更新存儲方案。這意味著我們不應該將應用強關聯與一個存儲方案。因此，存儲需要看上去像是原生的，也就是對上層用戶來說仿佛是一個文件系統，或者是某種現有的，易于理解的API。

另一種說法是我們希望容器存儲解決方案是“Cloud Native”（云原生的）。云原生計算組織（CNCF）定義了云原生系統的三個屬性。這些屬性也適用于存儲：

容器打包： 我們的物理或虛擬存儲位于容器之外，但是我們希望它僅對特定容器課件（這樣的話，容器就不會共享存儲，除非特殊需求）。除此以外，我們可能希望容器化存儲管理軟件本身，從而利用容器化來管理和升級存儲管理軟件。

動態管理：對于有狀態容器的持久部署，我們需要在無需管理員認為干預的情況下，分配存儲給新的容器，并清理失效的存儲。

面向微服務：當我們定義一個容器的時候，他應當明確的制定對存儲的依賴。除此以外，存儲管理軟件本身應當基于微服務部署，從而更好的實現擴容和異地部署。

為了滿足容器持久化存儲的需求，Kubernetes和Docker Swarm提供了一組聲明式資源來聲明并綁定持久化存儲至容器。這些持久化存儲的功能構建與一些存儲架構之上。我們首先來看一下這兩種環境下是如何支持容器來聲明對持久化存儲的以來的。

在Kubernetes中，容器存活于Pods中。每個pod包含一個或多個容器，它們共享網絡棧和持久存儲。持久化存儲的定義位于pod定義的volumn字段下。該卷可以被掛在到pod的任意一個容器下。比如，一下有一個Kubernetes的Pod定義，它使用了一個emptyDir卷在容器間共享信息。emptyDir卷初始為空，即使pod被遷移到另一個節點上仍將保存下來（這意味著容器的崩潰不會使其消失，但是node崩潰會將其刪除）

apiVersion: v1
kind: Pod
metadata:
  name: hello-storage
spec:
  restartPolicy: Never
  volumes:
  - name: shared-data
    emptyDir: {}
  containers:
  - name: nginx-container
    image: nginx
    volumeMounts:
    - name: shared-data
      mountPath: /usr/share/nginx/html
  - name: debian-container
    image: debian
    volumeMounts:
    - name: shared-data
      mountPath: /pod-data
    command: ["/bin/sh"]
    args: ["-c", "echo Hello from the debian container > /pod-data/index.html"]

如果你將以上內容保存到名為two-containers.yaml并使用kubectl create -f two-containers.yaml將其部署到kubernetes上，我們可以使用pod的IP地址來訪問NGINX服務器，并獲取新建的index.html文件。

這個例子說明了Kubernetes是如何支持在pod中使用volumn字段聲明一個存儲依賴的。但是，這不是真正的持久化存儲。如果我們的Kubernetes容器使用AWS EC2，yaml文件如下：

apiVersion: v1
kind: Pod
metadata:
  name: webserver
spec:
  containers:
  - image: nginx
    name: nginx
    volumeMounts:
    - mountPath: /usr/share/nginx/html
      name: web-files
  volumes:
  - name: web-files
    awsElasticBlockStore:
      volumeID: 
      fsType: ext4

在這個例子中，我們可以重復創建和銷毀pod，同一個持久存儲會被提供給新的pod，無論容器位于哪個節點上。但是，這個例子還是無法提供動態存儲，因為我們在創建pod之前必須先創建好EBS卷。為了從Kubernetes獲得動態存儲的支持，我們需要另外兩個重要的概念。第一個是storageClass，Kubernetes允許我們創建一個storageClass資源來收集一個持久化存儲供應者的信息。然后將其和persistentVolumeClaim，一個允許我們從storageClass動態請求持久化存儲的資源結合起來。Kubernetes會幫我們向選擇的storageClass發起請求。這里還是以AWS EBS為例：

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: file-store
provisioner: kubernetes.io/aws-ebs
parameters:
  type: io1
  zones: us-east-1d, us-east-1c
  iopsPerGB: "10"
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: web-static-files
spec:
  resources:
    requests:
      storage: 8Gi
  storageClassName: file-store
---
apiVersion: v1
kind: Pod
metadata:
  name: webserver
spec:
  containers:
  - image: nginx
    name: nginx
    volumeMounts:
    - mountPath: /usr/share/nginx/html
      name: web-files
  volumes:
  - name: web-files
    persistentVolumeClaim:
      claimName: web-static-files

如你所見，我們還在使用volume關鍵字來制定pod所需要的持久化存儲，但是我們使用了額外的PersistentVolumeClaim聲明來請求Kubernenetes替我們發起請求?？傮w上，集群管理員會為每一個集群部署一個StorageClass代表可用的底層存儲。然后應用開發者會在第一次需要持久存儲時指定PersistentVolumeClaim。之后根據應用程序升級的需要部署和更換pod，不會丟失持久存儲中的數據。

Docker Swarm利用我們在單節點Docker卷上看到的核心卷管理功能, 從而支持能夠為任何節點上的容器提供存儲：

version: "3"
services:
  webserver:
    image: nginx
    volumes:
      - web-files:/usr/share/nginx/html
volumes:
  web-files:
    driver: storageos
    driver-opts:
      size: 20
      storageos.feature.replicas: 2

當我們使用docker棧部署時，Docker Swarm會創建web-files卷，仿佛它并不存在。這個卷會被保留，及時我們刪除了docker棧。

總的來說，我們可以看到Kubernetes和Docker都滿足了云原生存儲的要求。他們允許容器聲明依賴的存儲，并且動態的管理存儲從而使其在應用需要時可見。無論容器在集群的哪個機器上運行，他們都能夠提供持久存儲。

想要了解更多開發技術，面試教程以及互聯網公司內推，歡迎關注我的微信公眾號！將會不定期的發放福利哦~