隨著金融行業的信息化建設深入，云技術在銀行應用日益普及，繼虛擬機替代傳統裸機大規模應用之后，容器作為一種新興操作系統級虛擬化技術應運而生，而基于容器技術所構建的應用開發、應用托管和應用運維平臺則可以稱為PaaS容器云平臺，容器結合日志、監控、認證、權限等基礎能力可以構建企業級的平臺和可復用服務，支撐企業業務敏捷研發和模式轉型，采用微服務架構實現企業技術服務中臺能力，容器云主要用于運行無狀態應用，但在某些特殊場景下，我們也需要容器去保存其狀態。本文主要從銀行實際應用出發，闡述容器云特性及持久化存儲方案實踐。

?一、 云平臺以及容器

IaaS/PaaS 是云平臺中建設中目前應用相對較廣的兩部分能力，其中PaaS在IaaS的基礎上，提供中間件，數據庫，以及容器云等便捷部署和運維能力，中間件和數據庫可以提供虛擬機部署形態，也可以提供容器資源部署。從容器自身來說，其提供的是 IaaS 層基礎計算能力，且常用于無狀態應用，容器消亡后無法保存消亡時的狀態。容器技術除了Docker以外，還有Coreos或者Podman等其他容器。相對來說，目前Docker 是一種最為常見容器引擎，金融行業通常使用 Docker 來運行操作容器，采用Kubernetes進行容器的編排管理，使用Kubernetes 實現容器調度和管理的能力，容器技術的應用為 PaaS 平臺的實現提供了一種新的資源形態，在金融私有云中，通常采用租戶進行IaaS資源的隔離，一個租戶可以配置一個或者多個Kubernetes集群，用于運行不同的應用系統，容器加上云計算租戶功能，則可以實現容器云平臺功能。

二、容器特點如何滿足中小銀行應用場景

可以結合微服務架構的思想構建容器化 PaaS 平臺，每個容器其實就是云操作系統的一個組件 / 進程， Kubernetes 相當于內核實現管理和調度這些組件 / 進程，而容器化 PaaS 平臺則是多集群多類型資源多類型應用的企業級云操作系統。提供應用開發、應用托管、應用運維的 PaaS 平臺能力?；谌萜魉鶚嫿ǖ娜萜髟破脚_的優勢也來源于容器的特點，適合輕量、變化快、彈性擴縮容、容器云平臺要使用基礎設施資源。通常我們基于虛擬化來構建容器云平臺節點，這樣可以實不提供中間件等服務，云管只管云基礎設施資源。

容器云平臺支撐微服務架構的應用則具備天生的優勢。而通過微服務化在企業內部構建可重用的技術服務、數據服務、業務服務等來構建服務中臺則能支撐企業業務應用的敏捷迭代，這才是比較好的匹配。容器作為一種開源技術，在不斷的發展完善中。由于其技術的快速迭代和變化，使很多對穩定性要求高的企業在應用容器技術時都采用小步快走的模式，在金融行業則是更甚。容器云平臺因它對于開發者具備便捷的調試、開發、部署、運維、遷移、擴容特性，并且伴隨著企業數字化轉型的加快，企業需要具有資源統一管理能力、系統彈性伸縮能力、運維成本低的平臺并結合 DevOps 和智能運維，實現開發、測試到系統運維、軟件交付的全生命周期一體化管理平臺，容器技術越來越熱。

眾所周知，銀行業屬于對IT科技要求很高的行業，銀行業在以往的IT建設中并不追求用最前沿最新的技術，而主要追求系統的可靠性與穩定性，因此相對互聯網公司，容器在銀行業的應用會相對步驟偏慢。但是，隨著容器在多個行業的深入應用，金融行業對于容器云也逐步深化應用，在金融領域銀行是容器云平臺典型的應用場景。由于互聯網技術的飛速發展，新興的金融類服務模式對銀行業務帶來了沖擊，近年來，銀行持續在對業務模式進行創新，也催生了對于傳統IT 流程、基礎架構和運維模式的升級，容器技術的成熟為傳統金融企業的數字化轉型提供了新思路。

銀行應用容器的主要場景:第一類是有敏態業務場景、內部的規范化管理。其中業務場景主要指銀行正在從傳統柜臺辦理業務向新應用轉型，在設計互聯網區域一些響應快速需求的敏態區域，則需要加快應用的部署能力，提升持續交付的能力，通過容器云平臺一方面可以標準化應用的部署和交付，另一方面更好地與 CI/CD 技術進行融合，可快速響應敏態業務的需求。第二類是內部規范化管理需要，主要是指銀行系統分支機構眾多、組織架構繁雜，通過云平臺中容器云管理能力，能規范化的管理容器鏡像、實現基礎安全和性能配置基線統一，更高效地管理 IT 基礎設施，滿足系統的合規性要求。

三、容器的存儲與配置

3.1 城商容器云持久化存儲應用場景及容器的持久化存儲類型

目前在城商行使用了容器云的，更多是用于部署應用層的一些組件，在涉及一些需要進行彈性伸縮的業務場景，例如秒殺、活動優惠等敏捷態業務，則采用容器部署應用app層的一些純Java程序、中間件、無狀態的Redis集群等，此外也會逐步碰到一些場景，需要我們的容器平臺能保存狀態，我們部署 MySQL、Redis 等數據庫，需要對這些數據庫產生的數據做備份。在容器云中，我們對Kubernetes中部署的應用都是以 Pod 容器的形式運行的，因為Pod是有生命周期的，如果 Pod 不掛載數據卷，那 Pod 被刪除或重啟后這些數據會隨之消失，如果想要長久的保留這些數據就要用到 Pod 數據持久化存儲。

除了希望數據不在Pod重啟后丟失，有時候也需要在Pod間共享文件。因此，衍生了Pod存儲持久化的話題。在云平臺的容器云中，都提供了一些方案來解決容器掛載持久化存儲的問題，但是主要都是通過Kubernetes提出的Volume對象方案進行封裝來解決該問題。

容器云支持的卷類型比較豐富，包括NFS文件系統，或者ISCSI/FC等映射存儲，Cephfs等分布式存儲系統，AWS等公有云存儲服務，還有EmptyDir，HostPath 等Kubernetes內置存儲類型。其中目前常見的主要是NFS映射文件系統，以及Hostpath內置存儲。Cephfs等分布式對象存儲系統，因其靈活擴容能力和海量存儲特性，目前有部分用戶用于進行容器備份。

其中 HostPath Volume 是指Pod掛載宿主機上的目錄或文件。HostPath Volume 使得容器可以使用宿主機的文件系統進行存儲，Hostpath（宿主機路徑）是節點級存儲卷，在Pod被刪除后存儲卷仍然存在Pod運行worknode上不會被刪除，只要同一個Pod 被調度到該節點上，在 Pod 被刪除重新被調度到這個節點之后，對應的數據依然是存在的。Hostpath 存儲卷缺點在于 Pod 刪除之后重新創建必須調度到同一個 node 節點，數據才不會丟失，對于多個Node的場景，是不合適采用的。

EmptyDir 類型的 Volume 是在 Pod 分配到 Node 上時被創建，Kubernetes 會在 Node 上自動分配一個目錄，因此無需指定宿主機 Node 上對應的目錄文件。這個目錄的初始內容為空，當 Pod 從 Node 上移除時， EmptyDir 中的數據會被永久刪除。EmptyDir Volume 主要用于某些應用程序無需永久保存的臨時目錄，多個容器的共享目錄等，但是如果是需要進行持久化存儲，則不合適采用。下面我們主要還是針對NFS方式配置持久化存儲進行闡述。

3.2 容器持久化存儲配置

容器在使用Volume時不需要關心后端存儲是什么系統，對它來說，所有類型的Volume都只是一個目錄。我們想要使用存儲卷，需要經歷如下步驟：

1、定義 PersistentVolume，并定義pvc指明這個 volume 要關聯到哪個存儲上的；2、在容器中要使用 Volumemounts 掛載對應的存儲，經過兩步才能正確的使用存儲卷。

PersistentVolume（PV）是群集中的一塊存儲，由管理員配置或使用存儲類動態配置，就像pod 是k8s 集群資源以及一個Lun的存儲單元可以類比于集中式存儲的最小邏輯單元一樣， PV被定義為集群中的基礎資源， PV 可以認為是一個存儲插件，其生命周期獨立于使用 PV 的任何單個pod。

PersistentVolumeClaim（PVC）則是一個持久化存儲卷，我們在創建 Pod 時可以定義這個類型的存儲卷。 它類似于一個Pod。Pod 消耗節點資源，PVC 消耗 PV 資源。Pod 可以請求特定級別的資源（CPU 和內存）。PVC 在申請 PV 的時候也可以請求特定的大小和訪問模式（例如，可以一次讀寫或多次只讀）。

三種PV的訪問模式：

（1）ReadWriteOnce：是最基本的方式，可讀可寫，但只支持被單個Pod掛載。

（2）ReadOnlyMany：可以以只讀的方式被多個Pod掛載。

（3）ReadWriteMany：這種存儲可以以讀寫的方式被多個Pod共享。

不是每一種存儲都支持這三種方式，像共享方式，目前支持的還比較少，比較常用的是NFS。在PVC綁定PV時通常根據兩個條件來綁定，一個是存儲的大小，另一個就是訪問模式。PV在設計時可以按照業務系統進行掛載，一個業務系統多個pod都共享同一個PV存儲，按照目錄進行區分，采用ReadWriteOnce模式；也可以精細化管理，每個pod對應一個PV，采用ReadWriteMany模式。

三個重聲明策略(reclaim policy)：

（1）Retain手動重新使用，生產系統中，因通常存儲上都是需要保留的數據、日志等，最為常用。

（2）Recycle基本的數據擦除 (“rm -rf /thevolume/*”)。

（3）Delete相關聯的后端存儲卷刪除， 后端存儲比如AWS EBS, GCE PD, Azure Disk, or OpenStack Cinder。

只有本地盤和NFS支持數據盤Recycle 擦除回收， 而AWS云盤或者Cinder存儲卷支持Delete策略。

PV卷包含四個階段狀態，其中Available狀態表示資源尚未被claim使用；Bound狀態表示卷已經被綁定到一個claim聲明；Released狀態表示聲明使用已經被刪除，卷處于釋放狀態，但未被集群回收。Failed狀態表示卷自動回收失敗。

PV是群集中的資源，PVC是對這些資源的請求，并且還充當對資源的檢查。PV和PVC之間的相互作用遵循以下生命周期：Provisioning，Binding，Using，Releasing，Recycling。

（1）供應準備Provisioning。Provisioning分為靜態和動態兩種，靜態提供Static：集群管理員創建多個PV。它們攜帶可供集群用戶使用的真實存儲的詳細信息。它們存在于Kubernetes API中，可用于消費，在生產系統中，推薦使用靜態，便于管理員在存儲段進行規范化的管理，并且靜態分配的存儲的數據是可以由管理員決定是否保存的，PV的命名也可以通過不同業務進行區分。NFS不支持動態存儲，動態通常需要借助第三方插件，當管理員創建的靜態PV都不匹配用戶的PersistentVolumeClaim時，集群可能會嘗試為PVC動態配置卷，動態分配的存儲總是會被刪除掉的。動態方式實際使用較少，可以考慮用于開發測試等非生產場景。

（2）綁定Binding。PVC根據請求的條件篩選并綁定對應的PV，一定PVC綁定PV后， 就會排斥其它綁定，即其它PVC無法再綁定同一個PV，即使這個PV設定的access mode允許多個node讀寫。此外 ，PVC 如何匹配不到相應條件的PV， 那么就會顯示unbound保持未綁定狀態，直到匹配為止。

（3）使用Using。Pods 掛載存儲， 即在Pod的template文件中定義Volumn使用某個PVC，用戶可在Pod中像volume一樣使用PVC。

（4）釋放Releasing。用戶刪除PVC來回收存儲資源，PV將變成“released”狀態。由于還保留著之前的數據，這些數據需要根據不同的策略來處理，否則這些存儲資源無法被其他PVC使用。見PersistentVolumeReclaimPolicy。

（5）重聲明Reclaiming。到這個階段會告訴cluster如何處理釋放的PV。數據可能被保留（需要手工清除），回收和刪除。

（6）回收Recycling---PV可以設置三種回收策略：保留（Retain），回收（Recycle）和刪除（Delete）。保留策略：允許人工處理保留的數據。刪除策略：將刪除PV和外部關聯的存儲資源，需要插件支持。回收策略：將執行清除操作，之后可以被新的PVC使用，需要插件支持。

3.3 NFS配置持久化存儲經驗分享

在實際生產環境中，針對有狀態的容器進行存儲設計時，需要考慮高可用、靈活擴容能力、便捷管理幾個方面。目前在城商行已有的案例中，較為常見的方案是采用集中式或者分布式NAS存儲提供持久化存儲服務，劃分文件系統給容器云掛載PV卷。目前采用集中式或分布式存儲提供持久化存儲服務，能較好的滿足在高可用、靈活擴容能力、便捷管理幾個方面的要求。

1、穩定性及性能：容器在進行彈性伸縮或者進行故障恢復時，同時將頻繁的發生存儲卷的掛載和卸載，為了保證整個生產環境的穩定性，在進行卷的掛載和卸載操作中需要保證足夠的穩定性，同時也需要PV卷服務端能保證較高的性能，避免應用延遲。采用專用的集中式存儲NFS可以提供較為穩定、高性能的存儲服務。集中式存儲設備通過Raid、冗余存儲機頭、分布式集群多節點等能力，保證了硬件故障情況下的高穩定性；當NFS表現出性能不足的情況下，集中式存儲可采用增加端口綁定的方式提升帶寬，分布式存儲也同樣可以采用增加綁定端口提升帶寬，擴容分布式節點提升整體集群存儲性能。

2、容災能力需求：通常銀行業會要求重要業務進行兩地三中心部署，通過集中式存儲和分布式存儲本身的雙中心雙活能力，也可以構建雙中心架構的容器集群。

3、運維管理需求：隨著容器有狀態應用的增長，對傳統存儲運維工作也會帶來挑戰，整體方案需要兼顧運維敏捷和安全。集中式和分布式NAS存儲產品，均具備界面化、便捷的管理手段。

4、容量擴容需求：隨著容器應用數據的增長，存儲卷容量需要考慮擴容的能力，最大程度避免對應用運行的影響。分布式集群更為靈活的擴容能力，集中式存儲在最大可配置硬盤柜范圍內，也可以較為方便的進行擴容。

下面分享從已有的集中式和分布式存儲劃分NAS成功實現備持久化存儲能力的容器集群實踐案例。本案例屬于城商行某風控相關系統，目前運行有多個業務系統，多個業務系統采用獨立的K8S容器集群運行承載，其中較大業務系統一個Kubernetes集群中部署有12個Pod，主要是運行業務系統的Java應用以及Web應用，該持久化存儲場景主要是為了保存業務運行日志，容器集群的持久化存儲通過兩套配備雙中心復制的存儲集群提供，一套為華為OceanStor 5500系列中端存儲，通過配置雙活NAS存儲發布服務至容器云集群，作為PV映射給Pod使用，另一套采用同樣具有雙中心目錄同步復制的SDS分布式集群配置，數據中心可以將復制卷發布至災備中心的Kubernetes災備集群，備中心的Kubernetes集群作為冷備集群，當主中心故障時進行切換。

在容器云中，我們會定義一個PV掛載nfs路徑：XX.XX.XX.XX:/nfsshare，并將該Pv-admin關聯PVS映射給某應用命名空間spacegs12zr9a使用。如果是作為持久化日志存儲使用，某個應用多個 Pod需要同時寫入，則訪問模式通常采用ReadWriteMany，而為了保證生產日志不會被刪除persistentVolumeReclaimPolicy的PV回收策略建議采用 Retain，這樣只有在PV被手工重定義的時候，PV里的數據才會擦除。

PVC配置中大多數屬性是從PV定義中繼承而來，在PVC中，主要是定義PV和應用之間的關聯關系，PV與應用的關聯關系通過配置命名空間namespace來完成。

四、總結

早期由于Kubernetes的存儲接口演進方向不明確，有狀態容器不成熟，加上受接口協議限制與Kubernetes配合比較好的主要是“分布式”開源存儲，早期那些與Kubernetes兼容適配較好的存儲產品，往往在性能和可靠性等方面滿足不了業務的需求，現在CSI插件的官方手冊Driver一節,對于國內外一些主流的如華為等存儲廠家均有推薦，集中式存儲提供服務作為容器持久化存儲已經較為成熟?？傮w來說，容器云的持久化存儲的選型，要根據承載的工作負載進行具體分析。譬如在容器云上部署關系型數據庫，且數據庫的數據是重要的業務系統數據，則選擇集中式存儲為宜。如果是業務應用系統的日志，或者是配置文件，則建議優先選擇分布式存儲，在擴展性和成本收益上更佳。