Day26 說了 CI/CD 與 GitOps 如何部署服務。當 YAML 指定要使用 api-a:v2，接著就有一個問題：這個 image 要放在哪裡，叢集又要去哪裡取得？

registry 就是存放與提供 image 的地方。今天要說的 Harbor，除了提供 registry，也能管理存取權限、掃描弱點，以及把 image 複寫到其他站點。

為什麼會需要 Harbor？

開發時，image 可以先放在自己的電腦。等到 CI 要發布、不同 Node 要啟動服務，就需要一個大家能連線取得 image 的位置。

Harbor 是開源的 registry 平台，可以自行架設。適合想把 image 留在自己的環境，並一起管理下面幾件事的團隊：Harbor 官方介紹

• 存取權限：用 Harbor 的 Project 分組管理 repository，決定誰可以上傳、下載。Private Project 的內容需要具備權限才能取得。
• 自動化帳號：用 Robot Account 提供 CI 或拉取 image 所需的身分，依用途設定權限與有效期限，方便更新或停用。
• 弱點掃描：搭配 Trivy 等 scanner，找出 image 裡已知的弱點，協助團隊決定哪些版本可以發布。
• 版本保存與分發：設定 tag immutability、保留規則與 replication，管理哪些版本要保留，以及哪些 image 要送到其他 registry。

Harbor 的 Project 是 registry 內的分組，和 Kubernetes Namespace 分別管理。Image 拉取權限可以透過 Kubernetes 的 imagePullSecrets 提供。

如果現有 registry 已符合需求，就可以繼續沿用。導入 Harbor 時，也要安排儲存空間、備份、憑證、升級與帳號管理。

Harbor 在部署流程裡做什麼？

可以把流程分成三個工作：

• CI 建置 image，完成測試後上傳到 Harbor。
• CD 或 GitOps 更新部署設定，指定服務使用哪個 registry、repository 與版本。
• Node 依設定取得 image，由 kubelet 透過 container runtime 執行拉取，再啟動 container。

例如 harbor-a.example.com/team/api-a:v2，包含 registry 位址、Harbor Project team、repository api-a 與 tag v2。

Harbor 負責保存與提供這個 image；前一天的 GitLab CD、kapp-controller 或 Argo CD，則負責把部署設定套用到叢集。Kubernetes Images

同一個 v2，如何送到另一個站點？

假設站點 A、B 各有一套相同版本的 Harbor，希望 B 的叢集能從當地取得 api-a:v2。可以在 A 建立 Push-based + Event Based 的 replication 規則：

• 先設定 B 的 endpoint，包含 registry 位址、連線認證與憑證信任。
• 選擇要複寫的 repository、tag 等條件，並設定目的端路徑。
• CI 將 v2 上傳到 A 後，符合條件的事件會觸發複寫工作，把 image 傳到 B。
• B 的部署設定使用 B 的 registry 位址，Node 就能向 B 拉取 image。

這個例子假設兩端都保留 team/api-a:v2 的路徑。Harbor 有 Destination Namespace 與 Flattening 設定，實際路徑要依複寫規則安排，B 的 YAML 也要使用對應位址。

複寫透過背景工作執行，完成時間會受到 image 大小、頻寬、工作排隊與重試影響。第一次建立規則時，可以先手動執行複寫，補上來源已存在的 image，再交給後續事件處理。

Push／Pull 與觸發時機，差在哪裡？

沿用 A 的 image 要送到 B 的情境，先看由哪一端發起：

• Push-based：規則建在 A，由 A 發起，將 image 複寫到 B。
• Pull-based：規則建在 B，由 B 發起，從 A 取得 image。

兩種方式的 image 都是從 A 到 B。接著才是「什麼時候執行」：

刪除與版本覆蓋要怎麼處理？

跨站保存 image 時，可以先決定 B 是要跟著 A 清理，還是另外保留版本：

• Manual、Scheduled：複寫符合條件的資源，來源端的刪除操作不會傳到目的端。
• Event Based：可以啟用 Delete remote resources when locally deleted，讓來源刪除 artifact 時，也刪除目的端對應內容；保留關閉則由目的端自行安排清理。
• 容量清理：Tag Retention 決定保留哪些版本，Garbage Collection 回收已無 manifest 引用的 blobs。兩端可以各自安排保存與空間回收規則。

版本名稱也要管理。同一個 tag 可以重新指向不同內容，v2 適合辨識版本，digest 則用來識別實際內容。正式版本可以搭配 tag immutability，保護符合規則的 tag，避免被覆蓋或刪除。

如果使用 Override 複寫同名資源，目的端仍會依權限與 immutability 等規則處理。兩邊都有人上傳相同 tag 時，先訂好哪一端負責發布這個版本，會比較好維護。

如何確認 B 已經能使用這個 image？

可以依照流程查看三個地方：

• 複寫工作：查看 execution、task 與 log，確認這次要同步的 image 已完成；失敗時先找連線、認證、權限或規則衝突。
• 目的端內容：在 B 查看正確的 repository、tag 與 digest，和 A 的內容比對。
• Node 拉取結果：用 B 的 registry 位址測試部署，確認 Node 能連線、信任憑證，也具備拉取權限。ImagePullBackOff 的原因可以從 Pod events 查看。

Harbor 的 replication 不會複製 Project 成員資訊，B 的權限要自行設定；自簽憑證的 CA 信任也要分別安排在複寫端與 Node 的 container runtime。Configuring Replication

跨站複寫讓 B 提前準備好需要的 image。服務更新由 CD 或 GitOps 負責，流量切換則交給入口與站點切換機制。把這幾段串起來，就能清楚知道發布流程卡在哪裡。

參考資料

• Harbor：官方介紹
• Harbor：Create Projects
• Harbor：Robot Accounts
• Harbor：Creating a Replication Rule
• Harbor：Garbage Collection
• Harbor：Tag Immutability
• Kubernetes：Images