[Container] Harbor와 Kaniko는 왜 함께 사용할까? - 이미지는 만들고, 저장하고, 배포한다

TL;DR

컨테이너 이미지를 운영하는 과정은 크게 빌드(Build), 저장(Store), 배포(Deploy) 의 세 단계로 나뉜다.

Kaniko는 Docker 이미지를 생성하는 Builder이고,

Harbor는 생성된 이미지를 저장하는 Registry이다.

둘은 경쟁 관계가 아니라 서로 역할이 다른 프로젝트이며, 함께 사용할 때 가장 큰 효과를 얻을 수 있다.

 

ㅁ 들어가며

Docker를 처음 공부하면 자연스럽게 다음 명령어를 사용하게 된다.

docker build
docker push
docker pull

 

하지만 Kubernetes 환경에서는 이야기가 조금 달라진다.

빌드 서버에는 Docker Engine이 없을 수도 있고, 보안상 Docker Daemon을 실행하기 어려운 환경도 많다.

그렇다면 Docker 이미지는 어떻게 만들고 어디에 저장할까?

이 문제를 해결하기 위해 등장한 대표적인 오픈소스가 Kaniko와 Harbor이다.

 

 

ㅁ 컨테이너 이미지는 세 단계를 거친다

컨테이너 이미지는 다음과 같은 흐름으로 관리된다.

Source Code
      │
      ▼
Image Build
      │
      ▼
Image Registry
      │
      ▼
Kubernetes

각 단계는 서로 다른 책임을 가진다.

단계	역할
Build	Dockerfile을 이용하여 이미지 생성
Store	생성된 이미지를 저장 및 관리
Deploy	저장된 이미지를 실행

ㅁ Kaniko는 이미지를 만드는 역할

Kaniko는 Dockerfile을 읽어 Docker 이미지를 생성하는 Image Builder이다.

기존에는 Docker 이미지를 만들기 위해 Docker Daemon이 반드시 필요했다.

docker build

 

하지만 Kubernetes에서는 Docker Daemon을 실행하지 않는 환경이 많다.

Kaniko는 Docker Daemon 없이도 이미지를 생성할 수 있기 때문에 Kubernetes 환경에서 널리 사용된다.

 

Kaniko의 주요 역할

기능	설명
Dockerfile 실행	Dockerfile 기반 이미지 생성
Docker Daemon 불필요	별도의 Docker Engine 없이 빌드
Kubernetes 실행	Pod 내부에서 이미지 빌드 가능
CI/CD 연동	Jenkins, GitLab CI, Tekton 등과 연계

즉, Kaniko는 이미지를 만드는 것(Build) 에만 집중한다.

ㅁ Harbor는 이미지를 저장하는 역할

이미지가 만들어졌다면 저장할 공간이 필요하다.

Harbor는 Docker Hub를 직접 구축하는 것과 같은 Private Container Registry이다.

 

Harbor의 주요 역할

기능	설명
이미지 저장	Private Registry 제공
프로젝트 관리	Repository 및 권한 관리
이미지 복제	Registry 간 Replication
취약점 검사	Trivy 기반 이미지 스캔
이미지 서명	Cosign / Notary 지원
웹 UI	이미지 관리 및 검색

 

즉, Harbor는 이미지를 저장하고 관리하는 것(Store) 에 집중한다.

ㅁ Harbor와 Kaniko는 어떻게 함께 사용할까?

실제 CI/CD에서는 다음과 같은 구조를 많이 사용한다.

Git Repository
        │
        ▼
     Jenkins
(GitLab CI / Tekton)
        │
        ▼
      Kaniko
 (Docker Image Build)
        │
        ▼
      Harbor
 (Image Registry)
        │
        ▼
   Kubernetes
 (Image Pull & Run)

 

역할을 비교하면 더욱 명확하다.

프로젝트	담당 역할
Kaniko	Dockerfile을 읽어 이미지 생성
Harbor	생성된 이미지 저장 및 관리
Kubernetes	Harbor에서 이미지를 내려받아 실행

ㅁ 왜 역할을 분리할까?

결국 이유는 하나다.

 

관심사의 분리(Separation of Concerns)

 

Kaniko는          "어떻게 이미지를 만들 것인가?"                                   를 책임진다.

Harbor는          "어떻게 이미지를 안전하게 저장하고 관리할 것인가?"를 책임진다.

Kubernetes는  "어떻게 이미지를 실행할 것인가?"                               를 책임진다.

 

각 시스템이 하나의 책임만 가지기 때문에 유지보수가 쉬워지고 확장성도 높아진다.

 

ㅁ 마무리 — 컨테이너 플랫폼의 핵심 흐름

컨테이너 플랫폼은 단순히 Docker 이미지를 만드는 것으로 끝나지 않는다.

  이미지를 빌드(Build) 하고,

  안전하게 저장(Store) 하며,

  필요한 환경에서 배포(Deploy) 하는

전 과정을 하나의 파이프라인으로 관리해야 한다.

Kaniko와 Harbor는 이 과정에서 각각 Builder와 Registry라는 역할을 맡아 컨테이너 플랫폼의 핵심 기반을 구성한다.