容器雲對接持久化儲存並使用

隨著容器為網際網路應用提供的敏捷開發、快速交付，對傳統金融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需求。

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