이번에는 1.5단계 — Kubernetes에 Harbor를 설치하면 어떤 Pod들이 생기고, 각각 무슨 역할을 하는지를 설명하겠습니다. 😊
📘 Harbor 학습 1.5단계
Kubernetes 안의 Harbor Pod 구조 이해하기
먼저 가장 중요한 것부터 보겠습니다.
Harbor는 하나의 Pod로 동작하는 프로그램이 아닙니다.
Kubernetes에 Harbor를 설치하면 Harbor라는 하나의 서비스를 만들기 위해 여러 Pod가 역할을 나눠서 동작합니다.
대략 이렇게 생각하면 됩니다.
사용자 / Kubernetes / CI-CD
│
↓
harbor.company.com
│
Ingress / LB
│
↓
┌──────────────────┐
│ Harbor │
└──────────────────┘
│
┌─────────────────┼──────────────────┐
│ │ │
↓ ↓ ↓
harbor-core harbor-portal harbor-registry
│ │
│ ↓
│ Image 저장소
│
├──────────────┐
↓ ↓
PostgreSQL Redis
+
harbor-jobservice
harbor-trivy처음 보면 복잡하지만, 하나씩 보면 어렵지 않습니다.
1. 🧠 harbor-core — Harbor의 두뇌
가장 먼저 기억해야 할 Pod입니다.
harbor-core쉽게 말하면:
Harbor 전체를 관리하는 두뇌
입니다.
예를 들어 사용자가 Harbor 웹 화면에서:
- 로그인
- Project 생성
- Repository 조회
- 사용자 권한 확인
- Replication 설정
- Robot Account 관리
등을 하면 상당 부분을 Core가 처리합니다.
구조를 아주 단순하게 보면:
사용자
│
↓
Harbor UI
│
↓
harbor-core
│
├─ 사용자 인증 확인
├─ 프로젝트 확인
├─ 권한 확인
├─ Repository 정보 확인
└─ Replication 관리비유
회사를 하나 생각하면 됩니다.
Harbor = 회사
harbor-core = 본사 관리부서직접 창고에서 물건을 옮기지는 않지만,
"이 사용자가 이 프로젝트에 접근해도 되는가?"
같은 관리 업무를 담당합니다.
2. 🖥️ harbor-portal — 웹 화면
Harbor에 브라우저로 접속하면 이런 관리 화면을 사용합니다.
https://harbor.company.com그 화면을 담당하는 것이 주로:
harbor-portal입니다.
쉽게 말하면:
Harbor의 홈페이지
입니다.
사용자 Browser
│
↓
harbor-portal
│
↓
harbor-corePortal 자체가 이미지 데이터를 저장하는 것은 아닙니다.
사용자에게 화면을 보여주는 역할입니다.
비유
Portal = 은행 앱 화면
Core = 은행 업무 시스템이라고 생각하면 상당히 쉽습니다.
3. 📦 harbor-registry — 가장 중요한 이미지 창고
Harbor를 사용하는 가장 중요한 목적은 무엇일까요?
바로 Container Image 저장입니다.
nginx:1.25
myapp:v1
pytorch:2.7
cuda:13이런 이미지 데이터를 관리하는 핵심 컴포넌트가:
harbor-registry입니다.
쉽게 말하면:
Docker Image 창고
입니다.
예를 들어 개발자가:
docker push harbor.company.com/project01/myapp:v1을 수행하면 최종적으로 이미지 데이터를 Registry가 처리합니다.
개발자
│
│ docker push
↓
Harbor
│
↓
Registry
│
↓
Storage여기에서 Storage가 굉장히 중요합니다.
4. 💾 Registry와 PVC/PV
Registry Pod 안에 Image를 그냥 저장하면 안 됩니다.
왜냐하면 Pod는 언제든 삭제되고 다시 만들어질 수 있기 때문입니다.
예를 들어:
harbor-registry Pod
│
X Pod 장애Pod 내부에만 Image가 있었다면:
Image도 같이 사라짐 😱이런 문제가 생길 수 있습니다.
그래서 Registry 뒤에 Persistent Storage를 연결합니다.
harbor-registry
│
↓
PVC
│
↓
PV
│
↓
실제 Storage예:
NAS
Ceph
Block Storage
Object Storage
S3 호환 Storage등을 사용할 수 있습니다.
따라서 중요한 구조는:
Registry Pod
↓
PVC
↓
Storage
↓
Container Image입니다.
5. 🗄️ harbor-database — Harbor의 장부
Harbor에는 PostgreSQL Database가 필요합니다.
Helm 설치 방식이나 구성에 따라 내부 PostgreSQL을 사용할 수도 있고 외부 PostgreSQL을 사용할 수도 있습니다.
쉽게 말하면 Database에는:
사용자 정보
Project 정보
Repository 메타데이터
권한 정보
Replication Rule
Robot Account 정보
정책 정보같은 관리정보가 저장됩니다.
여기서 중요한 구분이 있습니다.
Container Image 실제 데이터
↓
Registry Storage
Harbor 관리정보
↓
PostgreSQL둘은 다른 데이터입니다.
예를 들어:
project01/myapp:v1이라는 이미지가 있다면,
PostgreSQL에는:
"project01이라는 프로젝트가 있다."
"myapp이라는 Repository가 있다."
"어떤 권한을 가지고 있다."같은 관리정보가 존재합니다.
실제 수 GB짜리 Container Image Layer를 PostgreSQL 안에 넣어 놓는 것이 아닙니다.
6. ⚡ harbor-redis — 임시 정보 처리
Redis도 Harbor 운영에 필요합니다.
harbor-redisRedis는 PostgreSQL과 성격이 다릅니다.
쉽게 표현하면:
PostgreSQL
= 장기 보관 장부
Redis
= 빠르게 사용하는 메모장Harbor에서는 Redis를:
- Cache
- Session
- Job 처리 상태
- 임시 데이터
등에 활용합니다.
구조를 간단히 보면:
harbor-core
│
┌────────┴────────┐
↓ ↓
PostgreSQL Redis
│ │
중요 관리정보 빠른 임시정보7. ⚙️ harbor-jobservice — 작업 담당자
우리가 배우고 있는 Native Replication과 특히 관계가 깊은 컴포넌트입니다.
이름 그대로:
Harbor의 백그라운드 작업 담당자
입니다.
예를 들어 Harbor에서 이런 작업이 발생할 수 있습니다.
Image Replication
Garbage Collection
Artifact 처리
일부 Scan 관련 작업이런 장시간 작업을 Core가 직접 다 처리하면 비효율적입니다.
그래서 JobService가 처리합니다.
예를 들어 우리가 나중에 설정할:
Harbor A
↓ Replication
Harbor B도 내부적으로 Job 형태의 작업이 발생합니다.
개념적으로:
Replication Rule
↓
harbor-core
↓
harbor-jobservice
↓
Remote Registry
↓
Harbor B라고 이해하면 됩니다.
아주 쉽게
Core
= 관리자
JobService
= 실제 작업을 수행하는 직원입니다.
8. 🔍 harbor-trivy — 보안 검사 담당
Harbor에는 Trivy를 붙여서 Container Image의 취약점을 검사할 수 있습니다.
예를 들어:
myapp:v1이라는 이미지 안에:
OpenSSL 취약점
Linux Package 취약점
Python Library 취약점등이 있는지 검사할 수 있습니다.
구조는 대략:
Container Image
│
↓
Trivy
│
↓
취약점 검사
│
↓
Critical : 2
High : 5
Medium : 10이런 식입니다.
즉:
harbor-trivy
= 보안 검사원 🕵️이라고 생각하면 됩니다.
9. registryctl은 뭐야?
Harbor를 보다 보면 다음 Pod/Container 이름도 볼 수 있습니다.
registryctlRegistry를 관리하는 Harbor 전용 관리 컴포넌트입니다.
쉽게 보면:
Registry
= 실제 창고
registryctl
= 창고 관리자정도로 이해하면 충분합니다.
초보 단계에서는 깊게 들어갈 필요는 없습니다.
10. 🚪 Ingress / LoadBalancer
Harbor Pod들이 아무리 잘 떠 있어도 외부에서 접근할 주소가 필요합니다.
예:
https://harbor.company.com그래서 Kubernetes에서는 보통:
사용자
│
↓
DNS
│
↓
Load Balancer
│
↓
Ingress
│
↓
Harbor Service
│
↓
Harbor Pods구조를 사용합니다.
예를 들어 개발자가:
docker login harbor.company.com하면 실제로는:
docker login
↓
harbor.company.com
↓
LoadBalancer
↓
Ingress
↓
Harbor순서로 들어옵니다.
11. 🔐 TLS 인증서도 중요합니다
실제 운영에서는 보통:
http://harbor.company.com보다는:
https://harbor.company.com을 사용합니다.
따라서 인증서도 필요합니다.
Client
│
│ HTTPS
↓
Ingress / LB
│
TLS Certificate
│
↓
Harbor특히:
docker login
docker push
docker pull을 안정적으로 사용하려면 TLS 구성도 매우 중요합니다.
12. Kubernetes 관점에서 전체 구조
지금까지 배운 것을 하나로 합쳐보겠습니다.
개발자 / Kubernetes
│
docker push / docker pull
│
↓
harbor.company.com
│
↓
LoadBalancer
│
↓
Ingress
│
↓
┌──────────────────┐
│ Harbor │
└──────────────────┘
│
┌────────────────┼─────────────────┐
│ │ │
↓ ↓ ↓
Portal Pod Core Pod Registry Pod
│ │
┌──────┼──────┐ │
↓ ↓ ↓ ↓
DB Redis JobService PVC
│ │
↓ ↓
Replication Storage
│
↓
Container Images
+
Trivy
│
↓
Image Scan이 그림을 이해하면 Harbor 구조의 절반 이상은 이해했다고 봐도 됩니다.
13. 실제 kubectl get pod에서는?
실제 Harbor Namespace를 조회하면 대략 이런 형태를 볼 수 있습니다.
kubectl get pods -n harbor예:
NAME READY
harbor-core-xxxxxxxxxx-xxxxx 1/1
harbor-database-0 1/1
harbor-jobservice-xxxxxxxxxx-xxxxx 1/1
harbor-portal-xxxxxxxxxx-xxxxx 1/1
harbor-redis-0 1/1
harbor-registry-xxxxxxxxxx-xxxxx 2/2
harbor-trivy-0 1/1여기서 Registry가:
2/2처럼 보이는 경우가 있습니다.
이것은:
Pod가 두 개라는 의미가 아니라 하나의 Pod 안에 Container가 2개 있다는 의미
입니다.
예를 들어:
harbor-registry Pod
├─ registry Container
│
└─ registryctl Container처럼 구성될 수 있습니다.
Kubernetes 초보 단계에서 아주 자주 혼동하는 부분입니다.
14. Pod가 죽으면 어떻게 되나?
예를 들어 Core Pod가 죽었다고 해보겠습니다.
harbor-core Pod
XDeployment로 구성되어 있다면 Kubernetes가 다시 만들어 줍니다.
Core Pod 장애
↓
Kubernetes 감지
↓
새 Core Pod 생성
↓
서비스 복구Registry도 비슷합니다.
하지만 Registry에서 중요한 것이 바로 Storage입니다.
Registry Pod 장애
↓
새 Registry Pod
↓
기존 PVC 연결
↓
Image 그대로 유지따라서:
Harbor에서 Pod 자체보다 데이터가 어디에 저장되는지가 더 중요합니다.
15. Harbor Replication과 연결해서 이해하기
이제 우리가 배우는 핵심 주제로 돌아가겠습니다.
운영센터에 Harbor가 있습니다.
[K8s Cluster A]
Harbor A
├─ Core
├─ Portal
├─ Registry
├─ JobService
├─ DB
├─ Redis
└─ TrivyDR센터에도 Harbor가 있습니다.
[K8s Cluster B]
Harbor B
├─ Core
├─ Portal
├─ Registry
├─ JobService
├─ DB
├─ Redis
└─ Trivy그리고 Replication을 설정합니다.
운영센터
Kubernetes Cluster A
Harbor A
│
│
│ Native Replication
↓
===================
Network
===================
↓
Harbor B
Kubernetes Cluster B
DR센터그런데 실제 복제의 관점에서는:
Harbor A Registry
↓
Harbor A JobService
↓
Network
↓
Harbor B Registry
↓
Harbor B Storage라고 이해하면 됩니다.
⭐ 초보자에게 가장 중요한 구분
이 부분은 꼭 기억해 두시면 좋습니다.
| Portal | 홈페이지 | 웹 UI |
| Core | 두뇌 | Harbor 전체 관리 |
| Registry | 창고 | Container Image 저장/전송 |
| JobService | 작업자 | Replication 등 백그라운드 Job |
| PostgreSQL | 장부 | 프로젝트·사용자·정책 등 관리정보 |
| Redis | 메모장 | Cache·Session·Job 상태 |
| Trivy | 보안검사원 | Image 취약점 검사 |
| PVC/PV | 창고 공간 | Image 등 영구 데이터 보관 |
| Ingress/LB | 출입구 | 외부 접속 |
🎯 여기서 특히 3개만 기억한다면
① Core = 두뇌
Harbor 전체 관리② Registry = 이미지 창고
Docker / OCI Image③ JobService = 작업자
Replication
Garbage Collection
기타 Background Job이 세 개를 먼저 기억하시면 됩니다.
특히 앞으로 배울 Native Replication에서는:
Core
↓
Replication Rule
JobService
↓
Replication 작업
Registry
↓
Image 송수신
Storage
↓
실제 Image 보관이 흐름이 핵심입니다.
📌 1.5단계 최종 그림
이 그림 하나만 기억하셔도 됩니다.
Harbor
│
┌───────────────┼────────────────┐
│ │ │
↓ ↓ ↓
Core Registry JobService
두뇌 창고 작업자
│ │ │
↓ ↓ ↓
PostgreSQL PVC/PV Replication
장부 │
│ ↓
↓ Storage
Redis │
메모장 ↓
Container Image그리고 한 문장으로 정리하면:
Kubernetes의 Harbor는 여러 Pod가 역할을 나눠서 동작하며, Core가 관리하고, Registry가 이미지를 보관·전송하고, JobService가 Replication 같은 백그라운드 작업을 수행합니다.
이 구조가 이해되면 이제 **2단계의 Source / Destination / Endpoint / Replication Rule**이 훨씬 쉽게 보입니다.
댓글