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

?一、 云平臺(tái)以及容器

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

二、容器特點(diǎn)如何滿足中小銀行應(yīng)用場景

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

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

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

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

三、容器的存儲(chǔ)與配置

3.1 城商容器云持久化存儲(chǔ)應(yīng)用場景及容器的持久化存儲(chǔ)類型

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

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

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

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

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

3.2 容器持久化存儲(chǔ)配置

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

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

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

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

三種PV的訪問模式：

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

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

（3）ReadWriteMany：這種存儲(chǔ)可以以讀寫的方式被多個(gè)Pod共享。

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

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

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

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

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

只有本地盤和NFS支持?jǐn)?shù)據(jù)盤Recycle 擦除回收， 而AWS云盤或者Cinder存儲(chǔ)卷支持Delete策略。

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

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

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

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

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

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

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

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

3.3 NFS配置持久化存儲(chǔ)經(jīng)驗(yàn)分享

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

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

2、容災(zāi)能力需求：通常銀行業(yè)會(huì)要求重要業(yè)務(wù)進(jìn)行兩地三中心部署，通過集中式存儲(chǔ)和分布式存儲(chǔ)本身的雙中心雙活能力，也可以構(gòu)建雙中心架構(gòu)的容器集群。

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

4、容量擴(kuò)容需求：隨著容器應(yīng)用數(shù)據(jù)的增長，存儲(chǔ)卷容量需要考慮擴(kuò)容的能力，最大程度避免對(duì)應(yīng)用運(yùn)行的影響。分布式集群更為靈活的擴(kuò)容能力，集中式存儲(chǔ)在最大可配置硬盤柜范圍內(nèi)，也可以較為方便的進(jìn)行擴(kuò)容。

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

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

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

四、總結(jié)

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