Deployment와 Pod

• 계속해서, ArgoCD를 하향식으로 학습해 나가본다.
• 다음으로는 Deployment(전략) -> ReplicaSet(관리) -> Pod(실체) 순서로 내려가게 된다.

• 백엔드 개발자에게 익숙한 개념으로 비유해보자.
  • Deployment : 배포 전략서 (Blue/Green을 할지, Rolling을 할지, 버전은 뭔지)
  • ReplicaSet : "인스턴스 개수 유지 장치" (Scale-out 담당)
  • Pod : 실제 실행중인 Spring Boot 프로세스

1. Pod (파드): K8s의 가장 작은 원자 단위

많은 사람이 "K8s는 컨테이너를 관리한다"고 생각하지만, 사실은 K8s는 Pod를 관리한다.

• 개념 : 컨테이너를 감싸고 있는 껍데기이다.
• 특징
  • 1 Pod = 1 IP : Pod 하나마다 고유한 내부 IP를 할당받는다.
  • 일회용(Ephemeral) : Pod는 영원하지 않다. 죽으면 되살리는 게 아니라, 폐기하고 새로운 Pod를 만든다
  • 다중 컨테이너 : 보통은 Spring Boot 컨테이너 1개만 들어가지만, 로그 수집기나 프록시 같은 보조 컨테이너(Sidecar)를 옆에 끼워서 같이 띄울 수도 있다.
    • 이들은 localhost로 통신한다.

2. ReplicaSet (레플리카셋): 개수를 보장하는 중간 관리자

ArgoCD 화면에서 api-deployment-xxxxx 같은 이름으로 여러 개 보였던 녀석들이다.

• 역할: 무조건 N개를 유지해
• 동작: 사용자가 "Replicas: 3"이라고 설정하면, 현재 파드가 2개면 1개를 더 만들고, 4개면 1개를 죽인다.
  • 단순 무식하게 숫자를 맞춘다.
• 중요한 점: 우리는 이 ReplicaSet을 직접 만들지 않는다. Deployment가 알아서 만든다

3. Deployment: 진정한 관리자 (배포의 핵심)

우리가 작성하는 YAML 파일의 90%는 바로 이 Deployment이다.

• 역할: 앱의 버전 관리와 배포 전략을 담당한다.
• 핵심 기능:
  • 배포 이력 관리 : ArgoCD에서 본 회색 박스(과거 ReplicaSet)을 보관하고 있어, 언제든 롤백이 가능하다.
  • 무중단 배포 : 기존 Pod를 하나씩 죽이면서, 새 버전 Pod를 하나씩 띄우는 과정을 쥐휘한다.

4. 실제 YAML 뜯어보기

이제 "Deployment"가 어떻게 생겼는지 코드로 보자.
주석을 통해 각 설정이 Spring Boot 앱에 어떤 영향을 주는지 설명해 두었다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api # 앱 이름
spec:
  replicas: 2 # 서버 2대 띄워줘 (Scale-out)
  selector:
    matchLabels:
      app: api # 이 라벨이 붙은 Pod를 관리할게
  template:
    metadata:
      labels:
        app: api
  spec:
    containers:
      - name: api-container
        image: my-repo/api:v2.0.0 # 배포할 버전
        ports:
          - containerPort: 8080
 
        # 중요! 헬스 체크 (이게 없으면 배포 중 에러 나도 보름)
        readinessProbe: # 요청 받은 준비 됐는지 확인
          httpGet:
            path: /actuator/health
            port: 8080
          initialDelaySeconds: 30 # 앱 뜨는데 30초 기다려줘
        livenssProbe:
          httpGet:
            path: /actuator/health
            port: 8080

5. 배포의 마법: Rolling Update 과정

개발자가 이미지 태그를 v1에서 v2로 바꾸고 kubectl apply를 하면 무슨 일이 벌어질까?

1. Deployment가 "어? 버전이 바뀌었네?"라고 감지한다.
2. Deployment는 새로운 ReplicaSet(v2용)을 만든다. (아직 Pod 개수는 0)
3. Deployment가 새 RS에게 "Pod 1개 만들어봐"라고 시킨다. -> v2 Pod 1개 생성
4. 새 Pod가 ReadinessProbe (헬스 체크)를 통과해서 "준비 완료" 상태가 되면,
5. Deployment는 기존 RS(v1용)에게 "Pod를 1개 줄여"라고 시킨다. -> v1 Pod 1개 삭제
6. 이 과정을 목표 개수 (Replicas: 2)가 될 떄까지 반복한다.
7. 결과: 사용자는 다운타임 없이 v1에서 v2로 자연스럽게 넘어간다.