지금까지 Kubernetes 운영 환경을 다음과 같이 발전시켜 왔다.
Kubernetes
↓
Helm
↓
Argo CD + GitOps
↓
Prometheus + Grafana
↓
Loki
↓
Tempo
↓
Alertmanager
↓
자동 복구
이제 배포 단계에서도 한 단계 더 발전시킬 수 있다.
일반적인 Kubernetes Rolling Update는 새로운 버전의 Pod를 순차적으로 교체한다.
Version 1
████████████████████
↓ Deploy
Version 1
██████████
Version 2
██████████
↓
Version 2
████████████████████
하지만 운영 환경에서는 다음과 같은 문제가 발생할 수 있다.
새로운 버전에 버그가 있을 수 있다.
특정 API에서만 오류가 발생할 수 있다.
CPU 사용량이 급증할 수 있다.
응답 시간이 증가할 수 있다.
일부 사용자에게만 문제가 발생할 수 있다.
Pod는 정상인데 애플리케이션은 장애 상태일 수 있다.
따라서 새로운 버전을 한 번에 전체 사용자에게 배포하는 대신,
새 버전을 일부 트래픽에 먼저 노출하고 실제 서비스 지표를 확인한 뒤 점진적으로 확대하는 방식
을 사용할 수 있다.
이것이 Progressive Delivery다.
그리고 Kubernetes에서 Progressive Delivery를 구현할 때 대표적으로 사용하는 도구가 Argo Rollouts다.
Progressive Delivery는 배포를 한 번에 완료하지 않고 여러 단계로 나누어 진행하는 방식이다.
기존 방식:
Version 1
↓
Version 2
↓
Production 100%
Progressive Delivery:
Version 1
↓
Version 2
↓
10%
↓
Metric 검증
↓
25%
↓
Metric 검증
↓
50%
↓
Metric 검증
↓
100%
즉,
배포
↓
검증
↓
확대
↓
검증
↓
확대
를 반복한다.
운영 환경에서는 애플리케이션이 정상적으로 시작했다고 해서 배포가 성공한 것이 아니다.
예를 들어 새로운 FastAPI 버전이 배포되었다고 가정하자.
Pod
Running
Ready
Kubernetes 관점에서는 정상이다.
하지만 실제 사용자의 요청에서는:
HTTP 500 = 10%
일 수 있다.
또는:
P95 Latency
200ms → 2,000ms
가 될 수도 있다.
따라서 다음 두 가지를 구분해야 한다.
Infrastructure Health
+
Application Health
Progressive Delivery에서는 배포 중 실제 애플리케이션 지표를 확인할 수 있다.
Argo Rollouts는 Kubernetes Deployment를 확장하여 고급 배포 전략을 제공하는 Kubernetes Controller다.
대표적으로:
Rolling Update
Blue/Green
Canary
배포를 지원한다.
특히 Prometheus와 연결하여 다음과 같은 구조를 만들 수 있다.
Argo Rollouts
│
│ Analysis
▼
Prometheus
│
├── Error Rate
├── Latency
├── Request Rate
└── Availability
그리고 지표가 기준을 만족하지 못하면:
Rollout
↓
Failure
↓
Abort
↓
Rollback
구조로 연결할 수 있다.
앞서 만든 GitOps 구조에 Argo Rollouts를 추가하면 다음과 같다.
Developer
│
▼
Git
│
▼
GitHub Actions
│
┌────────┴────────┐
▼ ▼
Test Build
│
▼
Container Registry
│
▼
GitOps Repository
│
▼
Argo CD
│
▼
Argo Rollouts
│
▼
Kubernetes
│
┌──────────┼──────────┐
▼ ▼ ▼
FastAPI Redis PostgreSQL
│
▼
┌──────────────┐
│ Observability│
└───────┬──────┘
│
┌───────────┼───────────┐
▼ ▼ ▼
Prometheus Loki Tempo
│ │ │
└───────────┼───────────┘
▼
Grafana
│
▼
Alertmanager
│
Slack / Email
여기서 핵심은 Argo Rollouts가 Prometheus를 배포 검증에 사용한다는 것이다.
예를 들어 Pod가 4개라면:
v1 v1 v1 v1
새 버전 배포:
v2 v1 v1 v1
v2 v2 v1 v1
v2 v2 v2 v1
v2 v2 v2 v2
일반적인 Kubernetes Deployment의 Rolling Update 방식이다.
Canary에서는 새 버전을 먼저 일부 트래픽에 노출한다.
v1 v1 v1 v1
│
▼
v2
예:
v1 = 90%
v2 = 10%
검증:
Error Rate = 0.3%
Latency = 180ms
정상이면:
v1 = 75%
v2 = 25%
다시 검증한다.
Blue/Green은 두 개의 환경을 동시에 운영하는 방식이다.
Blue
Version 1
████████████████████
│
│ Traffic
▼
User
새 버전은 Green에서 실행한다.
Blue
Version 1
████████████████████
Green
Version 2
████████████████████
Green을 검증한 후 트래픽을 전환한다.
Before:
User
↓
Blue v1
After:
User
↓
Green v2
문제가 발생하면 다시 Blue로 트래픽을 전환한다.
| 항목 | Blue/Green | Canary |
|---|---|---|
| 기존 버전 | 유지 | 유지 |
| 신규 버전 | 별도 환경 | 일부 Pod/Traffic |
| 트래픽 | 한 번에 전환 | 점진적 전환 |
| 검증 | 전환 전 | 단계별 |
| Rollback | 트래픽 전환 | 이전 단계로 중단 |
| 리소스 사용량 | 상대적으로 큼 | 상대적으로 작음 |
| 적합한 상황 | 빠른 전환 | 점진적인 위험 감소 |
둘 중 어느 것이 항상 적합한 것은 아니다.
서비스 특성과 트래픽 구조, 인프라 비용, 데이터 변경 방식 등을 고려해야 한다.
Argo Rollouts Controller를 Kubernetes에 설치한다.
kubectl create namespace argo-rollouts
Argo Rollouts 설치:
kubectl apply -n argo-rollouts \
-f https://raw.githubusercontent.com/argoproj/argo-rollouts/stable/manifests/install.yaml
확인:
kubectl get pods -n argo-rollouts
예:
NAME READY
argo-rollouts-xxxxx 1/1
CLI도 설치할 수 있다.
kubectl argo rollouts version
Rollout 목록:
kubectl argo rollouts list rollouts \
-n tax-prod
상세 상태:
kubectl argo rollouts get rollout backend \
-n tax-prod
실시간 Watch:
kubectl argo rollouts get rollout backend \
-n tax-prod \
--watch
배포 상태를 터미널에서 실시간으로 확인할 수 있다.
일반 Kubernetes Deployment:
apiVersion: apps/v1
kind: Deployment
Argo Rollouts:
apiVersion: argoproj.io/v1alpha1
kind: Rollout
예:
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: backend
spec:
replicas: 4
selector:
matchLabels:
app: backend
template:
metadata:
labels:
app: backend
spec:
containers:
- name: backend
image: registry.example.com/tax-backend:1.5.0
ports:
- containerPort: 8000
strategy:
canary:
steps:
- setWeight: 10
- pause:
duration: 5m
- setWeight: 25
- pause:
duration: 5m
- setWeight: 50
- pause:
duration: 10m
이 설정에서는:
10%
↓
5분
↓
25%
↓
5분
↓
50%
↓
10분
순서로 진행한다.
Canary에서는 단순히 새 Pod를 만드는 것보다 Traffic을 어떻게 분배할 것인가가 중요하다.
구조:
Service
│
┌──────┴──────┐
▼ ▼
Stable Canary
v1 v2
Traffic:
Stable = 90%
Canary = 10%
다만 실제 정확한 트래픽 분배 방식은 Kubernetes Service, Ingress Controller 또는 Gateway API와 Argo Rollouts의 연동 방식에 따라 달라진다.
즉 setWeight: 10이라는 선언만 보고 모든 환경에서 정확히 HTTP 트래픽 10%가 보장된다고 생각하면 안 된다.
Canary 환경에서는 Stable과 Canary를 구분하기 위해 Service를 사용하는 구조가 일반적이다.
예:
apiVersion: v1
kind: Service
metadata:
name: backend-stable
spec:
selector:
app: backend
ports:
- port: 80
targetPort: 8000
Canary Service:
apiVersion: v1
kind: Service
metadata:
name: backend-canary
spec:
selector:
app: backend
ports:
- port: 80
targetPort: 8000
Argo Rollouts가 실제 ReplicaSet과 Service 연결을 관리한다.
Blue/Green은 다음과 같이 설정할 수 있다.
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: backend
spec:
replicas: 4
selector:
matchLabels:
app: backend
template:
metadata:
labels:
app: backend
spec:
containers:
- name: backend
image: registry.example.com/tax-backend:1.5.0
ports:
- containerPort: 8000
strategy:
blueGreen:
activeService: backend-active
previewService: backend-preview
autoPromotionEnabled: false
scaleDownDelaySeconds: 30
핵심은 두 개의 Service다.
backend-active
↓
현재 Production
backend-preview
↓
새로운 Version
현재:
Active
v1
████████████████████
새 버전:
Preview
v2
████████████████████
사용자는 계속 v1을 사용한다.
User
↓
Active Service
↓
v1
운영자는 Preview를 검증한다.
Preview
↓
Health Check
↓
Prometheus
↓
Loki
↓
Tempo
검증이 완료되면 Promotion한다.
v2
↓
Promotion
↓
Active
이제 Progressive Delivery의 핵심 부분이다.
단순한 Health Check:
Pod = Ready
만 사용하는 것이 아니라 Prometheus Metrics를 이용한다.
예:
HTTP Error Rate
HTTP Latency
Request Rate
CPU
Memory
Restart
Availability
특히 애플리케이션 배포 검증에는 다음과 같은 지표가 중요하다.
5xx Error Rate
P95 Latency
P99 Latency
Request Success Rate
Argo Rollouts에서는 AnalysisTemplate을 사용해 배포 검증 조건을 정의할 수 있다.
예:
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
name: backend-success-rate
spec:
metrics:
- name: success-rate
interval: 1m
count: 5
successCondition: result[0] >= 0.99
failureLimit: 2
provider:
prometheus:
address: http://prometheus-operated.monitoring.svc:9090
query: |
(
sum(
rate(
http_requests_total{
app="backend",
status!~"5.."
}[5m]
)
)
)
/
sum(
rate(
http_requests_total{
app="backend"
}[5m]
)
)
핵심은:
successCondition
이다.
예:
result >= 0.99
이면 성공이다.
성공률 대신 Error Rate를 사용할 수도 있다.
예를 들어:
HTTP 5xx < 1%
를 배포 성공 기준으로 정한다고 하자.
개념적으로:
sum(
rate(http_requests_total{
app="backend",
status=~"5.."
}[5m])
)
/
sum(
rate(http_requests_total{
app="backend"
}[5m])
)
결과:
0.003
이면:
0.3%
이다.
기준:
< 0.01
이면 성공이다.
HTTP 응답시간도 매우 중요하다.
예를 들어 P95 Latency를 측정한다고 하자.
histogram_quantile(
0.95,
sum(
rate(
http_request_duration_seconds_bucket{
app="backend"
}[5m]
)
) by (le)
)
결과가:
0.23
이라면:
P95 = 230ms
가 된다.
배포 기준:
P95 < 500ms
등으로 정의할 수 있다.
Rollout에서 AnalysisTemplate을 사용한다.
strategy:
canary:
analysis:
templates:
- templateName: backend-success-rate
steps:
- setWeight: 10
- pause:
duration: 5m
- setWeight: 25
- pause:
duration: 5m
- setWeight: 50
- pause:
duration: 10m
흐름:
10%
↓
Prometheus Analysis
↓
Success?
│
├── Yes → 25%
│
└── No → Abort
이제 핵심 기능을 연결할 수 있다.
New Version
↓
Canary 10%
↓
Prometheus
↓
Error Rate
│
├── 정상
│ ↓
│ 25%
│
└── 이상
↓
Abort
↓
Rollback
예를 들어:
v1 = stable
v2 = canary
배포 직후:
v2 Error Rate = 0.3%
정상.
하지만:
v2 Error Rate = 12%
가 발생하면 Analysis가 실패할 수 있다.
그러면:
Canary
↓
Abort
↓
Rollback
↓
Stable v1
으로 돌아간다.
자동 Rollback을 설계할 때 단순히 다음 조건 하나만 사용하는 것은 위험할 수 있다.
CPU > 80%
CPU가 높다고 반드시 장애인 것은 아니기 때문이다.
따라서 애플리케이션 특성에 맞게 여러 지표를 조합한다.
예:
5xx Error Rate < 1%
AND
P95 Latency < 500ms
AND
Availability > 99.9%
또는 다음과 같이 단계별로 구성할 수 있다.
Canary 10%
↓
Error Rate 검증
↓
Latency 검증
↓
Canary 25%
↓
Error Rate 검증
↓
Latency 검증
↓
Canary 50%
이 구조에서 GitHub Actions가 모든 배포를 직접 수행하는 것은 아니다.
GitHub Actions의 핵심 역할:
Code
↓
Test
↓
Build
↓
Image
↓
Registry
그리고 GitOps Repository를 변경한다.
values-prod.yaml
image:
tag: "1.6.0"
Commit:
Update backend to 1.6.0
Argo CD는 GitOps Repository를 감시한다.
GitOps
│
│ image = 1.6.0
▼
Argo CD
│
▼
Kubernetes
Argo CD는 Rollout Resource를 Kubernetes에 적용한다.
Rollout
image: 1.6.0
그리고 실제 Progressive Delivery는 Argo Rollouts Controller가 담당한다.
즉 역할을 분리하면:
GitHub Actions
= Build
Git
= Desired State
Argo CD
= Git → Kubernetes Sync
Argo Rollouts
= Progressive Delivery
Prometheus
= Deployment Verification
실전에서 가장 중요한 부분이다.
Developer
│
│ git push
▼
GitHub
│
▼
GitHub Actions
│
├── Test
├── Build
└── Docker Push
│
▼
Container Registry
│
▼
GitOps Repository
│
│ image tag 변경
▼
Argo CD
│
▼
Argo Rollouts
│
▼
Canary 10%
│
▼
Prometheus
│
┌────┴────┐
│ │
정상 이상
│ │
▼ ▼
25% Abort
│ │
▼ ▼
50% Rollback
│ │
▼ ▼
100% Stable
앞에서 만든 구조를 Progressive Delivery까지 확장하면 다음과 같이 구성할 수 있다.
gitops-repo
│
├── apps
│ │
│ └── tax-app
│ │
│ ├── Chart.yaml
│ ├── values.yaml
│ ├── values-dev.yaml
│ ├── values-prod.yaml
│ │
│ └── templates
│ ├── rollout.yaml
│ ├── service.yaml
│ ├── analysis-template.yaml
│ ├── ingress.yaml
│ ├── configmap.yaml
│ └── secret.yaml
│
└── argocd
└── tax-app.yaml
기존 Deployment Template을 Rollout Template으로 변경할 수 있다.
예:
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: {{ include "tax-app.fullname" . }}
spec:
replicas: {{ .Values.replicaCount }}
selector:
matchLabels:
app: backend
template:
metadata:
labels:
app: backend
spec:
containers:
- name: backend
image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
ports:
- containerPort: 8000
strategy:
canary:
steps:
- setWeight: 10
- pause:
duration: 5m
- setWeight: 25
- pause:
duration: 5m
- setWeight: 50
- pause:
duration: 10m
개발 환경에서는 Canary 단계를 빠르게 할 수 있다.
strategy:
canary:
steps:
- setWeight: 50
- pause:
duration: 1m
- setWeight: 100
개발 환경에서는 빠른 피드백이 중요하다.
Production에서는 더 신중하게 구성할 수 있다.
strategy:
canary:
steps:
- setWeight: 5
- pause:
duration: 10m
- setWeight: 10
- pause:
duration: 10m
- setWeight: 25
- pause:
duration: 15m
- setWeight: 50
- pause:
duration: 20m
- setWeight: 100
구체적인 비율과 대기 시간은 서비스 트래픽과 위험도에 맞춰 결정해야 한다.
Canary가 시작되면 Grafana에서 Stable과 Canary를 비교할 수 있다.
Stable Canary
Request 10,000 1,000
5xx 20 150
Error Rate 0.2% 15%
P95 200ms 1,200ms
이 경우 Canary에 문제가 있다고 판단할 수 있는 지표가 나타난다.
Argo Rollouts의 Analysis가 Prometheus에서 해당 값을 읽어 배포를 중단하도록 구성할 수 있다.
Prometheus가 숫자를 알려준다면 Loki는 원인을 찾는 데 도움을 준다.
예:
{namespace="tax-prod", app="backend"}
|= "ERROR"
Canary ReplicaSet을 구분할 수 있도록 라벨을 구성하면 더욱 편리하다.
예:
app=backend
rollout=backend
revision=abc123
검색:
{app="backend", revision="abc123"}
|= "ERROR"
이렇게 하면 특정 배포 Revision의 로그만 확인할 수 있다.
Canary에서 응답 시간이 증가했다면 Tempo를 이용해 Trace를 확인할 수 있다.
예:
Request
│
▼
FastAPI
│
├── Redis
│
└── PostgreSQL
Stable:
DB = 50ms
Canary:
DB = 900ms
그러면 코드 변경으로 인해 특정 DB Query가 느려졌을 가능성을 조사할 수 있다.
결국 배포 검증은 다음과 같이 구성된다.
Canary
│
┌──────────┼──────────┐
▼ ▼ ▼
Prometheus Loki Tempo
│ │ │
Metrics Logs Trace
│ │ │
└──────────┼──────────┘
▼
Analysis
│
┌──────┴──────┐
▼ ▼
Success Failure
│ │
▼ ▼
Promote Abort
│ │
▼ ▼
100% Rollback
이것이 Observability와 Progressive Delivery가 연결되는 핵심 구조다.
실제 운영 환경을 만들었다면 반드시 실패 상황도 테스트해야 한다.
새 버전에서 의도적으로 오류를 발생시킨다.
HTTP 500
Prometheus:
Error Rate ↑
Analysis:
Failure
Rollout:
Abort
의도적으로 API 응답을 지연시킨다.
import time
time.sleep(3)
Prometheus:
P95 Latency ↑
Analysis 실패:
Abort
잘못된 환경변수를 사용한다.
CrashLoopBackOff
Readiness 실패:
Progressing
또는:
Degraded
상태가 발생할 수 있다.
다음 명령으로 상태를 확인한다.
kubectl argo rollouts get rollout backend \
-n tax-prod
예:
Name: backend
Namespace: tax-prod
Status: Healthy
Strategy: Canary
배포 중에는:
Step: 2/5
Weight: 25%
등의 상태를 확인할 수 있다.
문제가 발견되면 Rollout을 중단할 수 있다.
kubectl argo rollouts abort backend \
-n tax-prod
상태 확인:
kubectl argo rollouts get rollout backend \
-n tax-prod
이후 안정 버전으로 복구되는지 확인한다.
Canary 단계에서 대기하도록 구성했다면 운영자가 다음 단계로 진행시킬 수도 있다.
kubectl argo rollouts promote backend \
-n tax-prod
예:
10%
↓
검증
↓
Manual Approval
↓
25%
Production에서는 이러한 승인 절차를 적절히 활용할 수 있다.
반대로 모든 Analysis가 성공하면 자동으로 다음 단계로 넘어가게 구성할 수도 있다.
10%
↓
Analysis
↓
Success
↓
25%
↓
Analysis
↓
Success
↓
50%
↓
Analysis
↓
Success
↓
100%
이 경우 사람이 직접 Promotion할 필요가 없다.
최종적으로 다음과 같은 자동화가 가능하다.
Git Push
↓
CI
↓
Image Build
↓
GitOps
↓
Argo CD
↓
Argo Rollouts
↓
Canary 10%
↓
Prometheus
│
├── 정상 → 25%
│
└── 이상 → Abort
↓
Rollback
즉 사람이 배포 결과를 계속 지켜보지 않아도 일정한 조건에 따라 배포를 중단할 수 있다.
자동화가 모든 문제를 해결하는 것은 아니다.
예를 들어 Database Migration이 있다.
Version 1
DB Schema A
Version 2
DB Schema B
Version 2가 배포된 후:
DB Schema 변경
이 발생했다면 애플리케이션만 Version 1로 되돌리는 것이 안전하지 않을 수 있다.
따라서 DB 변경은:
Backward Compatible Migration
등을 고려해야 한다.
예:
Deploy DB-compatible code
↓
Migration
↓
New Application
↓
Old Code 제거
처럼 단계적으로 변경하는 것이 중요하다.
Argo Rollouts가 Runtime에서 Rollback을 수행하더라도 Git의 Desired State와 일관성을 유지해야 한다.
예를 들어:
Git
v1.6.0
인데 Runtime이:
v1.5.0
으로 돌아가 있다면 Drift가 발생할 수 있다.
따라서 최종적으로는 GitOps Repository도 수정해야 한다.
Incident
↓
Rollback
↓
서비스 복구
↓
GitOps Repository 수정
↓
v1.5.0
↓
Argo CD Sync
Progressive Delivery는 단순한 배포 기술이 아니다.
SRE의 핵심 개념인 서비스 안정성과 연결된다.
예를 들어:
SLO
99.9%
라고 가정한다.
배포 중:
Availability
99.95%
라면 정상 범위다.
하지만:
Availability
98.5%
로 떨어진다면 배포를 계속 진행하는 것이 적절하지 않을 수 있다.
즉 배포 정책도 SLO와 연결할 수 있다.
SRE에서는 Error Budget을 사용할 수 있다.
예:
SLO = 99.9%
그러면 허용되는 장애 수준은:
0.1%
이다.
Progressive Delivery에서 이 기준을 활용할 수 있다.
Canary
↓
Error Rate
↓
SLO 기준 확인
↓
허용 범위?
│
├── Yes → Continue
│
└── No → Abort
이렇게 하면 "배포를 무조건 빠르게 하는 것"이 아니라 서비스 안정성을 고려한 배포가 가능해진다.
Production에서는 다음과 같은 Dashboard를 만들어두면 좋다.
==================================================
Kubernetes Progressive Delivery
==================================================
Application
backend
Version
Stable : 1.5.0
Canary : 1.6.0
Rollout
25%
--------------------------------------------------
Traffic
Stable 75%
Canary 25%
--------------------------------------------------
HTTP
Request Rate
5xx Error Rate
P95 Latency
P99 Latency
--------------------------------------------------
Resources
CPU
Memory
Restart
--------------------------------------------------
Observability
Logs
Traces
--------------------------------------------------
Rollout
Analysis: PASS
Next Step: 50%
==================================================
운영자는 하나의 Dashboard에서 배포 상태와 서비스 상태를 함께 볼 수 있다.
최종적으로 장애가 발생하면 다음과 같이 움직인다.
Deployment
│
▼
Canary
│
▼
Prometheus
│
Error Rate ↑
│
▼
Analysis Fail
│
▼
Argo Rollouts
│
▼
Abort
│
▼
Rollback
│
▼
Stable Version
│
▼
Grafana
│
┌─────────┴─────────┐
▼ ▼
Loki Tempo
│ │
└─────────┬─────────┘
▼
Root Cause
│
▼
Git Fix
│
▼
CI
│
▼
GitOps
│
▼
Argo CD
지금까지 구축한 모든 기술을 하나로 연결하면 다음과 같은 구조가 된다.
Developer
│
▼
┌─────────────┐
│ Git │
└──────┬──────┘
│
▼
┌──────────────────┐
│ GitHub Actions │
│ │
│ Test │
│ Build │
│ Security Scan │
└────────┬─────────┘
│
▼
┌──────────────────┐
│ Container │
│ Registry │
└────────┬─────────┘
│
▼
┌──────────────────┐
│ GitOps Repository│
│ Helm / YAML │
└────────┬─────────┘
│
▼
┌───────────┐
│ Argo CD │
└─────┬─────┘
│
▼
┌────────────────┐
│ Argo Rollouts │
└───────┬────────┘
│
┌──────┴───────┐
▼ ▼
Stable Canary
v1 v2
│ │
└──────┬───────┘
│
▼
Kubernetes
│
▼
┌─────────────────┐
│ Observability │
└────────┬────────┘
│
┌────────────┼────────────┐
▼ ▼ ▼
Prometheus Loki Tempo
│ │ │
└────────────┼────────────┘
▼
Grafana
│
▼
Alertmanager
│
┌──────┴──────┐
▼ ▼
Slack Email
이 구조를 가장 간단하게 표현하면 다음과 같다.
개발자가 코드 변경
↓
Git Push
↓
GitHub Actions
↓
Test
↓
Build
↓
Container Image
↓
Registry
↓
GitOps Repository 변경
↓
Argo CD
↓
Argo Rollouts
↓
Canary 5%
↓
Prometheus 검증
↓
정상?
┌───┴───┐
│ │
Yes No
│ │
▼ ▼
10% Abort
│ │
▼ ▼
25% Rollback
│
▼
50%
│
▼
100%
│
▼
Production 완료
이제 각 도구의 역할을 명확하게 구분할 수 있어야 한다.
| 기술 | 역할 |
|---|---|
| Git | 코드 및 Desired State 관리 |
| GitHub Actions | CI / Build / Test |
| Container Registry | Image 저장 |
| Helm | Kubernetes Package |
| Argo CD | GitOps 동기화 |
| Argo Rollouts | Progressive Delivery |
| Kubernetes | Container 실행 |
| Prometheus | Metrics |
| Grafana | Visualization |
| Loki | Logs |
| Tempo | Distributed Tracing |
| Alertmanager | Alert |
| SRE | 운영 방법론 |
특히 다음 네 가지를 기억하면 된다.
Argo CD
= 무엇을 배포할 것인가
Argo Rollouts
= 어떻게 점진적으로 배포할 것인가
Prometheus
= 배포 후 정상인가
Grafana/Loki/Tempo
= 문제가 있다면 어디서 왜 발생했는가
기존:
Git
↓
Argo CD
↓
Kubernetes
↓
100% 배포
Progressive Delivery:
Git
↓
Argo CD
↓
Argo Rollouts
↓
5%
↓
Prometheus
↓
검증
↓
10%
↓
검증
↓
25%
↓
검증
↓
50%
↓
검증
↓
100%
장애가 발생하면:
Prometheus
↓
Analysis Failure
↓
Argo Rollouts
↓
Abort
↓
Rollback
즉 배포 과정 자체가 관찰 가능한 자동화 프로세스가 된다.
지금까지 Kubernetes 운영 환경을 단계적으로 발전시키면 다음과 같은 구조가 만들어진다.
Kubernetes
↓
Helm
↓
GitOps
↓
Argo CD
↓
Argo Rollouts
↓
Progressive Delivery
↓
Prometheus
↓
Automated Verification
↓
Automatic Rollback
↓
Grafana / Loki / Tempo
↓
Incident Analysis
↓
SRE
여기서 중요한 것은 각각의 도구를 따로 사용하는 것이 아니다.
전체 흐름을 하나의 운영 시스템으로 연결하는 것이 핵심이다.
최종적으로는 다음과 같은 환경을 만들 수 있다.
개발자가 Git에 코드를 Push하면 CI가 테스트와 이미지를 생성하고, GitOps Repository에 배포 상태가 기록되며, Argo CD가 Kubernetes에 변경을 전달한다. Argo Rollouts는 새로운 버전을 Canary 또는 Blue/Green 방식으로 점진적으로 배포하고, Prometheus의 Error Rate·Latency·Availability 등을 이용해 배포 상태를 자동 검증한다. 문제가 발생하면 Rollout을 중단하고 이전 버전으로 복구하며, Grafana·Loki·Tempo를 통해 장애 원인을 분석한다.
이것이 CI/CD → GitOps → Progressive Delivery → Observability → Automated Rollback → SRE로 이어지는 실전 Kubernetes DevOps 운영 구조다.