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

作者：哲哲蛙 2022-07-11 15:35:42
云計算
云原生 本文主要從銀行實際應用出發(fā)，闡述容器云特性及持久化存儲方案實踐。

創(chuàng)新互聯(lián)公司技術團隊10年來致力于為客戶提供成都網站制作、成都網站設計、外貿營銷網站建設、成都品牌網站建設、營銷型網站、搜索引擎SEO優(yōu)化等服務。經過多年發(fā)展，公司擁有經驗豐富的技術團隊，先后服務、推廣了上千余家網站，包括各類中小企業(yè)、企事單位、高校等機構單位。

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

?一、 云平臺以及容器

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

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

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

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

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

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

三、容器的存儲與配置

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

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

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

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

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

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

3.2 容器持久化存儲配置

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

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

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

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

三種PV的訪問模式：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（6）回收Recycling---PV可以設置三種回收策略：保留（Retain），回收（Recycle）和刪除（Delete）。保留策略：允許人工處理保留的數據。刪除策略：將刪除PV和外部關聯(lián)的存儲資源，需要插件支持?；厥詹呗裕簩?zhí)行清除操作，之后可以被新的PVC使用，需要插件支持。

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

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

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

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

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

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

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

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

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

四、總結

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

網站名稱：城商行容器云平臺應用場景及持久化存儲實踐
瀏覽路徑：http://www.5511xx.com/article/dpshhie.html