주요 개념

Deployflow에서 사용하는 애플리케이션, 배포 구조, 배포 상태, 고급 배포 전략, 승인 프로세스, 권한 체계를 설명합니다.

애플리케이션

애플리케이션(Application)은 콘솔에서 생성, 수정, 이력 관리가 가능한 배포의 최상위 단위이자 대상입니다. 애플리케이션에는 배포 클러스터, 소스 리포지토리, 배포 방식, 승인 설정 등 배포에 필요한 설정이 포함됩니다.

애플리케이션은 배포 소스에 포함된 매니페스트를 기준으로 쿠버네티스 리소스를 생성하며, 배포 이후에는 토폴로지, 리비전, 히스토리를 통해 리소스 관계와 버전 이력을 확인하고 롤백을 수행할 수 있습니다.

주요 개념	설명
헬름 차트(Helm Chart)	쿠버네티스 리소스를 정의하는 패키지 형식으로, 템플릿화된 설정 파일을 통해 복잡한 앱을 쉽게 설치하고 업그레이드할 수 있게 합니다.
커스터마이즈(Kustomize)	기본 매니페스트에 환경별 설정을 오버레이 방식으로 적용해 별도 템플릿 엔진 없이 쿠버네티스 리소스를 관리할 수 있게 하는 구성 방식입니다.
쿠버네티스 매니페스트(K8s Manifest)	YAML 또는 JSON 형태로 작성된 쿠버네티스 리소스 설정 문서입니다.
토폴로지(Topology)	애플리케이션을 구성하는 쿠버네티스 리소스 간의 관계와 배포 상태를 시각적으로 표현한 뷰입니다.
히스토리(History)	동기화 또는 롤백 등 배포 작업의 실행 이력입니다. 이전 상태의 설정을 조회하거나 특정 시점으로 롤백할 수 있습니다.
리비전(Revision)	리소스가 배포될 때마다 부여되는 버전 식별자로, 현재 어떤 버전이 배포되어 있는지 추적하는 데 사용됩니다.
롤백(Rollback)	배포 실패 또는 장애 발생 시 이전 정상 버전의 상태로 되돌리는 작업입니다.

애플리케이션 생성 및 관리 방법은 애플리케이션 생성 및 관리를 참고하세요.

배포 구조

Deployflow는 선언적 방식(Declarative)을 채택하여 Git 저장소 또는 Codeflow의 빌드 결과물(Artifact)과 쿠버네티스 클러스터의 실제 상태를 동기화합니다.

• Deployflow 배포 엔진: 애플리케이션의 생성, 수정, 삭제(CRUD) 및 배포 파이프라인의 생명주기를 관리하는 핵심 엔진입니다.
• Target Cluster: 애플리케이션이 실제 배포되는 카카오클라우드 쿠버네티스 엔진(K8sE) 환경입니다.
• Repository: 배포에 필요한 매니페스트(YAML, Helm, Kustomize)가 저장된 소스 저장소입니다.

배포 상태

배포 상태는 애플리케이션 목록에서 확인할 수 있으며, 애플리케이션은 내부적으로 리소스의 건전성을 나타내는 배포 상태(Health Status)와 설정 파일과의 일치 여부를 나타내는 동기화 상태(Sync Status)를 가집니다. 배포 상태와 동기화 상태는 서로 다른 기준의 상태값이며, 배포 상태는 리소스의 실행 상태를, 동기화 상태는 소스와 클러스터 상태의 일치 여부를 나타냅니다.

배포 상태(Health Status)는 애플리케이션 리소스가 정상적으로 생성되어 실행 중인지, 생성 또는 업데이트 중인지, 오류나 누락이 있는지를 나타냅니다.

상태값	정의
Healthy	리소스가 정상적으로 생성되었으며, 서비스 제공에 이상이 없는 상태입니다.
Progressing	리소스가 현재 생성 중이거나 업데이트 중입니다. 곧 Healthy 상태로 전환될 것을 기대합니다.
Suspended	리소스가 일시 중단되었습니다. 특정 이벤트가 발생하기 전까지 대기 중인 상태입니다.
Missing	클러스터 내에 존재해야 할 리소스 일부가 누락되어 찾을 수 없는 상태입니다.
Degraded	리소스에 오류가 발생하여 정상적인 서비스가 불가능하거나 성능이 저하된 상태입니다.
Unknown	통신 문제 등으로 인해 리소스의 현재 상태를 확인할 수 없는 상태입니다.

동기화 상태(Sync Status)는 Git Repository의 배포 구성과 클러스터에 실제 반영된 리소스 상태가 일치하는지를 나타냅니다.

상태값	정의
Unknown	현재 상태를 알 수 없습니다.
Out of Sync	변경 사항 반영 대기 중 상태입니다. Git Repository와 클러스터 배포 상태가 불일치하여 동기화가 필요합니다.
Synced	Git Repository와 클러스터 배포 상태가 일치합니다.

고급 배포 전략

기본적인 배포 방식 외에 서비스 특성에 맞춰 다음과 같은 고급 전략 옵션을 선택할 수 있습니다.

• 자동 동기화(Auto Sync): 소스 저장소의 변경 사항이 감지되면 별도의 동기화 액션 없이 클러스터에 자동으로 반영합니다.
• 블루/그린(Blue/Green): 동일 규모의 신규 환경을 구축하여 한 번에 트래픽을 전환합니다. 빠른 롤백이 강점입니다.
• 카나리(Canary): 신규 버전에 트래픽의 일부만 먼저 유입시켜 테스트한 후 점진적으로 확대합니다.

배포 전략 설정과 상태 확인 방법은 애플리케이션 생성 및 관리를 참고하세요.

승인 프로세스(Approval Flow)

[승인 설정 옵션]을 사용으로 지정한 경우에만 아래 승인 프로세스가 적용되며, 배포의 안정성을 확보하기 위해 동기화 또는 롤백 실행 전 리뷰어의 승인을 거치도록 합니다.

• 승인(Approve): 리뷰어가 배포 내용을 확인하고 승인하면, 배포 파이프라인이 다음 단계(실제 클러스터 반영)로 진행됩니다.
• 반려(Reject): 배포 내용에 문제가 있을 경우 리뷰어가 반려할 수 있으며, 설정된 리뷰어 중 한 명이라도 반려하면 해당 승인 요청 건의 진행이 즉시 중단되고 반려 상태로 기록됩니다.
• 리뷰어 설정: 최소 1명에서 최대 5명까지 설정 가능하며, 설정된 모든 리뷰어가 승인해야 배포가 진행됩니다.

승인 요청 조회, 승인, 반려 방법은 승인 관리를 참고하세요.

승인 Flow

애플리케이션 생성 시 승인 설정 옵션 사용/미사용에 따라 배포 승인 프로세스가 아래와 같이 분기됩니다.

애플리케이션 생성
      │
      ▼
 승인 유형
    ├─▶ 승인 설정 옵션 '미사용' ──▶ 생성 저장 ──▶ 배포 가능
    ├─▶ 승인 설정 옵션 '사용' ──▶ 단일 승인(1명) 리뷰어 설정 ──▶ 생성 저장 ──▶ 승인 후 배포 가능
    └─▶ 승인 설정 옵션 '사용' ──▶ 전체 승인(2명 이상-최대 5명 이하) 리뷰어 설정 ──▶ 생성 저장 ──▶ 승인 후 배포 가능

전체 승인: 설정된 리뷰어 전원이 승인하는 시점에 승인이 완료됩니다. 예를 들어 리뷰어가 3명인 경우 3명 모두 승인해야 합니다.

'Progressing'   ──▶ 리뷰어 A 승인 ─┐
                ──▶ 리뷰어 B 승인 ─┼─ 전원 승인 ──▶ 결과 'Approved'
                ──▶ 리뷰어 C 승인 ─┘

반려: 설정된 리뷰어 중 한 명이라도 반려하면 승인 상태는 즉시 'Rejected'로 변경됩니다.

'Progressing'   ──▶ 리뷰어 A 승인 ─┐
                ──▶ 리뷰어 B 승인 ─┼─ (전원 승인 미도달)
                ──▶ 리뷰어 C 반려 ─┴───────────────────────▶ 결과 'Rejected'

리뷰어 정보 상태값 정의: Progressing 상태에서 승인 요청자와 리뷰어가 각각 취할 수 있는 액션과 결과 상태는 다음과 같습니다.

주체	액션	결과 상태
승인 요청자	승인 취소	Canceled
리뷰어	승인	Approved
리뷰어	반려	Rejected

승인 요청 시 배포 프로세스: 승인 요청이 생성된 이후의 승인 상태값은 승인 요청자와 리뷰어의 액션에 따라 아래와 같이 배포 단계가 제공됩니다.

승인 요청 생성
      │  (생성 직후 아래 상태값으로 변경)
      ▼
  'Progressing'(승인 프로세스 진행 중)
      │
      ├──▶ Approved (전체 승인 완료) ──▶ Ready (동기화/롤백 대기) ─ [동기화 또는 롤백 액션] ──▶ Done(승인 프로세스 완료)
      ├──▶ (한 명 이상 반려 시) ──▶ Rejected (반려)
      └──▶ 승인 요청자 취소 시 ──▶ Canceled (승인 요청 취소)

동기화 또는 롤백 액션이 실제로 수행된 후 승인 상태값이 Done(승인 완료)으로 변경됩니다. 각 상태값에 대한 목록 화면 기준 설명은 승인 프로세스 단계 확인을 참고하세요.

주의

승인 요청자나 리뷰어 계정이 삭제되거나 권한이 변경될 경우 승인 프로세스는 더 이상 진행이 어려우므로 이용에 주의하시기 바랍니다.

IAM 역할 관리

Deployflow는 IAM(Identity and Access Management)의 역할 기반 액세스 제어(Role-Based Access Control, RBAC)를 따릅니다. Deployflow 리소스는 프로젝트 하위에서 관리되며, 프로젝트 역할과 Deployflow 서비스 역할에 따라 접근 권한이 부여됩니다.

• 프로젝트 관리자와 프로젝트 멤버는 프로젝트 내 애플리케이션 등 Deployflow 리소스를 생성, 조회, 수정, 삭제할 수 있습니다.
• 프로젝트 리더는 프로젝트 내 Deployflow 리소스를 조회할 수 있습니다.
• Deployflow 리소스에 대한 권한만 별도로 부여하려면 Deployflow 매니저 또는 Deployflow 뷰어 서비스 역할을 사용할 수 있습니다. Deployflow 매니저는 모든 Deployflow 리소스를 생성, 조회, 수정, 삭제할 수 있으며, Deployflow 뷰어는 모든 Deployflow 리소스를 조회할 수 있습니다.

주의

Deployflow 매니저 역할만 부여받은 경우 프로젝트 접근 권한이 없어 애플리케이션 생성, 수정, 삭제 등 CRUD 작업이 제한될 수 있습니다. 정상적으로 애플리케이션을 관리하려면 프로젝트 리더 이상의 프로젝트 역할이 함께 부여되어야 합니다.

노트

나의 역할은 카카오클라우드 콘솔 > 우측 상단 프로필 > 조직 역할 또는 프로젝트 역할에서 확인할 수 있습니다.

프로젝트 역할의 권한 범위는 프로젝트 역할에서, Deployflow 서비스 역할의 권한 범위는 서비스 역할에서 확인할 수 있습니다. 사용자 또는 그룹에 역할을 할당하는 방법은 역할 할당 및 변경을 참고하세요.

권한	프로젝트 관리자 (Admin)	프로젝트 멤버 (Member)	프로젝트 리더 (Reader)	Deployflow 매니저 (Manager)	Deployflow 뷰어 (Viewer)
프로젝트 멤버 관리	✓
애플리케이션 생성	✓	✓		✓
애플리케이션 조회	✓	✓	✓	✓	✓
애플리케이션 설정	✓	✓		✓
애플리케이션 삭제	✓	✓		✓
승인 요청 생성	✓	✓		✓
승인 내역 조회	✓	✓	✓	✓	✓
승인/반려 관리	✓	✓		✓