4.2　容器云的備份與雙活

在實(shí)際項(xiàng)目生產(chǎn)環(huán)境中，容器云的備份、多集群管理、雙活與災(zāi)備是很受大家關(guān)注的話題。在本節(jié)中，我們會依次進(jìn)行介紹。

4.2.1　容器云的備份

在Kubernetes、OpenShift單集群部署時(shí)，我們會采用高可用的部署方式，如圖4-32所示。因此，在單一容器云集群中，我們不用擔(dān)心單點(diǎn)故障。

那么，針對容器云集群，我們?nèi)绾巫鰝浞荩總浞莘绞街饕譃閱渭喝總浞莺突贜amespaces增量備份兩種。

• 單集群全量備份：在集群級別備份所有重要文件和配置等，可以滿足相同地址（服務(wù)器主機(jī)名和IP與之前集群相同）集群的恢復(fù)及回滾到歷史時(shí)間點(diǎn)。它相當(dāng)于重新部署一套完全一樣的集群，必須在整個(gè)集群離線的條件下執(zhí)行恢復(fù)操作。
• 基于Namespace增量備份：在Namespaces級別備份所有資源對象，可以滿足任意時(shí)間點(diǎn)在任意一個(gè)集群的恢復(fù)操作。這種備份恢復(fù)不涉及OpenShift平臺底層基礎(chǔ)架構(gòu)，僅涉及平臺上的應(yīng)用和資源對象。

在實(shí)際的項(xiàng)目中，除了要考慮容器云自身的備份外，我們還需要考慮應(yīng)用持久化數(shù)據(jù)的備份。接下來，我們對這三點(diǎn)進(jìn)行說明。

1. 單集群全量備份

單集群全量備份的內(nèi)容如表4-3所示。

2. 基于Namespace增量備份

基于Namespace增量備份，同樣需要備份以下兩類內(nèi)容。

• 集群中所有Namespaces中的資源對象。
• 掛載持久化存儲的應(yīng)用數(shù)據(jù)的備份：平臺中所有掛載PV的Pod的應(yīng)用數(shù)據(jù)。

根據(jù)上述分類，需要使用不同的備份方式，如表4-4所示。

對于基于Namespace增量備份，常見需要備份的資源對象列舉如下（包含但不限于）：

• namespace
• deploymentconfig
• deployment
• buildconfig
• imagestream
• service
• route
• configmap
• rolebindings
• serviceaccounts
• secrets
• pvcs
• templates
• jobs
• cronjobs
• statefulsets
• hpas

3. 應(yīng)用數(shù)據(jù)備份

在上述兩種備份方式中，我們都提到應(yīng)用數(shù)據(jù)備份，這也是災(zāi)備中最難實(shí)現(xiàn)的地方。傳統(tǒng)數(shù)據(jù)中心可以利用磁帶庫和管理軟件實(shí)現(xiàn)數(shù)據(jù)備份，也可以依靠數(shù)據(jù)復(fù)制工具實(shí)現(xiàn)數(shù)據(jù)備份。根據(jù)作用層次的不同，我們可將數(shù)據(jù)備份主要分為以下三類。

• 基于存儲層面的數(shù)據(jù)備份：在存儲層面實(shí)現(xiàn)數(shù)據(jù)備份，商業(yè)存儲大部分都提供這項(xiàng)功能，主流產(chǎn)品有EMC Symmtrix、EMC Clarrion、IBM PPRC、HDS TrueCopy、HP CA等。
• 基于主機(jī)層面的數(shù)據(jù)備份：在操作系統(tǒng)層面實(shí)現(xiàn)數(shù)據(jù)復(fù)制，主流產(chǎn)品有VVR（Veritas Volume Replicator，卷遠(yuǎn)程復(fù)制）、VSF（Veritas Storage Foundation，卷遠(yuǎn)程鏡像）等。
• 基于應(yīng)用層面的數(shù)據(jù)備份：在應(yīng)用層面實(shí)現(xiàn)數(shù)據(jù)備份，通常是依賴應(yīng)用數(shù)據(jù)多副本或提供導(dǎo)出導(dǎo)入工具等實(shí)現(xiàn)。

當(dāng)然，我們在具體選擇數(shù)據(jù)備份的方式時(shí)，主要根據(jù)應(yīng)用的性質(zhì)決定。對于無狀態(tài)的應(yīng)用，直接在存儲層面或主機(jī)層面實(shí)現(xiàn)數(shù)據(jù)復(fù)制和恢復(fù)，比如Jenkins、鏡像倉庫。對于有狀態(tài)的應(yīng)用，通常使用應(yīng)用提供的工具，允許客戶在Pod中的應(yīng)用層面將文件或數(shù)據(jù)導(dǎo)出到備份存儲上保存，如GitLab、etcd。

關(guān)于更多容器云備份的技術(shù)細(xì)節(jié)，請參考《OpenShift在企業(yè)中的實(shí)踐：PaaS DevOps微服務(wù)（第2版）》的相關(guān)內(nèi)容。由于篇幅有限，這里不再贅述。

4.2.2　容器云的多集群管理

隨著容器云的普及，客戶將越來越多的應(yīng)用遷移到容器云上。如果容器云的集群數(shù)量不多，對集群進(jìn)行單獨(dú)管理是沒問題的。但如果容器云的集群數(shù)量超過10個(gè)，那么多集群管理就勢在必行了。

在容器云的項(xiàng)目實(shí)施過程中，很多國內(nèi)廠商基于DIY的方式定制容器云的管理平臺，實(shí)現(xiàn)對多個(gè)Kubernetes集群的納管。這樣做的好處是語言本地化支持做得好，并且由于針對不同的客戶提供定制化UI，因此界面相對友好。但問題在于這種DIY的方式脫離了開源社區(qū)，當(dāng)Kubernetes的版本升級后，我們大概率需要對定制化UI進(jìn)行一些調(diào)整。因此，筆者建議通過社區(qū)開源方案來實(shí)現(xiàn)容器云的多集群管理。

關(guān)于多集群管理的方案，此前開源社區(qū)的聯(lián)邦集群方案一直不太成熟。目前在開源社區(qū)多集群管理方案中，做得比較好的方案是RHACM（Red Hat Advanced Cluster Management for Kubernetes）方案。

針對Kubernetes/OpenShift集群，RHACM主要實(shí)現(xiàn)三大功能，分析如下。

• 多Kubernetes/OpenShift集群的監(jiān)控：RHACM上的multicluster-observability-operator可以監(jiān)視托管集群的運(yùn)行狀況，也可以進(jìn)行高級配置，如設(shè)置告警模式。
• 安全合規(guī)：應(yīng)用基于策略的監(jiān)管方法，自動監(jiān)控并確保安全防護(hù)與配置控制均符合行業(yè)合規(guī)要求或公司自定標(biāo)準(zhǔn)。目前RHACM已經(jīng)和StackRox整合，可以通過StackRox的能力實(shí)現(xiàn)較好的合規(guī)。
• 應(yīng)用發(fā)布：RHACM原生支持GitOps，支持在多個(gè)集群上發(fā)布應(yīng)用，并且監(jiān)控應(yīng)用的狀態(tài)。此外，RHACM實(shí)現(xiàn)了與ArgoCD的兼容和整合。目前OpenShift已經(jīng)支持ArgoCD。

1. RHACM多集群納管

我們查看RHACM的界面，可以看到它納管了10個(gè)分布在4個(gè)公有云上的Kubernetes集群，如圖4-33所示。我們在RHACM上創(chuàng)建應(yīng)用，界面如圖4-34所示。

應(yīng)用發(fā)布后，可以查看Kubernetes集群和應(yīng)用的拓?fù)洌鐖D4-35所示。

RHACM可以對多Kubernetes集群做合規(guī)配置檢查，如圖4-36所示。需要指出的是，新版本的RHACM已經(jīng)和StackRox方案進(jìn)行了整合，即由RHACM發(fā)起合規(guī)策略，StackRox執(zhí)行策略。

2. 多集群監(jiān)控

接下來，我們查看多集群監(jiān)控功能。通過RHACM可以實(shí)現(xiàn)對多個(gè)Kubernetes集群的性能監(jiān)控，如圖4-37所示。

Grafana可以統(tǒng)一查看多個(gè)Kubernetes集群的資源利用率，如查看單獨(dú)集群的資源利用情況。如果客戶有多Kubernetes集群監(jiān)控的需求，但又不想引入RHACM這樣的開源工具的話，那可以考慮使用Prometheus+ Thanos實(shí)現(xiàn)Prometheus聯(lián)邦，定制化DashBoard報(bào)表，對多集群資源情況進(jìn)行統(tǒng)一納管。

Thanos的架構(gòu)通過位于每個(gè)Prometheus服務(wù)器旁邊的Sidecar組件以及響應(yīng)PromQL查詢的中央Query組件，在所有服務(wù)器之間引入了一個(gè)中央查詢層，構(gòu)成了Thanos部署。組件間通信是通過成員列表Gossip協(xié)議實(shí)現(xiàn)的。Query可以水平擴(kuò)展，因?yàn)樗菬o狀態(tài)的，可以充當(dāng)智能反向代理，將請求傳遞給Sidecar，聚合它們的響應(yīng)并評估針對它們的PromQL查詢，如圖4-38所示。

Thanos通過使用對象存儲作為后端來解決存儲保留問題。只要Prometheus將數(shù)據(jù)寫入磁盤，并將其加載到對象存儲，Sidecar StoreAPI組件就會檢測到它。同一個(gè)Store組件還可以作為Gossip協(xié)議的檢索代理，讓Query組件與它通信以獲取數(shù)據(jù)，然后將統(tǒng)一的Grafana展現(xiàn)部署在頂層Prometheus的所在OpenShift集群中。

3. ArgoCD實(shí)現(xiàn)多集群應(yīng)用發(fā)布

目前RHACM已經(jīng)與ArgoCD進(jìn)行了集成。由于通過ArgoCD實(shí)現(xiàn)多容器云的應(yīng)用部署的步驟較多，我們只展示其部分效果。

OCP 4.7上的ArgoCD，是紅帽提供的Operator，如圖4-39所示。

使用同樣的方法，添加多個(gè)集群，成功添加的效果如圖4-40所示。

添加測試Demo代碼，并在第一個(gè)集群部署代碼：

[root@bastion ～]# argocd repo add https://github.com/mvazquezc/gitops-demo.git
repository 'https://github.com/mvazquezc/gitops-demo.git' added
[root@bastion ～]# argocd app create --project default --name pre-reversewords
    --repo https://github.com/mvazquezc/gitops-demo.git --path reversewords_app/base
    --dest-server  https://console-openshift-console.apps.ocp46.ats.com:6443
    --dest-namespace reverse-words --revision pre
application 'pre-reversewords' created

在第二個(gè)集群部署應(yīng)用：

[root@bastion ～]# argocd app create --project default --name pro-reversewords
    --repo https://github.com/mvazquezc/gitops-demo.git --path reversewords_app/base
    --dest-server  https://console-openshift-console.apps.ocp.ats.com:6443
    --dest-namespace reverse-words --revision pro
application 'pro-reversewords' created

登錄ArgoCD，可以看到部署成功的應(yīng)用，如圖4-41所示。

通過瀏覽器分別訪問兩個(gè)應(yīng)用的路由，如圖4-42所示。

在ArgoCD中修改應(yīng)用源碼后，可以觸發(fā)代碼自動構(gòu)建。

修改gitops-demo/reversewords_app/overlays/pro/deployment.yaml，將版本改為v0.0.4，如圖4-43所示。

此時(shí)登錄ArgoCD，看到repo代碼變更被發(fā)現(xiàn)，然后代碼會自動同步并重新部署應(yīng)用，如圖4-44所示。

通過瀏覽器訪問應(yīng)用，發(fā)現(xiàn)版本信息已經(jīng)發(fā)生變化，如圖4-45所示。

利用ArgoCD，我們可以在混合容器云中部署應(yīng)用，如圖4-46所示。

部署完畢后，查看ArgoCD，如圖4-47所示。圖中方框內(nèi)顯示應(yīng)用相關(guān)的資源，即在三個(gè)OCP集群分別部署應(yīng)用，還部署了一個(gè)haproxy。

我們可以查看haproxy指向的服務(wù)器，通過查看configmap進(jìn)行確認(rèn)：

[root@bastion app]# oc describe cm haproxy

#---------------------------------------------------------------------
# main frontend which proxys to the backends
#---------------------------------------------------------------------
frontend  main
    bind *:8080
    use_backend sushi_Dev if { hdr_beg(host) -i dev.sushi-everywhere }
    default_backend             sushi_Prod

frontend stats
    bind *:8404
    stats enable
    stats uri /stats
    stats refresh 10s

#---------------------------------------------------------------------
# round robin balancing between the various backends
#---------------------------------------------------------------------
backend sushi_Prod
    balance roundrobin
    option httpchk GET / HTTP/1.1\r\nHost:\ sushi.proxy
    http-request set-header Host sushi.proxy
    mode http
        #server Demo-Power 10.3.66.1:80 check weight 100
        server Demo-Z 172.16.32.239:80 check weight 100
        server Demo-x86 172.16.32.88:80 check weight 100

backend sushi_Dev
    balance roundrobin
    option httpchk GET / HTTP/1.1\r\nHost:\ dev.sushi.proxy
    http-request set-header Host dev.sushi.proxy
    mode http
        server local-x86 172.16.32.223:80 check weight 1
Events:  <none>

訪問開發(fā)環(huán)境的地址，顯示環(huán)境為x86_64，如圖4-48所示。

訪問生產(chǎn)環(huán)境的地址，可以看到是s390x，也就是Z環(huán)境，如圖4-49所示。

刷新生產(chǎn)環(huán)境頁面，出現(xiàn)x86_64。因?yàn)閔aproxy是輪詢轉(zhuǎn)發(fā)的，訪問結(jié)果如圖4-50所示。

ArgoCD修改源碼觸發(fā)應(yīng)用自動部署的完整步驟可查看“大魏分享”公眾號中文章《混合云中的OpenShift應(yīng)用發(fā)布》的相關(guān)內(nèi)容。

4.2.3　容器云的雙活與災(zāi)備

在多中心多云環(huán)境下，我們可以將容器云部署為多活/災(zāi)備模式，通過全局負(fù)載均衡器實(shí)現(xiàn)應(yīng)用的多中心多活與災(zāi)備。

需要指出的是，真正意義上的容器應(yīng)用跨數(shù)據(jù)中心的雙活，是將一個(gè)應(yīng)用的不同副本部署到不同的數(shù)據(jù)中心，如圖4-51所示的Database應(yīng)用。

圖4-51中的方案設(shè)計(jì)有幾個(gè)重要的技術(shù)點(diǎn)。

• 三個(gè)不同的區(qū)域?qū)⒂腥齻€(gè)OpenShift集群。每個(gè)集群都有一個(gè)有狀態(tài)的工作負(fù)載實(shí)例，工作負(fù)載實(shí)例是一個(gè)數(shù)據(jù)庫。這些實(shí)例將形成一個(gè)集群，并通過相互同步狀態(tài)組成一個(gè)單一的概念實(shí)體。所有實(shí)例都將處于活動狀態(tài)，并且使用Leader選舉算法（例如paxos或raft）選出Leader。
• 實(shí)例可以通過在OpenShift的SDN之間建立的網(wǎng)絡(luò)隧道相互通信，使用Submariner技術(shù)實(shí)現(xiàn)。

由于篇幅有限，本方案的具體實(shí)現(xiàn)我們不展開討論，對實(shí)現(xiàn)感興趣的讀者，可以查看“大魏分享”公眾號中的文章《有狀態(tài)應(yīng)用在OpenShift上實(shí)現(xiàn)多活》。

從筆者的角度來看，上述方案必須在應(yīng)用自身跨數(shù)據(jù)中心保證能多活時(shí)才能實(shí)現(xiàn)。此外Submariner的隧道打通方式會存在一定的網(wǎng)絡(luò)開銷，方案也較為復(fù)雜。而在容器云上的應(yīng)用多活，更多是采用一個(gè)應(yīng)用在多數(shù)據(jù)中心部署多份的方案，下面我們會介紹。

跨中心多活需要從全局負(fù)載均衡、集群配置、存儲、應(yīng)用數(shù)據(jù)緩存、數(shù)據(jù)庫這五個(gè)層面進(jìn)行相應(yīng)配置工作，如圖4-52所示。

1）全局負(fù)載均衡層：

• 使用F5等負(fù)載均衡器，為多個(gè)數(shù)據(jù)中心的容器云提供統(tǒng)一的入口流量；
• 每個(gè)集群的Route服務(wù)域名應(yīng)保持相同；
• 全局負(fù)載均衡層需要配置每個(gè)應(yīng)用所對應(yīng)的集群分發(fā)地址，并根據(jù)集群中所給的資源配比配置權(quán)重。

2）集群配置層：

• 應(yīng)用部署時(shí)，不同集群可以使用獨(dú)立的鏡像庫，以提升鏡像的獲取速度；
• 應(yīng)用部署時(shí)，各集群中的服務(wù)信息應(yīng)保持一致，服務(wù)名稱、外部地址應(yīng)相同；
• 同一應(yīng)用容器使用的PV/PVC應(yīng)保持一致。

3）存儲層：

• 基于Ceph的分布式存儲同步能力，可以使用客戶提供的符合要求的鏡像庫和存儲同步方案；
• 原則上每個(gè)中心的PaaS平臺使用本中心內(nèi)的存儲資源，只有當(dāng)集群和異地存儲的時(shí)間延遲和網(wǎng)絡(luò)抖動滿足應(yīng)用的要求時(shí)，才會做跨中心的存儲訪問。

4）應(yīng)用數(shù)據(jù)緩存層：

• 如果使用Redis集群，則使用redis-migrate-tool或RedisShake做跨集群的異步復(fù)制，我們將在8.1.7節(jié)介紹兩種實(shí)現(xiàn)的區(qū)別。如果對緩存的數(shù)據(jù)一致性要求很高，可以使用JBoss Data Grid（對應(yīng)開源社區(qū)Infinispan）自動實(shí)現(xiàn)跨中心的雙向數(shù)據(jù)同步。
• 對于單純的讀緩存的數(shù)據(jù)，由應(yīng)用系統(tǒng)進(jìn)行初始化以及災(zāi)備切換后的初始化之后，從數(shù)據(jù)庫中讀取。
• 對于會話性緩存數(shù)據(jù)，如果希望PaaS端發(fā)生多活切換后，客戶端應(yīng)用不重新構(gòu)建會話數(shù)據(jù)，則需要單獨(dú)搭建數(shù)據(jù)緩存的跨中心復(fù)制功能。
• 每個(gè)數(shù)據(jù)中心的應(yīng)用，只訪問各自數(shù)據(jù)中心的緩存，不跨集群訪問。

5）數(shù)據(jù)庫層：

• 建議將MySQL部署到物理機(jī)上；
• 數(shù)據(jù)庫采用MySQL主從復(fù)制的方式，可以一主多從；
• 從數(shù)據(jù)中心寫數(shù)據(jù)庫需訪問主庫；
• 兩個(gè)數(shù)據(jù)中心可以實(shí)現(xiàn)MySQL的讀寫分離，即主中心的數(shù)據(jù)讀寫主庫，從中心讀從庫、寫主庫。

接下來，我們看3個(gè)銀行客戶在容器云雙活方面考量的實(shí)例。客戶主要從7個(gè)技術(shù)點(diǎn)進(jìn)行考量。

1）應(yīng)用的雙活實(shí)現(xiàn)（考慮OpenShift集群之間是否需要打通VPN）。

a）一個(gè)應(yīng)用的不同副本部署到兩個(gè)OCP集群？

b）一個(gè)應(yīng)用在兩個(gè)OCP集群各部署一套。

2）GLB的實(shí)現(xiàn)策略（考慮負(fù)載均衡器的能力）：

a）通過F5（或其他負(fù)載均衡器）的負(fù)載均衡策略實(shí)現(xiàn)（主從、輪詢、性能）；

b）通過F5（或其他負(fù)載均衡器）的header過濾，不同地區(qū)請求轉(zhuǎn)發(fā)到不同的OCP。

3）兩數(shù)據(jù)中心應(yīng)用的工作模式（考慮容器應(yīng)用是否實(shí)現(xiàn)了無狀態(tài)）：雙寫、讀寫分離、主從復(fù)制。

4）緩存的設(shè)計(jì)（考慮數(shù)據(jù)中心之間的帶寬以及是否可以接受服務(wù)降級）：Redis集群的部署方式以及復(fù)制方式。

5）數(shù)據(jù)庫的設(shè)計(jì)（考慮數(shù)據(jù)庫是否本身支持雙活）：數(shù)據(jù)中心的部署方式以及復(fù)制方式，如分布分表、分布式數(shù)據(jù)庫、主從復(fù)制。

6）公有云（考慮公有云與私有云的業(yè)務(wù)分配與CI/CD打通）：公有云上的OCP與數(shù)據(jù)中心內(nèi)部的雙活設(shè)計(jì)、業(yè)務(wù)劃分。

7）鏡像倉庫設(shè)計(jì)（考慮數(shù)據(jù)中心之間的網(wǎng)絡(luò)帶寬）：不同數(shù)據(jù)中心之間的鏡像倉庫復(fù)制設(shè)計(jì)。

根據(jù)以上7個(gè)技術(shù)問題，3個(gè)客戶在容器云雙活方面的設(shè)計(jì)如表4-5所示。

多活容器云的異地災(zāi)備中的環(huán)境配置、應(yīng)用部署過程與雙活配置相同，但是會增加如下恢復(fù)環(huán)節(jié)：

• 確認(rèn)切換目標(biāo)集群的對應(yīng)的應(yīng)用配置庫；
• 確認(rèn)數(shù)據(jù)復(fù)制、恢復(fù)狀態(tài)；
• 應(yīng)用初始化；
• 應(yīng)用狀態(tài)確認(rèn)；
• 接通全局負(fù)載均衡的流量。