Kubernetes CI/CD 흐름도 상세 설명 - GitLab Jenkins Maven Docker Harbor K8s 배포 구조

 

Kubernetes CI/CD 흐름도 상세 설명 - AS-IS와 TO-BE 배포 구조

본 구성은 개발자가 GitLab에 소스 코드를 Push하면 Webhook을 통해 Jenkins Pipeline이 실행되고, Maven Build, Docker Image Build, Harbor Image Push를 거쳐 최종적으로 Kubernetes Cluster에 애플리케이션을 배포하는 CI/CD 자동화 구조입니다.

흐름도의 핵심은 기존 CI/CD 체계를 완전히 폐기하고 새로운 시스템으로 일괄 전환하는 구조가 아니라, 기존 시스템의 CI/CD 체계를 유지하면서 신규 시스템을 위한 독립적인 CI/CD 체계를 추가하는 것입니다.

전체 핵심 흐름

개발자 → GitLab → Webhook → Jenkins → Git Clone → 배포 파일 생성 → Maven Build → Docker Build → Harbor Push → Kubernetes Deploy → Namespace → Pod

1. 전체 구성 한눈에 보기

개발자
   │
   │ Source Push
   ▼
GitLab
   │
   │ Webhook
   ▼
Jenkins
   │
   ├─ ① Git Clone
   ├─ ② File Write
   ├─ ③ Maven Build
   ├─ ④ Docker Build
   ├─ ⑤ Docker Push
   └─ ⑥ Kubernetes Deploy
                │
                ▼
             Harbor
                │
                ▼
      Kubernetes Cluster
                │
        ┌───────┴───────┐
        ▼               ▼
    Namespace         Namespace
        │               │
        ▼               ▼
       Pod             Pod

GitLab은 소스 코드 저장소, Jenkins는 CI/CD Pipeline 실행 엔진, Maven은 Java 애플리케이션 Build, Docker는 Container Image 생성, Harbor는 Container Image Registry, Kubernetes는 최종 애플리케이션 실행 환경을 담당합니다.

2. 구성요소별 역할

구성요소	역할	주요 작업
개발자	애플리케이션 개발	소스 수정 및 Git Push
GitLab	Source Repository	소스 코드 저장 및 변경 이력 관리
Webhook	CI/CD Trigger	GitLab 변경 사항을 Jenkins에 전달
Jenkins	CI/CD Pipeline	Build부터 Kubernetes 배포까지 Pipeline 수행
Maven	Application Build	Java Source Compile 및 WAR 생성
Docker	Container Image Build	WAR를 포함한 Docker Image 생성
Harbor	Container Registry	생성된 Container Image 저장
Kubernetes	Container Orchestration	Deployment, Pod 등의 애플리케이션 Resource 실행
Namespace	논리적 Resource 분리	기존 시스템과 신규 시스템 Resource 격리
DevOps 담당자	CI/CD 및 Platform 운영	Jenkins, Harbor, Kubernetes 관리 및 운영

3. AS-IS 기존 시스템 CI/CD 구조

AS-IS는 현재 운영 중인 기존 시스템의 CI/CD 구조입니다.

기존 시스템 개발자
        │
        │ Source Push
        ▼
      GitLab
        │
        │ Webhook
        ▼
      Jenkins
        │
        ▼
  CI/CD Pipeline
        │
        ▼
Kubernetes Cluster
        │
        ▼
AS-IS Namespace
(ns-old-system)
        │
        ▼
     Pod 실행

개발자가 기존 시스템 Repository에 소스를 Push하면 GitLab Webhook이 Jenkins를 호출합니다. Jenkins에서는 사전에 정의된 Pipeline에 따라 Build 및 배포 과정을 순차적으로 수행합니다.

4. 개발자의 GitLab Source Push

CI/CD Pipeline의 시작점은 개발자의 Source Code 변경입니다.

Developer
    │
    │ git push
    ▼
GitLab Repository

개발자는 Java Source, 설정 파일 등 애플리케이션 관련 코드를 GitLab Repository에 Push합니다. GitLab은 Source Code의 중앙 저장소 역할을 수행합니다.

5. GitLab Webhook → Jenkins

GitLab Repository에 변경 사항이 발생하면 Webhook을 통해 Jenkins Pipeline 실행을 Trigger할 수 있습니다.

GitLab

Source Push 발생
      │
      │ Webhook
      ▼
Jenkins

Pipeline 실행

이 구조를 사용하면 운영자가 Jenkins에서 매번 수동으로 Build 버튼을 실행하지 않아도 Git 변경을 기준으로 자동 CI/CD Pipeline을 구성할 수 있습니다.

6. Jenkins Pipeline의 전체 6단계

흐름도에서 Jenkins 이후의 Pipeline은 총 6단계로 구성되어 있습니다.

① Git Clone
      ↓
② File Write
      ↓
③ Maven Build
      ↓
④ Docker Build
      ↓
⑤ Docker Push
      ↓
⑥ K8s Deploy

각 단계가 성공해야 최종적으로 Kubernetes에 새로운 애플리케이션 버전을 배포할 수 있습니다.

7. ① Git Clone - Source Code 가져오기

Jenkins Pipeline이 시작되면 첫 번째로 GitLab Repository에서 Source Code를 가져옵니다.

GitLab Repository
       │
       │ Clone / Checkout
       ▼
Jenkins Workspace

Jenkins Workspace에는 이후 Build에 필요한 Source Code가 준비됩니다.

개념적인 명령은 다음과 같습니다.

git clone GITLAB_REPOSITORY

실제 Jenkins Pipeline에서는 Git Plugin이나 Pipeline의 Checkout 기능을 이용할 수도 있습니다.

8. ② File Write - Dockerfile과 deploy.yaml 생성

두 번째 단계에서는 Container Image 생성과 Kubernetes 배포에 필요한 파일을 준비합니다.

Dockerfile
deploy.yaml

흐름도에서는 Jenkins Pipeline 과정에서 해당 파일을 생성하는 구조로 표현되어 있습니다.

각 파일의 역할은 다음과 같습니다.

파일	역할
Dockerfile	애플리케이션을 포함하는 Docker Image의 생성 방법 정의
deploy.yaml	Kubernetes에 배포할 Resource 정의

예를 들어 deploy.yaml에는 다음과 같은 정보가 포함될 수 있습니다.

apiVersion: apps/v1
kind: Deployment

metadata:
  name: application

spec:
  replicas: 3

  template:
    spec:
      containers:
      - name: application
        image: harbor.example.com/project/application:VERSION

9. ③ Maven Build - WAR 생성

세 번째 단계에서는 Maven을 이용하여 Java 애플리케이션을 Build합니다.

mvn clean package

일반적인 처리 과정은 다음과 같습니다.

Java Source
     │
     ▼
Maven
     │
     ├─ Compile
     ├─ Test
     └─ Package
           │
           ▼
          WAR

흐름도에서는 Maven Build 결과물로 WAR 파일을 생성하는 구조입니다.

10. ④ Docker Build - WAR를 Container Image로 생성

Maven에서 생성된 WAR 파일은 다음 단계에서 Docker Image 내부에 포함됩니다.

WAR
 │
 │
 ▼
Dockerfile
 │
 ▼
docker build
 │
 ▼
Container Image

즉 Java Application Artifact인 WAR를 실제 Kubernetes에서 실행할 수 있는 Container Image로 변환하는 과정입니다.

개념적인 Dockerfile 구조는 다음과 같습니다.

FROM APPLICATION_SERVER_IMAGE

COPY application.war /deployments/application.war

그리고 Jenkins에서 Image를 생성합니다.

docker build -t application:VERSION .

11. ⑤ Docker Push - Harbor에 Image 업로드

생성된 Docker Image는 Jenkins 서버에만 존재하면 Kubernetes Node에서 안정적으로 사용할 수 없습니다.

따라서 Container Registry인 Harbor에 Image를 Push합니다.

Jenkins
   │
   │ Docker Push
   ▼
Harbor
   │
   └─ application:v1
   └─ application:v2
   └─ application:v3

Harbor는 CI/CD 구조에서 Container Image 중앙 저장소 역할을 수행합니다.

12. ⑥ Kubernetes Deploy - kubectl apply

마지막 단계에서는 Jenkins가 Kubernetes 배포 Manifest를 적용합니다.

kubectl apply -f deploy.yaml

전체 흐름은 다음과 같습니다.

Jenkins
   │
   │ kubectl apply
   ▼
Kubernetes API Server
   │
   ▼
Deployment
   │
   ▼
ReplicaSet
   │
   ▼
Pod

Kubernetes는 Deployment에 정의된 Desired State를 기준으로 필요한 Pod를 생성합니다.

13. Kubernetes는 Harbor에서 Image를 Pull한다

여기서 CI/CD 흐름도를 이해할 때 중요한 부분이 하나 있습니다.

Jenkins는 Docker Image를 Harbor에 Push하지만, 실제 Pod에서 Image를 실행하기 위해서는 Kubernetes Node가 Harbor에서 Image를 Pull해야 합니다.

Jenkins
   │
   │ PUSH
   ▼
Harbor
   ▲
   │ PULL
   │
Kubernetes Worker Node
   │
   ▼
Container
   │
   ▼
Pod

따라서 실제 운영 환경에서는 Kubernetes Worker Node에서 Harbor Registry로의 네트워크 연결과 Private Registry 인증 구성도 중요합니다.

14. AS-IS Kubernetes 배포 영역

기존 시스템은 Kubernetes Cluster 내부의 기존 Namespace에 배포됩니다.

Kubernetes Cluster
        │
        ▼
AS-IS Namespace
(ns-old-system)
        │
   ┌────┼────┐
   ▼    ▼    ▼
 Pod   Pod   Pod

Namespace를 사용하면 동일한 Kubernetes Cluster 안에서도 시스템별 Resource를 논리적으로 구분하여 관리할 수 있습니다.

15. TO-BE 구조의 핵심

TO-BE에서는 기존 시스템을 유지하면서 신규 시스템을 위한 CI/CD 영역이 추가됩니다.

TO-BE

기존 시스템
   │
   ├─ 기존 GitLab
   ├─ 기존 Jenkins
   ├─ 기존 CI/CD Pipeline
   └─ 기존 시스템 Namespace


신규 시스템
   │
   ├─ 신규 GitLab Repository
   ├─ 신규 Jenkins CI/CD
   ├─ 신규 CI/CD Pipeline
   └─ 신규 시스템 Namespace

즉 기존 시스템과 신규 시스템의 Source Repository, Jenkins Pipeline 및 Kubernetes 배포 영역을 논리적으로 분리하여 운영하는 구조입니다.

16. TO-BE 기존 시스템 CI/CD

TO-BE 전환 이후에도 기존 시스템의 CI/CD 흐름 자체는 유지됩니다.

기존 시스템 개발자
        │
        ▼
기존 GitLab Repository
        │
        │ Webhook
        ▼
기존 Jenkins
        │
        ▼
Git Clone
        │
        ▼
File Write
        │
        ▼
Maven Build
        │
        ▼
Docker Build
        │
        ▼
Harbor Push
        │
        ▼
K8s Deploy
        │
        ▼
ns-old-system

따라서 기존 서비스에 대한 개발 및 배포 체계를 유지하면서 신규 시스템을 병행 구축할 수 있습니다.

17. TO-BE 신규 시스템 CI/CD

신규 시스템은 별도의 개발자, GitLab Repository, Jenkins CI/CD Pipeline을 이용하여 독립적인 배포 흐름을 구성합니다.

신규 시스템 개발자
        │
        │ Source Push
        ▼
신규 GitLab Repository
        │
        │ Webhook
        ▼
신규 Jenkins
        │
        ├─ Git Clone
        ├─ File Write
        ├─ Maven Build
        ├─ Docker Build
        ├─ Docker Push
        └─ K8s Deploy
                │
                ▼
       Kubernetes Cluster
                │
                ▼
       신규 시스템 Namespace
         (ns-new-system)
                │
          ┌─────┼─────┐
          ▼     ▼     ▼
         Pod   Pod   Pod

18. 기존 시스템과 신규 시스템의 Namespace 분리

TO-BE 구성에서 중요한 부분 중 하나는 Kubernetes Cluster 내부에서 기존 시스템과 신규 시스템을 Namespace 단위로 분리한다는 점입니다.

Kubernetes Cluster
        │
        ├─────────────────────┐
        │                     │
        ▼                     ▼
ns-old-system             ns-new-system
기존 시스템                신규 시스템
        │                     │
   ┌────┼────┐           ┌────┼────┐
   ▼    ▼    ▼           ▼    ▼    ▼
 Pod   Pod   Pod         Pod   Pod   Pod

이를 통해 동일한 Kubernetes Cluster를 사용하면서도 Resource 이름, RBAC, ConfigMap, Secret, NetworkPolicy, ResourceQuota 등의 관리 범위를 시스템별로 분리할 수 있습니다.

주의: Namespace 분리는 논리적 격리입니다. Namespace를 분리했다고 해서 Worker Node, Network, Storage 등의 물리적 자원이 자동으로 완전히 분리되는 것은 아닙니다. 강한 격리가 필요한 경우 NetworkPolicy, RBAC, ResourceQuota, Node Affinity 등의 추가 정책을 검토해야 합니다.

19. AS-IS와 TO-BE의 가장 큰 차이

구분	AS-IS	TO-BE
대상 시스템	기존 시스템	기존 + 신규 시스템
개발 조직	기존 시스템 개발자	기존 / 신규 시스템 개발자 분리
GitLab	기존 Repository	기존 / 신규 Repository 분리
Jenkins	기존 CI/CD	기존 / 신규 CI/CD 영역 분리
Build	Maven	각 시스템별 Maven Build
Image Registry	Harbor	Harbor 기반 운영
Kubernetes	기존 Cluster	동일 Cluster 내 시스템별 배포
Namespace	AS-IS Namespace	기존 / 신규 Namespace 분리

20. CI 영역과 CD 영역을 나누어 보면

전체 Pipeline은 크게 CI와 CD 영역으로 나눌 수 있습니다.

CI - Continuous Integration

Git Push
   ↓
GitLab
   ↓
Webhook
   ↓
Jenkins
   ↓
Git Clone
   ↓
File Write
   ↓
Maven Build
   ↓
Docker Build
   ↓
Docker Push
   ↓
Harbor

CI 영역에서는 Source Code를 검증하고 Build하여 배포 가능한 Container Image를 만드는 것이 핵심입니다.

CD - Continuous Delivery / Deployment

Harbor Image
      ↓
Jenkins
      ↓
kubectl apply
      ↓
Kubernetes
      ↓
Deployment
      ↓
Pod

CD 영역에서는 CI 과정에서 만들어진 Container Image를 이용하여 Kubernetes에 실제 애플리케이션을 배포합니다.

21. DevOps 담당자의 역할

흐름도에서는 기존 시스템과 신규 시스템 각각에 DevOps 운영 영역이 표시되어 있습니다.

DevOps 담당자는 일반적으로 다음 영역을 관리합니다.

Jenkins 관리
      │
      ├─ Pipeline 관리
      ├─ Credential 관리
      └─ Build Agent 관리

Harbor 관리
      │
      ├─ Project 관리
      ├─ Image 관리
      └─ Registry 권한 관리

Kubernetes 관리
      │
      ├─ Namespace
      ├─ Deployment
      ├─ Service
      ├─ ConfigMap / Secret
      ├─ Resource
      └─ 장애 대응

개발자는 Source Code 개발에 집중하고, DevOps 담당자는 Source가 실제 Kubernetes 운영 환경까지 안정적으로 배포될 수 있도록 CI/CD Platform을 관리합니다.

22. 배포 시 실제 Kubernetes 내부 동작

Jenkins가 kubectl apply를 수행하면 단순히 Pod 하나가 바로 생성되는 것이 아니라 Kubernetes Controller 구조에 따라 Resource가 생성됩니다.

Jenkins

kubectl apply
      │
      ▼
Kubernetes API Server
      │
      ▼
Deployment
      │
      ▼
ReplicaSet
      │
      ▼
Pod 생성 요청
      │
      ▼
Scheduler
      │
      ▼
Worker Node 결정
      │
      ▼
Harbor Image Pull
      │
      ▼
Container 생성
      │
      ▼
Pod Running

23. Image Version 관리도 중요하다

CI/CD Pipeline에서 Docker Image Tag를 어떻게 관리할지도 중요한 요소입니다.

예를 들어 다음과 같이 관리할 수 있습니다.

application:1.0.0

application:1.0.1

application:build-101

application:build-102

application:COMMIT_SHA

각 Build마다 고유한 Image Tag를 사용하면 어떤 Source Version이 어떤 Kubernetes 배포에 사용되었는지 추적하기 쉬워집니다.

운영 환경에서는 모든 배포에 단순히 latest Tag만 사용하는 것보다 Build Number나 Git Commit SHA처럼 식별 가능한 Immutable Tag를 사용하는 방법을 고려하는 것이 좋습니다.

24. 배포 실패 지점도 구분할 수 있다

Pipeline 단계가 명확하게 분리되어 있기 때문에 장애 발생 지점 역시 단계별로 분석할 수 있습니다.

단계	대표적인 실패 원인
Git Clone	GitLab 연결, Credential, Repository 권한 문제
File Write	파일 경로, 변수 치환, 권한 문제
Maven Build	Compile 오류, Dependency 다운로드 실패, Test 실패
Docker Build	Dockerfile 오류, Base Image Pull 실패
Docker Push	Harbor 인증, Network, Project 권한 문제
K8s Deploy	kubeconfig, RBAC, Manifest 오류
Pod Start	ImagePullBackOff, CrashLoopBackOff, Resource 부족

25. ImagePullBackOff가 발생하는 위치

예를 들어 Kubernetes에서 ImagePullBackOff가 발생한다면 Jenkins의 Maven Build 단계보다는 다음 구간을 확인해야 합니다.

Jenkins
   │
   │ Docker Push
   ▼
Harbor
   │
   │ Image Pull
   ▼
Kubernetes Worker Node
   │
   X
ImagePullBackOff

대표적으로 다음 항목을 확인합니다.

Harbor에 Image가 존재하는가?

Image Tag가 정확한가?

deploy.yaml의 Image 주소가 정확한가?

Worker Node → Harbor 통신이 가능한가?

imagePullSecrets가 정상인가?

Harbor 인증서가 정상인가?

26. 기존 시스템과 신규 시스템을 분리하는 이유

TO-BE 구조에서 기존과 신규 시스템을 분리하는 가장 큰 이유는 신규 시스템 도입 과정에서 기존 서비스에 미치는 영향을 최소화하고 각 시스템의 변경과 배포를 독립적으로 관리하기 위해서입니다.

기존 시스템 변경
       │
       ▼
기존 Pipeline
       │
       ▼
ns-old-system


신규 시스템 변경
       │
       ▼
신규 Pipeline
       │
       ▼
ns-new-system

신규 시스템 배포가 발생하더라도 기존 시스템 Pipeline을 직접 변경하지 않고, 반대로 기존 시스템의 배포 역시 신규 시스템 Pipeline에 직접 영향을 주지 않도록 구성할 수 있습니다.

27. TO-BE 구조의 장점

기존 서비스 영향 최소화

기존 CI/CD 흐름을 유지한 상태에서 신규 시스템을 추가하기 때문에 전환 위험을 줄일 수 있습니다.

배포 경로 분리

기존 시스템과 신규 시스템이 각각 별도의 Repository와 Pipeline을 사용할 수 있어 배포 변경 사항을 분리하여 관리할 수 있습니다.

Kubernetes Namespace 분리

동일 Cluster에서도 시스템별 Kubernetes Resource를 논리적으로 분리할 수 있습니다.

장애 범위 파악 용이

Pipeline과 Namespace가 구분되어 있기 때문에 어느 시스템에서 Build 또는 배포 문제가 발생했는지 파악하기 쉽습니다.

단계적 전환 가능

기존 시스템을 유지하면서 신규 시스템을 구축하고 검증할 수 있기 때문에 일괄 전환보다 단계적인 Migration 전략을 구성하기 쉽습니다.

28. TO-BE 구조에서 추가로 검토할 사항

흐름도는 전체적인 CI/CD 논리 구조를 보여주고 있으며, 실제 구축 단계에서는 다음 항목을 추가로 검토하는 것이 좋습니다.

GitLab Repository 권한 분리

Jenkins Credential 분리

Jenkins Pipeline 권한

Harbor Project 분리

Harbor Image Tag 정책

Kubernetes ServiceAccount

Kubernetes RBAC

Namespace ResourceQuota

LimitRange

Secret 관리

ConfigMap 관리

NetworkPolicy

Deployment Rollout 전략

Rollback 전략

Image Vulnerability Scan

CI/CD 로그 보관

배포 승인 절차

29. 전체 CI/CD 흐름 최종 정리

┌───────────────┐
│    개발자      │
└───────┬───────┘
        │ Source Push
        ▼
┌───────────────┐
│    GitLab      │
└───────┬───────┘
        │ Webhook
        ▼
┌───────────────┐
│    Jenkins     │
└───────┬───────┘
        │
        ├─ ① Git Clone
        │
        ├─ ② Dockerfile / deploy.yaml 생성
        │
        ├─ ③ Maven Build → WAR
        │
        ├─ ④ Docker Build → Image
        │
        ├─ ⑤ Docker Push → Harbor
        │
        └─ ⑥ kubectl apply
                     │
                     ▼
             Kubernetes Cluster
                     │
            ┌────────┴────────┐
            │                 │
            ▼                 ▼
      ns-old-system      ns-new-system
            │                 │
            ▼                 ▼
           Pod               Pod

30. 결론

본 CI/CD 흐름도는 GitLab → Jenkins → Maven → Docker → Harbor → Kubernetes로 이어지는 Container 기반 애플리케이션의 자동 Build 및 배포 구조를 나타냅니다.

개발자가 GitLab에 Source Code를 Push하면 Webhook으로 Jenkins Pipeline이 시작되고, Jenkins는 Source Clone, 배포 파일 생성, Maven Build, Docker Image Build, Harbor Image Push 및 Kubernetes 배포를 순차적으로 수행합니다.

AS-IS에서는 기존 시스템의 CI/CD Pipeline을 통해 기존 Kubernetes Namespace로 배포하고 있으며, TO-BE에서는 기존 구조를 유지하면서 신규 시스템을 위한 별도의 Repository와 CI/CD Pipeline, Kubernetes Namespace를 추가하는 형태입니다.

따라서 TO-BE 구조의 핵심은 기존 서비스를 유지하면서 신규 시스템의 개발·Build·Image·배포 영역을 논리적으로 분리하고, 최종적으로 동일 Kubernetes Cluster에서 Namespace 단위로 기존 시스템과 신규 시스템을 구분하여 운영하는 것이라고 정리할 수 있습니다.

한 줄 요약

개발자가 GitLab에 Source를 Push하면 Jenkins가 자동으로 WAR와 Docker Image를 생성하고 Harbor에 저장한 뒤 Kubernetes에 배포하며, TO-BE에서는 이 CI/CD 경로를 기존 시스템과 신규 시스템으로 분리하여 각각의 Namespace에 독립적으로 배포하는 구조입니다.