PaaS中OpenShift持久化存储的管理实践
在 OpenShift 中，Pod 會(huì)被經(jīng)常性的創(chuàng)建和銷毀，也會(huì)在不同的主機(jī)之間快速的遷移。為了保證容器在重啟或者遷移以后能夠使用原來(lái)的數(shù)據(jù)，就必須使用持久化存儲(chǔ)。所以，持久化存儲(chǔ)的管理對(duì)于 PaaS 平臺(tái)來(lái)說(shuō)就顯得非常重要。
1
? ?
OpenShift 存儲(chǔ) PV 和 PVC
OpenShift 利用 Kubernetes Persistent Volume 概念來(lái)管理存儲(chǔ)。管理員可以快速劃分卷提供給容器使用。開發(fā)人員通過命令行和界面申請(qǐng)使用存儲(chǔ)，而不必關(guān)心后端存儲(chǔ)的具體類型和工作機(jī)制。
Persistent Volume（PV）是一個(gè)開放的存儲(chǔ)管理框架，提供各種不同類型存儲(chǔ)的支持。OpenShift 默認(rèn)支持 NFS、GlusterFS、Cinder、Ceph、EBS、iSCSI 和 Fibre Channel 等存儲(chǔ)，用戶還可以根據(jù)需求對(duì) PV 框架進(jìn)行擴(kuò)展，從而使其支持更多類型的存儲(chǔ)。
PersistentVolumeClaim (PVC) 是用戶的一個(gè) Volume 請(qǐng)求。用戶通過創(chuàng)建 PVC 消費(fèi) PV 的資源。
PV 只有被 PVC 綁定后才能被 Pod 掛載使用，PV 和 PVC 的生命周期如下圖 2-72 所示：
圖2-72 PV和PVC的生命周期
從圖中可以看到，生命周期包含5個(gè)階段：
Avaliable：這個(gè)階段表示PV創(chuàng)建完成，處于可用狀態(tài)。創(chuàng)建PV可以通過手動(dòng)創(chuàng)建或動(dòng)態(tài)創(chuàng)建。
Pending：這個(gè)階段表示PV和PVC處于匹配狀態(tài)，匹配的策略有訪問模式和卷大小，以及支持通過label匹配。如果無(wú)法匹配則PVC會(huì)一直處于Pending狀態(tài)，如果可以匹配，但是后端存儲(chǔ)置備卷失敗，則會(huì)轉(zhuǎn)為Failure狀態(tài)。
Bound：這個(gè)階段表示PV和PVC已經(jīng)處于綁定狀態(tài)，這個(gè)狀態(tài)的PVC才能被Pod掛載使用。
Release：這個(gè)階段表示掛載PVC的Pod被刪除，PVC處于釋放狀態(tài)，也就是未被任何Pod掛載，但這個(gè)狀態(tài)的PV無(wú)法被PVC再次綁定。
Retain：這個(gè)階段表示刪除PVC，PV轉(zhuǎn)變?yōu)榛厥諣顟B(tài)，該狀態(tài)下的PV無(wú)法直接被新的PVC綁定。回收狀態(tài)下PV是否保留數(shù)據(jù)取決于PV的回收策略定義，默認(rèn)會(huì)保留。如果想要將改狀態(tài)的PV轉(zhuǎn)變?yōu)锳valiable，必須刪除PV然后重新創(chuàng)建。
在PV和PVC的生命周明中，最關(guān)鍵的兩個(gè)階段是創(chuàng)建和綁定。PV按創(chuàng)建方式的不同可分為動(dòng)態(tài)PV和靜態(tài)PV。靜態(tài)PV指通過手動(dòng)創(chuàng)建的PV，而動(dòng)態(tài)卷是指由StorageClass（簡(jiǎn)稱SC）自動(dòng)創(chuàng)建PV。
靜態(tài)PV需要手動(dòng)編輯Yaml文件并應(yīng)用到集群中，不同的存儲(chǔ)后端，PV的配置參數(shù)不同，如NFS后端的PV示例內(nèi)容如下：
apiVersion:?v1 kind:?PersistentVolume metadata:name:?nfs-pv0001 spec:capacity:storage:?5GiaccessModes:-?ReadWriteOncenfs:path:?/data/mydbserver:?xxx.xxx.xxx.xxxpersistentVolumeReclaimPolicy:?Retain其中訪問模式和PV容量對(duì)能否和PVC綁定至關(guān)重要。PV支持的訪問模式共有三種，如下表2-8所示：
表2-8 PV訪問模式
訪問模式 | 簡(jiǎn)寫 | 描述 |
ReadWriteOnce | RWO | PV可以由單個(gè)Pod以讀寫方式掛載。 |
ReadOnlyMany | ROX | PV可以由多個(gè)Pod以只讀方式掛載。 |
ReadWriteMany | RWX | PV可以由多個(gè)Pod以讀寫方式掛載。 |
對(duì)于不同后端存儲(chǔ)對(duì)訪問模式的支持是不同的。接下來(lái)我們看一下常見后端存儲(chǔ)支持的PV訪問模式，如下表2-9所示：
表2-9 不同存儲(chǔ)后端支持的訪問模式
AWS EBS | Yes | No | No |
Azure File | Yes | Yes | Yes |
Azure Disk | Yes | No | No |
Cinder | Yes | No | No |
Fibre Channel | Yes | Yes | No |
GCE Persistent Disk | Yes | No | No |
HostPath | Yes | No | No |
iSCSI | Yes | Yes | No |
LocalVolume | Yes | No | No |
NFS | Yes | Yes | Yes |
VMware vSphere | Yes | No | No |
從上表中，我們可以看到，Azure File和NFS支持的讀寫類型是最全的。我們可以使用NAS或者配置NFS Server。當(dāng)然，企業(yè)級(jí)NAS的性能要比NFS Server好得多。在OpenShift中，除了上表列出常見存儲(chǔ)類型之外，還可以選擇軟件定義存儲(chǔ)，如Ceph，Ceph可以同時(shí)提供塊存儲(chǔ)RBD、對(duì)象存儲(chǔ)、文件系統(tǒng)存儲(chǔ)CephFS。
除了靜態(tài)PV之外，OpenShift還可以使用StorageClass來(lái)管理動(dòng)態(tài)PV。每個(gè)StorageClass都定義一個(gè)Provisioner屬性，也就是后端存儲(chǔ)類型。OpenShift安裝后，會(huì)內(nèi)嵌一些Provisioner，它們的StorageClass會(huì)被自動(dòng)創(chuàng)建，如下表所示：
AWS EBS | Yes | kubernetes.io/aws-ebs |
Azure File | Yes | kubernetes.io/azure-file |
Azure Disk | Yes | kubernetes.io/azure-disk |
Cinder | Yes | kubernetes.io/cinder |
Fibre Channel | No | |
GCE Persistent Disk | Yes | kubernetes.io/gce-pd |
HostPath | No | |
iSCSI | No | |
LocalVolume | No | |
NFS | No | |
VMware vSphere | Yes | kubernetes.io/vsphere-volume |
如果要?jiǎng)?chuàng)建一個(gè)沒有對(duì)應(yīng) Provisioner的StorageClass，也稱為靜態(tài)StorageClass，可以使用kubernetes.io/no-provisioner，示例如下：
apiVersion:?storage.k8s.io/v1 kind:?StorageClass metadata: name:?static-provisioner provisioner:?kubernetes.io/no-provisioner volumeBindingMode:?WaitForFirstConsumerStorageClass創(chuàng)建之后，就可以通過創(chuàng)建PVC觸發(fā)StorageClass完成PV的創(chuàng)建。但是，靜態(tài)StorageClass除外，因?yàn)殪o態(tài)StorageClass沒有真實(shí)的后端存儲(chǔ)，依然需要手動(dòng)創(chuàng)建PV并明確指定storageClassName為靜態(tài)StorageClass的名稱，詳細(xì)的使用案例參見第三章3.2.4-2小節(jié)。
無(wú)論是通過靜態(tài)還是動(dòng)態(tài)創(chuàng)建PV，只有PVC和PV綁定之后才能被Pod使用。尤其在集群中有多個(gè)不同的后端的PV，PVC如何能綁定到滿足預(yù)期的PV將成為關(guān)鍵，下面我們就進(jìn)行詳細(xì)說(shuō)明。
2
? ?
PV 和 PVC 綁定邏輯
在上一小節(jié)中，我們介紹了 PV 的創(chuàng)建方式和支持的類型，那么如果一個(gè)集群中，既有多種類型的 StorageClass，又有多種不同后端的靜態(tài) PV，PVC 與 PV 的匹配遵循一定的邏輯，如下圖 2-73 所示：
圖2-73 PV和PVC匹配邏輯
從圖中可以看出動(dòng)態(tài)卷優(yōu)先，如果動(dòng)態(tài)卷無(wú)法滿足PVC需求，才會(huì)匹配靜態(tài)PV。而且能否匹配成功是根據(jù)PV、PVC、集群中StorageClass的配置等多方面決定的，匹配大致邏輯如下：
1. 創(chuàng)建PVC后，首先會(huì)判定PVC中是否指定了storageClassName字段，例如下面PVC定義會(huì)觸發(fā)StorageClass gp2創(chuàng)建的PV并綁定（靜態(tài)StorageClass需要手動(dòng)創(chuàng)建PV，后文不再重復(fù)強(qiáng)調(diào)），如果無(wú)法找到指定的StorageClass，則PVC處于Pending狀態(tài)：
kind:?PersistentVolumeClaim apiVersion:?v1 metadata: name:?pvc-claim spec: storageClassName:?gp2 accessModes: -?ReadWriteOnce resources: requests: storage:?3Gi2. 如果PVC中沒有指定storageClassName參數(shù)，則會(huì)判定集群中是否有默認(rèn)StorageClass，如果存在，則會(huì)直接使用默認(rèn)StorageClass創(chuàng)建PV。一個(gè)集群最多只能有一個(gè)默認(rèn)StorageClass，表示如果PVC中未指定明確的storageClassName，則使用默認(rèn)StorageClass創(chuàng)建PV。使用如下命令將集群中一個(gè)SC設(shè)置為默認(rèn)StorageClass：
# oc annotate storageclass <SC_NAME> "storageclass.kubernetes.io/is-default-class=true"
建議不要設(shè)置靜態(tài)StorageClass為默認(rèn)StorageClass，因?yàn)殪o態(tài)StorageClass不會(huì)自動(dòng)創(chuàng)建PV，即使設(shè)定為默認(rèn)StorageClass，還是要手動(dòng)創(chuàng)建設(shè)定storageClassName的PV，導(dǎo)致設(shè)定為默認(rèn)StorageClass沒有價(jià)值。
3. 如果集群未定義默認(rèn)StorageClass，則會(huì)進(jìn)入靜態(tài)PV匹配。首先會(huì)判定在PVC是否定義了selector用于匹配特定標(biāo)簽的PV。通常在PV上設(shè)定標(biāo)簽主要用于對(duì)PV分級(jí)，比如根據(jù)存儲(chǔ)性能，存儲(chǔ)地理位置等。例如下面的PVC就只能匹配包含storage-tier=gold且volume-type=ssd的PV，如果無(wú)法找到符合標(biāo)簽的PV則PVC處于Pending狀態(tài)。
apiVersion:?v1 kind:?PersistentVolumeClaim metadata: name:?high-performance-volume spec: accessModes: -?ReadWriteOnce resources: requests: storage:?2Gi selector: matchLabels: storage-tier:?gold volume-type:?ssd4. 如果PVC中未定義selector，或者有滿足selector的PV，則根據(jù)PVC和PV兩者中定義的訪問模式和容量大小匹配。其中訪問模式必須完全相同，而容量是只要PV定義的容量大小大于等于PVC定義的容量大小就可以匹配成功。如果訪問模式或者容量大小無(wú)法滿足需要，則PVC處于Pending狀態(tài)。
可以發(fā)現(xiàn)，在動(dòng)態(tài)卷綁定時(shí)只判斷storageClassName，而在靜態(tài)PV綁定時(shí)才會(huì)判斷selector、訪問模式、容量大小。
另外，需要注意的是，訪問模式和容量大小的匹配只是邏輯上的，并不會(huì)校驗(yàn)后端存儲(chǔ)是否支持這種訪問模式或后端存儲(chǔ)的真實(shí)空間大小。例如我們完全可以通過多讀寫訪問模式掛載iSCSI卷，只不過由于鎖機(jī)制，無(wú)法同時(shí)啟動(dòng)多個(gè)實(shí)例。
3
? ?
容器云原生存儲(chǔ)
OpenShift 目前主推 OpenShift Container Storage（簡(jiǎn)稱 OCS）實(shí)現(xiàn)存儲(chǔ)層。OCS 主要是通過 Rook+Ceph 實(shí)現(xiàn)的。
Rook（https://rook.io/）使 Ceph 部署、引導(dǎo)、配置、供應(yīng)、擴(kuò)展、升級(jí)、遷移、災(zāi)難恢復(fù)、監(jiān)視和資源管理自動(dòng)化。Operator 將啟動(dòng)和監(jiān)視 Ceph ( https://rook.io/）使 Ceph 部署、引導(dǎo)、配置、供應(yīng)、擴(kuò)展、升級(jí)、遷移、災(zāi)難恢復(fù)、監(jiān)視和資源管理自動(dòng)化。Operator 將啟動(dòng)和監(jiān)視 Ceph ) Monitor 容器，提供 RADOS 存儲(chǔ)的 Ceph OSD 守護(hù)程序，以及啟動(dòng)和管理其他 Ceph 守護(hù)程序。通過初始化 Pod 和運(yùn)行服務(wù)所需的其他工件來(lái)管理存儲(chǔ)池，對(duì)象存儲(chǔ)（S3 / Swift）和文件系統(tǒng)的 CRD。
Rook的功能如下：
高可用性和彈性-Ceph沒有單點(diǎn)故障（SPOF），并且其所有組件都以高可用性的方式本地工作
數(shù)據(jù)保護(hù)-Ceph會(huì)定期清理不一致的對(duì)象，并在必要時(shí)進(jìn)行修復(fù)，以確保副本始終保持一致
跨混合云的一致存儲(chǔ)平臺(tái)-Ceph可以部署在任何位置（內(nèi)部部署或裸機(jī)），因此無(wú)論用戶身在何處，都能提供類似的體驗(yàn)
塊，文件和對(duì)象存儲(chǔ)服務(wù)-Ceph可以通過多個(gè)存儲(chǔ)接口公開您的數(shù)據(jù)，從而解決所有應(yīng)用程序用例
放大/縮小-Operator完全負(fù)責(zé)添加和刪除存儲(chǔ)。
儀表板-Operator部署了一個(gè)儀表板，用于監(jiān)視和自檢群集。
OCS的架構(gòu)圖如下圖2-74所示：
圖2-74 OCS存儲(chǔ)架構(gòu)
OCS通過Operator方式進(jìn)行安裝。目前支持在OpenShift物理節(jié)點(diǎn)上離線安裝。
OCS的安裝很簡(jiǎn)單，大致步驟如下圖2-75所示，安裝OCS的Operator：
圖2-75安裝OCS的Operator
接下來(lái)，利用OCS Operator部署的API創(chuàng)建Ceph集群，選擇加入到OCS的節(jié)點(diǎn)。此處我們選擇新添加的三個(gè)節(jié)點(diǎn)：如下圖2-76所示：
圖2-76 選擇OCS節(jié)點(diǎn)
當(dāng)OCS相關(guān)所有Pod都創(chuàng)建成功并處于Running狀態(tài)，代表OCS部署成功。OCS部署成功后，我們查看OpenShift中的StorageClass，增加了Ceph相關(guān)的內(nèi)容：
# oc get sc
NAME??????????????????????????PROVISIONER?????????????????????????????AGE localblock????????????????????kubernetes.io/no-provisioner????????????51m ocs-storagecluster-ceph-rbd???openshift-storage.rbd.csi.ceph.com??????51m ocs-storagecluster-cephfs?????openshift-storage.cephfs.csi.ceph.com???51m openshift-storage.noobaa.io???openshift-storage.noobaa.io/obc?????????45m部署成功后，就可以在OpenShift中通過CSI的方式調(diào)用OCS了。
我們使用配置文件創(chuàng)建一個(gè)PVC（調(diào)用storageClassName: ocs-storagecluster-ceph-rbd）：
# cat create_ns_ocs_pvc.yaml
--- kind:?Namespace apiVersion:?v1 metadata: name:?"e-library" labels: name:?"e-library" --- apiVersion:?v1 kind:?PersistentVolumeClaim metadata: name:?ocs-pv-claim labels: name:?"e-library" namespace:?"e-library" spec: accessModes: -?ReadWriteOnce resources: requests: storage:?10Gi storageClassName:?ocs-storagecluster-ceph-rbd查看PVC創(chuàng)建成功，并且OCS自動(dòng)創(chuàng)建PV與之綁定。
# oc get pvc
NAME???????????STATUS???VOLUME?????????????????????????????????????CAPACITY???ACCESS?MODES???STORAGECLASS??AGE ocs-pv-claim???Bound????pvc-f06484c8-abd7-11ea-b311-0242ac110022???10Gi???????RWO????????????ocs-storagecluster-ceph-rbd??3m52s接下來(lái)，我們就可以創(chuàng)建Pod來(lái)消費(fèi)這個(gè)PVC了。
在OCS早期版本，只支持內(nèi)置模式，也是就說(shuō)，必須把OCS裝在OpenShift上，利用OpenShift的Worker Node的本地存儲(chǔ)空間做存儲(chǔ)空間。這種模式部署、使用都很方便。唯一的問題是：存儲(chǔ)服務(wù)器無(wú)法與OpenShift集群解耦。
OCS 從v4.5版本開始支持外部的存儲(chǔ)模式。也就是說(shuō)，通過OpenShift上安裝的OCS Operator，可以對(duì)接在外部物理機(jī)上安裝的Ceph。然后以O(shè)penShift中Rook的方式管理外部物理機(jī)上的Ceph，實(shí)現(xiàn)存儲(chǔ)服務(wù)器與OpenShift集群解耦。
我們?cè)贠penShift上部署OCS Operator后，可以選擇連接外部的Cluster：然后提示下載Python腳本。將這個(gè)腳本在外置的Ceph集群的任意一個(gè)Monitor節(jié)點(diǎn)上執(zhí)行，獲取到Ceph集群信息，輸入到OCS對(duì)接外部存儲(chǔ)的位置，如下圖2-77所示：
圖2-77 OCS對(duì)接外置存儲(chǔ)
我們將這個(gè)腳本在外置的ceph的mon的節(jié)點(diǎn)上執(zhí)行：
首先查看腳本的使用幫助：
#python?ceph-external-cluster-details-exporter.py?--help在下面的命令中，rbd-data-pool-name指定要?jiǎng)?chuàng)建的pool的名稱；rgw-endpoint指定Ceph集群對(duì)象網(wǎng)關(guān)地址：
#python?ceph-external-cluster-details-exporter.py?--rbd-data-pool-name?abc?--rgw-endpoint?192.168.18.203:8080命令執(zhí)行后，會(huì)以json的方式返回一大串輸出結(jié)果，我們將結(jié)果粘貼到如到上圖2-77的所示的空白處，即可完成添加。由于后續(xù)的操作步驟與內(nèi)置模式類似，因此不再展開說(shuō)明。
OCS對(duì)接外置Ceph存儲(chǔ)的后續(xù)步驟，請(qǐng)參考repo中“ocs外置存儲(chǔ)方式”。
4
? ?
OpenShift/kubernetes 存儲(chǔ)趨勢(shì)
在 OpenShift 的網(wǎng)絡(luò)部分，我們提到了一個(gè)開源項(xiàng)目 CNI。它定義網(wǎng)絡(luò)插件和容器之間的通用接口，實(shí)現(xiàn)了容器運(yùn)行時(shí)與 SDN 的松耦合。那么，在容器存儲(chǔ)方面，有沒有類似的開源項(xiàng)目呢？
開源項(xiàng)目 Container Storage Interface（CSI）正是這個(gè)目的。CSI旨在提供一種標(biāo)準(zhǔn)，將任意塊存儲(chǔ)和文件存儲(chǔ)在符合這種標(biāo)準(zhǔn)的情況下，可以為Kubernetes上的容器化提供持久存儲(chǔ)。隨著CSI的采用，Kubernetes存儲(chǔ)層變得真正可擴(kuò)展。使用CSI，第三方存儲(chǔ)提供商可以編寫和部署插件，在Kubernetes中公開新的存儲(chǔ)系統(tǒng)，而無(wú)需觸及核心Kubernetes代碼。CSI為Kubernetes用戶提供了更多存儲(chǔ)選項(xiàng)，使系統(tǒng)更加安全可靠。目前在OpenShift中的CSI正式GA。
CSI是通過External CSI Controllers實(shí)現(xiàn)的，它是一個(gè)運(yùn)行在Infra節(jié)點(diǎn)包含三個(gè)容器的Pod。如下圖2-78所示：
external CSI attacher container：它將從OpenShift發(fā)過來(lái)的attach 和detach調(diào)用轉(zhuǎn)換為對(duì)CSI driver的ControllerPublish和ControllerUnpublish調(diào)用。
external CSI provisioner container，它將從OpenShift發(fā)過來(lái)的provision 和 delete的調(diào)用轉(zhuǎn)化為對(duì)CSI Driver的CreateVolume 和 DeleteVolume ?的調(diào)用。
CSI driver container
圖2-78 OpenShift CSI邏輯圖
通過一個(gè)CSI Driver DaemonSet，在每個(gè)OpenShift節(jié)點(diǎn)上啟動(dòng)一個(gè)Driver容器。它允許OpenShift將CSI driver提供的存儲(chǔ)掛載到OpenShift節(jié)點(diǎn)，并將其映射掛載到Pod中。
需要指出的是，從Ceph 社區(qū)版本v14開始，OpenShift訪問Ceph必須要有CSI Driver，無(wú)法繞開CSI直接訪問Ceph存儲(chǔ)。
本文選自《OpenShift在企業(yè)中的實(shí)踐》（第2版），經(jīng)出版社授權(quán)發(fā)布。
掃碼京東購(gòu)買
推薦語(yǔ)：經(jīng)典暢銷書再次升級(jí)！紅帽首席解決方案架構(gòu)師聯(lián)合撰寫，20位全球知名企業(yè)IT負(fù)責(zé)人推薦，基于OpenShift v4，詳述PaaS、DevOps、云原生、微服務(wù)治理。完整描繪企業(yè)數(shù)字化轉(zhuǎn)型路線，為企業(yè)通過OpenShift實(shí)現(xiàn)IT轉(zhuǎn)型給出具體建議和參考架構(gòu)。
微信淘寶等平臺(tái)要互通！？騰訊阿里字節(jié)回應(yīng)
2021-09-14
一文詳解 API 設(shè)計(jì)最佳實(shí)踐
2021-09-12
12 種經(jīng)典億級(jí)流量架構(gòu)之資源隔離思想與方法論
2021-09-09
拼夕夕訂單超時(shí)未支付自動(dòng)關(guān)閉實(shí)現(xiàn)方案！
2021-09-08
在騰訊，我們?nèi)绾巫?Code Review
2021-09-24
紫色飛豬：基于K8s的集群穩(wěn)定架構(gòu)
2021-09-23
2W 字詳解設(shè)計(jì)模式！
2021-09-22
巨人大哥聊聊電商微服務(wù)體系中分層設(shè)計(jì)和領(lǐng)域的劃分
2021-09-20
億級(jí)流量架構(gòu)怎么做資源隔離？口琴這篇寫得太好了！
2021-09-17
螞蟻集團(tuán)于雨：萬(wàn)級(jí)規(guī)模 K8S 集群 Etcd 高可用建設(shè)之路
2021-09-16
干貨丨千萬(wàn)流量大型分布式系統(tǒng)架構(gòu)設(shè)計(jì)實(shí)戰(zhàn)
2021-09-15
京東面試官：你是怎么理解 MySQL 的優(yōu)化原理的？
2021-09-26
在騰訊，我們?nèi)绾巫?Code Review
2021-09-24
紫色飛豬：基于K8s的集群穩(wěn)定架構(gòu)
2021-09-23
2W 字詳解設(shè)計(jì)模式！
2021-09-22
巨人大哥聊聊電商微服務(wù)體系中分層設(shè)計(jì)和領(lǐng)域的劃分
2021-09-20
億級(jí)流量架構(gòu)怎么做資源隔離？口琴這篇寫得太好了！
2021-09-17
螞蟻集團(tuán)于雨：萬(wàn)級(jí)規(guī)模 K8S 集群 Etcd 高可用建設(shè)之路
2021-09-16
干貨丨千萬(wàn)流量大型分布式系統(tǒng)架構(gòu)設(shè)計(jì)實(shí)戰(zhàn)
2021-09-15
微信淘寶等平臺(tái)要互通！？騰訊阿里字節(jié)回應(yīng)
2021-09-14
一文詳解 API 設(shè)計(jì)最佳實(shí)踐
2021-09-12
12 種經(jīng)典億級(jí)流量架構(gòu)之資源隔離思想與方法論
2021-09-09
美團(tuán)技術(shù)：到店結(jié)算平臺(tái)實(shí)踐（膠片）
2021-09-06
Serverless實(shí)戰(zhàn)之路
2021-09-03
柴華：DDD在哈啰交易中臺(tái)的實(shí)踐
2021-09-02
建設(shè)微服務(wù)API網(wǎng)關(guān)的一些實(shí)踐
2021-10-13
新公司要上監(jiān)控，我決定用Prometheus
2021-10-12
RabbitMQ 七戰(zhàn) Kafka，差異立現(xiàn)！
2021-09-30
分布領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（DDD）：領(lǐng)域接口化設(shè)計(jì)式緩存的選擇
2021-09-27
新人創(chuàng)作打卡挑戰(zhàn)賽發(fā)博客就能抽獎(jiǎng)！定制產(chǎn)品紅包拿不停！總結(jié)
以上是生活随笔為你收集整理的PaaS中OpenShift持久化存储的管理实践的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 全链路灰度发布
- 下一篇： Golang之空结构体和零长数组的实践