隨著容器為互聯網應用提供的敏捷開發、快速交付，對傳統金融IT帶來了技術革新的挑戰。針對數據爆炸式增長、應用復雜性提高、業務品種快速更新、應用系統軟件快速迭代等一系列挑戰，容器技術在金融行業數字化轉型浪潮中越來越受到青睞。

本文主要從容器云對存儲的使用方面做建議介紹。Kubernetes支持很多類型的卷，Pod可以同時使用任意數目的卷類型。臨時卷類型的生命周期與Pod相同，但持久卷可以比Pod的存活期長。當Pod不再存在時，Kubernetes也會銷毀臨時卷；不過Kubernetes不會銷毀持久卷。對于給定Pod中任何類型的卷，在容器重啟期間數據都不會丟失，卷掛載在鏡像中的指定路徑下。容器對接存儲，都會使用一個存儲CSI插件進行連接和管理。

容器云中存儲的分類

Kubernetes能使用的存儲可以分為如下幾類：

1）臨時存儲

常見的臨時存儲主要是emptyDir卷，當Pod分派到某個Node上時，emptyDir 卷會被創建，并且Pod在該節點上運行期間，卷一直存在。當Pod因為某些原因被從節點上刪除時，emptyDir 卷中的數據也會被永久刪除。一般情況下emptyDir存儲都是用來充當臨時存儲空間。emptyDir 常見的一些用途如：（1）緩存空間，例如基于磁盤的歸并排序。（2）為耗時較長的計算任務提供檢查點，以便任務能方便地從崩潰前狀態恢復執行。（3）在 Web 服務器容器服務數據時，保存內容管理器容器獲取的文件。

2）半持久存儲

半持久化存儲主要是HostPath。當使用HostPath卷時，它的范圍應盡量限于所需的文件或目錄，并以只讀方式掛載。HostPath 常見的一些用途如：（1）運行一個需要訪問Docker 內部機制的容器；可使用 hostPath 掛載 /var/lib/docker 路徑。（2）在容器中運行cAdvisor時，以 hostPath 方式掛載 /sys。（3）允許Pod指定給定的hostPath在運行 Pod 之前是否應該存在，是否應該創建以及應該以什么方式存在。

3）持久化存儲

對于持久化存儲，Kubernetest引入了StorageClass，Volume，PVC，PV的概念。Kubernetes支持的持久化存儲包括主流的塊存儲、對象存儲和網絡文件存儲等等。Kubernetes引入了兩個新的API資源：PersistentVolume和PersistentVolumeClaim。持久卷（PersistentVolume，PV）是集群中的一塊存儲，可以由管理員事先制備，或者使用存儲類（Storage Class）來動態制備。持久卷是集群資源，就像節點也是集群資源一樣。

4）特殊存儲

特殊存儲類主要包括secret，configMap等。（1）secret 卷用來給Pod傳遞敏感信息，例如密碼。secret 卷由tmpfs（基于RAM的文件系統）提供存儲，因此它們永遠不會被寫入非易失性（持久化的）存儲器。（2）ConfigMap提供了向Pod注入配置數據的方法，用來將非機密性的數據保存到鍵值對中，比如存儲卷中的配置文件，以key-value的形式調用。

容器云中存儲的使用

Kubernetes中，PV卷是集群中的資源。PVC申領是對這些資源的請求，也被用來執行對資源的申領檢查。PV卷和PVC 的使用過程一般如下：

1）制備：PV 卷的制備有兩種方式：靜態制備或動態制備。（1）靜態制備。集群管理員創建若干PV卷。這些卷對象帶有真實存儲的細節信息，并且對集群用戶可用。（2）動態制備。動態制備操作是基于StorageClass來實現的：PVC申領必須請求某個存儲類，同時集群管理員必須已經創建并配置了該類，這樣動態制備卷的動作才會發生。如果PVC申領指定存儲類為 “”（空），則相當于為自身禁止使用動態制備的卷。

2）綁定：用戶創建一個帶有特定存儲容量和特定訪問模式需求的PersistentVolumeClaim對象；在動態制備場景下，這個PVC對象可能已經創建完畢。一旦PV與PVC的綁定關系建立，則PersistentVolumeClaim綁定就是排他性的，PVC申領與PV卷之間的綁定是一種一對一的映射。

如果找不到匹配的PV卷，PVC申領會無限期地處于未綁定狀態。當與之匹配的PV卷可用時，PVC申領會被綁定。例如，即使某集群上制備了很多10 Gi大小的PV卷，也無法與請求20 Gi大小的存儲的PVC匹配。當新的20 Gi PV卷被加入到集群時，該PVC才有可能被綁定。

3）使用：Pod將PVC申領當做存儲卷來使用。集群會檢查PVC申領，找到所綁定的卷，并為Pod掛載該卷。對于支持多種訪問模式的卷，用戶要在Pod中以卷的形式使用申領時指定期望的訪問模式。

4）保護使用中的存儲對象：保護使用中的存儲對象（Storage Object in Use Protection）這一功能特性的目的是確保仍被Pod使用的PersistentVolumeClaim（PVC）對象及其所綁定的PersistentVolume（PV）對象在系統中不會被刪除，因為這樣做可能會引起數據丟失。

5）回收（Reclaiming）：當用戶不再使用其存儲卷時，他們可以從API中將PVC對象刪除，從而允許該資源被回收再利用。PersistentVolume對象的回收策略告訴集群，當其被從申領中釋放時如何處理該數據卷。目前，數據卷可以被 Retained（保留）、Recycled（回收）或 Deleted（刪除）。

• 保留（Retain）：回收策略 Retain 使得用戶可以手動回收資源。當PersistentVolumeClaim對象被刪除時，PersistentVolume卷仍然存在，對應的數據卷被視為"已釋放（released）"。
• 刪除（Delete）：對于支持Delete回收策略的卷插件，刪除動作會將PersistentVolume對象從 Kubernetes中移除，同時也會從外部基礎設施（如 AWS EBS、CEPH）中移除所關聯的存儲資產。
• 回收（Recycle）：回收策略Recycle在Kubernetes 新版本中已被廢棄。取而代之的建議方案是使用動態制備。

容器云存儲的落地實踐

目前，我們銀行已經在開發測試和生產環境部署了多套容器云集群平臺，并已經承載運行了重要應用系統的服務。現階段主要還是將無狀態的應用容器化，數據庫、中間件等一些有狀態的組件仍在虛擬機中運行，將在未來逐步遷移。行內容器云平臺涉及到的持久化存儲主要分為如下幾大塊：

1）容器鏡像類數據存儲。在內網環境中，建立一套自己的私有鏡像倉庫，做好相關配置后容器云平臺就可以從私有鏡像庫中拉取鏡像。當有pod所在服務器宕機或故障，pod需要在新節點啟動時，這時就會需要向私有鏡像庫拉取鏡像，當生產環境pod數量達到一定規模時，需要考慮多鏡像并行拉取導致的IO風暴。所以容器鏡像類數據存儲建議采用分布式塊存儲，能夠承擔一定的并發能力和有一定擴展能力的持久性存儲，當然有存量集中式塊存儲也是可以利舊以節約投資，同時也要考慮做好該部分存儲的備份或私有鏡像倉庫的冗余存儲。

2）Pod/container類數據存儲。容器云集群的Etcd 的數據會時刻以日志的形式記錄在內存和硬盤中，etcd 對磁盤的延遲會非常敏感，建議將Etcd部署在物理機/虛擬機（視集群規模）中，底層存儲配置SSD磁盤，保證低延遲、高性能的寫入。大部分應用Pod/container對于存儲性能要求不高，主要耗費計算資源，所以Pod/container在node上運行的鏡像建議采用服務器本地盤存儲即可。

3）應用之間共享類數據存儲。不管是有狀態還是無狀態應用之間需要共享數據時，NFS是一個主流的文件共享服務器。NFS數據卷可以提供對NFS掛載支持，可以自動將NFS共享路徑掛載到Pod中。在各應用pod中需文件共享時建議采用NAS雙活存儲提供的NFS文件系統以滿足業務系統文件共享需求。

4）日志類數據存儲。日志類數據收集，一般有如下常見幾種方案。（1）app的鏡像中自己集成日志收集組件，好處在于app應用的yaml文件不需要特殊配置，一個鏡像解決問題，但是同時也造成耦合性強，未來組件或應用無法單獨升級。（2）在同一個pod中運行app容器和日志收集組件容器，相較如上方案降低了耦合度，但是pod的yaml文件需單獨編寫、配置，較繁瑣。（3）直接將pod的日志掛在到宿主機node，每臺node起一個pod或者采用二進制進程進行日志收集，好處是收集日志與應用pod完全解耦，管理方便，只需要做好日志輸出規范，統一日志目錄和輸出方式即可，此方式日志存儲性能高。日志類數據存儲建議可采用pod日志輸出掛載在本地服務器的存儲，通過Filebeat+Logstash+ElasticSearch+Kibana（ELK）或者Fluentd + Filebeat + Elasticsearch + Kibana（EFK）構建統一的日志采集、分類、分析、查詢、展示平臺。

在整個容器云平臺的持久化存儲選型過程中，比如在日志類數據存儲我們也有考慮將其存放于分布式塊存儲（如ceph、longhorn等）上做日志統一存儲平臺，但是為沿用已有的ELK日志收集展示平臺、初期容器規模較小等原因，暫將分布式塊存儲列為二期規劃建設。一期主要完成無狀態應用的容器化工作，二期將重點放在有狀態應用（如redis、zk、輕載mysql等）的容器化，建議部署為StatefulSet，當節點重啟漂移到其他機器上時，可通過掛載的PVC(PersistentVolumeClaim)拿到原來的完整數據，但是分布式存儲帶來的讀寫延遲需要根據不同的容器化應用敏感程度配置不同性能的分布式存儲，以滿足對業務發展的IO需求。

總而言之，容器云持久化存儲最佳實踐沒有一個統一使用某種存儲的完美方案，而是需要根據業務類型、系統重要等級、集群規模、擴展性等多方面進行綜合考量，再結合本行的一個長遠規劃進行存儲架構設計，以匹配科技戰略，助力業務發展。