Argo Rollouts Pod 재시작 방법

배경

Argo CD에서 Helm Chart를 이용해 애플리케이션을 배포하고, Argo Rollouts로 Blue/Green 배포 전략을 구성했다.

기존 Deployment 환경에서는 다음 명령으로 Pod를 재시작했다.

kubectl rollout restart deployment <deployment명> -n <네임스페이스>

하지만 Argo Rollouts의 Rollout 리소스는 Kubernetes 기본 Deployment와 다른 리소스다.

따라서 Rollout으로 관리하는 Pod를 재시작하려면 Argo Rollouts 전용 명령이나 spec.restartAt 필드를 사용해야 한다.

먼저 구분하기: Argo CD, Helm, Argo Rollouts

각 구성요소의 역할을 구분하면 재시작 대상이 명확해진다.

재시작 명령은 Helm Chart 이름이 아니라 실제 생성된 Rollout 리소스 이름을 대상으로 실행한다.

Argo CD Application 이름과 Rollout 이름도 서로 다를 수 있다.

1. Rollout 리소스 확인

배포된 Rollout 목록을 확인한다.

kubectl get rollouts.argoproj.io -n <네임스페이스>

NAME          DESIRED   CURRENT   UP-TO-DATE   AVAILABLE
example-app   3         3         3            3

상세 설정을 확인하려면 다음 명령을 사용한다.

kubectl get rollouts.argoproj.io "example-app" \
  -n "my-app" \
  -o yaml

Blue/Green 전략을 사용하는 Rollout에는 다음과 같은 설정이 있다.

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: example-app
spec:
  strategy:
    blueGreen:
      activeService: example-app-active
      previewService: example-app-preview
      autoPromotionEnabled: false

2. Argo Rollouts CLI로 재시작

플러그인 확인

다음 명령이 실행되는지 확인한다.

kubectl argo rollouts version

명령을 인식하지 못한다면 kubectl-argo-rollouts 플러그인이 설치되어 있고, 실행 파일이 PATH에 포함되어 있는지 확인한다.

재시작 실행

kubectl argo rollouts restart "example-app" \
  -n "my-app"

예제 값을 직접 입력하면 다음과 같다.

kubectl argo rollouts restart example-app -n my-app

이 명령은 Rollout의 spec.restartAt을 갱신하여 Pod 재시작을 요청한다.

진행 상태 확인

kubectl argo rollouts get rollout "example-app" \
  -n "my-app" \
  --watch

별도 터미널에서는 Pod 교체 상태를 확인할 수 있다.

kubectl get pods -n "my-app" -w

네임스페이스에 여러 애플리케이션이 있다면 실제 워크로드의 라벨에 맞춰 조회 범위를 제한한다.

3. 플러그인 없이 kubectl patch로 재시작

Argo Rollouts CLI 플러그인을 설치하기 어려운 환경에서는 spec.restartAt을 직접 변경할 수 있다.

다음 예제는 Bash 기준이다.

NAMESPACE=my-app
ROLLOUT=example-app

RESTART_AT="$(date -u +%Y-%m-%dT%H:%M:%SZ)"

kubectl patch rollouts.argoproj.io "example-app" \
  -n "my-app" \
  --type merge \
  -p "{\"spec\":{\"restartAt\":\"${RESTART_AT}\"}}"

변경된 값을 확인한다.

kubectl get rollouts.argoproj.io "example-app" \
  -n "my-app" \
  -o jsonpath='{.spec.restartAt}{"\n"}'

restartAt은 RFC 3339 형식의 UTC 시각이다.

컨트롤러는 이 시각보다 먼저 생성된 Pod를 재시작 대상으로 판단한다. 미래 시각을 지정하면 해당 시각 이후에 재시작을 시작하도록 예약할 수도 있다.

4. Argo CD Web UI에서 재시작

Argo CD에는 Rollout용 restart 리소스 액션이 제공된다.

1. Argo CD에서 대상 Application을 연다.
2. 리소스 트리에서 Rollout 리소스를 선택한다.
3. 리소스 액션 메뉴에서 Restart를 실행한다.
4. Rollout과 Pod 상태를 확인한다.

Application 전체를 다시 Sync하는 것과 Rollout의 Restart 액션을 실행하는 것은 다른 작업이다.

Argo CD CLI에서도 실행할 수 있다.

argocd app actions run <Application명> restart \
  --kind Rollout \
  --resource-name <rollout명>

예시:

argocd app actions run example-application restart \
  --kind Rollout \
  --resource-name example-app

여기서 example-application은 Argo CD Application 이름이고, example-app은 Kubernetes Rollout 리소스 이름이다.

5. Deployment 재시작과 무엇이 다른가?

먼저 명령어부터 구분해야 한다.

# Kubernetes Deployment
kubectl rollout restart deployment example-app -n my-app

# Argo Rollouts의 Rollout
kubectl argo rollouts restart example-app -n my-app

kubectl restart deploy가 아니라 kubectl rollout restart deployment가 정확한 명령이다.

핵심 비교

Deployment: Pod 템플릿을 변경해 업데이트 유도

kubectl rollout restart deployment는 Pod 템플릿에 재시작 시각 annotation을 설정하는 방식이다.

개념적으로 다음 위치가 변경된다.

spec:
  template:
    metadata:
      annotations:
        kubectl.kubernetes.io/restartedAt: "<재시작 시각>"

Pod 템플릿이 바뀌므로 새로운 ReplicaSet이 생성되고, Deployment에 설정된 전략에 따라 Pod를 교체한다.

일반적인 RollingUpdate 환경에서는 새 ReplicaSet의 Pod를 늘리면서 기존 ReplicaSet의 Pod를 줄인다.

Argo Rollouts: 기존 ReplicaSet 안에서 Pod 재생성

Argo Rollouts의 재시작은 다음 필드를 변경한다.

spec:
  restartAt: "<재시작 시각>"

spec.template을 변경하지 않으므로 재시작 자체로 새 ReplicaSet을 만들지 않는다.

컨트롤러는 기존 ReplicaSet에 속한 Pod의 생성 시각을 확인하고, 재시작 기준 시각보다 오래된 Pod를 eviction한다. 이후 ReplicaSet이 대체 Pod를 생성한다.

즉, 새로운 버전을 배포하는 작업이 아니라 기존 버전의 Pod를 다시 만드는 작업이다.

6. Restart는 Blue/Green 재배포가 아니다

Blue/Green 전략을 사용하더라도 restart 명령이 다음 과정을 다시 실행하는 것은 아니다.

새 ReplicaSet 생성
        ↓
Preview 환경 확인
        ↓
Promote
        ↓
Active Service 전환

Restart는 Blue/Green·Canary의 일반적인 업데이트 절차를 건너뛰고 기존 Pod를 재생성한다.

목적에 따라 작업을 구분해야 한다.

수동 승인을 사용하는 Blue/Green 배포에서는 다음 명령으로 승격할 수 있다.

kubectl argo rollouts promote "example-app" \
  -n "my-app"

7. 운영 시 주의사항

단일 Replica에서는 서비스 중단 가능

Argo Rollouts Restart는 기존 Pod를 eviction한 뒤 대체 Pod가 생성되는 방식이다.

Deployment의 RollingUpdate에서 maxSurge를 이용해 새 Pod를 먼저 추가하는 방식과 다르다.

따라서 Replica가 하나뿐이라면 재시작 과정에서 서비스가 중단될 수 있다.

PodDisruptionBudget 확인

Argo Rollouts는 재시작 시 Pod를 직접 삭제하는 대신 eviction을 사용하므로 PodDisruptionBudget을 존중한다.

PDB가 eviction을 허용하지 않으면 재시작이 진행되지 않을 수 있다.

kubectl get pdb -n "my-app"
kubectl describe pdb <PDB명> -n "my-app"

단일 Replica에서 minAvailable: 1처럼 가용 Pod 하나를 반드시 유지하도록 설정했다면, 재시작이 막힐 수 있다는 점을 고려한다.

PDB를 제거하는 방식부터 시도하기보다는 Replica 수와 가용성 요구사항을 함께 검토한다.

재시작 중 Pod 템플릿 변경 주의

재시작 도중 spec.template이 변경되면 Argo Rollouts는 재시작 절차를 취소하고 일반적인 Blue/Green 또는 Canary 업데이트를 진행한다.

이미지 업데이트나 설정 배포 작업과 단순 재시작 작업을 같은 시점에 겹치지 않도록 관리한다.

8. 실무용 명령어 모음

플러그인이 있는 경우

NAMESPACE=my-app
ROLLOUT=example-app

# 대상 확인
kubectl get rollouts.argoproj.io "example-app" -n "my-app"

# 재시작
kubectl argo rollouts restart "example-app" -n "my-app"

# 진행 상태 확인
kubectl argo rollouts get rollout "example-app" \
  -n "my-app" \
  --watch

플러그인이 없는 경우

NAMESPACE=my-app
ROLLOUT=example-app
RESTART_AT="$(date -u +%Y-%m-%dT%H:%M:%SZ)"

# 재시작 요청
kubectl patch rollouts.argoproj.io "example-app" \
  -n "my-app" \
  --type merge \
  -p "{\"spec\":{\"restartAt\":\"${RESTART_AT}\"}}"

# 재시작 기준 시각 확인
kubectl get rollouts.argoproj.io "example-app" \
  -n "my-app" \
  -o jsonpath='{.spec.restartAt}{"\n"}'

# Pod 교체 상태 확인
kubectl get pods -n "my-app" -w

정리

Deployment와 Argo Rollouts는 Pod를 재시작하는 방식이 다르다.

• Deployment는 Pod 템플릿을 변경하여 새로운 ReplicaSet 기반의 업데이트를 유도한다.
• Argo Rollouts는 spec.restartAt을 변경하여 기존 ReplicaSet의 Pod를 재생성한다.
• Rollout Restart는 Blue/Green 신규 배포나 트래픽 전환을 다시 실행하는 명령이 아니다.
• 새 버전을 Blue/Green으로 배포하려면 이미지 등 Pod 템플릿 변경을 Argo CD로 동기화해야 한다.

동일 버전의 Pod만 재시작하려는 경우에는 다음 명령을 사용하면 된다.

kubectl argo rollouts restart <rollout명> -n <네임스페이스>