GitOps Overview¶
GitOps는 cluster 상태를 직접 손으로 맞추는 대신, Git에 선언된 manifest를 원하는 상태로 삼는 운영 방식입니다.
이 예제에서는 Argo CD가 cd-repo의 environment path를 감시합니다. Git에 변경이 merge되면 Argo CD가 해당 manifest를 읽고 Kubernetes cluster에 적용합니다.
1. GitOps의 네 가지 원칙¶
OpenGitOps는 GitOps를 다음 네 가지 원칙으로 설명합니다.
| 원칙 | 이 guide에서의 의미 |
|---|---|
| Declarative | Kubernetes와 Argo CD desired state를 YAML과 Kustomize로 선언합니다. |
| Versioned and immutable | 변경을 Git commit과 pull request history로 남기고, 배포 image는 digest로 고정합니다. |
| Pulled automatically | Argo CD가 Git repository에서 desired state를 가져옵니다. CI가 cluster에 직접 push하지 않습니다. |
| Continuously reconciled | Argo CD가 Git desired state와 cluster live state를 계속 비교합니다. |
여기서 pulled automatically는 모든 변경을 즉시 배포해야 한다는 뜻이 아닙니다. Dev는 automated sync를 사용할 수 있고, stg는 merge 승인과 배포 시점을 분리하기 위해 manual sync를 사용할 수 있습니다. 두 경우 모두 Argo CD가 Git에 선언된 상태를 pull하고 적용합니다.
2. Source Repo와 CD Repo의 차이¶
source repo와 CD repo는 서로 다른 질문에 답합니다.
| Repo | Main question |
|---|---|
source-repo |
이 app/package/image가 올바르게 만들어졌는가? |
cd-repo |
어떤 image를 어떤 환경에 배포할 것인가? |
source repo는 package, app, contract, test, image build를 검증합니다. CD repo는 검증된 image를 environment overlay에 배치합니다.
Source CI는 cluster credential을 가지고 직접 kubectl apply하지 않습니다. CI가 image와 release evidence를 만들면, GitOps pull request가 어떤 artifact를 어느 environment에 배포할지 결정합니다.
3. GitOps Flow¶
일반적인 흐름은 다음과 같습니다.
source-repo
-> test, contract validation, image build
-> image publish
-> release handoff
cd-repo
-> exact tag와 digest로 environment overlay update
-> pull request
-> merge to main
-> Argo CD automated 또는 manual sync
-> Kubernetes rollout
4. Desired state, live state와 OutOfSync¶
| 상태 | 의미 |
|---|---|
| Desired state | Git repository에 선언된 배포 상태 |
| Live state | 현재 cluster에서 실행 중인 상태 |
Synced |
Desired state와 live state가 일치함 |
OutOfSync |
두 상태가 다름 |
OutOfSync는 차이가 있다는 관찰 결과이지, 항상 장애를 뜻하지는 않습니다.
- Dev automated sync에서는 reconciliation 중 잠깐 나타날 수 있습니다.
- Stg manual sync에서는 PR merge 후 실제 배포 승인을 기다리는 의도된 상태일 수 있습니다.
- Sync 후에도 계속 유지되면 hook, immutable field, admission mutation 또는 sync 실패를 확인합니다.
- Live resource를 직접 바꿔 발생했다면 Git에 반영할 변경인지 판단하고, 아니면 desired state로 복원합니다.
자세한 판단과 명령은 Operations, environment별 sync와 승격 기준은 Image Promotion을 봅니다.
5. Why Git Keeps the Deployment Record¶
배포 변경은 Git history로 남아야 합니다.
Git history는 어떤 image가 언제 어떤 환경으로 들어갔는지 보여줍니다. 장애가 발생했을 때도 kubectl edit 기록을 추적하는 대신, CD repo commit과 Argo CD revision을 기준으로 원인을 좁힐 수 있습니다.
Live patch가 incident 대응에 꼭 필요했다면 복구 후 같은 desired state를 Git pull request로 반영하거나 live state를 Git 상태로 되돌립니다. Cluster에만 남은 변경을 정상 운영 상태로 두지 않습니다.
6. Current Cluster Model¶
현재 dev와 stg는 같은 Kubernetes API server를 사용하고 namespace로 환경을 나눕니다.
| Environment | Namespace |
|---|---|
| dev | tirosh-guide-dev |
| stg | tirosh-guide-stg |
이 구성은 guide 예제에서 배포 경계를 이해하기 위한 단순한 모델입니다. 실제 production 환경은 별도 cluster, 별도 project, 더 강한 approval gate를 둘 수 있습니다.
Namespace는 이름 충돌과 policy 적용 범위를 나누지만 cluster 자체를 격리하지는 않습니다. Production이나 강한 보안 경계가 필요하면 별도 cluster, Argo CD Project, RBAC와 network policy를 함께 검토합니다.