ArgoCD 배포 시 실패한 Pod는 삭제됐는데 ReplicaSet은 남아있다? 괜찮은 걸까?

 

 

쿠버네티스 환경에서 ArgoCD로 애플리케이션을 배포하다 보면, 실패한 Pod는 삭제됐는데 ReplicaSet(RS)은 계속 남아 있는 상황을 접할 수 있습니다. 처음에는 “이거 뭔가 잘못된 거 아닌가?” 싶지만, 사실은 정상적인 동작입니다. 이번 글에서는 왜 이런 현상이 발생하는지, ReplicaSet을 어떻게 관리해야 하는지 정리해 보겠습니다.

---

1. ReplicaSet이 남는 이유

• Deployment의 기본 동작 원리
  쿠버네티스에서 Deployment(또는 Argo Rollouts)는 직접 Pod를 생성하지 않습니다. 대신 ReplicaSet을 생성하고, ReplicaSet이 파드를 관리합니다. 따라서 파드가 실패해 삭제되더라도 ReplicaSet은 그대로 남아 있으며, 필요 시 새 파드를 다시 만들 준비를 하고 있습니다.
• 롤백 히스토리 보존
  Deployment는 새로운 버전을 배포할 때마다 새로운 ReplicaSet을 생성합니다. 이전 ReplicaSet은 replicas 수가 0으로 줄더라도 롤백을 위해 남겨집니다.

즉, ReplicaSet이 남아 있는 것은 ArgoCD의 문제가 아니라 쿠버네티스의 정상 동작입니다.

---

2. ArgoCD는 ReplicaSet을 관리하지 않는다

ArgoCD는 GitOps 방식으로 쿠버네티스 리소스를 관리하는 도구일 뿐, ReplicaSet의 수명 주기를 직접 통제하지는 않습니다. ReplicaSet을 생성하고 유지하는 주체는 Kubernetes Deployment 컨트롤러이고, ArgoCD는 단순히 이를 보여주고 동기화할 뿐입니다.

---

3. 불필요한 ReplicaSet 관리하기

ReplicaSet이 계속 쌓이면 kubectl get rs 목록이 길어지고 etcd에 불필요한 리소스가 남을 수 있습니다. 이를 방지하려면 Deployment나 Rollout 매니페스트에 다음 설정을 추가하세요:

 

spec:
  revisionHistoryLimit: 2   # 최근 2개만 유지 (롤백 필요 없으면 0도 가능)

 

• 기본값은 10
• 배포가 잦은 환경에서는 2~3 정도로 줄이는 것이 관리상 유리합니다.

---

4. Argo Rollouts 사용 시 주의할 점

Argo Rollouts로 Canary/Blue-Green 배포를 할 경우, ReplicaSet이 더 복잡하게 관리됩니다.

• scaleDownDelaySeconds 설정
  새 ReplicaSet으로 트래픽을 넘길 때 IP 테이블 업데이트가 지연될 수 있습니다. 이 경우 예기치 않게 트래픽이 잘못된 파드로 갈 수 있는데, 이를 방지하려면:

  strategy:
    canary:
      scaleDownDelaySeconds: 30

  
  
• Pause 단계에는 duration 지정
• pause: {}만 두면 무한 대기 상태가 될 수 있습니다.
  

  pause:
    duration: 30s

---

5. 수동 정리 팁

이미 쌓여버린 ReplicaSet을 정리하려면 replicas=0인 오래된 RS만 삭제하면 됩니다.

 

kubectl delete rs $(kubectl get rs -o jsonpath='{ .items[?(@.spec.replicas==0)].metadata.name }')

 

---

6. ReplicaSet이 남아있을 때 신경 써야 하는 경우

일반적으로는 문제가 없지만, 아래와 같은 경우에는 확인이 필요합니다:

• OwnerReference가 없음 → Deployment와의 연결이 끊긴 ‘고아’ RS일 수 있음. 수동 삭제해도 무방.
• replicas > 0인데 오래된 RS가 남아 있음 → 롤아웃이 Pause/Aborted 상태이거나 전환 중일 가능성.
• Deployment 삭제 후에도 RS가 안 지워짐 → Kubernetes garbage collector 문제이거나 --cascade=orphan 옵션 사용 여부 확인 필요.

---

✅ 결론

• 실패한 Pod는 삭제되고 ReplicaSet이 남는 것은 정상 동작
• ArgoCD가 아니라 Kubernetes의 동작 방식
• 불필요하게 쌓이는 것은 revisionHistoryLimit으로 관리
• Argo Rollouts에서는 scaleDownDelaySeconds, pause.duration 같은 추가 설정 고려
• 필요 시 replicas=0인 RS를 수동 정리

즉, ReplicaSet이 남아 있는 것은 문제라기보다 ‘롤백 히스토리’ 기능입니다. 환경에 맞게 관리 전략을 세우는 것이 중요합니다.

---

📚 Reference

• Kubernetes ReplicaSet 공식 문서
• StackOverflow - Clean up ReplicaSets when updating Deployments
• Medium - ReplicaSet not being deleted with Deployment
• Argo Rollouts 공식 문서
• Dev.to - ArgoCD Best Practices
• ArgoCD Discussions - Why do ReplicaSets remain