如何讀懂Harbor的高可用方案

這篇文章主要為大家分析了如何讀懂Harbor的高可用方案的相關(guān)知識(shí)點(diǎn)，內(nèi)容詳細(xì)易懂，操作細(xì)節(jié)合理，具有一定參考價(jià)值。如果感興趣的話，不妨跟著跟隨小編一起來看看，下面跟著小編一起深入學(xué)習(xí)“如何讀懂Harbor的高可用方案”的知識(shí)吧。

隨著 Harbor 被越來越多地部署在生產(chǎn)環(huán)境下，Harbor 的高可用性成為用戶關(guān)注的熱點(diǎn)。對(duì)于一些大中型企業(yè)用戶，如果只有單實(shí)例的 Harbor，則一旦發(fā)生故障，其從開發(fā)到交付的流水線就可能被迫停止，無法滿足高可用需求。

下面提供基于 Harbor 的不同安裝包的高可用方案，目標(biāo)是移除單點(diǎn)故障，提高系統(tǒng)的高可用性。其中，基于 Harbor Helm Chart 的高可用方案為官方驗(yàn)證過的方案，基于多 Kubernetes 集群和基于離線安裝包的高可用方案為參考方案。

1. 基于 Harbor Helm Chart 的高可用方案

Kubernetes 平臺(tái)具有自愈（self-healing）能力，當(dāng)容器崩潰或無響應(yīng)時(shí)，可自動(dòng)重啟容器，必要時(shí)可把容器從失效的節(jié)點(diǎn)調(diào)度到正常的節(jié)點(diǎn)。本方案通過 Helm 部署 Harbor Helm Chart 到 Kubernetes 集群來實(shí)現(xiàn)高可用，確保每個(gè)Harbor 組件都有多于一個(gè)副本運(yùn)行在 Kubernetes 集群中，當(dāng)某個(gè) Harbor 容器不可用時(shí)，Harbor 服務(wù)依然可正常使用。

為實(shí)現(xiàn) Harbor 在 Kubernetes 集群中的高可用，Harbor 的大部分組件都是無狀態(tài)組件。有狀態(tài)組件的狀態(tài)信息被保存在共享存儲(chǔ)而非內(nèi)存中。這樣一來，在 Kubernetes 集群中只需配置組件的副本個(gè)數(shù)，即可借助Kubernetes平臺(tái)實(shí)現(xiàn)高可用。（本文來自公眾號(hào)：亨利筆記）

◎ Kubernetes平臺(tái)通過協(xié)調(diào)調(diào)度（Reconciliation Loop）機(jī)制使Harbor各組件達(dá)到期望的副本數(shù)，從而實(shí)現(xiàn)服務(wù)的高可用。

◎ PostgreSQL、Redis 集群實(shí)現(xiàn)數(shù)據(jù)的高可用性、一致性和前端會(huì)話（session）的共享。

◎ 共享數(shù)據(jù)存儲(chǔ)實(shí)現(xiàn) Artifact 數(shù)據(jù)的一致性。

多Kubernetes集群的高可用架構(gòu)

上述介紹了使用 Harbor Helm Chart 在單個(gè)Kubernetes集群中搭建 Harbor 高可用環(huán)境的方案，其中實(shí)現(xiàn)了 Harbor 服務(wù)的高可用，但服務(wù)的整體可用性還是受到其運(yùn)行所依賴的 Kubernetes 集群可用性的影響，如果集群崩潰，則會(huì)導(dǎo)致服務(wù)的不可用。在某些生產(chǎn)環(huán)境下會(huì)對(duì)可用性有更高的要求，因而基于多數(shù)據(jù)中心部署的多 Kubernetes 集群的高可用方案尤為重要。下面是在多個(gè)跨數(shù)據(jù)中心的 Kubernetes 集群上構(gòu)建 Harbor 高可用環(huán)境的參考方案。

上圖可以看到，Harbor 在兩個(gè)數(shù)據(jù)中心分別擁有獨(dú)立的數(shù)據(jù)和內(nèi)容存儲(chǔ)。在兩個(gè)數(shù)據(jù)中心之間配置了 Harbor 自帶的遠(yuǎn)程復(fù)制功能，實(shí)現(xiàn)了對(duì) Artifact （制品） 數(shù)據(jù)的復(fù)制（如鏡像復(fù)制）。也就是說，在兩個(gè) Kubernetes 集群的數(shù)據(jù)存儲(chǔ)上，通過遠(yuǎn)程復(fù)制來保證 Artifact 的一致性。而對(duì)于兩個(gè)數(shù)據(jù)中心之間的PostgreSQL 和 Redis 的數(shù)據(jù)一致性，這里需要用戶基于不同類型的數(shù)據(jù)中心提供自己的數(shù)據(jù)備份方案，目的是保持兩個(gè)數(shù)據(jù)中心的 PostgreSQL 和 Redis 數(shù)據(jù)的一致性。

本方案使用了 Harbor 主從（Active-Standby）模式，由于采用了鏡像等 Artifact 遠(yuǎn)程復(fù)制，在數(shù)據(jù)同步上有一定的延時(shí)，在實(shí)際使用中需要留意對(duì)應(yīng)用的影響。對(duì)實(shí)時(shí)性要求不高的用戶，可參考此方案搭建跨數(shù)據(jù)中心多 Kubernetes 集群的高可用方案。

注意：在多次安裝過程中都需要保證 values.yml 配置項(xiàng) core.secretName 和core.xsrfKey 的值相同，其他配置項(xiàng)可根據(jù)不同數(shù)據(jù)中心的需求自行配置。

關(guān)于core.secretName 和 core.xsrfKey 值相同的具體原因，詳見下文關(guān)于多 Harbor 實(shí)例之間需要共享的文件或者配置部分的內(nèi)容。

2. 基于離線安裝包的高可用方案

基于Kubernetes集群搭建的高可用架構(gòu)是 Harbor 官方提供的方案。但用戶可能出于某種原因無法部署獨(dú)立的 Kubernetes 集群，更希望創(chuàng)建基于 Harbor 離線安裝包的高可用方案?；?nbsp;Harbor 離線安裝包搭建高可用系統(tǒng)是一項(xiàng)復(fù)雜的任務(wù)，需要用戶具有高可用的相關(guān)技術(shù)基礎(chǔ)，并深入了解 Harbor 的架構(gòu)和配置。本節(jié)介紹的兩種常規(guī)模式僅為參考方案，主要說明基于離線安裝包實(shí)現(xiàn)高可用時(shí)，用戶需要解決的問題和需要注意的地方。建議先閱讀本章的其他內(nèi)容，理解 Harbor 的安裝及部署方式，在此基礎(chǔ)上再結(jié)合各自的實(shí)際生產(chǎn)情況進(jìn)行修改并實(shí)施。（本文來自公眾號(hào)：亨利筆記）

（1）基于共享服務(wù)的高可用方案

此方案的基本思想是多個(gè) Harbor 實(shí)例共享 PostgreSQL、Redis 及存儲(chǔ)，通過負(fù)載均衡器實(shí)現(xiàn)多臺(tái)服務(wù)器提供 Harbor 服務(wù)。

重要配置：多個(gè) Harbor 實(shí)例需要適當(dāng)?shù)呐渲貌拍芄ぷ?，下面介紹相關(guān)原理，實(shí)際中用戶可以靈活運(yùn)用。

a）關(guān)于負(fù)載均衡器的設(shè)置

需要設(shè)置每個(gè) Harbor 實(shí)例的配置文件的 external_url 項(xiàng)，把該項(xiàng)地址指定為負(fù)載均衡器的地址。通過該項(xiàng)指定負(fù)載均衡器的地址后，Harbor 將不再使用配置文件中的 hostname 作為訪問地址?？蛻舳耍?Docker 和瀏覽器等）通過 external_url 提供的地址（即負(fù)載均衡器的地址）訪問后端服務(wù)的API。（本文來自公眾號(hào)：亨利筆記）

如果不設(shè)置該值，則客戶端會(huì)依據(jù) hostname 的地址來訪問后端服務(wù)的API，負(fù)載均衡在這里并沒有起到作用。也就是說，服務(wù)訪問并沒有通過負(fù)載均衡直接到達(dá)后端，當(dāng)后端地址不被外部識(shí)別時(shí)（如有NAT或防火墻等情況），服務(wù)訪問還會(huì)失敗。

如果 Harbor 實(shí)例使用了 HTTPS，特別是自持證書時(shí)，需要配置負(fù)載均衡器信任其后端每個(gè) Harbor 實(shí)例的證書。同時(shí)，需要將負(fù)載均衡器的證書放置于每個(gè)Harbor實(shí)例中，其位置為 harbor.yml 配置項(xiàng)中 data_volume 指定路徑下的 “ca_download” 文件夾中，該文件夾需要手動(dòng)創(chuàng)建。這樣，用戶從任意 Harbor 實(shí)例的UI下載的證書就是負(fù)載均衡器的證書，如圖所示。

b）外置數(shù)據(jù)庫的配置

用戶需要自行創(chuàng)建 PostgreSQL 共享實(shí)例或者集群，并將其信息配置到每個(gè) Harbor 實(shí)例外置的數(shù)據(jù)庫配置項(xiàng)中。注意：外置 PostgreSQL 數(shù)據(jù)庫需要預(yù)先為Harbor Core、Clair、Notary Server及Notary Signer組件分別創(chuàng)建空數(shù)據(jù)庫 registry、clair、notary_server 及 notary_singer ，并將創(chuàng)建的數(shù)據(jù)庫信息配置到相應(yīng)組件外置的數(shù)據(jù)庫信息部分。Harbor 在啟動(dòng)時(shí)，會(huì)自動(dòng)創(chuàng)建對(duì)應(yīng)數(shù)據(jù)庫的數(shù)據(jù)庫表。（本文來自公眾號(hào)：亨利筆記）

c）外置Redis的配置

用戶需要自行創(chuàng)建Redis共享實(shí)例或者集群，并將其信息配置到每個(gè) Harbor 實(shí)例外置的Redis配置項(xiàng)中。

d）外置存儲(chǔ)的配置

用戶需要提供本地或云端共享存儲(chǔ)，并將其信息配置到每個(gè) Harbor 實(shí)例的外置存儲(chǔ)配置項(xiàng)中。

e）多個(gè) Harbor 實(shí)例之間需要共享的文件或者配置

基于離線安裝包安裝的高可用方案需要保證以下文件在多個(gè)實(shí)例之間的一致性。同時(shí)，由于這些文件是在各個(gè) Harbor 實(shí)例的安裝過程中默認(rèn)生成的，所以需要用戶手動(dòng)復(fù)制這些文件來保證一致性。

private_key.pem和root.crt文件

Harbor在客戶端認(rèn)證流程中提供了證書和私鑰文件供 Distribution 創(chuàng)建和校驗(yàn)請(qǐng)求中的Bearer token。在多實(shí)例 Harbor 的高可用方案中，多實(shí)例之間需要做到任何一個(gè)實(shí)例創(chuàng)建的Bearer token都可被其他實(shí)例識(shí)別并校驗(yàn)，也就是說，所有實(shí)例都需要使用相同的 private_key.pem 和 root.crt 文件。

如果多實(shí)例 Harbor 之間的這兩個(gè)文件不同，在認(rèn)證過程中就可能發(fā)生隨機(jī)性的成功或失敗。失敗的原因是請(qǐng)求被負(fù)載均衡器轉(zhuǎn)發(fā)到非創(chuàng)建該Bearer token的實(shí)例中，該實(shí)例無法解析非自身創(chuàng)建的token，從而導(dǎo)致認(rèn)證失敗。

private_key.pem文件位于harbor.yml配置項(xiàng)data_volume 指定路徑的“secret/core”子目錄下。root.crt 文件位于 harbor.yml 配置項(xiàng) data_volume 指定路徑的“secret/registry”子目錄下。

csrf_key

為防止跨站攻擊（Cross Site Request Forgery），Harbor 啟用了 csrf 的 token 校驗(yàn)。Harbor 會(huì)生成一個(gè)隨機(jī)數(shù)作為 csrf 的 token 附加在 cookie 中，用戶提交請(qǐng)求時(shí)，客戶端會(huì)從 cookie 中提取這個(gè)隨機(jī)數(shù)，并將其作為 csrf 的 token 一并提交。Harbor 會(huì)依據(jù)這個(gè)值是否為空或者無效來拒絕該訪問請(qǐng)求。那么，多實(shí)例之間需要做到任何一個(gè)實(shí)例創(chuàng)建的 token 都可被其他任意實(shí)例成功校驗(yàn)，也就是需要統(tǒng)一各個(gè)實(shí)例的 csrf token 私鑰值。

該配置位于 Harbor 安裝目錄下的“common/config/core/env”文件中，用戶需要把一個(gè) Harbor 實(shí)例的值手動(dòng)復(fù)制到其他實(shí)例上，使該值在所有實(shí)例上保持一致。

注意：手動(dòng)修改以上文件或配置時(shí)，均需要通過 docker-compose 重啟 Harbor 實(shí)例以使配置生效。另外，如果后續(xù)要使用 Harbor 安裝包中的 prepare 腳本，則需要重復(fù)上述手動(dòng)復(fù)制過程。（本文來自公眾號(hào)：亨利筆記）

（2）基于復(fù)制策略的高可用方案

此方案的基本思想是多個(gè) Harbor 實(shí)例使用 Harbor 原生的遠(yuǎn)程復(fù)制功能實(shí)現(xiàn)Artifact 的一致性，通過負(fù)載均衡器實(shí)現(xiàn)多臺(tái)服務(wù)器提供單一的 Harbor 服務(wù)。

方案(2)與方案(1)不同的是，在安裝 Harbor 實(shí)例時(shí)不需要指定外置的 PostgreSQL、Redis 及存儲(chǔ)，每個(gè)實(shí)例都使用自己獨(dú)立的存儲(chǔ)。Harbor 的多實(shí)例之間通過遠(yuǎn)程復(fù)制功能實(shí)現(xiàn) Artifact 數(shù)據(jù)的一致性。關(guān)于 PostgreSQL 和 Redis 的數(shù)據(jù)一致性問題，需要用戶自行實(shí)現(xiàn)數(shù)據(jù)同步的解決方案?；趶?fù)制的多實(shí)例解決方案，其實(shí)時(shí)性不如基于共享存儲(chǔ)的方案，但相比之下搭建更為簡(jiǎn)單，用戶使用 Harbor 離線安裝包提供的 PostgreSQL、Redis 即可。

關(guān)于“如何讀懂Harbor的高可用方案”就介紹到這了,更多相關(guān)內(nèi)容可以搜索億速云以前的文章，希望能夠幫助大家答疑解惑，請(qǐng)多多支持億速云網(wǎng)站！