共計 4313 個字符，預計需要花費 11 分鐘才能閱讀完成。
這篇文章主要為大家分析了如何讀懂 Harbor 的高可用方案的相關知識點，內容詳細易懂，操作細節合理，具有一定參考價值。如果感興趣的話，不妨跟著跟隨丸趣 TV 小編一起來看看，下面跟著丸趣 TV 小編一起深入學習“如何讀懂 Harbor 的高可用方案”的知識吧。
隨著 Harbor 被越來越多地部署在生產環境下，Harbor 的高可用性成為用戶關注的熱點。對于一些大中型企業用戶，如果只有單實例的 Harbor，則一旦發生故障，其從開發到交付的流水線就可能被迫停止，無法滿足高可用需求。
下面提供基于 Harbor 的不同安裝包的高可用方案，目標是移除單點故障，提高系統的高可用性。其中，基于 Harbor Helm Chart 的高可用方案為官方驗證過的方案，基于多 Kubernetes 集群和基于離線安裝包的高可用方案為參考方案。
1. 基于 Harbor Helm Chart 的高可用方案
Kubernetes 平臺具有自愈（self-healing）能力，當容器崩潰或無響應時，可自動重啟容器，必要時可把容器從失效的節點調度到正常的節點。本方案通過 Helm 部署 Harbor Helm Chart 到 Kubernetes 集群來實現高可用，確保每個 Harbor 組件都有多于一個副本運行在 Kubernetes 集群中，當某個 Harbor 容器不可用時，Harbor 服務依然可正常使用。
為實現 Harbor 在 Kubernetes 集群中的高可用，Harbor 的大部分組件都是無狀態組件。有狀態組件的狀態信息被保存在共享存儲而非內存中。這樣一來，在 Kubernetes 集群中只需配置組件的副本個數，即可借助 Kubernetes 平臺實現高可用。（本文來自公眾號：亨利筆記）
◎ Kubernetes 平臺通過協調調度（Reconciliation Loop）機制使 Harbor 各組件達到期望的副本數，從而實現服務的高可用。
◎ PostgreSQL、Redis 集群實現數據的高可用性、一致性和前端會話（session）的共享。
◎ 共享數據存儲實現 Artifact 數據的一致性。
多 Kubernetes 集群的高可用架構
上述介紹了使用 Harbor Helm Chart 在單個 Kubernetes 集群中搭建 Harbor 高可用環境的方案，其中實現了 Harbor 服務的高可用，但服務的整體可用性還是受到其運行所依賴的 Kubernetes 集群可用性的影響，如果集群崩潰，則會導致服務的不可用。在某些生產環境下會對可用性有更高的要求，因而基于多數據中心部署的多 Kubernetes 集群的高可用方案尤為重要。下面是在多個跨數據中心的 Kubernetes 集群上構建 Harbor 高可用環境的參考方案。
上圖可以看到，Harbor 在兩個數據中心分別擁有獨立的數據和內容存儲。在兩個數據中心之間配置了 Harbor 自帶的遠程復制功能，實現了對 Artifact（制品） 數據的復制（如鏡像復制）。也就是說，在兩個 Kubernetes 集群的數據存儲上，通過遠程復制來保證 Artifact 的一致性。而對于兩個數據中心之間的 PostgreSQL 和 Redis 的數據一致性，這里需要用戶基于不同類型的數據中心提供自己的數據備份方案，目的是保持兩個數據中心的 PostgreSQL 和 Redis 數據的一致性。
本方案使用了 Harbor 主從（Active-Standby）模式，由于采用了鏡像等 Artifact 遠程復制，在數據同步上有一定的延時，在實際使用中需要留意對應用的影響。對實時性要求不高的用戶，可參考此方案搭建跨數據中心多 Kubernetes 集群的高可用方案。
注意：在多次安裝過程中都需要保證 values.yml 配置項 core.secretName 和 core.xsrfKey 的值相同，其他配置項可根據不同數據中心的需求自行配置。
關于 core.secretName 和 core.xsrfKey 值相同的具體原因，詳見下文關于多 Harbor 實例之間需要共享的文件或者配置部分的內容。
2. 基于離線安裝包的高可用方案
基于 Kubernetes 集群搭建的高可用架構是 Harbor 官方提供的方案。但用戶可能出于某種原因無法部署獨立的 Kubernetes 集群，更希望創建基于 Harbor 離線安裝包的高可用方案。基于 Harbor 離線安裝包搭建高可用系統是一項復雜的任務，需要用戶具有高可用的相關技術基礎，并深入了解 Harbor 的架構和配置。本節介紹的兩種常規模式僅為參考方案，主要說明基于離線安裝包實現高可用時，用戶需要解決的問題和需要注意的地方。建議先閱讀本章的其他內容，理解 Harbor 的安裝及部署方式，在此基礎上再結合各自的實際生產情況進行修改并實施。（本文來自公眾號：亨利筆記）
（1）基于共享服務的高可用方案
此方案的基本思想是多個 Harbor 實例共享 PostgreSQL、Redis 及存儲，通過負載均衡器實現多臺服務器提供 Harbor 服務。
重要配置：多個 Harbor 實例需要適當的配置才能工作，下面介紹相關原理，實際中用戶可以靈活運用。
a）關于負載均衡器的設置
需要設置每個 Harbor 實例的配置文件的 external_url 項，把該項地址指定為負載均衡器的地址。通過該項指定負載均衡器的地址后，Harbor 將不再使用配置文件中的 hostname 作為訪問地址。客戶端（Docker 和瀏覽器等）通過 external_url 提供的地址（即負載均衡器的地址）訪問后端服務的 API。（本文來自公眾號：亨利筆記）
如果不設置該值，則客戶端會依據 hostname 的地址來訪問后端服務的 API，負載均衡在這里并沒有起到作用。也就是說，服務訪問并沒有通過負載均衡直接到達后端，當后端地址不被外部識別時（如有 NAT 或防火墻等情況），服務訪問還會失敗。
如果 Harbor 實例使用了 HTTPS，特別是自持證書時，需要配置負載均衡器信任其后端每個 Harbor 實例的證書。同時，需要將負載均衡器的證書放置于每個 Harbor 實例中，其位置為 harbor.yml 配置項中 data_volume 指定路徑下的 “ca_download” 文件夾中，該文件夾需要手動創建。這樣，用戶從任意 Harbor 實例的 UI 下載的證書就是負載均衡器的證書，如圖所示。
b）外置數據庫的配置
用戶需要自行創建 PostgreSQL 共享實例或者集群，并將其信息配置到每個 Harbor 實例外置的數據庫配置項中。注意：外置 PostgreSQL 數據庫需要預先為 Harbor Core、Clair、Notary Server 及 Notary Signer 組件分別創建空數據庫 registry、clair、notary_server 及 notary_singer，并將創建的數據庫信息配置到相應組件外置的數據庫信息部分。Harbor 在啟動時，會自動創建對應數據庫的數據庫表。（本文來自公眾號：亨利筆記）
c）外置 Redis 的配置
用戶需要自行創建 Redis 共享實例或者集群，并將其信息配置到每個 Harbor 實例外置的 Redis 配置項中。
d）外置存儲的配置
用戶需要提供本地或云端共享存儲，并將其信息配置到每個 Harbor 實例的外置存儲配置項中。
e）多個 Harbor 實例之間需要共享的文件或者配置
基于離線安裝包安裝的高可用方案需要保證以下文件在多個實例之間的一致性。同時，由于這些文件是在各個 Harbor 實例的安裝過程中默認生成的，所以需要用戶手動復制這些文件來保證一致性。
private_key.pem 和 root.crt 文件
Harbor 在客戶端認證流程中提供了證書和私鑰文件供 Distribution 創建和校驗請求中的 Bearer token。在多實例 Harbor 的高可用方案中，多實例之間需要做到任何一個實例創建的 Bearer token 都可被其他實例識別并校驗，也就是說，所有實例都需要使用相同的 private_key.pem 和 root.crt 文件。
如果多實例 Harbor 之間的這兩個文件不同，在認證過程中就可能發生隨機性的成功或失敗。失敗的原因是請求被負載均衡器轉發到非創建該 Bearer token 的實例中，該實例無法解析非自身創建的 token，從而導致認證失敗。
private_key.pem 文件位于 harbor.yml 配置項 data_volume 指定路徑的“secret/core”子目錄下。root.crt 文件位于 harbor.yml 配置項 data_volume 指定路徑的“secret/registry”子目錄下。
csrf_key
為防止跨站攻擊（Cross Site Request Forgery），Harbor 啟用了 csrf 的 token 校驗。Harbor 會生成一個隨機數作為 csrf 的 token 附加在 cookie 中，用戶提交請求時，客戶端會從 cookie 中提取這個隨機數，并將其作為 csrf 的 token 一并提交。Harbor 會依據這個值是否為空或者無效來拒絕該訪問請求。那么，多實例之間需要做到任何一個實例創建的 token 都可被其他任意實例成功校驗，也就是需要統一各個實例的 csrf token 私鑰值。
該配置位于 Harbor 安裝目錄下的“common/config/core/env”文件中，用戶需要把一個 Harbor 實例的值手動復制到其他實例上，使該值在所有實例上保持一致。
注意：手動修改以上文件或配置時，均需要通過 docker-compose 重啟 Harbor 實例以使配置生效。另外，如果后續要使用 Harbor 安裝包中的 prepare 腳本，則需要重復上述手動復制過程。（本文來自公眾號：亨利筆記）
（2）基于復制策略的高可用方案
此方案的基本思想是多個 Harbor 實例使用 Harbor 原生的遠程復制功能實現 Artifact 的一致性，通過負載均衡器實現多臺服務器提供單一的 Harbor 服務。
方案 (2) 與方案 (1) 不同的是，在安裝 Harbor 實例時不需要指定外置的 PostgreSQL、Redis 及存儲，每個實例都使用自己獨立的存儲。Harbor 的多實例之間通過遠程復制功能實現 Artifact 數據的一致性。關于 PostgreSQL 和 Redis 的數據一致性問題，需要用戶自行實現數據同步的解決方案。基于復制的多實例解決方案，其實時性不如基于共享存儲的方案，但相比之下搭建更為簡單，用戶使用 Harbor 離線安裝包提供的 PostgreSQL、Redis 即可。
關于“如何讀懂 Harbor 的高可用方案”就介紹到這了, 更多相關內容可以搜索丸趣 TV 以前的文章，希望能夠幫助大家答疑解惑，請多多支持丸趣 TV 網站！
