[HARBOR - 3단계] Source / Destination / Endpoint / Replication Rule 이해하기 !!

 

 

3단계. Source / Destination / Endpoint / Replication Rule 이해하기

이번 단계부터 Harbor Native Replication의 핵심 설정 개념으로 들어갑니다.

우리 목표는 다음 구조입니다.

[운영]
PROD Harbor
harbor-prod.company.com
      ▲
      │
      │ Pull
      │ HTTPS 443
      │
[DR]
DR Harbor
harbor-dr.company.com

그리고 설정은 DR Harbor에서 합니다.

DR Harbor
 │
 ├─ Endpoint
 │    └─ PROD Harbor 등록
 │
 └─ Replication Rule
      ├─ Mode       : Pull-Based
      ├─ Source     : PROD Harbor Endpoint
      ├─ Filter     : 어떤 Artifact를 가져올지
      └─ Trigger    : Scheduled

Harbor 공식 문서상 Replication Rule을 만들기 전에 먼저 Endpoint가 존재해야 하며, Pull-Based Rule에서는 구성된 Endpoint를 Source Registry로 선택합니다. Harbor

---

 

3.1 먼저 4개 용어를 한 번에 이해해 보자 ⭐

가장 간단하게 표현하면 다음과 같습니다.

용어	의미	DR 환경
Source	Artifact가 원래 있는 곳	PROD Harbor
Destination	Artifact를 복사해 둘 곳	DR Harbor
Endpoint	상대방 Harbor 접속정보	DR에 등록한 PROD Harbor 정보
Replication Rule	무엇을 언제 어떻게 복제할지 정한 정책	DR에 생성하는 Pull Rule

즉:

Source
=
물건이 있는 창고

Destination
=
물건을 가져다 놓을 창고

Endpoint
=
상대 창고 주소 + 출입정보

Replication Rule
=
어떤 물건을 언제 가져올지 적은 작업지시서

이렇게 이해하면 됩니다.

---

 

3.2 우리가 사용할 예제 환경

앞으로 설명을 쉽게 하기 위해 환경을 고정하겠습니다.

운영

PROD Kubernetes

Harbor
harbor-prod.company.com

Project
├─ app
│   ├─ web:v1
│   ├─ web:v2
│   └─ api:v5
│
└─ ai
    └─ inference:v10

DR

DR Kubernetes

Harbor
harbor-dr.company.com

목표는:

PROD                              DR

app/web:v1   ─────────────────▶ app/web:v1
app/web:v2   ─────────────────▶ app/web:v2
app/api:v5   ─────────────────▶ app/api:v5

ai/inference:v10 ─────────────▶ ai/inference:v10

입니다.

---

 

3.3 Source Registry란?

Source는 말 그대로:

복제할 Artifact가 원래 존재하는 Registry

입니다.

우리 환경에서는:

Source Registry
      =
PROD Harbor

입니다.

┌─────────────────────────┐
│ PROD Harbor             │
│                         │
│ app/web:v1              │
│ app/web:v2              │
│ app/api:v5              │
└───────────┬─────────────┘
            │
            │ Replication
            ▼
          DR Harbor

따라서:

Source = PROD

라고 기억하면 됩니다.

---

 

3.4 Destination Registry란?

Destination은:

복제된 Artifact가 최종적으로 저장되는 Registry

입니다.

우리 환경에서는:

Destination Registry
       =
DR Harbor

입니다.

PROD Harbor
     │
     │
     ▼
┌────────────────────────┐
│ DR Harbor              │
│                        │
│ app/web:v1             │
│ app/web:v2             │
│ app/api:v5             │
└────────────────────────┘

Destination

따라서 전체 데이터 흐름은:

Source                        Destination

PROD Harbor
     │
     │ Artifact Replication
     ▼
DR Harbor

입니다.

---

 

3.5 그런데 Endpoint는 무엇인가? ⭐⭐⭐

초보자에게 가장 헷갈리는 것이 Endpoint입니다.

쉽게 말하면:

📒 Endpoint = 다른 Registry에 접속하기 위한 주소록

이라고 보면 됩니다.

예를 들어 DR Harbor가 PROD Harbor에서 Artifact를 가져오려면 최소한 다음을 알아야 합니다.

PROD Harbor는 어디 있어?

https://harbor-prod.company.com

↓

접속 계정은?

↓

인증정보는?

↓

TLS 인증서는 신뢰할 수 있어?

이런 정보를 Endpoint 하나로 등록합니다.

Harbor 공식 문서에서는 Administration → Registries → + New Endpoint에서 Provider, Name, URL, Access ID, Access Secret 등을 입력하고 Test Connection으로 연결을 확인하도록 합니다. Endpoint에는 다른 Harbor뿐 아니라 지원되는 외부 Registry도 등록할 수 있습니다. Harbor

---

 

3.6 환경에서는 Endpoint를 어디에 만들까?

이게 중요합니다.

사용할 방식은:

Pull-Based

입니다.

즉:

DR이 PROD에서 가져온다.

그래서 DR Harbor에 PROD Harbor Endpoint를 등록합니다.

                  PROD Harbor
             harbor-prod.company.com
                       ▲
                       │
                       │
              Endpoint가 가리킴
                       │
                       │
┌──────────────────────┴────────────┐
│ DR Harbor                         │
│                                   │
│ Administration                    │
│    └─ Registries                  │
│         └─ PROD-HARBOR            │
│              │                    │
│              ├─ Provider: Harbor  │
│              ├─ URL: https://...  │
│              └─ Credentials       │
└───────────────────────────────────┘

Harbor의 Pull Rule에서는 이처럼 원격 Registry Endpoint를 Source Registry로 선택합니다. Harbor

---

 

3.7 Endpoint를 전화번호부로 생각하면 쉽다 📖

예를 들어 DR Harbor 내부에:

Registry Endpoint 목록

┌───────────────────────────────┐
│ Name        : PROD-HARBOR     │
│ Provider    : Harbor          │
│ URL         : https://prod... │
│ Access ID   : robot$dr-pull   │
│ Secret      : *************   │
└───────────────────────────────┘

가 있다고 해봅시다.

이것만 만들었다고 Replication이 자동으로 시작되는 것은 아닙니다.

Endpoint는 단지:

"PROD Harbor가 어디 있는지"

알려주는 정보입니다.

즉:

Endpoint
   ≠
Replication

입니다.

---

 

3.8 그러면 Replication Rule이 필요하다 ⭐⭐⭐

Replication Rule은:

Endpoint를 이용해서 어떤 Artifact를 언제 어떤 방식으로 복제할지를 정의한 정책

입니다.

예를 들어:

Rule Name
DR-PROD-PULL

Mode
Pull-Based

Source
PROD-HARBOR

Resource Filter
app/**

Trigger
Scheduled

Schedule
10분마다

라고 만들 수 있습니다.

그러면 의미는:

"DR Harbor야,

PROD-HARBOR Endpoint에 접속해서

app 아래 Artifact를 확인하고

정해진 주기에 따라 가져와."

가 됩니다.

Harbor Replication Rule에서는 Pull/Push 모드, Source Filter, Destination Namespace, Trigger Mode, Override 등의 조건을 지정할 수 있습니다. Harbor

---

 

3.9 Endpoint와 Rule의 차이 ⭐

이 둘을 반드시 구분해야 합니다.

Endpoint

PROD Harbor 주소가 어디냐?

https://harbor-prod.company.com

Rule

PROD에서

무엇을?
app/**

어떻게?
Pull

언제?
Scheduled

어디로?
DR Harbor

입니다.

쉽게 비유하면:

Endpoint
=
택배 받을 곳 주소


Replication Rule
=
택배 주문서

입니다.

---

 

3.10 실제 DR Harbor에서는 이렇게 구성된다

DR Harbor 화면을 개념적으로 보면:

DR Harbor
│
├─ Administration
│
│
├─ Registries
│    │
│    └─ PROD-HARBOR
│         │
│         ├─ URL
│         ├─ ID
│         └─ Password/Secret
│
└─ Replications
     │
     └─ PROD-TO-DR
          │
          ├─ Mode
          │    Pull-Based
          │
          ├─ Source
          │    PROD-HARBOR
          │
          ├─ Filter
          │    app/**
          │
          └─ Trigger
               Scheduled

즉 순서가 중요합니다.

① Endpoint 생성

        ↓

② Replication Rule 생성

공식 문서도 Endpoint가 먼저 존재해야 Replication Rule을 생성할 수 있다고 명시합니다. Harbor

---

 

3.11 Endpoint 실제 입력 항목 미리 보기

DR Harbor에 로그인해서:

Administration

→ Registries

→ + New Endpoint

로 들어갑니다. 공식 main 문서도 동일한 흐름을 안내합니다. Harbor

예제는 다음과 같습니다.

항목예제

Provider	Harbor
Name	PROD-HARBOR
Description	PROD Harbor for DR
Endpoint URL	https://harbor-prod.company.com
Access ID	복제용 계정
Access Secret	비밀번호/Secret
Verify Remote Cert	운영 환경에서는 정상 CA 인증서 사용 권장
Test Connection	성공 확인

Endpoint URL에는 원격 Registry의 전체 URL을 입력하며, Harbor 공식 문서는 다른 Harbor를 연결하는 예제로 HTTPS 주소를 제시합니다. 연결 대상 Registry는 Endpoint 생성 시점에 실제로 존재하고 실행 중이어야 합니다. Harbor

---

 

3.12 Verify Remote Cert는 무엇인가?

이 옵션도 나중에 온프레미스에서 중요합니다.

DR Harbor
    │
    │ HTTPS
    ▼
PROD Harbor
    │
    └─ TLS Certificate

DR Harbor가 PROD Harbor에 접속하면서:

"이 서버 인증서를 믿어도 되는가?"

를 검증합니다.

공식 문서에는 Verify Remote Cert 옵션이 있으며, 원격 Registry가 self-signed 또는 신뢰되지 않는 인증서를 사용하는 경우 체크를 해제할 수 있다고 되어 있습니다. Harbor

하지만 실제 운영에서는 단순히 검증을 끄기보다는:

사내 CA
     │
     ▼
PROD Harbor 인증서
     │
     ▼
DR 환경에서 CA Trust

처럼 정상적인 인증서 신뢰체계를 구성하는 방향을 우선 권장합니다.

TLS/사설 CA 부분은 네트워크 단계에서 자세히 다루겠습니다.

---

 

3.13 Test Connection도 매우 중요하다

Endpoint 저장 전에:

Test Connection

을 할 수 있습니다. 공식 절차도 연결 테스트 성공 후 Endpoint를 저장하도록 안내합니다. Harbor

여기서 실패하면 보통 다음 계층을 확인합니다.

① DNS

harbor-prod.company.com
          ↓
IP 해석 가능?


② Network

DR → PROD
TCP 443 가능?


③ TLS

인증서 정상?


④ 인증

ID / Secret 정상?


⑤ Harbor

PROD Harbor 정상?

따라서 Endpoint Test는 단순 Harbor 설정 확인이 아니라:

DNS
+
Network
+
TLS
+
Authentication
+
Harbor

를 한꺼번에 확인하는 첫 번째 관문이라고 생각하면 됩니다.

---

 

3.14 Replication Rule 실제 항목

Endpoint를 만들었다면 이제:

Administration
   ↓
Replications
   ↓
New Replication Rule

로 들어갑니다. Harbor 공식 문서에서도 System Administrator가 이 메뉴에서 새 Rule을 생성하도록 설명합니다. Harbor

우리 환경에서는 개념적으로:

Name
PROD-TO-DR-PULL

Replication Mode
Pull-Based

Source Registry
PROD-HARBOR

Source Resource Filter
app/**

Destination Namespace
필요에 따라 지정

Destination Flattening
No Flattening

Trigger Mode
Scheduled

정도로 구성하게 됩니다.

---

 

3.15 왜 Source Registry에 PROD-HARBOR가 나오는가?

중요합니다.

우리는 DR Harbor에서 Rule을 만들고 있습니다.

DR Harbor

그리고 Mode는:

Pull-Based

입니다.

따라서 DR 기준으로:

내가 가져올 상대방
       =
Source
       =
PROD Harbor

입니다.

그래서:

Source Registry
      ↓
PROD-HARBOR Endpoint

을 선택합니다.

공식 문서에서도 Pull-Based Rule을 만들면 Source Registry 드롭다운에서 구성된 Replication Endpoint를 선택하도록 합니다. Harbor

---

 

3.16 Push 방식이라면 반대다

Push에서는 Rule을 일반적으로 보내는 쪽에서 실행합니다.

PROD Harbor
      │
      │ PUSH
      ▼
DR Harbor

즉 PROD 기준:

내가 Artifact를 보낼 상대방
       =
Destination
       =
DR Harbor

따라서 Push Rule에서는 원격 Endpoint를 Destination Registry로 선택합니다. Harbor 공식 문서도 Push-Based Rule에서 Destination Registry를 Endpoint 목록에서 선택하도록 정의합니다. Harbor

그래서 비교하면:

방식Rule 실행 관점Endpoint가 나타나는 위치

Push	PROD → DR	Destination Registry
Pull	DR ← PROD	Source Registry

우리 DR 설계는 아래쪽입니다.

---

 

3.17 이것만 기억하면 Push/Pull이 안 헷갈린다 ⭐

          PUSH

PROD ───────────────▶ DR
 ↑                     ↑
Source              Destination

Rule: PROD 쪽
Endpoint: DR


          PULL

PROD ───────────────▶ DR
 ↑                     ↑
Source              Destination

                        ↑
                     Rule: DR
                     Endpoint: PROD

데이터가 이동하는 결과는 둘 다:

PROD
 │
 │ Artifact
 ▼
DR

입니다.

차이는:

누가 복제를 시작하느냐

입니다.

---

 

3.18 Source Resource Filter란?

모든 이미지를 가져올 필요가 없을 수도 있습니다.

예를 들어 PROD Harbor에:

app/web:v1

app/api:v5

ai/model:v10

test/test:v1

dev/dev:v2

가 있는데 DR에는 운영용 app만 필요하다고 합시다.

그러면 Filter를 사용할 수 있습니다.

app/**

개념적으로:

PROD

app/web:v1       ───▶ DR ✅
app/api:v5       ───▶ DR ✅

ai/model:v10           ❌
test/test:v1           ❌
dev/dev:v2             ❌

Harbor는 Name, Tag, Label 및 Resource 종류를 기준으로 Source Resource Filter를 구성할 수 있으며 *, **, ?, {a,b} 같은 Pattern도 지원합니다. **는 /가 포함된 하위 경로까지 매칭할 수 있습니다. Harbor

---

 

3.19 Resource Filter의 Image / Artifact / All

Harbor Rule에는 Resource 종류도 있습니다.

공식 문서는 다음과 같이 구분합니다. Harbor

Images

Artifacts

All

여기서 Artifact는 일반 Container Image만 의미하는 것보다 넓은 개념입니다.

예를 들어:

OCI Artifact
Container Image
관련 OCI Resource

등을 다루게 됩니다.

DR센터에서 Harbor의 Registry 내용 전체를 보호하려는 목적이라면 실제 사용하는 Artifact 유형을 확인한 뒤 필요한 범위를 포함하도록 Rule을 설계해야 합니다.

---

 

3.20 Destination Namespace는 무엇인가?

예를 들어 PROD에:

app/web:v1

가 있다고 합시다.

DR에서도 동일하게:

app/web:v1

로 유지하고 싶을 수 있습니다.

Harbor에서는 Destination Namespace를 지정하지 않으면 Source와 동일한 Namespace에 Resource를 배치할 수 있습니다. Harbor

DR에서는 보통 원본 Repository 경로를 가능한 한 유지하는 것이 운영상 편합니다.

왜냐하면 Kubernetes가:

image: harbor.company.com/app/web:v1

같은 형태로 사용하고 있기 때문입니다.

DR 전환 후에도:

app/web:v1

경로가 그대로라면 DNS/VIP 등의 접속점만 바꾸는 방식으로 설계하기가 훨씬 쉬워집니다.

---

 

3.21 여기서 Destination Flattening을 꼭 주의하자 ⭐⭐⭐

Harbor에는 Destination Flattening이라는 설정이 있습니다.

예를 들어 Source가:

company/prod/app/web

라고 해봅시다.

No Flattening이면 계층을 유지합니다.

company/prod/app/web

반면 Flattening을 적용하면 앞쪽 경로 일부를 제거할 수 있습니다. 현재 공식 문서는 Flatten All Levels, No Flattening, Flattening 1/2/3 level을 제공하며 현재 기본 선택값은 Flattening 1 level이라고 설명합니다. Harbor

따라서 DR에서 경로를 그대로 유지하려는 경우:

No Flattening 여부를 반드시 검토해야 합니다.

이것은 꽤 중요한 실무 포인트입니다.

설정을 무심코 기본값으로 두면 Repository 경로가 기대와 달라질 수 있기 때문입니다.

---

 

3.22 Trigger Mode는 언제 복제할지 결정한다

Rule을 만들어도:

“언제 실행할 것인가?”

가 필요합니다.

Harbor는 현재 공식 문서 기준으로:

Manual
Scheduled
Event Based

Trigger Mode를 제공합니다. Harbor

Manual

관리자가 Replicate 클릭
        ↓
복제

Scheduled

정해진 Cron 시간
        ↓
Replication

Event Based

Artifact Push 등의 이벤트
        ↓
Replication

우리 DR 설계에서는:

Pull-Based
+
Scheduled

방식을 중심으로 공부하겠습니다.

---

 

3.23 Scheduled 방식의 아주 중요한 제약 ⚠️

이건 DR 설계에서 반드시 기억해 두세요.

Harbor 공식 문서에 따르면:

Manual과 Scheduled Replication에서는 삭제 작업이 복제되지 않습니다. Harbor

예를 들어:

처음

PROD                   DR

web:v1                 web:v1
web:v2                 web:v2

그리고 PROD에서:

web:v1 삭제

했다고 해서 다음 Scheduled Pull 시 무조건:

DR web:v1 자동 삭제

된다고 생각하면 안 됩니다.

즉:

PROD 삭제

     ≠

Scheduled Replication을 통한
DR 자동 삭제

입니다.

이 특성은 DR에서는 오히려 삭제 사고가 그대로 DR에 전파되지 않도록 하는 장점으로 활용할 수도 있지만, 반대로 PROD와 DR을 완전히 동일하게 유지하려면 별도의 운영정책이 필요합니다.

나중에 DR 설계 단계에서 다시 중요하게 다루겠습니다.

---

 

3.24 실제 네트워크 방향도 이해하자

우리 구조가 Pull이므로:

DR
 │
 │ Connection Start
 ▼
PROD

입니다.

실제 개념은:

┌──────── DR센터 ────────┐

DR Harbor
     │
     │ Pull
     │
     └─────────────────────────┐
                               │
══════════ Firewall ═══════════╪════
                               │
                               ▼
                       PROD Harbor

                    └── 운영 ──┘

일반적인 HTTPS Harbor Endpoint라면 결국 DR 환경에서 PROD Harbor Endpoint로 통신할 수 있어야 합니다. 공식 Endpoint 구성도 원격 Registry의 전체 URL을 등록하고 연결 테스트를 수행하도록 되어 있습니다. Harbor

따라서 앞으로 네트워크 설계에서는 주로:

DR → PROD

DNS
HTTPS/TCP 443
TLS
Routing
Firewall

를 확인하게 됩니다.

---

 

3.25 K8s에서는 Endpoint가 Pod IP인가?

보통 그렇게 설계하지 않습니다.

예를 들어:

PROD Registry Pod IP

10.244.3.21

를 DR Harbor Endpoint로 잡는 식은 피합니다.

Pod IP는 K8s 내부 구현 주소이므로, 서로 독립된 두 Cluster 사이의 DR 연결점으로는 일반적으로 Harbor의 안정적인 서비스 접점을 사용합니다.

예:

DR Harbor
     │
     │
     ▼
harbor-prod.company.com
     │
     ▼
DNS
     │
     ▼
VIP / Load Balancer
     │
     ▼
Ingress
     │
     ▼
Harbor Service
     │
     ▼
Harbor Pod

즉 Endpoint 관점에서는:

https://harbor-prod.company.com

처럼 DR센터에서 안정적으로 접근 가능한 Harbor 주소를 사용하는 방향으로 설계합니다.

이 DNS/VIP/Ingress/F5 흐름은 뒤 네트워크 단계에서 상세하게 설명하겠습니다.

---

 

3.26 전체 Replication 동작을 한 번 연결해 보자 ⭐⭐⭐

설정이 모두 끝났다고 가정해 보겠습니다.

DR Harbor:

Endpoint
└─ PROD-HARBOR
     └─ https://harbor-prod.company.com

그리고:

Replication Rule

Name     : PROD-TO-DR
Mode     : Pull-Based
Source   : PROD-HARBOR
Filter   : app/**
Trigger  : Scheduled

가 있습니다.

그러면:

              [DR Harbor]

                  │
          Scheduled Trigger
                  │
                  ▼
          Replication 실행
                  │
                  ▼
         PROD-HARBOR Endpoint
                  │
                  │ HTTPS
                  ▼
════════════════ Firewall ════════════════
                  │
                  ▼
             [PROD Harbor]
                  │
                  ▼
             app/** 검색
                  │
                  ▼
       ┌────────────────────┐
       │ app/web:v1         │
       │ app/web:v2         │
       │ app/api:v5         │
       └─────────┬──────────┘
                 │
                 │ Pull
                 ▼
             [DR Harbor]
                 │
                 ▼
            DR Registry
                 │
                 ▼
            DR Storage

완료 후에는 Harbor UI에서 Rule의 Execution 상태와 개별 Task, 로그 등을 확인할 수 있습니다. 공식 문서도 Rule을 선택해 Execution Status와 Task List, 상세 Task Log를 확인할 수 있도록 제공합니다. Harbor

---

 

3.27 예제로 한 번 더 이해해 보자

PROD에 현재:

app/web:v1
app/web:v2
app/api:v4
app/api:v5

가 있습니다.

DR에는:

app/web:v1
app/api:v4

만 있습니다.

Replication이 실행됩니다.

DR
 │
 │ PROD 확인
 ▼

PROD
 │
 ├─ web:v1
 ├─ web:v2  ← DR에 없음
 ├─ api:v4
 └─ api:v5  ← DR에 없음

필요한 Artifact가 전달됩니다.

PROD                    DR

web:v2 ───────────────▶ web:v2

api:v5 ───────────────▶ api:v5

결과:

PROD                    DR

web:v1                  web:v1
web:v2                  web:v2

api:v4                  api:v4
api:v5                  api:v5

이것이 우리가 원하는 Artifact DR 동기화의 기본 원리입니다.

---

 

3.28 Source / Destination / Endpoint / Rule 관계 최종 그림

이 그림 하나를 기억하세요.

┌────────────────────────────────────┐
│           PROD Harbor              │
│                                    │
│          SOURCE Registry           │
│                                    │
│  app/web:v1                        │
│  app/web:v2                        │
│  app/api:v5                        │
└────────────────▲───────────────────┘
                 │
                 │ HTTPS 443
                 │
                 │ PULL
                 │
═════════════════╪════ Firewall ═══════════════
                 │
                 │
┌────────────────┴───────────────────┐
│            DR Harbor               │
│                                    │
│        DESTINATION Registry        │
│                                    │
│ ┌───────────────────────────────┐  │
│ │ Endpoint                      │  │
│ │                               │  │
│ │ PROD-HARBOR                   │  │
│ │ https://harbor-prod...        │  │
│ └───────────────────────────────┘  │
│                 │                  │
│                 ▼                  │
│ ┌───────────────────────────────┐  │
│ │ Replication Rule              │  │
│ │                               │  │
│ │ Mode   : Pull                 │  │
│ │ Source : PROD-HARBOR          │  │
│ │ Filter : app/**               │  │
│ │ Trigger: Scheduled            │  │
│ └───────────────────────────────┘  │
│                                    │
└────────────────────────────────────┘

---

 

3.29 이번 단계 핵심 5가지 ⭐

① Source

Artifact가 원래 있는 곳

PROD Harbor

② Destination

Artifact를 복제해 둘 곳

DR Harbor

③ Endpoint

상대 Registry 접속정보

URL
+
인증정보
+
TLS 설정

Endpoint는 Replication보다 먼저 만들어야 합니다. Harbor

④ Replication Rule

무엇을
+
어떤 방향으로
+
언제
+
어디로

복제할지 정의한 정책

⑤ 우리 DR 구조

가장 중요한 부분입니다.

                PROD Harbor
                    ▲
                    │
                 PULL
                    │
                    │
                DR Harbor
                    │
          ┌─────────┴──────────┐
          │                    │
       Endpoint               Rule
          │                    │
          │                    ├─ Pull
          │                    ├─ Source Filter
          │                    ├─ Scheduled
          ▼                    └─ No Flattening 검토
     PROD Harbor

즉 한 문장으로 정리하면:

DR Harbor에 PROD Harbor를 Endpoint로 등록하고, DR Harbor에 Pull-Based Replication Rule을 만들어 PROD의 Artifact를 주기적으로 가져오는 구조입니다.

---

 

➡️ 다음 4단계: Push vs Pull + 실제 네트워크 흐름

다음 단계에서는 이제 아주 중요한 네트워크 관점으로 넘어가면 좋습니다.

특히 다음 질문을 연결해서 설명하겠습니다.

① Push와 Pull은 정확히 뭐가 다른가?

② 왜 DR에서는 Pull을 선택할 수 있는가?

③ 실제 TCP 연결은 누가 시작하는가?

④ 방화벽은
   PROD → DR을 열어야 하나?
   DR → PROD를 열어야 하나?

⑤ Jobservice / Ingress / Service는
   어떤 경로로 연결되는가?

⑥ F5 / VIP가 있다면
   Replication Traffic은 어디를 통과하는가?

⑦ PROD 전체 장애가 나면
   Pull Replication은 어떻게 되는가?

⑧ Scheduled Pull의 RPO는
   어떻게 계산해야 하는가?

그리고 4단계에서는 아래처럼 K8s + F5/VIP + Ingress + Harbor Service까지 포함한 실제 패킷 흐름으로 설명하면 지금까지 배운 내용이 네트워크 구성과 연결됩니다.

DR Jobservice
     │
     ▼
DR Node
     │
     ▼
Firewall
     │
     ▼
PROD VIP / F5
     │
     ▼
Ingress Controller
     │
     ▼
Harbor Service
     │
     ▼
Registry / Core

여기까지 이해하면 Harbor Native Replication의 핵심 구조는 거의 잡힌 상태입니다.