Key Concepts

This page describes applications, deployment structure, deployment status, advanced deployment strategies, approval processes, and the permission model used in Deployflow.

Application

An application is the top-level deployment unit and target that can be created, modified, and managed with history in the console. An application includes the settings required for deployment, such as the deployment cluster, source repository, deployment method, and approval settings.

An application creates Kubernetes resources based on manifests included in the deployment source. After deployment, you can use topology, revisions, and history to check resource relationships and version history, and perform rollbacks.

Key concept	Description
Helm Chart	Package format for defining Kubernetes resources. It helps you install and upgrade complex applications through templated configuration files.
Kustomize	Configuration method that applies environment-specific settings as overlays to base manifests, allowing you to manage Kubernetes resources without a separate template engine.
Kubernetes Manifest	Kubernetes resource configuration document written in YAML or JSON.
Topology	View that visually represents relationships and deployment status of Kubernetes resources that make up an application.
History	Execution history of deployment operations such as synchronization or rollback. You can view previous settings or roll back to a specific point in time.
Revision	Version identifier assigned whenever a resource is deployed. It is used to track which version is currently deployed.
Rollback	Operation that reverts to a previous healthy version after deployment failure or service issues.

For how to create and manage applications, see Create and manage applications.

Deployment structure

Deployflow uses a declarative model to synchronize the desired state of a Git repository or Codeflow build artifact with the actual state of a Kubernetes cluster.

• Deployflow deployment engine: Core engine that manages application creation, modification, deletion (CRUD), and the deployment pipeline lifecycle.
• Target Cluster: KakaoCloud Kubernetes Engine (K8sE) environment where the application is deployed.
• Repository: Source repository where manifests required for deployment, such as YAML, Helm, and Kustomize, are stored.

Deployment status

Deployment status can be checked in the application list. Internally, an application has a deployment status (Health Status), which indicates resource health, and a sync status (Sync Status), which indicates whether the resource state matches the configuration files. Deployment status and sync status are based on different criteria. Deployment status indicates the runtime state of resources, while sync status indicates whether the source and cluster state match.

Deployment status (Health Status) indicates whether application resources have been created and are running normally, are being created or updated, or have errors or missing resources.

Status	Definition
Healthy	Resources have been created normally and the service is operating without issues.
Progressing	Resources are being created or updated. They are expected to transition to Healthy soon.
Suspended	Resources are suspended and waiting until a specific event occurs.
Missing	Some resources that should exist in the cluster are missing.
Degraded	A resource has an error, making normal service unavailable or reducing performance.
Unknown	Current resource status cannot be checked due to communication issues or other reasons.

Sync status (Sync Status) indicates whether the deployment configuration in the Git Repository matches the resource state actually applied to the cluster.

Status	Definition
Unknown	Current status is unknown.
Out of Sync	Changes are waiting to be applied. The Git Repository and cluster deployment state do not match, and synchronization is required.
Synced	The Git Repository and cluster deployment state match.

Advanced deployment strategy

In addition to the default deployment method, you can select the following advanced strategy options according to service characteristics.

• Blue/Green: Creates a new environment of the same size and switches traffic at once. It is useful for fast rollback.
• Canary: Routes only part of the traffic to the new version first for testing, then gradually expands the traffic.
• Auto sync: Automatically applies changes to the cluster without a separate sync action when changes are detected in the source repository.

For how to configure deployment strategies and check their status, see Create and manage applications.

Approval flow

The following approval process applies only when the [Approval setting option] is set to Use. To ensure deployment stability, reviewers must approve before synchronization or rollback is executed.

• Approve: If a reviewer checks and approves the deployment content, the deployment pipeline proceeds to the next stage where changes are applied to the cluster.
• Reject: If deployment content has an issue, a reviewer can reject it. If any configured reviewer rejects the request, the approval request stops immediately and is recorded as rejected.
• Reviewer settings: You can configure at least 1 and up to 5 reviewers. All configured reviewers must approve before deployment proceeds.

For how to view, approve, and reject approval requests, see Approval management.

Approval flow

When an application is created, the deployment approval process branches as follows depending on whether the approval setting option is enabled.

Application creation
      |
      v
 Approval type
    |-- Approval setting option 'Not used' --> Save creation --> Deployment available
    |-- Approval setting option 'Used' --> Single approval reviewer setting (1 reviewer) --> Save creation --> Deployment available after approval
    `-- Approval setting option 'Used' --> Full approval reviewer setting (2 to 5 reviewers) --> Save creation --> Deployment available after approval

Full approval: Approval is complete when all configured reviewers approve. For example, if three reviewers are configured, all three must approve.

'Progressing'   --> Reviewer A approves --\
                --> Reviewer B approves ---+-- All approved --> Result 'Approved'
                --> Reviewer C approves --/

Reject: If any configured reviewer rejects the request, the approval status immediately changes to Rejected.

'Progressing'   --> Reviewer A approves --\
                --> Reviewer B approves ---+-- (Full approval not reached)
                --> Reviewer C rejects ----+-------------------------> Result 'Rejected'

Reviewer information status definitions: The following table describes the actions that approval requesters and reviewers can take in the Progressing status and their resulting statuses.

Subject	Action	Result status
Approval requester	Cancel approval	Canceled
Reviewer	Approve	Approved
Reviewer	Reject	Rejected

Deployment process after approval request: After an approval request is created, the following deployment stages are provided according to the actions of the approval requester and reviewers.

Approval request created
      |  (changed to the following status immediately after creation)
      v
  'Progressing' (approval process in progress)
      |
      |-- Approved (full approval complete) --> Ready (waiting for sync/rollback) -- [Sync or rollback action] --> Done (approval process complete)
      |-- (one or more reviewers reject) --> Rejected
      `-- Approval requester cancels --> Canceled

After the sync or rollback action is actually performed, the approval status changes to Done. For descriptions of each status in the list screen, see View approval process status.

Caution

If an approval requester or reviewer account is deleted or its permissions change, the approval process may no longer proceed. Use approval settings carefully.

IAM-based role management

Deployflow follows role-based access control (RBAC) in IAM (Identity and Access Management). Deployflow resources are managed under a project, and access permissions are granted according to project roles and Deployflow service roles.

• Project Admin and Project Member can create, view, modify, and delete Deployflow resources such as applications in the project.
• Project Reader can view Deployflow resources in the project.
• To grant only permissions for Deployflow resources, use the Deployflow Manager or Deployflow Viewer service role. Deployflow Manager can create, view, modify, and delete all Deployflow resources. Deployflow Viewer can view all Deployflow resources.

Caution

If only the Deployflow Manager role is granted, CRUD operations such as application creation, modification, and deletion may be restricted because the user has no project access permission. To manage applications normally, a project role of Project Reader or higher must also be granted.

note

You can check your roles in the KakaoCloud console from the profile menu in the upper-right corner under organization roles or project roles.

For the permission scope of project roles, see Project roles. For the permission scope of Deployflow service roles, see Service roles. For how to assign roles to users or groups, see Assign and modify roles.

Permission	Project Admin (Admin)	Project Member (Member)	Project Reader (Reader)	Deployflow Manager (Manager)	Deployflow Viewer (Viewer)
Manage project members	✓
Create applications	✓	✓		✓
View applications	✓	✓	✓	✓	✓
Configure applications	✓	✓		✓
Delete applications	✓	✓		✓
Create approval requests	✓	✓		✓
View approval history	✓	✓	✓	✓	✓
Manage approvals/rejections	✓	✓		✓