이제 3단계 — Push Replication vs Pull Replication으로 넘어가겠습니다.
이번 단계에서는 특히 운영센터 ↔ DR센터, 방화벽, 443 포트, 누가 접속을 시작하는지 중심으로 이해하면 됩니다.
📘 Harbor Native Replication 3단계
Push vs Pull + 방화벽/네트워크 관점
Harbor 공식 문서 기준으로 Replication Rule을 만들 때 Push-based 또는 Pull-based를 선택할 수 있습니다. Push는 원격 Registry로 보내는 방식이고, Pull은 원격 Registry에서 가져오는 방식입니다.
1. 가장 중요한 차이 한 줄
먼저 이것부터 기억하면 됩니다.
Push
= Source가 Destination으로 접속한다.
Pull
= Destination이 Source로 접속한다.즉 이미지가 어느 방향으로 이동하느냐보다, 누가 네트워크 연결을 시작하느냐가 중요합니다.
2. 📤 Push Replication
운영 Harbor A에 Image가 있고 DR Harbor B로 보내는 상황입니다.
운영센터 DR센터
Harbor A Harbor B
Source Destination
│
│ HTTPS 연결 시작
│ TCP 443
├───────────────────────────→
│
│ Image Push
├───────────────────────────→
│
▼즉:
Harbor A가 Harbor B에게 접속해서 이미지를 밀어 넣습니다.
3. Push를 택배로 비유하면
서울 창고가 부산 창고에 직접 택배를 보냅니다.
서울 창고
│
│ 택배 발송
↓
부산 창고Harbor에서는:
Harbor PROD
│
│ PUSH
↓
Harbor DR입니다.
4. Push에서 Replication Rule은 어디에 만드나?
보통 Source인 Harbor A에 만듭니다.
Harbor A 관리화면
Administration
↓
Registries
↓
Harbor B Endpoint 등록
그리고
Replications
↓
New Replication Rule
↓
Push-based개념적으로:
Harbor A
Endpoint:
harbor-dr
Replication Rule:
prod-to-dr
Mode:
Push
Destination:
harbor-dr입니다.
Push Rule에서는 원격 Registry가 Destination Registry가 됩니다.
5. 🔥 Push에서 방화벽은 어떻게 열어야 하나?
이 부분이 핵심입니다.
환경을 이렇게 가정해 보겠습니다.
[운영센터]
10.10.0.0/16
Harbor A
10.10.10.100
│
Firewall
│
[DR센터]
10.20.0.0/16
Harbor B
10.20.10.100Push 방식에서는 Harbor A가 Harbor B로 접속합니다.
따라서 기본적인 네트워크 요구는:
Source
Harbor A
↓
Destination
Harbor B : TCP 443입니다.
방화벽 관점:
ALLOW
Source IP:
Harbor A 측 주소
Destination IP:
Harbor B / LB / VIP 주소
Destination Port:
TCP 443입니다.
Harbor 공식 Endpoint 예시도 HTTPS Registry 주소를 https://...:443 형태로 등록하도록 설명합니다.
6. 중요한 포인트 — Pod IP를 방화벽에 넣는가?
대부분 아닙니다.
예를 들어 Harbor가 Kubernetes 안에 있다고 해보겠습니다.
K8s Cluster A
harbor-jobservice Pod
10.244.1.25
harbor-core Pod
10.244.2.17Pod IP는 변경될 수 있습니다.
그래서 보통 방화벽에:
10.244.1.25 → DR Harbor처럼 특정 Pod IP를 넣는 것은 좋은 설계가 아닙니다.
실제 네트워크에서는 환경에 따라:
Pod
↓
Node
↓
SNAT
↓
Firewall
↓
DR Harbor VIP/LB형태가 될 수 있습니다.
따라서 방화벽 팀에는 보통:
“Harbor Pod가 외부로 나갈 때 실제 Source IP가 무엇으로 보이는가?”
를 확인해야 합니다.
예:
Harbor JobService Pod
10.244.1.25
↓ SNAT
Worker Node
10.10.10.31
↓
Firewall에서 보이는 Source
10.10.10.31일 수도 있습니다.
7. Kubernetes에서는 이 부분이 특히 중요합니다
Push Replication을 실제로 수행하는 Harbor 컴포넌트 관점에서는 JobService가 Replication Job을 처리합니다.
개념적으로:
Harbor A
Core
│
│ Replication Rule
↓
JobService Pod
│
│ HTTPS
↓
K8s Network
│
↓
Node / NAT
│
↓
Firewall
│
↓
Harbor B LB / Ingress
│
↓
Registry그래서 네트워크 장애가 있으면 Replication이 실패할 수 있습니다.
Harbor 문서도 네트워크 상태에 따라 Replication 지연이 발생할 수 있고 실패한 Task를 재시도한다고 설명합니다.
8. Push 전체 구조
이 그림을 기억하면 됩니다.
┌─────────────────────────┐
│ 운영센터 K8s │
│ │
│ Harbor A │
│ │
│ Core │
│ │ │
│ ↓ │
│ JobService │
│ │ │
└─────┼───────────────────┘
│
│ HTTPS TCP 443
│
│ PUSH →
▼
=============================
Firewall
=============================
│
▼
┌─────────────────────────┐
│ DR센터 K8s │
│ │
│ LB / Ingress │
│ │ │
│ ↓ │
│ Harbor B │
│ │ │
│ Registry │
│ │ │
│ ↓ │
│ Storage │
└─────────────────────────┘9. 📥 Pull Replication
이번에는 반대입니다.
DR Harbor B가 운영 Harbor A의 이미지를 가져옵니다.
운영센터 DR센터
Harbor A Harbor B
Source Destination
↑ │
│ │
│ HTTPS 연결 │
│ TCP 443 │
└───────────────────────────┤
│
Pull 시작즉:
DR Harbor B가 운영 Harbor A로 접속해서 이미지를 가져옵니다.
10. Pull을 택배로 비유하면
Push가:
서울에서 부산으로 보내기라면 Pull은:
부산에서 서울 창고로 가서
물건을 가져오기입니다.
서울 창고
↑
│ 가져감
│
부산 창고Harbor에서는:
Harbor PROD
↑
│ PULL
│
Harbor DR입니다.
11. Pull Rule은 어디에 만드나?
보통 이미지를 가져올 Harbor, 즉 Harbor B에 만듭니다.
Harbor B
Endpoint:
harbor-prod
Replication Rule:
prod-pull
Mode:
Pull
Source Registry:
harbor-prodHarbor 공식 문서에서도 Pull-based Rule에서는 설정된 Endpoint 중에서 Source Registry를 선택하도록 되어 있습니다.
12. 🔥 Pull에서는 방화벽 방향이 반대입니다
Pull에서는:
Harbor B
DR센터
↓ TCP 443
Harbor A
운영센터가 됩니다.
따라서:
ALLOW
Source:
DR Harbor 측 네트워크
Destination:
운영 Harbor LB/VIP
Port:
TCP 443입니다.
Push와 비교하면 정확히 반대입니다.
13. Push vs Pull 방화벽 비교
여기가 오늘 가장 중요한 표입니다.
| 데이터 원본 | Harbor A | Harbor A |
| 최종 저장 | Harbor B | Harbor B |
| 연결 시작 | Harbor A | Harbor B |
| 네트워크 방향 | A → B | B → A |
| Endpoint 위치 | 보통 A | 보통 B |
| Rule 생성 위치 | 보통 A | 보통 B |
| Remote Registry | Destination | Source |
| 대표 목적 | 원본이 DR로 보냄 | DR이 원본에서 가져옴 |
14. 여기서 재미있는 점
결과는 똑같을 수 있습니다.
Push 결과:
Harbor A
project01/app:v1
↓
Harbor B
project01/app:v1Pull 결과:
Harbor A
project01/app:v1
↓
Harbor B
project01/app:v1최종 결과만 보면 똑같습니다.
하지만 네트워크는:
Push
A ─────────→ B이고
Pull
A ←───────── B입니다.
이 차이가 중요합니다.
15. 왜 Pull 방식이 필요한가?
여기서 이런 의문이 생깁니다.
"그냥 Push만 쓰면 되는 거 아니야?"
그렇지 않습니다.
보안 정책 때문입니다.
예를 들어 운영센터가 아주 중요한 환경이라고 해보겠습니다.
운영센터
Production
보안등급 높음보안 정책상:
DR센터에서 운영센터로 들어오는 연결은 금지
일 수 있습니다.
그런 환경에서는:
DR → PROD가 막혀있습니다.
하지만:
PROD → DR는 허용할 수 있습니다.
그렇다면:
Push 방식
이 적합할 수 있습니다.
16. 반대 상황도 있습니다
어떤 회사에서는 운영센터에서 DR센터로 Outbound 연결을 거의 허용하지 않을 수도 있습니다.
PROD → DR
X 차단대신 DR 쪽에서 운영 Registry를 읽어오는 것은 허용한다고 해봅시다.
DR → PROD
O 허용그러면:
Pull 방식
을 선택할 수 있습니다.
17. DMZ가 있으면 더 중요합니다
실제 기업 네트워크에서는 이런 구조가 있을 수 있습니다.
Production Zone
│
Firewall A
│
DMZ
│
Firewall B
│
DR Zone이 경우 Push라면:
PROD
│
│ Outbound
↓
Firewall A
↓
DMZ
↓
Firewall B
↓
DR Harbor : 443경로가 허용되어야 합니다.
Pull이라면:
DR
│
│ Outbound
↓
Firewall B
↓
DMZ
↓
Firewall A
↓
PROD Harbor : 443경로가 허용되어야 합니다.
그래서 Replication 방식 결정 전에 네트워크 담당자와 반드시 확인해야 합니다.
18. 네트워크팀에는 어떻게 요청하면 될까?
예를 들어 Push를 사용할 경우:
목적:
Harbor Native Replication
Source:
운영 Harbor/Kubernetes Egress IP
10.10.10.30/32
Destination:
DR Harbor VIP
10.20.10.100
Protocol:
TCP
Port:
443
Direction:
PROD → DR이런 식으로 정리할 수 있습니다.
Pull이라면:
목적:
Harbor Native Replication
Source:
DR Harbor/Kubernetes Egress IP
10.20.10.30/32
Destination:
PROD Harbor VIP
10.10.10.100
Protocol:
TCP
Port:
443
Direction:
DR → PROD가 됩니다.
19. 🔐 인증도 같이 생각해야 합니다
방화벽이 열렸다고 Replication이 되는 것은 아닙니다.
Harbor B가 인증을 요구하기 때문입니다.
Push라면:
Harbor A
│
│ ① TCP 443 접속
│
│ ② TLS 인증
│
│ ③ ID/Secret 인증
│
│ ④ 권한 확인
↓
Harbor BEndpoint에는 원격 Registry에 접근할 Access ID / Access Secret과 적절한 권한이 필요합니다. Harbor 공식 문서도 Endpoint 등록 시 원격 Registry에 필요한 권한을 가진 계정을 사용하도록 안내합니다.
20. TLS 인증서도 중요합니다
Endpoint:
https://harbor-dr.company.com를 등록하면 Harbor A는 Harbor B의 인증서를 확인합니다.
Harbor A
│
│ HTTPS
↓
Harbor B
Certificate
↓
정상인가?정상적인 공인/사내 신뢰 CA라면 문제가 없습니다.
하지만 Self-Signed 인증서를 사용하면 Certificate Trust 문제가 발생할 수 있습니다.
Harbor Endpoint 설정에는 원격 인증서를 검증하는 Verify Remote Cert 옵션도 있습니다.
운영환경에서는 검증을 무작정 끄기보다는:
사내 CA
↓
Harbor 인증서 발급
↓
각 Harbor에서 CA 신뢰방식이 더 바람직합니다.
21. DNS도 확인해야 합니다
Endpoint가:
https://harbor-dr.company.com이라면 Harbor A에서 이 이름이 해석되어야 합니다.
즉:
Harbor JobService Pod
↓
DNS Query
↓
harbor-dr.company.com
↓
10.20.10.100가 되어야 합니다.
방화벽만 열어놓고 DNS가 안 되면:
Connection 실패할 수 있습니다.
22. 따라서 네트워크 점검은 4단계로 생각하면 쉽습니다
Replication이 안 될 때는:
① DNS
harbor-dr.company.com
↓
IP 해석되는가?② TCP 연결
Harbor A
↓
Harbor B:443
접속 가능한가?③ TLS
Certificate
정상인가?④ Authentication
Robot Account
ID / Secret
권한
정상인가?입니다.
즉:
DNS
↓
Network
↓
TLS
↓
Authentication
↓
Replication순서입니다.
23. Test Connection이 중요한 이유
Endpoint를 등록할 때 Harbor에서:
Test Connection을 할 수 있습니다.
이 버튼이 상당히 중요합니다.
왜냐하면:
URL
↓
DNS
↓
Network
↓
TLS
↓
ID / Password등 원격 Registry 연결 여부를 빠르게 확인할 수 있기 때문입니다.
따라서 실제 구축에서는:
Endpoint 등록
↓
Test Connection
↓
Success 확인
↓
Replication Rule 생성순서로 진행하는 것이 좋습니다.
24. Kubernetes까지 포함한 Push 구조
우리가 실제로 구축한다고 생각하고 전체 그림을 그려보겠습니다.
[운영센터]
Kubernetes Cluster A
┌────────────────────────────┐
│ │
│ Harbor Core │
│ │ │
│ ↓ │
│ Harbor JobService │
│ │ │
└───────┼────────────────────┘
│
│
SNAT
│
↓
Egress / Node IP
│
│ TCP 443
↓
===============================
Firewall
===============================
│
↓
DR Harbor VIP
│
↓
LoadBalancer / Ingress
│
↓
Harbor Registry
│
↓
PVC / Storage
[DR센터]이것이 Push Replication의 실제 네트워크 흐름이라고 생각하면 됩니다.
25. Pull 구조는 반대입니다
[DR센터]
Kubernetes Cluster B
┌────────────────────────────┐
│ │
│ Harbor Core │
│ │ │
│ ↓ │
│ Harbor JobService │
│ │ │
└───────┼────────────────────┘
│
│
SNAT
│
↓
Egress / Node IP
│
│ TCP 443
↓
===============================
Firewall
===============================
│
↓
운영 Harbor VIP / LB
│
↓
Harbor Registry
[운영센터]26. 그런데 Replication 데이터는 443 하나만 보면 될까?
Harbor Endpoint를 HTTPS로 제공하고 외부 접근도 HTTPS로 통일했다면 Registry 간 외부 통신은 일반적으로 HTTPS 443을 중심으로 설계합니다.
다만 실제 구축에서는:
Harbor
↓
Ingress
↓
LB
↓
Firewall구조와 회사 내부 포트 매핑에 따라 달라질 수 있습니다.
예를 들어:
443
↓
LoadBalancer
↓
8443
↓
Ingress같은 구조가 있을 수도 있습니다.
그래서 방화벽 설계에서는 항상:
“상대 Harbor Endpoint URL에 실제로 접근하는 Port”
를 기준으로 확인해야 합니다.
27. 운영 → DR이면 Push가 더 좋은가?
무조건 그렇다고 할 수는 없습니다.
하지만 매우 흔하게 생각할 수 있는 구조는:
Production
│
│ Push
↓
DR입니다.
왜냐하면 운영 Harbor에서 Image가 생성되는 즉시 DR로 보내는 구조가 직관적이기 때문입니다.
예를 들어 Event Based Replication과 조합하면:
CI/CD
↓ Push
Harbor PROD
↓ Event
Replication Job
↓ Push
Harbor DR이 됩니다.
28. 제가 먼저 검토할 구조
운영 → DR Container Image 동기화가 목적이라면 저는 먼저:
PROD Harbor
│
│ Push Replication
│ Event Based
↓
DR Harbor구조가 가능한지 검토하겠습니다.
그리고 네트워크:
PROD Harbor Egress
↓ TCP 443
DR Harbor VIP를 확인합니다.
다만 회사의 망분리·보안정책에서:
PROD → DR
금지라면 Pull 방식으로 검토해야 합니다.
29. ⚠️ 아주 중요한 점: Replication은 동기식 미러링이 아닙니다
Push 방식이라도:
Harbor A 저장
동시에
Harbor B 저장처럼 DB 동기복제 수준으로 동작한다고 생각하면 안 됩니다.
실제 흐름은:
Harbor A Image Push 완료
↓
Replication Event
↓
Job 생성
↓
Network 전송
↓
Harbor B 저장
↓
Replication Success입니다.
따라서 잠깐 동안:
Harbor A : v10 존재
Harbor B : 아직 v9일 수 있습니다.
Harbor 공식 문서도 네트워크 상황에 따라 Replication에 지연이 발생할 수 있다고 설명합니다.
30. 대용량 Image에서는 네트워크가 더 중요합니다
예를 들어 AI/GPU 환경이라면 Container Image가:
5 GB
10 GB
20 GB
30 GB이상일 수도 있습니다.
특히 CUDA/PyTorch Image는 매우 큽니다.
그러면:
Harbor A
│
│ 20GB Image
↓
WAN
↓
Harbor B가 됩니다.
그래서:
- WAN 대역폭
- Latency
- Firewall Session
- Proxy Timeout
- LB Timeout
- Storage IOPS
- Registry 성능
등도 Replication 시간에 영향을 줄 수 있습니다.
31. ⭐ Push / Pull을 판단하는 가장 쉬운 질문
네트워크 담당자에게 이것만 물어보면 됩니다.
질문 1
운영센터에서 DR센터 Harbor HTTPS 443으로 접속할 수 있나요?
YES라면:
Push 가능질문 2
DR센터에서 운영센터 Harbor HTTPS 443으로 접속할 수 있나요?
YES라면:
Pull 가능입니다.
32. 최종 비교
| 의미 | 내가 보냄 | 내가 가져옴 |
| Rule 생성 | Source Harbor | Destination Harbor |
| Remote Endpoint | Destination | Source |
| 연결 시작 | Source | Destination |
| 데이터 결과 | Source → Destination | Source → Destination |
| TCP 연결 | PROD → DR | DR → PROD |
| 주요 Port | 보통 HTTPS 443 | 보통 HTTPS 443 |
| 방화벽 | PROD Outbound 허용 | DR Outbound 허용 |
| Event 기반 DR | 직관적 | 정책에 따라 가능 |
| 네트워크 정책 영향 | 큼 | 큼 |
🎯 3단계 핵심 그림
이 두 줄만 기억해도 됩니다.
PUSH
PROD Harbor ──────── 443 ────────→ DR Harbor
"내가 보내겠다"PULL
PROD Harbor ←─────── 443 ───────── DR Harbor
"내가 가져오겠다"그런데 Image 데이터의 최종 방향은 둘 다:
PROD
↓
DR입니다.
차이는:
누가 HTTPS 연결을 시작하느냐
입니다.
📌 그리고 Kubernetes 환경에서는 한 단계 더 기억
Harbor Pod IP
≠ 반드시 Firewall에 보이는 IP실제로는:
Harbor JobService Pod
↓
Kubernetes Network
↓
Node / NAT / Egress
↓
Firewall일 수 있으므로 방화벽 신청 전에 실제 Egress Source IP를 확인하는 것이 중요합니다.
이 부분은 실제 구축 단계에서 상당히 중요합니다.
📚 다음 4단계
이제 개념은 충분히 잡혔습니다.
4단계에서는 실제로 Harbor A → Harbor B Push Replication을 구성하는 과정으로 넘어가는 것이 좋습니다.
예제를 이렇게 두고:
PROD
harbor-prod.company.com
↓ Push
DR
harbor-dr.company.com① DR Robot Account 생성 → ② Endpoint 등록 → ③ Test Connection → ④ Replication Rule 생성 → ⑤ Manual 테스트 → ⑥ Event Based 전환 → ⑦ 로그/Task 확인 → ⑧ 실제 docker push로 검증
댓글