城商行容器雲平臺應用場景及持久化儲存實踐

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

【作者】哲哲蛙，某城商銀行系統環境管理經理，長期服務於資訊科技部門，熟悉大型企業的IT資料中心基礎平臺的建設和維護工作，對容災架構有較為深刻的理解，對小型機、X86伺服器、儲存、作業系統、資料庫、虛擬化、備份等各類主流產品以及技術較為熟悉。

一、 雲平臺以及容器

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一節,對於國內外一些主流的如華為等儲存廠家均有推薦，集中式儲存提供服務作為容器持久化儲存已經較為成熟。總體來說，容器雲的持久化儲存的選型，要根據承載的工作負載進行具體分析。譬如在容器雲上部署關係型資料庫，且資料庫的資料是重要的業務系統資料，則選擇集中式儲存為宜。如果是業務應用系統的日誌，或者是配置檔案，則建議優先選擇分散式儲存，在擴充套件性和成本收益上更佳。