강의링크

면접 준비가 막막했던 취준생의 JSCODE 제이온님 Java 면접 대비 강의 후기

강의를 듣게 된 계기

현재 2026 하반기 공채를 준비하고 있는 취준생이다. 막상 본격적으로 취준을 시작하려고 하니 할게 정말 정말 많았다.

현재 기본적으로 이력서와 포트폴리오를 작성해둔 상태이지만, 채용 공고를 보다 보면 기업에서 원하는 기술 부분에서 내가 부족한 점이 많다고 생각하여 관련 기술 공부도 하고 포폴도 틈틈히 디벨롭 하고 있다. 개발자다 보니 코테도 준비해야 하고 면접 준비도 해야 한다. 하나를 잡으면 다른 하나가 밀리는 느낌이라 매일 우선순위를 다시 짜는 것도 일이었다.

그 중에서도 제일 막막했던게 면접 준비였던 것 같다. CS로 공부할 내용이 정말 많았다. Java, Spring, DB, 운영체제, 컴퓨터 구조, 네트워크 등... 이 cs를 책 한권을 사서 온전히 공부한 후 기술 면접을 준비하기에는 거의 몇 년이 걸릴 것 같았다. 게다가 책을 처음부터 끝까지 다 읽는다고 해서 그 내용이 그대로 면접 답변이 되는 것도 아니다. 아는 것과 말로 설명할 수 있는 것은 완전히 다른 문제니까. 실제로 혼자 예상 질문을 뽑아서 답변해보려고 하면 "어... 그건 그러니까..." 하다가 끝나는 경우가 많았다. 내가 이해한 게 맞는지, 이 정도 깊이로 대답해도 되는건지 확인해줄 사람이 없다는 게 제일 답답했다.

이런 막막함을 가지고 있을 때 JSCODE 제이온님의 면접 대비 강의를 발견하게 되었다. 나의 막막했던 면접 준비를 조금 수월하게 만들어줄 수 있는 강의였다.

강의는 이렇게 구성되어 있다

해당 강의는 실제 면접 질문에서 많이 나오는 질문들에 대해 어떻게 대답을 하면 좋은지 질문 별로 Bronze, Silver, Gold 답변 예시를 보여준다. 답변에 어떤 키워드가 들어가면 좋은지, 해당 답변에 이은 꼬리 질문에는 어떤 것들이 나올 수 있는지...

이 Bronze / Silver / Gold 구성이 개인적으로 제일 좋았다. 보통 "이 질문엔 이렇게 답하세요" 하고 모범 답안 하나만 주는 자료가 많은데, 이 강의는 부족한 답변부터 잘한 답변까지 단계별로 보여주니까 "내 답변은 지금 어느 단계에 있는지"를 스스로 채점할 수 있다.

나는 실제 강의를 들으면서 속으로 답변을 해보면 최대 silver에서 머물렀다. 하지만 Gold 답변을 보면서 내 답변에서 어디가 부족한지 되짚으면서 들을 수 있었다. 대부분 개념 자체를 몰라서가 아니라, 개념은 알지만 "그래서 그게 왜 중요한지", "실무에서 어떤 문제로 이어지는지"까지 연결하지 못해서 Silver에 머무는 경우였다. 이걸 알게 된 것만으로도 앞으로 CS를 공부하는 방향이 꽤 명확해졌다.

꼬리 질문 파트도 실전에서 진짜 도움이 될 것 같다. 면접에서 제일 무서운 건 첫 질문이 아니라 그 뒤에 따라오는 "그럼 왜 그렇게 동작하나요?" 같은 질문이니까. 미리 어떤 꼬리 질문이 나올 수 있는지 알고 있으면, 답변을 할 때 그 방향까지 염두에 두고 말하게 된다.

강의 내용

내가 이번에 들은 강의는 Java편이었다. 강의는 아래와 같은 섹션으로 이루어져있다.

• JVM과 실행 원리 — 자바 코드가 실제로 어떤 과정을 거쳐 실행되는지. 면접에서 거의 빠지지 않고 나오는 단골 주제다.
• GC — 가비지 컬렉션의 동작 방식과 관련 개념들. 혼자 공부할 때 제일 정리가 안 되던 파트였는데 답변 기준이 생기니 훨씬 잡기 쉬웠다.
• 동시성 이슈 — 멀티스레드 환경에서 생기는 문제와 그걸 다루는 방법. 백엔드 면접이라면 반드시 짚고 넘어가야 하는 부분.
• 객체지향 프로그래밍 — 알고 있다고 생각했지만 막상 말로 설명하려니 제일 애매했던 주제.
• 람다, 스트림 — 실무에서 자주 쓰면서도 "왜 쓰는지"를 설명하라고 하면 막히는 부분.

그리고 특별 부록으로 빈출 질문 PDF도 추가로 제공된다!! 강의를 다 들은 후에 이 PDF로 혼자 셀프 모의면접을 해볼 수 있어서 복습용으로 아주 좋다.

이런 분들께 추천

해당 강의는 Java에 대한 기본 개념이 있다는 전제하에 강의를 진행한다. 하지만 해당 개념 공부를 해본 적 없는 사람이더라도 질문 주제에 대한 개념을 스스로 정리해본 후 강의를 수강하는 것 정도는 괜찮다고 생각하고, CS 면접 대비를 가장 빠르고 완벽하게 해낼 수 있는 방법이라고 생각한다!!

정리하자면,

• 이력서/포폴은 어느정도 준비했는데 면접 준비는 어디서부터 손대야 할지 모르겠는 취준생
• CS 개념은 공부했는데 막상 말로 설명하려니 막히는 사람
• 내 답변이 면접관 기준에서 몇 점짜리인지 확인받고 싶은 사람

이런 분들이라면 한 번 들어볼 만한 강의다. 나도 Java편을 먼저 들었으니, 남은 CS 영역들도 이런 식으로 하나씩 채워나갈 생각이다.

• Remote-SSH는 VSCode의 확장 프로그램으로 만들어져 있다.

2. key pair 권한 수정하기

• key pair는 AWS EC2를 생성할 때 발급받은 키페어이다.
• 해당 Key pair를 ssh라는 빈 폴더를 만들고 그 안에 key pair를 복사해 넣어둔다.
• 위 경로에서 터미널로 파일 권한을 수정해준다.

  // Mac/Linux
  chmod 400 ~/.ssh/your-key.pem
  

// Windows icacls "C:\Users\사용자명.ssh\your-key.pem" /inheritance:r /grant:r "$env:USERNAME:R"

## 3. Remote-SSH: Connect to Host
![](https://velog.velcdn.com/images/jina_ham/post/06f8f7fe-8671-42a5-9b17-38d861cd6006/image.png)
![](https://velog.velcdn.com/images/jina_ham/post/00dba315-2259-4952-ab68-e565f586fde4/image.png)
![](https://velog.velcdn.com/images/jina_ham/post/fd61798a-29ac-4b71-98e3-de0a845210a7/image.png)
![](https://velog.velcdn.com/images/jina_ham/post/87780620-92bf-4f7b-9ea2-e516461c1c50/image.png)

- config파일이 열리면 아래 내용을 입력해준다.

Read more about SSH config files: https://linux.die.net/man/5/ssh_config

Host myec2 HostName [EC2 인스턴스의 IP 주소] User ec2-user IdentityFile ~/.ssh/ec2_key.pem // 실제 키 파일의 위치 StrictHostKeyChecking accept-new

```

• 아래와 같이 myec2가 생성된 것을 볼 수 있다.

• 새로 window가 열리면서 ec2에 원격으로 연결된 것을 볼 수 있다.
• terminal을 통해 ec2에 원격으로 명령어를 입력할 수 있고, 폴더를 관리하기 쉬워진다.

Controller란 무엇인가

Pod를 직접 만들면 관리는 사람의 몫이 된다. Pod가 죽어도 아무도 다시 만들어주지 않고, 트래픽이 늘어도 알아서 늘어나지 않으며, 버전을 올리려면 일일이 지우고 다시 만들어야 한다.

Controller는 Pod를 대신 관리해 주는 오브젝트다. 사용자가 원하는 상태를 선언해 두면, Controller가 현재 상태를 계속 감시하면서 그 상태에 맞추는 작업을 수행한다.

   [ Pod만 직접 만들 때 ]              [ Controller를 쓸 때 ]

   Pod가 죽음                          Pod가 죽음
        │                                   │
        ▼                                   ▼
   사람이 인지                         Controller가 즉시 인지
        │                                   │
        ▼                                   ▼
   사람이 다시 생성                    자동으로 새 Pod 생성

Controller가 제공하는 기능은 네 가지다.

3-1. Controller의 네 가지 기능

Auto Healing

Pod가 죽거나 Pod가 올라가 있는 Node 자체에 장애가 발생하면, Controller가 즉각적으로 인지해서 다른 Node에 Pod를 새로 만든다.

   ┌──────────────────┐
   │   Controller     │  ← 상태를 계속 감시
   └────┬────────┬────┘
        │        │
   장애 인지     새로 생성
        │        │
        ▼        ▼
  ┌──────────┐  ┌──────────┐
  │  Node1   │  │  Node2   │
  │ ┌──────┐ │  │ ┌──────┐ │
  │ │ Pod1 │ │  │ │ Pod1 │ │  ← 새 Node에 다시 생성
  │ │  ✗   │ │  │ │  ✓   │ │
  │ └──────┘ │  │ └──────┘ │
  │  ⚠ 장애  │  │          │
  └──────────┘  └──────────┘

사람이 개입하기 전에 복구가 끝나므로, 엔지니어는 복구 이력만 확인하면 된다.

담당 Controller: ReplicationController, ReplicaSet, DaemonSet

Auto Scaling

Pod의 리소스 사용량이 limit에 도달한 상태를 Controller가 인지하면, Pod를 하나 더 만들어서 부하를 분산시킨다.

   ┌──────────────────┐
   │   Controller     │  ← 리소스 사용량 감시
   └────────┬─────────┘
            │  Pod1이 limit 도달
            ▼
   ┌──────┐        ┌──────────┐
   │ Pod1 │ ─┬───▶ │  Pod1    │  부하 50%
   │ ███  │  │     │  ██      │
   │ 한계 │  │     └──────────┘
   └──────┘  │     ┌──────────┐
             └───▶ │  Pod2    │  부하 50%
                   │  ██      │  ← 새로 생성
                   └──────────┘

Pod를 늘려 부하를 나누므로 서비스가 느려지거나 멈추는 상황을 막을 수 있다.

담당 Controller: HPA (Horizontal Pod Autoscaler)

Software Update

여러 개의 Pod를 한 번에 새로운 버전으로 업그레이드한다. 업데이트 중 문제가 생기면 이전 버전으로 되돌리는 것도 가능하다.

   ┌──────────────────┐
   │   Controller     │
   └────────┬─────────┘
            │
   ┌────────┴─────────────────────┐
   │                              │
   ▼                              ▼
 v1 v1 v1                     v2 v2 v2
 ┌──┐┌──┐┌──┐    ──────▶     ┌──┐┌──┐┌──┐
 │P1││P2││P3│                │P1││P2││P3│
 └──┘└──┘└──┘                └──┘└──┘└──┘
 v1 v1 v1                     v2 v2 v2
 ┌──┐┌──┐┌──┐                ┌──┐┌──┐┌──┐
 │P4││P5││P6│                │P4││P5││P6│
 └──┘└──┘└──┘                └──┘└──┘└──┘

담당 Controller: Deployment

Job

일시적인 작업을 해야 하는 경우, Controller가 필요한 순간에만 Pod를 만든다. 작업이 끝나면 Pod가 사용하던 자원을 반납한다.

   ┌──────────────────┐
   │   Controller     │
   └───┬──────────┬───┘
       │          │
       ▼          ▼
  ┌─────────┐ ┌─────────┐ ┌─────────┐
  │  Pod    │ │  Pod    │ │  Pod    │
  │ (없음)  │→│ (실행)  │→│ (종료)  │
  └─────────┘ └─────────┘ └─────────┘
  Resource    Resource     Resource
  ┌─┐┌─┐┌─┐   ┌─┐┌ ┐┌ ┐    ┌─┐┌─┐┌─┐
  └─┘└─┘└─┘   └─┘└ ┘└ ┘    └─┘└─┘└─┘
  자원 여유    자원 사용중   자원 반납

Pod를 계속 띄워두지 않으므로 자원을 효율적으로 사용할 수 있다.

담당 Controller: Job, CronJob

3-2. ReplicationController와 ReplicaSet

두 Controller의 관계

역할은 같지만 ReplicaSet이 더 발전된 selector 기능을 갖추면서 ReplicationController를 대체했다. 현재는 ReplicaSet을 사용한다.

두 Controller는 세 가지 요소로 구성된다.

Template

Controller를 만들 때 Pod의 내용을 템플릿으로 넣어둔다. Controller가 Pod를 새로 만들어야 할 때 이 템플릿을 그대로 사용한다.

   ┌──────────────────────────────┐
   │       Replication            │
   │                              │        ┌──────────┐
   │  selector    template        │        │ Pod:v2   │
   │  ┌────────┐  ┌──────────┐    │        │          │
   │  │type:web│  │  Pod:v2  │◀───┼────────│ Template │
   │  └────────┘  └──────────┘    │        │  Update  │
   └───────┬──────────────────────┘        └──────────┘
           │
     Re-create
           │
   ┌───────┴──────┬──────────────┐
   ▼              ▼              ▼
┌────────┐   ┌────────┐    ┌──────────┐
│  Pod   │   │  Pod   │    │  Pod:v2  │
│type:web│   │type:web│    │ type:web │
│  ⚠     │   │   ✗    │    │    ✓     │
└────────┘   └────────┘    └──────────┘
  기존 Pod    삭제하면       템플릿대로
              새로 생성됨     v2로 생성

여기서 중요한 동작이 있다. 템플릿을 v2로 수정해도 이미 실행 중인 Pod는 그대로 남는다. 기존 Pod를 삭제해야 그때 템플릿을 보고 v2 Pod가 새로 만들어진다.

이 성질을 이용하면 Pod를 하나씩 지우면서 버전을 올리는 것이 가능하다. 다만 수작업이므로, 실제 버전 업그레이드는 뒤에 나올 Deployment가 담당한다.

Pod를 직접 만드는 경우

apiVersion: v1
kind: Pod
metadata:
  name: pod-1
  labels:
    type: web
spec:
  containers:
    - name: container
      image: tmkube/app:v1

ReplicationController로 만드는 경우

apiVersion: v1
kind: ReplicationController
metadata:
  name: replication-1
spec:
  replicas: 1
  selector:
    type: web
  template:
    metadata:
      name: pod-1
      labels:
        type: web
    spec:
      containers:
        - name: container
          image: tmkube/app:v2

template 안의 내용이 앞의 Pod YAML과 동일한 구조라는 점을 보면 이해하기 쉽다. Pod 정의를 Controller 안에 그대로 넣어둔 것이다.

Replicas

지정한 개수만큼 Pod가 유지되도록 관리한다.

   ┌──────────────────┐          ┌──────────────────┐
   │   Replication    │          │   Replication    │
   │                  │          │                  │
   │   replicas       │          │  replicas  template
   │   ┌────┐         │          │  ┌────┐  ┌──────┐│
   │   │ 3  │         │          │  │ 2  │  │ Pod  ││
   │   └────┘         │          │  └────┘  └──────┘│
   └──┬────┬────┬─────┘          └───┬──────────┬───┘
      │    │    │                    │    ⚠     │
      │    │    │  Scale Out         │  Pod 삭제 │
      ▼    ▼    ▼                    ▼          ▼
   ┌───┐┌───┐┌───┐                ┌───┐      ┌───┐
   │Pod││Pod││Pod│                │Pod│      │Pod│
   └───┘└───┘└───┘                └───┘      └───┘
                                        새로 생성됨

여기서 알 수 있는 것은 Auto Healing과 Auto Scaling이 사실 같은 동작이라는 점이다. Controller는 "지정된 개수를 유지한다"는 하나의 원칙만 수행하며, 그 결과가 상황에 따라 복구로도 보이고 확장으로도 보이는 것이다.

또한 죽은 Pod를 되살리는 것이 아니라 항상 새 Pod를 만든다. 따라서 Pod 안에 저장한 데이터는 복구되지 않는다.

Selector

어떤 Pod를 관리 대상으로 삼을지 고르는 조건이다. Service의 selector가 트래픽을 보낼 Pod를 고르는 것과 같은 방식이다.

ReplicationController와 ReplicaSet의 가장 큰 차이가 여기에 있다.

   ReplicationController          ReplicaSet
   ─────────────────────          ──────────────────────────
   ┌──────────────┐               ┌──────────────────────────┐
   │  type: web   │               │ matchLabels  matchExpressions
   │              │               │ ┌────────┐  ┌───────────┐│
   │  (값이 정확히│               │ │type:web│  │key: ver   ││
   │   같아야 함) │               │ └────────┘  │operator:  ││
   └──────────────┘               │             │  Exists   ││
                                  │             └───────────┘│
                                  └──────────────────────────┘

선택 결과 예시

세 개의 Pod가 있다고 하자.

  ┌────────────┐  ┌────────────┐  ┌────────────┐
  │   Pod1     │  │   Pod2     │  │   Pod3     │
  │ type: web  │  │ type: web  │  │ type: db   │
  │ ver : v1   │  │ ver : alpha│  │ ver : beta │
  └────────────┘  └────────────┘  └────────────┘

ReplicaSet에서 두 조건이 모두 지정되면 둘 다 만족하는 Pod만 선택된다.

matchExpressions의 operator

matchExpressions는 네 가지 연산자를 제공한다.

        Exists                          DoesNotExist
  ┌──────────────────┐            ┌──────────────────┐
  │   ReplicaSet     │            │   ReplicaSet     │
  │   Key: A         │            │   Key: A         │
  └──────────────────┘            └──────────────────┘
   ┌────┐┌────┐┌────┐              ┌────┐┌────┐┌────┐
   │Pod1││Pod2││Pod3│              │Pod1││Pod2││Pod3│
   │A:1 ││A:2 ││B:2 │              │A:1 ││A:2 ││B:2 │
   └────┘└────┘└────┘              └────┘└────┘└────┘
     ✓     ✓     ✗                   ✗     ✗     ✓
   A라는 key가 있으면 선택          A라는 key가 없으면 선택


          In                              NotIn
  ┌──────────────────┐            ┌──────────────────┐
  │   ReplicaSet     │            │   ReplicaSet     │
  │   Key: A         │            │   Key: A         │
  │   Values: 2,3    │            │   Values: 2,3    │
  └──────────────────┘            └──────────────────┘
   ┌────┐┌────┐┌────┐              ┌────┐┌────┐┌────┐
   │Pod1││Pod2││Pod3│              │Pod1││Pod2││Pod3│
   │A:1 ││A:2 ││A:3 │              │A:1 ││A:2 ││A:3 │
   └────┘└────┘└────┘              └────┘└────┘└────┘
     ✗     ✓     ✓                   ✓     ✗     ✗
   값이 2 또는 3이면 선택           값이 2, 3이 아니면 선택

값을 정확히 알지 못해도 "버전 정보가 붙어 있는 Pod 전부"처럼 유연한 조건을 만들 수 있다는 것이 ReplicaSet의 장점이다.

ReplicaSet YAML

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: replica-1
spec:
  replicas: 3
  selector:
    matchLabels:
      type: web
    matchExpressions:
      - {key: ver, operator: Exists}
  template:
    metadata:
      name: pod
      labels:
        type: web
        ver: v1
    spec:
      containers:
        - name: container
          image: tmkube/app

주의할 점 — template의 label은 selector를 만족해야 한다

selector 조건과 template의 labels가 맞지 않으면 문제가 생긴다.

   selector: type: web        template의 labels: type: db
        │                              │
        │  조건에 맞는 Pod를 찾음      │  이 Pod를 만듦
        ▼                              ▼
   조건에 맞는 Pod가 없음  ──────▶  계속 새 Pod 생성
                                       │
                                   무한 반복

Controller가 만든 Pod를 자기 자신이 인식하지 못하므로, 개수를 채우려고 Pod를 계속 만들어내게 된다. 쿠버네티스는 이런 설정을 아예 거부하여 ReplicaSet 생성을 막는다.

3-3. Deployment

Deployment란

Deployment는 Software Update를 담당하는 Controller다. 앞에서 본 ReplicaSet은 Pod의 개수를 유지할 뿐, 버전을 올리는 기능은 없었다.

Deployment는 ReplicaSet을 직접 관리하면서 버전 업그레이드를 처리한다.

   Deployment  ──관리──▶  ReplicaSet  ──관리──▶  Pod
   (버전 관리)            (개수 유지)          (실행)

사용자는 Deployment만 만들면 된다. ReplicaSet은 Deployment가 알아서 생성하고 관리한다.

배포 방식의 종류

Deployment는 두 가지 배포 방식을 직접 지원하고, 나머지 두 가지는 Service와 조합해 구현한다.

3-3-1. ReCreate

개념

기존 Pod를 전부 삭제한 뒤 새 버전의 Pod를 만드는 방식이다. 가장 단순하지만 다운타임이 발생한다.

동작 과정

v1 Pod 2개를 v2로 올리는 상황이다.

① 초기 상태

              ┌──────────────┐
              │   Service    │
              └──┬────────┬──┘
                 │        │
          ┌──────▼──┐ ┌───▼─────┐
          │ Pod v1  │ │ Pod v1  │
          └─────────┘ └─────────┘

   자원 사용량:  ██ ██        (2개)
   서비스 상태:  정상

② v1 Pod를 모두 삭제

              ┌──────────────┐
              │   Service    │
              └──────────────┘
                 연결할 Pod 없음

          ┌─────────┐ ┌─────────┐
          │ Pod v1  │ │ Pod v1  │
          │    ✗    │ │    ✗    │
          └─────────┘ └─────────┘

   자원 사용량:  □□ □□        (0개, 자원도 함께 반납됨)
   서비스 상태:  ⚠ Downtime 발생

이 시점에 사용자가 접속하면 연결할 Pod가 없어 서비스가 중단된다.

③ v2 Pod 2개 생성

              ┌──────────────┐
              │   Service    │
              └──┬────────┬──┘
                 │        │
          ┌──────▼──┐ ┌───▼─────┐
          │ Pod v2  │ │ Pod v2  │
          └─────────┘ └─────────┘

   자원 사용량:  ██ ██        (2개)
   서비스 상태:  정상 복구

자원 사용량의 변화

   사용량
     │
   2 │ ██ ██              ██ ██
     │
   0 │        □□ □□
     └────────────────────────────▶ 시간
       초기    삭제 후     생성 후
              (Downtime)

배포 중 자원 사용량이 0으로 떨어진다. 추가 자원이 필요 없다는 것이 유일한 장점이다.

YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment-1
spec:
  selector:
    matchLabels:
      type: app
  replicas: 2
  strategy:
    type: Recreate
  revisionHistoryLimit: 1
  template:
    metadata:
      labels:
        type: app
    spec:
      containers:
        - name: container
          image: tmkube/app:v1

내부에서 일어나는 일

Deployment는 ReplicaSet의 replicas 수를 조절하는 방식으로 동작한다.

   ┌────────────────────────────────────────────┐
   │              Deployment                     │
   │   selector   replicas   template            │
   │   type:app      2       Pod v2  ◀── 템플릿 변경
   └───────┬────────────────────┬───────────────┘
           │                    │
    ┌──────▼──────┐      ┌──────▼──────┐
    │ ReplicaSet  │      │ ReplicaSet  │
    │  (v1용)     │      │  (v2용)     │
    │ replicas 0  │      │ replicas 2  │
    └─────────────┘      └──────┬──────┘
      Pod 없음                  │
                         ┌──────┴──────┐
                         ▼             ▼
                   ┌─────────┐   ┌─────────┐
                   │ Pod v2  │   │ Pod v2  │
                   └─────────┘   └─────────┘

기존 ReplicaSet의 replicas를 2에서 0으로 내리고, 새 ReplicaSet의 replicas를 0에서 2로 올린다. 두 작업이 순차적으로 일어나므로 그 사이에 Pod가 하나도 없는 구간이 생긴다.

기존 ReplicaSet은 삭제되지 않고 replicas: 0 상태로 남는다. 롤백할 때 다시 이 값을 올리기 위해서다.

사용하는 경우

• 개발 환경처럼 다운타임이 허용되는 경우
• v1과 v2가 동시에 떠 있으면 안 되는 경우 (같은 DB 스키마를 공유하는데 호환되지 않는 경우 등)

3-3-2. Rolling Update

개념

Pod를 하나씩 교체하는 방식이다. Deployment의 기본값이며, 다운타임이 없다.

동작 과정

replicas: 2, 기본값인 maxSurge: 1, maxUnavailable: 0 기준이다. Pod 개수는 2 → 3 → 2 → 3 → 2로, 3에서 머무르지 않고 매번 2로 돌아온 뒤 다시 늘어난다.

① 초기 상태 (2개)

              ┌──────────────┐
              │   Service    │
              └──┬────────┬──┘
                 │        │
          ┌──────▼──┐ ┌───▼─────┐
          │ Pod v1  │ │ Pod v1  │
          └─────────┘ └─────────┘

   자원 사용량:  ██ ██        (2개)

② v2 Pod 하나 생성 → Ready 대기 (3개)

              ┌──────────────────┐
              │     Service      │
              └──┬───────┬────┬──┘
                 │       │    │
          ┌──────▼──┐ ┌──▼───┐ ┌─▼──────┐
          │ Pod v1  │ │Pod v1│ │Pod v2  │  ← 새로 생성, Ready 대기
          └─────────┘ └──────┘ └────────┘

   자원 사용량:  ██ ██ ██     (3개, 증가)
   서비스 상태:  v1과 v2가 동시에 서비스 중

여기가 Rolling Update의 특징이다. 이 시점에 접속하는 사용자는 v1에 연결될 수도 있고 v2에 연결될 수도 있다. Service가 두 버전의 Pod에 모두 트래픽을 분배하기 때문이다.

③ v2가 Ready 되면, v1 하나 삭제 (2개로 감소)

              ┌──────────────┐
              │   Service    │
              └──┬────────┬──┘
                 │        │
          ┌──────▼──┐ ┌───▼─────┐
          │ Pod v1  │ │ Pod v2  │
          └─────────┘ └─────────┘

   자원 사용량:  ██ ██        (2개, 다시 감소)
   서비스 상태:  v1 1개, v2 1개

maxUnavailable: 0이므로 새 Pod가 Ready 상태가 되어야만 기존 Pod를 삭제한다. "삭제"와 "생성"은 동시에 일어나는 것이 아니라 항상 하나씩 순차적으로 일어난다.

④ v2 Pod 하나 더 생성 → Ready 대기 (3개로 증가)

              ┌──────────────────┐
              │     Service      │
              └──┬───────┬────┬──┘
                 │       │    │
          ┌──────▼──┐ ┌──▼───┐ ┌─▼──────┐
          │ Pod v1  │ │Pod v2│ │Pod v2  │  ← 새로 생성, Ready 대기
          └─────────┘ └──────┘ └────────┘

   자원 사용량:  ██ ██ ██     (3개, 다시 증가)
   서비스 상태:  v1 1개, v2 2개

⑤ 남은 v1 삭제 → 완료 (2개)

              ┌──────────────┐
              │   Service    │
              └──┬────────┬──┘
                 │        │
          ┌──────▼──┐ ┌───▼─────┐
          │ Pod v2  │ │ Pod v2  │
          └─────────┘ └─────────┘

   자원 사용량:  ██ ██        (2개, 원상 복귀)
   서비스 상태:  정상

자원 사용량의 변화

   사용량
     │
   3 │      ██        ██
     │     ╱  ╲       ╱ ╲
   2 │ ██ ╱    ██   ╱     ██
     │
     └──────────────────────────▶ 시간
       초기  생성  삭제  생성  삭제
             (v2)  (v1) (v2)  (v1)

3에서 머무르지 않고 생성 → 삭제 → 생성 → 삭제를 한 번에 한 동작씩 순서대로 밟으며 3과 2 사이를 오간다. Pod 개수가 많아질수록 이 오르내림이 그만큼 더 반복된다. 배포 중 일시적으로 추가 자원을 요구한다는 것이 ReCreate와의 차이이며, 대신 다운타임이 없다.

내부에서 일어나는 일

   ┌────────────────────────────────────────────┐
   │              Deployment                     │
   │   selector   replicas   template            │
   │   type:app      2       Pod v2              │
   └───────┬────────────────────┬───────────────┘
           │                    │
    ┌──────▼──────┐      ┌──────▼──────┐
    │ ReplicaSet  │      │ ReplicaSet  │
    │  (v1용)     │      │  (v2용)     │
    │ 2 → 2 → 1 → │      │ 0 → 1 → 1 → │
    │     1 → 0   │      │     2 → 2   │
    └─────────────┘      └─────────────┘
       한 번에 한 칸씩만 움직인다

한 번에 한 ReplicaSet의 값만 1씩 움직이며, 두 ReplicaSet의 합이 replicas + maxSurge(여기선 3)를 넘지 않고 replicas - maxUnavailable(여기선 2) 밑으로 내려가지도 않도록 조절된다.

ReCreate가 2 → 0 후 0 → 2로 한 번에 크게 움직였다면, Rolling Update는 한 칸씩 번갈아 가며 조절한다. 그래서 두 버전의 Pod가 잠시 공존한다.

YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment-2
spec:
  selector:
    matchLabels:
      type: app
  replicas: 2
  strategy:
    type: RollingUpdate
  minReadySeconds: 10
  template:
    metadata:
      labels:
        type: app
    spec:
      containers:
        - name: container
          image: tmkube/app:v1

minReadySeconds가 필요한 이유가 있다. Pod가 Ready 상태가 되었더라도 애플리케이션이 완전히 안정화되지 않았을 수 있다. 이 값을 두면 각 단계마다 잠시 기다리므로, 문제가 있는 버전이 한꺼번에 배포되는 것을 막을 수 있다.

주의할 점

v1과 v2가 동시에 서비스되는 구간이 있으므로, 두 버전이 공존해도 문제가 없어야 한다.

• API 응답 형식이 바뀌면 클라이언트가 혼란을 겪을 수 있다
• DB 스키마가 바뀌면 한쪽 버전에서 오류가 발생할 수 있다

이런 경우에는 ReCreate나 Blue/Green을 고려해야 한다.

3-3-3. Blue/Green

개념

Controller를 하나 더 만들어서 새 버전을 통째로 준비해 두고, Service의 연결 대상만 바꾸는 방식이다.

Deployment가 직접 지원하는 기능이 아니라, Controller 두 개와 Service의 Label을 이용해 직접 구현한다.

동작 과정

① v1 Controller와 Pod만 존재 (Blue)

   ┌──────────────┐
   │  Controller  │
   │    (v1)      │
   └──┬────────┬──┘
      │        │
 ┌────▼────┐ ┌─▼───────┐
 │ Pod     │ │ Pod     │
 │ ver: v1 │ │ ver: v1 │
 └────┬────┘ └────┬────┘
      │           │
      └─────┬─────┘
            │
      ┌─────▼──────┐
      │  Service   │
      │  ver: v1   │  ← selector가 v1을 가리킴
      └────────────┘

   자원 사용량:  ██ ██        (2개)

② v2 Controller를 새로 생성 (Green)

   ┌──────────────┐        ┌──────────────┐
   │  Controller  │        │  Controller  │
   │    (v1)      │        │    (v2)      │  ← 새로 생성
   └──┬────────┬──┘        └──┬────────┬──┘
      │        │              │        │
 ┌────▼────┐ ┌─▼───────┐ ┌────▼────┐ ┌─▼───────┐
 │ Pod     │ │ Pod     │ │ Pod     │ │ Pod     │
 │ ver: v1 │ │ ver: v1 │ │ ver: v2 │ │ ver: v2 │
 └────┬────┘ └────┬────┘ └─────────┘ └─────────┘
      │           │
      └─────┬─────┘         트래픽 없음 (대기 상태)
            │
      ┌─────▼──────┐
      │  Service   │
      │  ver: v1   │
      └────────────┘

   자원 사용량:  ██ ██ ██ ██   (4개, 2배)

이 시점에서 v2 Pod는 떠 있지만 Service가 연결하지 않으므로 트래픽을 받지 않는다. 이 상태에서 v2를 충분히 검증할 수 있다.

③ Service의 Label만 v2로 변경

   ┌──────────────┐        ┌──────────────┐
   │  Controller  │        │  Controller  │
   │    (v1)      │        │    (v2)      │
   └──┬────────┬──┘        └──┬────────┬──┘
      │        │              │        │
 ┌────▼────┐ ┌─▼───────┐ ┌────▼────┐ ┌─▼───────┐
 │ Pod     │ │ Pod     │ │ Pod     │ │ Pod     │
 │ ver: v1 │ │ ver: v1 │ │ ver: v2 │ │ ver: v2 │
 └─────────┘ └─────────┘ └────┬────┘ └────┬────┘
                              │           │
   트래픽 없음                └─────┬─────┘
                                    │
                              ┌─────▼──────┐
                              │  Service   │
                              │  ver: v2   │  ← selector 변경
                              └────────────┘

Service의 selector를 ver: v1에서 ver: v2로 수정하는 것만으로 순간적으로 전환된다. Pod를 만들거나 지우는 과정이 없으므로 다운타임이 없다.

④ v1 Controller 삭제

                           ┌──────────────┐
                           │  Controller  │
                           │    (v2)      │
                           └──┬────────┬──┘
                              │        │
                         ┌────▼────┐ ┌─▼───────┐
                         │ Pod     │ │ Pod     │
                         │ ver: v2 │ │ ver: v2 │
                         └────┬────┘ └────┬────┘
                              └─────┬─────┘
                              ┌─────▼──────┐
                              │  Service   │
                              │  ver: v2   │
                              └────────────┘

   자원 사용량:  ██ ██        (2개로 복귀)

자원 사용량의 변화

   사용량
     │
   4 │     ████ ████
     │
   2 │ ██ ██        ██ ██
     │
     └───────────────────────────▶ 시간
       초기  배포 중     완료
            (2배 사용)

장점과 단점

롤백의 차이가 특히 중요하다. Rolling Update는 롤백할 때도 Pod를 하나씩 다시 교체해야 하지만, Blue/Green은 Label 하나만 되돌리면 즉시 복구된다. 그래서 실패했을 때의 영향이 가장 적은 방식이다.

3-3-4. Canary

개념

새 버전을 일부 트래픽에만 먼저 노출해서 검증한 뒤, 문제가 없으면 전체로 확대하는 방식이다.

이름은 탄광에서 유독가스를 미리 감지하던 카나리아 새에서 유래했다.

방법 1 — Pod 개수로 비율 조절

가장 단순한 구현이다. Service 하나가 v1과 v2 Pod를 모두 선택하도록 하고, Pod 개수로 트래픽 비율을 조절한다.

   ┌──────────────┐        ┌──────────────┐
   │  Controller  │        │  Controller  │
   │    (v1)      │        │    (v2)      │
   └──┬────────┬──┘        └──────┬───────┘
      │        │                  │
 ┌────▼────┐ ┌─▼───────┐    ┌─────▼─────┐
 │ Pod     │ │ Pod     │    │ Pod       │
 │ ty: app │ │ ty: app │    │ ty: app   │
 │ ver: v1 │ │ ver: v1 │    │ ver: v2   │
 └────┬────┘ └────┬────┘    └─────┬─────┘
      │           │               │
      └───────────┼───────────────┘
                  │
            ┌─────▼──────┐
            │  Service   │
            │  ty: app   │  ← ver를 조건에 넣지 않음
            └────────────┘

   트래픽 비율:  v1 67%  /  v2 33%

Service의 selector가 ty: app만 보므로 v1, v2 Pod를 모두 선택한다. v2 Pod가 1개, v1 Pod가 2개이므로 트래픽의 약 1/3이 v2로 간다.

문제가 없으면 v2 Pod를 늘리고 v1 Pod를 줄여가며 비율을 조정한다.

방법 2 — Ingress Controller로 경로 분기

URL 경로에 따라 서비스를 나누는 방식이다. Ingress Controller를 활용한다.

   ┌──────────────┐        ┌──────────────┐
   │  Controller  │        │  Controller  │
   │    (v1)      │        │    (v2)      │
   └──┬────────┬──┘        └──────┬───────┘
      │        │                  │
 ┌────▼────┐ ┌─▼───────┐    ┌─────▼─────┐
 │ Pod     │ │ Pod     │    │ Pod       │
 │ ver: v1 │ │ ver: v1 │    │ ver: v2   │
 └────┬────┘ └────┬────┘    └─────┬─────┘
      └─────┬─────┘               │
            │                     │
      ┌─────▼──────┐        ┌─────▼──────┐
      │  Service   │        │  Service   │
      │  ver: v1   │        │  ver: v2   │
      └─────┬──────┘        └─────┬──────┘
            │                     │
          /app                 /v2/app
            │                     │
            └──────────┬──────────┘
                       │
           ┌───────────▼────────────┐
           │  Ingress Controller    │
           └────────────────────────┘

특정 사용자에게만 /v2/app 경로를 안내해 새 버전을 먼저 써보게 할 수 있다. 검증이 끝나면 Ingress 설정을 바꿔 /app 요청이 v2로 가도록 전환한다.

   검증 전:  /app     ──▶  v1
             /v2/app  ──▶  v2

   전환 후:  /app     ──▶  v2

자원 사용량의 변화

   사용량
     │
   3 │      ███ ███ ███
     │
   2 │ ██ ██          ██ ██
     │
     └───────────────────────────▶ 시간
       초기  검증 중     완료

v2 Pod를 조금만 띄우므로 Blue/Green처럼 2배가 필요하지는 않다.

장점과 단점

네 가지 배포 방식 비교

   ReCreate           Rolling Update      Blue/Green         Canary
   ────────           ──────────────      ──────────         ──────
   v1 v1              v1 v1               v1 v1  v2 v2       v1 v1 v2
     ↓                  ↓                    ↘  ↙              ↓  ↓
   (없음) ⚠            v1 v2              Service 전환      Service
     ↓                  ↓                    ↓                 ↓
   v2 v2              v2 v2               v2 v2             비율 조정

   Downtime 발생      Zero Downtime       Zero Downtime     Zero Downtime
   자원 추가 없음      자원 일부 증가       자원 2배          자원 일부 증가

선택 기준

• 다운타임이 허용되고 두 버전이 공존하면 안 되는가 → ReCreate
• 무난하게 무중단 배포를 하고 싶은가 → Rolling Update (가장 일반적)
• 자원에 여유가 있고 즉시 롤백이 중요한가 → Blue/Green
• 새 버전의 위험이 크고 실제 트래픽으로 검증하고 싶은가 → Canary

3-4. DaemonSet, Job, CronJob

3-4-1. DaemonSet

개념

ReplicaSet은 "Pod를 몇 개 유지할지"를 정하고, 스케줄러가 자원 여유를 보고 배치할 Node를 고른다. 그래서 Pod가 특정 Node에 몰리거나, 어떤 Node에는 하나도 배치되지 않을 수 있다.

DaemonSet은 다르다. Node의 자원 상태와 상관없이 모든 Node에 Pod를 하나씩 생성한다.

   [ ReplicaSet ]                    [ DaemonSet ]
   ──────────────                    ─────────────
   ┌────────────┐                    ┌────────────┐
   │ ReplicaSet │                    │ DaemonSet  │
   └─┬────┬─────┘                    └─┬───┬───┬──┘
     │    │                            │   │   │
   ┌─▼────▼──────┐                   ┌─▼───────────┐
   │   Node1     │                   │   Node1     │
   │  Pod  Pod   │                   │    Pod      │
   │  ▓▓ ▓▓ ▓▓   │  자원 여유 많음   │             │
   └─────────────┘                   └─────────────┘
   ┌─────────────┐                   ┌─────────────┐
   │   Node2     │                   │   Node2     │
   │    Pod      │                   │    Pod      │
   │  ▓▓ ▓▓      │                   │             │
   └─────────────┘                   └─────────────┘
   ┌─────────────┐                   ┌─────────────┐
   │   Node3     │                   │   Node3     │
   │  (없음)     │  자원 부족        │    Pod      │
   │  ▓          │                   │             │
   └─────────────┘                   └─────────────┘

   자원 여유에 따라 배치            Node마다 무조건 1개

Node가 새로 추가되면 DaemonSet이 그 Node에도 자동으로 Pod를 하나 생성한다. Node가 제거되면 그 Pod도 함께 사라진다.

사용 사례

Node마다 하나씩 떠 있어야 의미가 있는 작업에 사용한다.

공통점은 Node 하나하나의 정보에 접근해야 한다는 것이다. 로그를 수집하려면 모든 Node에 수집기가 있어야 하고, 한 Node라도 빠지면 그 Node의 로그는 유실된다.

Volume에서 다룬 hostPath가 DaemonSet과 함께 쓰이는 이유도 여기에 있다. 모든 Node에 Pod를 하나씩 띄우고, 각 Pod가 자기 Node의 /var/log를 마운트해 로그를 읽는 구조다.

nodeSelector — 특정 Node에만 배치

모든 Node가 아니라 조건에 맞는 Node에만 배치할 수도 있다.

   ┌──────────────────────────────┐
   │        DaemonSet             │
   │  selector    template        │
   │  type:app    Pod             │──▶ nodeSelector: os: centos
   └───┬──────────┬───────────┬───┘
       │          │           │
       ▼          ▼           ✗
  ┌─────────┐┌─────────┐┌─────────┐
  │  Node1  ││  Node2  ││  Node3  │
  │  Pod    ││  Pod    ││ (없음)  │
  │os:centos││os:centos││os:ubuntu│
  └─────────┘└─────────┘└─────────┘

os: centos Label이 붙은 Node에만 Pod가 생성되고, os: ubuntu인 Node3에는 생성되지 않는다.

hostPort — Node의 포트로 직접 접근

DaemonSet은 Node마다 Pod가 하나씩이므로, Node의 포트를 Pod에 직접 연결할 수 있다.

   ┌─────────────────┐  ┌─────────────────┐
   │     Node1       │  │     Node2       │
   │   ┌─────────┐   │  │   ┌─────────┐   │
   │   │  Pod    │   │  │   │  Pod    │   │
   │   │  8080   │   │  │   │  8080   │   │
   │   └────┬────┘   │  │   └────┬────┘   │
   │        │        │  │        │        │
   │   [ 18080 ]     │  │   [ 18080 ]     │
   └────────┬────────┘  └────────┬────────┘
            │                    │
        Node IP : 18080 로 직접 접근

NodePort와 비슷해 보이지만 차이가 있다. NodePort는 Service를 거쳐 어느 Node로 들어와도 Pod가 있는 Node로 전달되지만, hostPort는 그 Node의 Pod에 직접 연결된다. 각 Node의 상태를 개별적으로 확인해야 하는 모니터링 도구에 적합하다.

YAML

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: daemonset-1
spec:
  selector:
    matchLabels:
      type: app
  template:
    metadata:
      labels:
        type: app
    spec:
      nodeSelector:
        os: centos
      containers:
        - name: container
          image: tmkube/app
          ports:
            - containerPort: 8080
              hostPort: 18080

replicas가 없다는 점이 다른 Controller와 가장 뚜렷한 차이다.

3-4-2. Job

Pod, ReplicaSet, Job의 차이

세 오브젝트 모두 Pod를 만들지만, Pod가 종료되었을 때의 동작이 다르다.

   ┌──────────────┐
   │     Pod      │   Node1 장애 시 →  Pod 사라짐, 복구 없음
   └──────────────┘

   ┌──────────────┐                    ┌─────────────────────┐
   │  ReplicaSet  │   Node1 장애 시 →  │ Node2에 Recreate    │
   └──────────────┘                    │ 계속 Running 유지   │
                                       └─────────────────────┘

   ┌──────────────┐                    ┌─────────────────────┐
   │     Job      │   Node1 장애 시 →  │ Node2에 Recreate    │
   └──────────────┘                    │ 작업 끝나면 Finish  │
                                       └─────────────────────┘

핵심은 ReplicaSet은 Pod가 끝나는 것을 장애로 보고 다시 띄우지만, Job은 정상 종료로 인정한다는 점이다.

웹 서버가 꺼지면 문제이므로 다시 띄워야 하지만, 백업 작업이 끝난 것은 성공이므로 다시 띄우면 안 된다. 이 차이 때문에 Job이 따로 존재한다.

사용 사례

작업이 끝나면 Pod가 종료되고 자원이 반납되므로, 항상 띄워두는 것보다 자원을 효율적으로 쓸 수 있다.

completions — 몇 번 실행할 것인가

   ┌─────────────────────────────────┐
   │            Job                   │
   │       completions : 6            │
   │   ┌────┐ ┌────┐ ┌────┐          │
   │   │Pod │ │Pod │ │Pod │          │
   │   └────┘ └────┘ └────┘          │
   │   ┌────┐ ┌────┐ ┌────┐          │
   │   │Pod │ │Pod │ │Pod │          │
   │   └────┘ └────┘ └────┘          │
   └─────────────────────────────────┘
        Pod 6개가 순차적으로 실행되고 완료

completions: 6은 성공적으로 완료되어야 하는 Pod의 수를 뜻한다. 6개가 모두 성공해야 Job이 완료 상태가 된다.

parallelism — 몇 개를 동시에 실행할 것인가

   parallelism: 2

   ┌────┐ ┌────┐     ┌────┐ ┌────┐     ┌────┐ ┌────┐
   │Pod │ │Pod │  →  │Pod │ │Pod │  →  │Pod │ │Pod │
   └────┘ └────┘     └────┘ └────┘     └────┘ └────┘
    1회차 (2개)       2회차 (2개)       3회차 (2개)

        합계 6개 = completions

기본값은 1이라 하나씩 순차 실행되지만, parallelism: 2를 주면 2개씩 동시에 실행된다. 6개를 처리하는 데 걸리는 시간이 줄어든다.

activeDeadlineSeconds — 제한 시간

   ┌────┐                              ┌ ─ ─┐
   │Job │ ────────────────────────────▶  Job
   └────┘                              └ ─ ─┘
     시작              30초 경과        강제 종료

작업이 지정한 시간 안에 끝나지 않으면 강제로 종료한다. 무한 루프에 빠지거나 응답 없는 외부 시스템을 기다리며 Pod가 영원히 남는 상황을 막는다.

YAML

apiVersion: batch/v1
kind: Job
metadata:
  name: job-1
spec:
  completions: 6
  parallelism: 2
  activeDeadlineSeconds: 30
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: container
          image: tmkube/init

restartPolicy는 Job에서 반드시 지정해야 하는 값이다.

Always는 Job에서 사용할 수 없다. 작업이 끝나도 계속 재시작하게 되어 Job의 목적과 맞지 않기 때문이다.

3-4-3. CronJob

개념

CronJob은 Job을 정해진 일정에 따라 반복 생성하는 Controller다. Job을 직접 만드는 것이 아니라, Job을 만드는 Controller라는 점이 핵심이다.

   ┌─────────────────────────────────────────┐
   │              CronJob                     │
   │   schedule : */1 * * * *                 │
   │   jobTemplate : Job                      │
   └────┬──────────────┬──────────────┬──────┘
        │              │              │
     1 Min          2 Min          3 Min
        │              │              │
        ▼              ▼              ▼
   ┌─────────┐   ┌─────────┐   ┌─────────┐
   │   Job   │   │   Job   │   │   Job   │
   └────┬────┘   └────┬────┘   └────┬────┘
        │             │             │
        ▼             ▼             ▼
   ┌─────────┐   ┌─────────┐   ┌─────────┐
   │   Pod   │   │   Pod   │   │   Pod   │
   └─────────┘   └─────────┘   └─────────┘

1분마다 Job이 하나씩 생성되고, 각 Job이 Pod를 만들어 작업을 수행한다.

schedule — 일정 지정

리눅스의 cron 표현식을 그대로 사용한다.

   * * * * *
   │ │ │ │ │
   │ │ │ │ └── 요일 (0~6, 0=일요일)
   │ │ │ └──── 월 (1~12)
   │ │ └────── 일 (1~31)
   │ └──────── 시 (0~23)
   └────────── 분 (0~59)

concurrencyPolicy — 이전 작업이 안 끝났을 때

정해진 시간이 되었는데 이전 Job이 아직 끝나지 않은 경우를 어떻게 처리할지 정한다.

        Allow                   Forbid                  Replace
   ┌───────────────┐     ┌───────────────┐      ┌───────────────┐
   │1min 2min 3min │     │1min 2min 3min │      │1min 2min 3min │
   │               │     │      skip     │      │               │
   │ Job  Job  Job │     │ Job   ⚠   Job │      │ Job  Job  Job │
   │  │    │    │  │     │  │        │   │      │  │ ✗  │    │  │
   │ Pod  Pod  Pod │     │ Pod ────▶ Pod │      │ Pod  Pod  Pod │
   └───────────────┘     └───────────────┘      └───────────────┘

   이전 Job과 상관없이   이전 Job이 실행 중이면   이전 Job을 삭제하고
   무조건 새로 생성       이번 차례는 건너뜀       새 Job으로 교체

Suspend와 Manual Trigger

   ┌─────────────────────────────────┐
   │           CronJob               │◀── Suspend (일시 중지)
   │   schedule : */1 * * * *        │
   │   jobTemplate : Job             │◀── Manual Trigger (수동 실행)
   └─────────────────────────────────┘

# 일시 중지
kubectl patch cronjob cron-job -p '{"spec":{"suspend":true}}'

# 수동 실행
kubectl create job --from=cronjob/cron-job manual-job-1

YAML

apiVersion: batch/v1
kind: CronJob
metadata:
  name: cron-job
spec:
  schedule: "*/1 * * * *"
  concurrencyPolicy: Allow
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: Never
          containers:
            - name: container
              image: tmkube/app

구조가 한 겹 더 깊다는 점에 주의해야 한다.

   CronJob
     └── jobTemplate        ← Job의 정의
           └── template     ← Pod의 정의
                 └── containers

CronJob이 Job을 만들고, Job이 Pod를 만들기 때문에 템플릿이 두 번 중첩된다.

Job과 CronJob의 공통점과 차이점

공통점

차이점

        Job                          CronJob
   ────────────                 ──────────────────
   ┌──────────┐                 ┌──────────┐
   │   Job    │                 │ CronJob  │
   └────┬─────┘                 └────┬─────┘
        │                            │ 일정마다
        ▼                       ┌────┼────┬────┐
   ┌──────────┐                 ▼    ▼    ▼    ▼
   │   Pod    │              ┌────┐┌────┐┌────┐
   └──────────┘              │Job ││Job ││Job │
                             └─┬──┘└─┬──┘└─┬──┘
   한 번 실행하고 끝            ▼     ▼     ▼
                             Pod   Pod   Pod

                             일정에 따라 반복

관계로 정리하면 이렇다.

   CronJob  ──생성──▶  Job  ──생성──▶  Pod
   (일정 관리)        (작업 관리)      (실제 실행)

CronJob은 Job을 대체하는 것이 아니라 Job을 반복 실행해 주는 상위 개념이다. 한 번만 실행할 작업이면 Job을, 주기적으로 실행할 작업이면 CronJob을 사용한다.

2-1. Pod

Pod는 쿠버네티스에서 애플리케이션을 배포하는 가장 작은 단위다. Pod를 이해하려면 Container, Label, Node Schedule 세 가지를 알아야 한다.

2-1-1. Container

구조

┌──────────── Pod (IP: 10.244.1.7) ────────────┐
│                                               │
│   ┌────────────────┐   ┌────────────────┐    │
│   │  container1    │   │  container2    │    │
│   │  port 8000     │   │  port 8080     │    │
│   └────────────────┘   └────────────────┘    │
│                                               │
│      하나의 IP를 공유 → 포트는 달라야 한다    │
└───────────────────────────────────────────────┘

포트

각 컨테이너는 Service가 연결될 수 있도록 포트를 가진다. Service는 이 포트를 통해 컨테이너에 트래픽을 전달한다.

Pod 안의 컨테이너들은 하나의 IP를 공유하므로 같은 Pod 안에서 동일한 포트를 사용할 수 없다. 두 컨테이너가 모두 8080을 사용하면 포트 충돌이 발생한다. 위 구조처럼 8000과 8080으로 다르게 지정해야 한다.

Pod의 IP

Pod IP는 고정되지 않으므로 다른 애플리케이션이 Pod IP를 직접 지정해 통신하면 안 된다. 이 문제를 해결하기 위해 뒤에서 다룰 Service를 사용한다.

YAML

apiVersion: v1
kind: Pod
metadata:
  name: pod-1
spec:
  containers:
    - name: container1
      image: tmkube/p8000
      ports:
        - containerPort: 8000
    - name: container2
      image: tmkube/p8080
      ports:
        - containerPort: 8080

더 알아두면 좋은 것

containerPort는 실제로 포트를 열어주는 설정이 아니다. 애플리케이션이 어떤 포트를 사용하는지 명시하는 문서 역할에 가깝다. 실제 포트는 컨테이너 내부의 애플리케이션이 연다. 다만 이 값을 적어두면 Service를 연결하거나 다른 사람이 YAML을 볼 때 구조를 파악하기 쉬워지므로 작성하는 것이 좋다.

2-1-2. Label

개념

Label은 오브젝트에 붙이는 key: value 형태의 이름표다. Pod뿐 아니라 Service, Node 등 모든 오브젝트에 붙일 수 있다.

쿠버네티스에서 오브젝트가 많아지면 이름만으로는 관리가 어렵다. Label을 붙여두면 원하는 조건의 오브젝트만 골라내는 것이 가능해진다. 이때 조건을 지정하는 쪽이 selector다.

예시 상황

개발 환경과 운영 환경에 각각 web, db, server를 운영한다고 하자. Pod가 총 6개다.

                      Label로 분류된 Pod들

  ┌──────────────────────────┬──────────────────────────┐
  │        lo: dev           │      lo: production      │
  ├──────────────────────────┼──────────────────────────┤
  │  ┌────────────────────┐  │  ┌────────────────────┐  │
  │  │ Pod                │  │  │ Pod                │  │
  │  │ type: web          │  │  │ type: web          │  │
  │  │ lo: dev            │  │  │ lo: production     │  │
  │  └────────────────────┘  │  └────────────────────┘  │
  │  ┌────────────────────┐  │  ┌────────────────────┐  │
  │  │ Pod                │  │  │ Pod                │  │
  │  │ type: db           │  │  │ type: db           │  │
  │  │ lo: dev            │  │  │ lo: production     │  │
  │  └────────────────────┘  │  └────────────────────┘  │
  │  ┌────────────────────┐  │  ┌────────────────────┐  │
  │  │ Pod                │  │  │ Pod                │  │
  │  │ type: server       │  │  │ type: server       │  │
  │  │ lo: dev            │  │  │ lo: production     │  │
  │  └────────────────────┘  │  └────────────────────┘  │
  └──────────────────────────┴──────────────────────────┘

각 Pod는 두 개의 Label을 갖는다.

• type : 어떤 역할인가 (web / db / server)
• lo : 어떤 환경인가 (dev / production)

Selector로 골라내기

Service가 selector: type: web 을 지정하면, type이 web인 Pod에만 연결된다.

   Service svc-1
   selector:
     type: web
        │
        │  type: web 인 Pod만 선택
        ▼
  ┌─────────────┐   ┌─────────────┐
  │ type: web   │   │ type: web   │      ┌─────────────┐
  │ lo: dev     │   │ lo:         │      │ type: db    │  ← 선택 안 됨
  │             │   │ production  │      │ lo: dev     │
  └─────────────┘   └─────────────┘      └─────────────┘

여기서 lo는 조건에 없으므로 dev와 production의 web Pod가 모두 선택된다. 개발용 Service를 따로 만들고 싶다면 조건을 두 개로 지정하면 된다.

selector:
  type: web
  lo: dev

Label이 여러 개 지정되면 모두 만족하는 Pod만 선택된다.

Label을 붙이는 이유

마지막 항목이 특히 중요하다. Service는 특정 Pod를 이름으로 기억하지 않는다. 조건에 맞는 Pod를 그때그때 찾아서 연결한다. 그래서 Pod가 재생성되어 IP가 바뀌어도, 새 Pod에 같은 Label만 붙어 있으면 Service는 문제없이 동작한다.

YAML

Service — 조건을 지정하는 쪽

apiVersion: v1
kind: Service
metadata:
  name: svc-1
spec:
  selector:
    type: web
  ports:
    - port: 8080

Pod — Label을 붙이는 쪽

apiVersion: v1
kind: Pod
metadata:
  name: pod-2
  labels:
    type: web
    lo: dev
spec:
  containers:
    - name: container
      image: tmkube/init

더 알아두면 좋은 것

Label과 비슷하게 생겼지만 목적이 다른 Annotation이 있다. Label은 오브젝트를 선택하기 위한 정보이고, Annotation은 선택에는 쓰이지 않는 부가 정보를 기록하는 용도다. 배포 일시, 담당자, 관련 문서 링크 같은 것을 Annotation에 적는다.

2-1-3. Node Schedule

개념

Pod는 반드시 어느 한 Node 위에서 실행된다. 어떤 Node에서 실행할지 결정하는 과정을 Node Schedule이라고 한다.

방법은 두 가지다.

방법 1 — 직접 지정 (nodeSelector)

Node에도 Label을 붙일 수 있다. Pod에 nodeSelector를 지정하면 해당 Label을 가진 Node에만 배치된다.

   Pod-3
   nodeSelector:
     hostname: node1
        │
        │ hostname: node1 인 Node를 찾는다
        ▼
  ┌──────────────────┐   ┌──────────────────┐
  │ Node1            │   │ Node2            │
  │ hostname: node1  │   │ hostname: node2  │
  │                  │   │                  │
  │   [Pod-3] ← 배치 │   │                  │
  └──────────────────┘   └──────────────────┘

apiVersion: v1
kind: Pod
metadata:
  name: pod-3
spec:
  nodeSelector:
    hostname: node1
  containers:
    - name: container
      image: tmkube/init

주의할 점: 조건에 맞는 Node가 없거나, 그 Node에 자원이 부족하면 Pod는 배치되지 못하고 Pending 상태로 대기한다. 다른 Node로 알아서 옮겨가지 않는다.

사용하는 경우: GPU가 달린 Node에서만 실행해야 하거나, SSD가 장착된 Node에 데이터베이스를 배치해야 하는 경우처럼 특정 Node의 조건이 필요할 때 사용한다.

방법 2 — 스케줄러 판단 (resources)

Node를 지정하지 않으면 스케줄러가 결정한다. 이때 판단 기준이 되는 것이 resources다.

apiVersion: v1
kind: Pod
metadata:
  name: pod-4
spec:
  containers:
    - name: container
      image: tmkube/init
      resources:
        requests:
          memory: 2Gi
        limits:
          memory: 3Gi

스케줄러의 판단 과정

Pod-4가 requests: memory 2Gi를 요구하는 상황이다. 클러스터에 Node가 세 개 있다.

  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐
  │   Node1      │  │   Node2      │  │   Node3      │
  │              │  │              │  │              │
  │ 전체 8Gi     │  │ 전체 8Gi     │  │ 전체 8Gi     │
  │ 사용중 7Gi   │  │ 사용중 2Gi   │  │ 사용중 5Gi   │
  │ 여유  1Gi    │  │ 여유  6Gi    │  │ 여유  3Gi    │
  └──────────────┘  └──────────────┘  └──────────────┘
        ✗                 ✓                 ✓
     2Gi 불가          배치 가능         배치 가능

1단계 — 필터링 (Filtering)

배치가 불가능한 Node를 먼저 제외한다.

• Node1: 여유 메모리가 1Gi뿐이라 2Gi를 확보할 수 없다 → 제외
• Node2, Node3: 조건 충족 → 후보로 남는다

2단계 — 스코어링 (Scoring)

남은 후보 중 가장 적합한 Node를 점수로 고른다. 자원 여유가 많은 Node가 높은 점수를 받는다.

• Node2: 여유 6Gi → 높은 점수
• Node3: 여유 3Gi → 낮은 점수

3단계 — 배치

점수가 가장 높은 Node2에 Pod-4를 배치한다.

  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐
  │   Node1      │  │   Node2      │  │   Node3      │
  │              │  │  [Pod-4]     │  │              │
  │ 여유  1Gi    │  │ 여유  4Gi    │  │ 여유  3Gi    │
  └──────────────┘  └──────────────┘  └──────────────┘
                        ↑ 배치됨

이렇게 스케줄러는 자원 여유가 부족한 Node를 걸러내고, 남은 Node 중 가장 여유 있는 곳에 Pod를 배치해 클러스터 전체의 자원 사용을 고르게 유지한다.

requests와 limits의 동작 차이

두 값의 역할이 다르므로 구분해서 이해해야 한다.

메모리가 limits를 초과하면 컨테이너가 강제 종료된다. 이 상태를 OOMKilled(Out Of Memory Killed)라고 한다. CPU는 초과해도 종료되지 않고 사용량이 제한되기만 한다.

더 알아두면 좋은 것

nodeSelector는 조건이 맞지 않으면 Pod가 배치되지 않는 단순하고 엄격한 방식이다. 실무에서는 "가능하면 이 Node에, 안 되면 다른 Node에라도" 처럼 유연한 조건이 필요한 경우가 많다. 이런 조건은 Node Affinity로 표현하며, 이후 단계에서 다루는 개념이다. 처음에는 nodeSelector로 Node 지정의 개념을 이해하고, 이후에 Affinity로 확장해 나가면 된다.

2-2. Service

Service란 무엇이고 왜 필요한가

문제 상황 — Pod IP는 신뢰할 수 없다

Pod는 언제든지 죽을 수 있다. 노드에 장애가 나거나, 새 버전을 배포하거나, 자원이 부족해 재배치되는 경우 Pod는 삭제되고 새로 생성된다.

이때 Pod가 재생성되면 IP가 바뀐다.

       [ 배포 전 ]                      [ Pod 재생성 후 ]

  ┌────────────────┐               ┌────────────────┐
  │ Pod-1          │               │ Pod-1 (새로)   │
  │ IP 10.244.1.7  │               │ IP 10.244.1.23 │  ← IP 변경
  └────────────────┘               └────────────────┘
         ▲                                  ▲
         │ 10.244.1.7 로 호출                │  연결 끊김 ✗
  ┌────────────────┐               ┌────────────────┐
  │ 다른 애플리케이션│               │ 다른 애플리케이션│
  └────────────────┘               └────────────────┘

Pod IP를 직접 지정해 통신하면, Pod가 한 번 재생성되는 순간 연결이 끊긴다. 즉 Pod IP는 신뢰성이 없다.

해결 — Service가 고정된 주소를 제공한다

Service는 사용자가 직접 삭제하지 않는 한 삭제되거나 재생성되지 않는다. 따라서 Service의 IP는 변하지 않는다.

  ┌─────────────────────────────────────────────┐
  │  Service (IP 172.96.10.17) ← 변하지 않음    │
  └──────────────────┬──────────────────────────┘
                     │ Label로 Pod를 찾아 연결
                     ▼
        ┌────────────────────────────┐
        │ Pod  IP 10.244.1.7         │
        │  ↓ 재생성                   │
        │ Pod  IP 10.244.1.23        │  ← IP가 바뀌어도
        └────────────────────────────┘     Service가 알아서 다시 연결

Service는 특정 Pod를 IP로 기억하지 않고 Label 조건으로 그때그때 찾아서 연결한다. 그래서 Pod가 재생성되어 IP가 바뀌어도 새 Pod에 같은 Label만 붙어 있으면 연결이 유지된다.

정리하면 Service의 역할은 다음과 같다.

Service의 종류

세 가지는 별개의 기능이 아니라 누적되는 구조다. NodePort는 ClusterIP의 기능을 포함하고, LoadBalancer는 NodePort의 기능을 포함한다.

  ┌───────────────────────────────────────────┐
  │  LoadBalancer                             │
  │  ┌─────────────────────────────────────┐  │
  │  │  NodePort                           │  │
  │  │  ┌───────────────────────────────┐  │  │
  │  │  │  ClusterIP                    │  │  │
  │  │  │  (기본 - 내부 접근)           │  │  │
  │  │  └───────────────────────────────┘  │  │
  │  │  + 모든 Node에 포트 개방            │  │
  │  └─────────────────────────────────────┘  │
  │  + 외부 로드밸런서와 전용 IP              │
  └───────────────────────────────────────────┘

2-2-1. ClusterIP

특징

ClusterIP는 Service의 기본 타입이다. type을 지정하지 않으면 자동으로 ClusterIP가 된다.

구조

┌─────────────────── Cluster ───────────────────┐
│                                                │
│   ┌──────────────────────────────────────┐    │
│   │  Service svc-1                       │    │
│   │  IP: 172.96.10.17                    │    │
│   │  port 9000  →  targetPort 8080       │    │
│   │  selector: app: pod                  │    │
│   └───────────────┬──────────────────────┘    │
│                   │  app: pod 인 Pod를 찾음   │
│                   ▼                            │
│      ┌────────────────────────┐               │
│      │ Pod-1                  │               │
│      │ labels: app: pod       │               │
│      │ containerPort: 8080    │               │
│      └────────────────────────┘               │
│                                                │
└────────────────────────────────────────────────┘
              ▲
              │  ✗ 외부에서 172.96.10.17 접근 불가
        ┌───────────┐
        │  External │
        └───────────┘

포트의 흐름

Service에는 포트가 두 개 등장한다. 처음 배울 때 가장 헷갈리는 부분이므로 흐름으로 이해하는 것이 좋다.

   요청: 172.96.10.17 : 9000
                │
                │  ① port 9000 으로 Service에 도착
                ▼
        ┌───────────────┐
        │   Service     │
        │   port: 9000  │
        └───────┬───────┘
                │  ② targetPort 8080 으로 전달
                ▼
        ┌───────────────┐
        │   Pod         │
        │   8080        │
        └───────────────┘

Service IP로 Pod에 접근하기

클러스터 내부의 다른 Pod에서 접근하는 방법이다.

# Service의 IP로 접근
curl 172.96.10.17:9000

# Service의 이름으로 접근 (권장)
curl svc-1:9000

IP 대신 Service 이름으로도 접근할 수 있다. 쿠버네티스에는 내부 DNS가 있어서 Service 이름을 IP로 변환해 준다. Service를 지우고 다시 만들면 IP는 바뀔 수 있지만 이름은 그대로이므로, 실무에서는 이름으로 접근하는 방식을 사용한다.

클러스터 외부에서 확인해야 할 때는 다음 명령으로 임시 터널을 열 수 있다.

kubectl port-forward svc/svc-1 9000:9000

사용 사례

ClusterIP는 외부에 노출되지 않기 때문에 안전하다. 다음과 같은 경우에 사용한다.

• 내부 트래픽: 백엔드 애플리케이션이 데이터베이스나 캐시 서버에 접근할 때
• 서비스 디버깅: 개발자가 특정 Pod의 동작을 확인할 때
• 대시보드, 모니터링: 내부 관리 도구에 접근할 때
• 인증된 사용자 연결: 별도의 인증을 거친 사용자만 내부 경로로 연결할 때

YAML

apiVersion: v1
kind: Service
metadata:
  name: svc-1
spec:
  selector:
    app: pod
  ports:
    - port: 9000
      targetPort: 8080
  type: ClusterIP

apiVersion: v1
kind: Pod
metadata:
  name: pod-1
  labels:
    app: pod
spec:
  containers:
    - name: container
      image: tmkube/app
      ports:
        - containerPort: 8080

연결의 핵심은 Pod의 labels와 Service의 selector가 일치하는 것이다. 둘 중 하나라도 다르면 Service는 Pod를 찾지 못한다.

2-2-2. NodePort

특징

NodePort는 ClusterIP의 기능을 그대로 가지면서, 외부에서 접근할 수 있는 통로를 추가한다.

구조

┌───────────────────── Cluster ─────────────────────┐
│                                                    │
│         ┌──────────────────────────────┐          │
│         │  Service svc-2               │          │
│         │  IP 172.96.10.17 : 9000      │          │
│         └───┬──────────────────────┬───┘          │
│             │                      │              │
│  ┌──────────▼─────────┐  ┌─────────▼──────────┐  │
│  │ Node1              │  │ Node2              │  │
│  │ 192.168.56.31      │  │ 192.168.56.32      │  │
│  │   ┌──────────┐     │  │   ┌──────────┐     │  │
│  │   │   Pod    │     │  │   │   Pod    │     │  │
│  │   └──────────┘     │  │   └──────────┘     │  │
│  │   [ 30001 ]        │  │   [ 30001 ]        │  │
│  └────────┬───────────┘  └─────────┬──────────┘  │
└───────────┼────────────────────────┼─────────────┘
            │                        │
            └────────┬───────────────┘
                     │  ← 모든 Node에 같은 포트가 열린다
              ┌────────────┐
              │  External  │
              └────────────┘

  외부 접근:  192.168.56.31:30001  또는  192.168.56.32:30001
              (어느 Node로 접근해도 동일하게 동작)

핵심은 "모든 Node에 Port 할당" 이다. Pod가 Node1에만 있어도 Node2의 30001로 접근할 수 있다. 요청을 받은 Node가 Pod가 있는 Node로 트래픽을 전달해 주기 때문이다.

요청의 흐름

   외부 요청: 192.168.56.32 : 30001
                    │
                    │  ① Node2의 nodePort로 도착
                    ▼
            ┌───────────────┐
            │  Service      │  ② port 9000
            └───────┬───────┘
                    │  ③ targetPort 8080 으로 전달
                    ▼
            ┌───────────────┐
            │   Pod  8080   │
            └───────────────┘

YAML

apiVersion: v1
kind: Service
metadata:
  name: svc-2
spec:
  selector:
    app: pod
  ports:
    - port: 9000
      targetPort: 8080
      nodePort: 30000
  type: NodePort

externalTrafficPolicy

NodePort에는 트래픽 전달 방식을 정하는 옵션이 있다.

spec:
  externalTrafficPolicy: Local

   [ Cluster ]                        [ Local ]

  Node2로 요청                       Node2로 요청
      │                                   │
      │ Node2에 Pod 없음                  │ Node2에 Pod 없음
      ▼                                   ▼
  Node1의 Pod로 전달 ✓                요청 실패 ✗
  (한 번 더 이동하므로               (이동이 없어 빠르고
   클라이언트 IP가 사라짐)            클라이언트 IP가 유지됨)

Local은 불필요한 Node 간 이동을 없애고 클라이언트의 원래 IP를 알 수 있다는 장점이 있지만, Pod가 없는 Node로 요청이 오면 실패한다는 단점이 있다.

프로덕션에서 사용하지 않는 이유

NodePort는 데모나 임시 연결용이며 실제 서비스 환경에는 적합하지 않다.

이런 문제를 해결하기 위해 실제 서비스에서는 LoadBalancer를 사용한다.

2-2-3. LoadBalancer

특징

LoadBalancer는 NodePort의 기능을 그대로 가지면서, 외부 로드밸런서를 통해 하나의 접속 주소를 제공한다.

구조

              ┌────────────┐
              │  External  │
              └──────┬─────┘
                     │  접속 주소 하나만 알면 된다
                     ▼
        ┌────────────────────────────┐
        │      Load Balancer         │  ← 클라우드가 제공
        │      (외부 IP 할당)        │
        └──────┬──────────────┬──────┘
               │              │
┌──────────────┼──────────────┼─────────────────┐
│  Cluster     │              │                 │
│  ┌───────────▼──────┐ ┌─────▼────────────┐   │
│  │ Node1            │ │ Node2            │   │
│  │  ┌──────────┐    │ │  ┌──────────┐    │   │
│  │  │   Pod    │    │ │  │   Pod    │    │   │
│  │  └──────────┘    │ │  └──────────┘    │   │
│  └──────────────────┘ └──────────────────┘   │
└───────────────────────────────────────────────┘

NodePort에서는 사용자가 Node의 IP를 직접 알아야 했지만, LoadBalancer는 로드밸런서 주소 하나만 알면 된다. 로드밸런서가 정상 동작하는 Node를 골라서 트래픽을 전달하므로, Node 하나가 죽어도 서비스가 계속된다.

YAML

apiVersion: v1
kind: Service
metadata:
  name: svc-3
spec:
  selector:
    app: pod
  ports:
    - port: 9000
      targetPort: 8080
  type: LoadBalancer

nodePort를 적지 않아도 내부적으로 자동 할당된다. LoadBalancer가 NodePort의 기능을 포함하고 있기 때문이다.

사용 시 주의점

LoadBalancer는 로드밸런서를 제공해 주는 플랫폼이 있어야 동작한다. AWS, GCP, Azure 같은 클라우드 환경에서는 Service를 만드는 순간 클라우드가 로드밸런서를 자동으로 생성해 준다.

반면 개인 PC에 설치한 학습용 클러스터(minikube, kubeadm 등)에서는 로드밸런서를 만들어 줄 주체가 없다. 이 경우 Service의 상태를 조회하면 EXTERNAL-IP가 계속 <pending> 으로 남는다.

$ kubectl get svc
NAME    TYPE           EXTERNAL-IP     PORT(S)
svc-3   LoadBalancer   <pending>       9000:31234/TCP

또한 클라우드에서 LoadBalancer 타입 Service를 만들면 로드밸런서가 하나씩 생성되며, 이는 비용이 발생한다. Service를 여러 개 만들면 로드밸런서도 그만큼 생성되므로 실무에서는 Ingress를 함께 사용해 로드밸런서 하나로 여러 서비스를 처리하는 구성을 많이 쓴다.

세 가지 Service 비교

   ClusterIP              NodePort                LoadBalancer
   ─────────              ────────                ────────────
                                                  ┌──────────┐
                                                  │    LB    │
                                                  └────┬─────┘
                          ┌────┐  ┌────┐          ┌────┴─────┐
     ┌──────┐             │30001│ │30001│          │30001│30001│
     │ Svc  │             └──┬─┘  └──┬─┘          └──┬──┘└──┬─┘
     └──┬───┘             ┌──┴────┬──┴──┐          ┌──┴────┬─┴───┐
     ┌──┴───┐             │ Node1 │Node2│          │ Node1 │Node2│
     │ Pod  │             │  Pod  │ Pod │          │  Pod  │ Pod │
     └──────┘             └───────┴─────┘          └───────┴─────┘

   내부만 접근           Node IP로 접근          전용 IP 하나로 접근

2-3. Volume

Volume이란 무엇이고 왜 필요한가

컨테이너 안에 저장한 데이터는 컨테이너가 재시작되면 사라진다. 컨테이너는 이미지를 기반으로 매번 새로 만들어지기 때문에, 실행 중에 쓴 파일은 남지 않는다.

   ┌──────────────┐          ┌──────────────┐
   │ Container    │          │ Container    │
   │              │  재시작  │  (새로 생성) │
   │ /data/a.txt  │  ──────▶ │              │  ← 파일 사라짐
   └──────────────┘          └──────────────┘

Volume은 이 문제를 해결하기 위해 컨테이너 외부에 데이터를 저장하는 공간을 컨테이너에 연결해 주는 오브젝트다.

Volume에는 세 가지 방식이 있으며, 데이터가 얼마나 오래 살아남는지가 다르다.

   emptyDir          hostPath           PVC / PV
   ────────          ────────           ────────
   Pod 삭제 시       Node 삭제 시       외부 저장소에 보관
   사라짐            사라짐             계속 남음

   [ 짧음 ] ──────────────────────────────▶ [ 김 ]
                    데이터 수명

2-3-1. emptyDir

특징

emptyDir은 Pod 안에 생성되는 볼륨이다.

Pod와 생명주기가 같기 때문에, 영구 보관이 필요 없는 일시적 목적의 데이터를 담는다.

구조

┌─────────────────── Pod ───────────────────┐
│                                            │
│                    ┌──────────────────┐   │
│                ┌──▶│  Container1      │   │
│  ┌──────────┐  │   │  mountPath:      │   │
│  │  Volume  │──┤   │   /mount1        │   │
│  │(emptyDir)│  │   └──────────────────┘   │
│  └──────────┘  │   ┌──────────────────┐   │
│                └──▶│  Container2      │   │
│                    │  mountPath:      │   │
│                    │   /mount2        │   │
│                    └──────────────────┘   │
│                                            │
│   Pod 생성 시 만들어지고, 삭제 시 없어짐   │
└────────────────────────────────────────────┘

같은 Volume을 두 컨테이너가 각각 다른 경로에 마운트했다. Container1이 /mount1에 파일을 쓰면 Container2는 /mount2에서 그 파일을 읽을 수 있다. 경로 이름은 달라도 실체는 같은 저장 공간이다.

어떤 데이터를 넣는가

Pod가 사라지면 없어져도 괜찮은 데이터를 넣는다.

반대로 주문 내역, 회원 정보, 업로드된 원본 파일처럼 사라지면 안 되는 데이터는 절대 emptyDir에 두면 안 된다.

YAML

apiVersion: v1
kind: Pod
metadata:
  name: pod-volume-1
spec:
  containers:
    - name: container1
      image: tmkube/init
      volumeMounts:
        - name: empty-dir
          mountPath: /mount1
    - name: container2
      image: tmkube/init
      volumeMounts:
        - name: empty-dir
          mountPath: /mount2
  volumes:
    - name: empty-dir
      emptyDir: {}

volumes에서 볼륨을 정의하고, volumeMounts에서 각 컨테이너에 연결하는 두 단계 구조다.

2-3-2. hostPath

특징

hostPath는 Pod가 올라가 있는 Node의 경로를 볼륨으로 사용한다.

구조

┌─────────────── Node1 ────────────────┐
│                                       │
│   ┌──────────────┐    ┌───────────┐  │
│   │   Volume     │───▶│   Pod1    │  │
│   │  /node-v1    │    │  /data    │  │
│   │              │    └───────────┘  │
│   │  (Node의     │    ┌───────────┐  │
│   │   실제 경로) │───▶│   Pod2    │  │
│   └──────────────┘    │  /data    │  │
│                       └───────────┘  │
└───────────────────────────────────────┘
        │
        │  Pod2가 죽고 Node2에 재생성되면?
        ▼
┌─────────────── Node2 ────────────────┐
│                                       │
│   ┌──────────────┐    ┌───────────┐  │
│   │   Volume     │───▶│   Pod2    │  │
│   │  /node-v1    │    │  /data    │  │
│   │              │    └───────────┘  │
│   │  ← 비어 있음 │                   │
│   └──────────────┘                   │
└───────────────────────────────────────┘
       Node1의 데이터는 볼 수 없다

이것이 hostPath의 가장 큰 함정이다. Pod가 재생성될 때 다른 Node에 배치되면, 그 Node의 경로에는 이전 데이터가 없다. 같은 경로 이름을 썼더라도 물리적으로 다른 디스크이기 때문이다.

또한 Node를 추가할 때마다 해당 경로를 직접 만들고 마운트를 걸어줘야 한다. Node가 늘어날수록 관리 부담이 커진다.

어떤 데이터를 넣는가

hostPath는 애플리케이션 데이터 저장용이 아니라, Node 자체의 정보에 접근하기 위해 사용한다.

이런 작업은 Node마다 하나씩 Pod를 띄우는 방식(DaemonSet) 과 함께 쓰인다. 모든 Node에 로그 수집기를 하나씩 배치하는 구성이 대표적이다.

YAML

apiVersion: v1
kind: Pod
metadata:
  name: pod-volume-2
spec:
  containers:
    - name: container
      image: tmkube/init
      volumeMounts:
        - name: host-path
          mountPath: /mount1
  volumes:
    - name: host-path
      hostPath:
        path: /node-v
        type: Directory

type: Directory로 지정하면 사전에 그 경로가 Node에 없을 경우 Pod가 생성되지 않는다. 경로가 없을 때 자동으로 만들려면 DirectoryOrCreate를 사용한다.

2-3-3. PVC / PV

왜 필요한가

emptyDir은 Pod와 함께 사라지고, hostPath는 Node에 묶여 있다. 데이터베이스 데이터처럼 어떤 상황에도 사라지면 안 되는 데이터는 두 방식 모두 적합하지 않다.

PV와 PVC는 클러스터 외부의 저장소(NFS, AWS EBS, iSCSI 등)를 연결해 영속성 있는 볼륨을 제공한다.

   emptyDir              hostPath              PV / PVC
   ────────              ────────              ────────
   Pod 안에 저장          Node에 저장           외부 저장소에 저장
        │                     │                      │
   Pod 삭제 → 소멸       Node 변경 → 소멸       Pod·Node와 무관하게 보존

두 오브젝트의 역할 분리

PV와 PVC가 나뉘어 있는 이유는 관리자와 사용자의 역할을 분리하기 위해서다.

        User (개발자)                    Admin (인프라 관리자)
   ───────────────────────         ────────────────────────────
   "1Gi 저장 공간이 필요해요"      "실제 저장소를 준비해뒀습니다"
            │                                   │
           PVC                                 PV
     (요청서 / 신청서)               (실제 저장소 연결 정보)

개발자는 저장소가 NFS인지 AWS EBS인지 알 필요 없이 "1Gi가 필요하다"고 요청만 하면 된다. 저장소 종류가 바뀌어도 PVC는 수정할 필요가 없다.

생성 과정

┌────────────── User ──────────────┐   ┌───────────── Admin ─────────────┐
│                                   │   │                                  │
│                                   │   │  ┌────────────────────┐         │
│                                   │   │  │ PersistentVolume   │  ┌─────┐│
│                                   │   │  │ pv-01              │──│ 실제││
│                                   │   │  │ 용량 1Gi           │  │저장소││
│                                   │   │  └─────────┬──────────┘  │ NFS ││
│                                   │   │            │             │ AWS ││
│         ┌──────────────────┐      │   │            │             │iSCSI││
│         │ PersistentVolume │◀─────┼───┼────────────┘             └─────┘│
│         │ Claim  pvc-01    │  ③   │   │  ┌────────────────────┐         │
│         │ 요청 1Gi         │      │   │  │ PersistentVolume   │         │
│         └────────┬─────────┘      │   │  │ pv-02              │         │
│                  │  ②             │   │  └────────────────────┘         │
│         ┌────────▼─────────┐      │   │            ①                    │
│         │      Pod         │      │   │                                  │
│         │  PVC 마운트  ④   │      │   │                                  │
│         └──────────────────┘      │   │                                  │
└───────────────────────────────────┘   └──────────────────────────────────┘

① PV 정의 생성 (Admin)

관리자가 실제 저장소를 PV로 등록한다. "1Gi 짜리 저장 공간이 이 위치에 있다"는 정보다.

② PVC 생성 (User)

개발자가 "1Gi가 필요하다"는 요청서를 만든다.

③ PV 연결 (자동)

쿠버네티스가 조건에 맞는 PV를 찾아 PVC와 연결한다. 이 연결을 바인딩(Binding) 이라고 한다. 조건에 맞는 PV가 없으면 PVC는 Pending 상태로 대기한다.

④ Pod 생성 시 PVC 마운트 (User)

Pod에서 PVC를 볼륨으로 지정하면, 연결된 PV의 실제 저장소를 사용하게 된다.

Pod는 PV를 직접 참조하지 않고 항상 PVC를 통해서만 접근한다.

어떤 데이터를 넣는가

사라지면 안 되는 모든 데이터를 넣는다.

YAML

PV — 관리자가 저장소를 등록

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-01
spec:
  capacity:
    storage: 1G
  accessModes:
    - ReadWriteOnce
  local:
    path: /node-v
  nodeAffinity:
    required:
      nodeSelectorTerms:
        - matchExpressions:
            - {key: kubernetes.io/hostname, operator: In, values: [node1]}

local 타입은 특정 Node의 디스크를 사용하므로, 그 Node에서만 접근 가능하다. 그래서 nodeAffinity로 Pod가 반드시 node1에 배치되도록 강제한다.

PVC — 사용자가 저장 공간을 요청

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-01
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1G
  storageClassName: ""

Pod — PVC를 볼륨으로 사용

apiVersion: v1
kind: Pod
metadata:
  name: pod-volume-3
spec:
  containers:
    - name: container
      image: tmkube/init
      volumeMounts:
        - name: pvc-pv
          mountPath: /volume
  volumes:
    - name: pvc-pv
      persistentVolumeClaim:
        claimName: pvc-01

accessModes

PV와 PVC를 연결할 때 반드시 일치해야 하는 값이다.

ReadWriteOnce가 가장 일반적이며, 데이터베이스처럼 하나의 Pod만 데이터를 쓰는 경우에 사용한다. 여러 Pod가 동시에 같은 파일에 써야 한다면 ReadWriteMany를 지원하는 저장소(NFS 등)가 필요하다.

세 가지 Volume 비교

   emptyDir                hostPath                 PVC / PV
   ────────                ────────                 ────────
  ┌──────────┐          ┌──────────────┐        ┌──────────────┐
  │   Pod    │          │    Node      │        │    Pod       │
  │ ┌──────┐ │          │  ┌────────┐  │        │      │       │
  │ │Volume│ │          │  │  Pod   │  │        │     PVC      │
  │ └──────┘ │          │  └───┬────┘  │        │      │       │
  └──────────┘          │  ┌───▼────┐  │        │      PV      │
                        │  │ /path  │  │        └──────┼───────┘
                        │  └────────┘  │               ▼
                        └──────────────┘        ┌──────────────┐
                                                │ 외부 저장소  │
                                                │ NFS / AWS    │
                                                └──────────────┘

선택 기준은 다음과 같이 정리할 수 있다.

• 데이터가 Pod와 함께 사라져도 되는가 → emptyDir
• Node 자체의 파일에 접근해야 하는가 → hostPath
• 데이터가 절대 사라지면 안 되는가 → PVC / PV

2-4. ConfigMap과 Secret

왜 필요한가

문제 상황 — 환경마다 값이 다르다

같은 애플리케이션이라도 개발 환경과 운영 환경에서 설정 값이 달라야 하는 경우가 많다.

이 값들을 컨테이너 이미지 안에 넣어두면 어떻게 될까.

   ┌──────────────────────┐    ┌──────────────────────┐
   │ Container for Dev    │    │ Container for Prod   │
   │  ┌────────────────┐  │    │  ┌────────────────┐  │
   │  │  A Service     │  │    │  │  A Service     │  │
   │  │  SSH  : False  │  │    │  │  SSH  : True   │  │
   │  │  User : Dev    │  │    │  │  User : Prod   │  │
   │  │  Key  : LS0tLs.│  │    │  │  Key  : MII3Ld.│  │
   │  └────────────────┘  │    │  └────────────────┘  │
   └──────────────────────┘    └──────────────────────┘

        환경마다 이미지를 따로 만들어야 한다

이 방식에는 두 가지 문제가 있다.

• 이미지가 환경 수만큼 늘어난다. 개발·스테이징·운영이 있다면 이미지가 3개다. 코드는 완전히 같은데 설정만 다른 이미지를 각각 관리해야 한다.
• 개발 환경에서 검증한 이미지가 운영에 그대로 가지 않는다. 운영용 이미지는 별도로 빌드된 것이므로, 테스트한 것과 다른 이미지가 배포된다.

해결 — 설정을 이미지 밖으로 분리한다

이미지는 값을 비워둔 채 하나만 만들고, 실제 값은 배포 시점에 외부에서 주입한다.

   ┌──────────────────────┐
   │  Container (하나)    │
   │  ┌────────────────┐  │
   │  │  A Service     │  │
   │  │  SSH  : [    ] │  │  ← 값이 비어 있음
   │  │  User : [    ] │  │
   │  │  Key  : [    ] │  │
   │  └────────────────┘  │
   └──────────────────────┘
              │
      ┌───────┴────────┐
      ▼                ▼
   [ Dev 값 주입 ]  [ Prod 값 주입 ]

이때 값을 담아두는 오브젝트가 ConfigMap과 Secret이다.

ConfigMap과 Secret의 구분

전체 구조

┌──────────── Dev ────────────┐   ┌──────── Production ─────────┐
│                              │   │                              │
│  ┌────────────┐              │   │  ┌────────────┐              │
│  │ ConfigMap  │              │   │  │ ConfigMap  │              │
│  │ SSH : False│──┐           │   │  │ SSH : True │──┐           │
│  │ User: Dev  │  │           │   │  │ User: Prod │  │           │
│  └────────────┘  │  ┌──────┐ │   │  └────────────┘  │  ┌──────┐ │
│                  ├─▶│ Pod  │ │   │                  ├─▶│ Pod  │ │
│  ┌────────────┐  │  │ Env  │ │   │  ┌────────────┐  │  │ Env  │ │
│  │  Secret    │  │  └──────┘ │   │  │  Secret    │  │  └──────┘ │
│  │ Key:LS0tLs.│──┘           │   │  │ Key:MII3Ld.│──┘           │
│  └────────────┘              │   │  └────────────┘              │
└──────────────────────────────┘   └──────────────────────────────┘

        같은 이미지 + 다른 ConfigMap/Secret = 다른 동작

Pod를 생성할 때 ConfigMap과 Secret의 값을 가져와 컨테이너의 환경변수에 세팅한다. 이미지는 하나지만 어떤 ConfigMap을 붙이느냐에 따라 Dev용 Pod가 되기도 하고 Production용 Pod가 되기도 한다.

Secret이 메모리에 저장되는 이유

Secret은 Node의 디스크가 아니라 메모리(tmpfs) 에 저장된다. 보안상의 이유 때문이다.

   [ 디스크에 저장한다면 ]              [ 메모리에 저장하면 ]

   ┌──────────────────┐               ┌──────────────────┐
   │  Node 디스크     │               │  Node 메모리     │
   │  password=1234   │               │  password=1234   │
   └──────────────────┘               └──────────────────┘
            │                                   │
   Node 종료 후에도 파일이 남음          Node 종료 시 함께 사라짐
   디스크를 확보하면 값을 볼 수 있음     흔적이 남지 않음

Secret에는 크기 제한이 있다. 하나의 Secret은 1MByte를 넘을 수 없다. 메모리에 저장되기 때문에, 큰 데이터를 담으면 Node의 메모리를 잠식할 수 있어서다.

Base64 인코딩

Secret에 값을 넣을 때는 Base64로 인코딩해서 넣는다.

   원본 값              Base64 인코딩         Secret에 저장
   "1234"      ──────▶   "MTIzNA=="    ──────▶  data.Key
                                                     │
                                                     │ Pod에 주입 시
                                                     │ 자동 디코딩
                                                     ▼
                                              컨테이너 환경변수
                                                  PW = 1234

컨테이너에 전달될 때는 쿠버네티스가 자동으로 디코딩하므로, 애플리케이션은 원본 값을 그대로 받는다.

여기서 반드시 알아야 할 점이 있다. Base64는 암호화가 아니다. 누구나 되돌릴 수 있는 단순 변환이다.

$ echo "MTIzNA==" | base64 --decode
1234

Base64를 쓰는 이유는 보안이 아니라, 인증서처럼 줄바꿈이나 특수문자가 섞인 값을 YAML에 안전하게 담기 위해서다. 따라서 Secret이 담긴 YAML 파일을 Git에 그대로 올리면 안 된다. 실무에서는 별도의 비밀 관리 도구(Sealed Secrets, Vault 등)를 함께 사용한다.

값을 주입하는 세 가지 방법

ConfigMap과 Secret의 값을 컨테이너에 전달하는 방법은 세 가지다.

   ① Env (Literal)        ② Env (File)         ③ Volume Mount (File)
   ───────────────        ────────────         ─────────────────────
   상수 값을              파일 내용을           파일을 파일 그대로
   환경변수로             환경변수로            컨테이너에 마운트

   SSH = False            file = (파일 내용)    /mount/file.txt

2-4-1. Env (Literal) — 상수를 환경변수로

개념

가장 기본적인 방식이다. ConfigMap과 Secret에 key: value 형태의 상수를 넣고, 이를 컨테이너의 환경변수로 주입한다.

구조

  ┌─────────────────┐        ┌─────────────────┐
  │   ConfigMap     │        │     Secret      │
  │   cm-dev        │        │     sec-dev     │
  │                 │        │                 │
  │  Key   : Value  │        │  Key   : Value  │
  │  SSH   : False  │        │  PW    : Base64 │  ← 메모리 1Mbyte
  │  user  : dev    │        │                 │
  └────────┬────────┘        └────────┬────────┘
           │                          │
           │                          │  Decoding
           ▼                          ▼
  ┌──────────────────────────────────────────┐
  │                  Pod                      │
  │  ┌────────────────────────────────────┐  │
  │  │            Container               │  │
  │  │  env                               │  │
  │  │   SSH  : False                     │  │
  │  │   user : dev                       │  │
  │  │   PW   : 1234   ← 자동 디코딩됨    │  │
  │  └────────────────────────────────────┘  │
  └──────────────────────────────────────────┘

ConfigMap의 값은 그대로 전달되고, Secret의 값은 Base64에서 원본으로 디코딩되어 전달된다.

YAML

ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: cm-dev
data:
  SSH: "false"
  User: dev

Secret

apiVersion: v1
kind: Secret
metadata:
  name: sec-dev
data:
  Key: MTIzNA==

Pod

apiVersion: v1
kind: Pod
metadata:
  name: pod-1
spec:
  containers:
    - name: container
      image: tmkube/init
      envFrom:
        - configMapRef:
            name: cm-dev
        - secretRef:
            name: sec-dev

envFrom을 쓰면 안에 있는 key가 전부 환경변수가 된다. 특정 key만 골라서 가져오고 싶다면 env를 사용한다.

사용 예시

애플리케이션에서 다음과 같이 값을 읽는다.

// Spring Boot
@Value("${SSH}")
private boolean sshEnabled;

애플리케이션 코드는 이 값이 ConfigMap에서 왔는지 Secret에서 왔는지 알 필요가 없다. 그냥 환경변수를 읽을 뿐이다.

2-4-2. Env (File) — 파일 내용을 환경변수로

개념

설정 값이 길거나 이미 파일로 존재하는 경우, 파일 자체를 ConfigMap에 넣을 수 있다. 이때 파일 이름이 key가 되고, 파일 안의 내용이 value가 된다.

        file.txt
   ┌──────────────────┐
   │  Content         │      ConfigMap에 넣으면
   │  (파일 내용)     │  ──────────────────────▶  key   : file.txt
   └──────────────────┘                           value : Content
        ▲        ▲
     파일 이름  파일 내용
        │        │
       key     value

구조

              file.txt
       ┌──────────────────┐
       │     Content      │
       └────┬────────┬────┘
            │        │
            ▼        ▼
  ┌─────────────┐  ┌─────────────┐
  │  ConfigMap  │  │   Secret    │
  │             │  │             │
  │ Key : Value │  │ Key : Value │
  │ file.txt :  │  │ file.txt :  │
  │   Content   │  │   Base64    │
  └──────┬──────┘  └──────┬──────┘
         │                │  Decoding
         ▼                ▼
  ┌──────────────────────────────┐
  │            Pod                │
  │  ┌────────────────────────┐  │
  │  │       Container        │  │
  │  │  env                   │  │
  │  │   file : Content       │  │
  │  └────────────────────────┘  │
  └───────────────────────────────┘

생성 방법

이 방식은 YAML로 직접 작성하지 않고 명령어로 생성한다. 파일 내용을 사람이 옮겨 적을 필요가 없다.

# ConfigMap 생성
kubectl create configmap cm-file --from-file=./file.txt

# Secret 생성 (Base64 인코딩은 자동으로 처리됨)
kubectl create secret generic sec-file --from-file=./file.txt

--from-file 옵션을 쓰면 파일 이름이 key가 되고 내용이 value가 된다. Secret은 인코딩까지 자동으로 해준다.

YAML

apiVersion: v1
kind: Pod
metadata:
  name: file
spec:
  containers:
    - name: container
      image: tmkube/init
      env:
        - name: file
          valueFrom:
            configMapKeyRef:
              name: cm-file
              key: file.txt

앞의 envFrom이 모든 key를 가져왔다면, env + valueFrom은 특정 key 하나만 골라서 원하는 이름의 환경변수로 만든다. 위 예시에서는 file.txt라는 key의 값을 file이라는 환경변수로 받는다.

한계

환경변수는 컨테이너가 시작될 때 한 번 주입되고 끝난다. ConfigMap의 값을 나중에 수정해도 이미 실행 중인 컨테이너의 환경변수는 바뀌지 않는다. 새 값을 반영하려면 Pod를 재생성해야 한다.

2-4-3. Volume Mount (File) — 파일을 파일로 마운트

개념

ConfigMap의 내용을 환경변수가 아니라 파일 형태 그대로 컨테이너 안에 넣는 방식이다. Volume에서 배운 마운트 방식을 그대로 사용한다.

구조

              file.txt
       ┌──────────────────┐
       │     Content      │
       └────┬────────┬────┘
            │        │
            ▼        ▼
  ┌─────────────┐  ┌─────────────┐
  │  ConfigMap  │  │   Secret    │
  │ file.txt :  │  │ file.txt :  │
  │   Content   │  │   Base64    │
  └──────┬──────┘  └──────┬──────┘
         │                │  Decoding
         ▼                ▼
  ┌──────────────────────────────────┐
  │              Pod                  │
  │  ┌────────────────────────────┐  │
  │  │        Container           │  │
  │  │                            │  │
  │  │   /mount                   │  │  ← mountPath
  │  │     └── file.txt           │  │  ← key가 파일명이 된다
  │  │           Content          │  │  ← value가 파일 내용이 된다
  │  └────────────────────────────┘  │
  └───────────────────────────────────┘

마운트한 경로 아래에 key 이름의 파일이 생성되고, 그 파일 안에 value가 들어간다.

YAML

apiVersion: v1
kind: Pod
metadata:
  name: mount
spec:
  containers:
    - name: container
      image: tmkube/init
      volumeMounts:
        - name: file-volume
          mountPath: /mount
  volumes:
    - name: file-volume
      configMap:
        name: cm-file

Volume에서 emptyDir이나 hostPath를 쓰던 자리에 configMap을 넣는 구조다. Secret을 마운트할 때는 secret: secretName: sec-file 형태로 작성한다.

컨테이너 안에서 확인하면 다음과 같다.

$ ls /mount
file.txt

$ cat /mount/file.txt
Content

어떤 경우에 사용하는가

환경변수로는 여러 줄로 된 설정 파일을 다루기 어렵다. 이런 경우 Volume Mount 방식이 적합하다.

환경변수 방식과의 결정적 차이

Volume Mount 방식은 ConfigMap을 수정하면 마운트된 파일도 자동으로 갱신된다. Pod를 재생성하지 않아도 된다.

   [ Env 방식 ]                     [ Volume Mount 방식 ]

   ConfigMap 수정                    ConfigMap 수정
        │                                 │
        ▼                                 ▼
   컨테이너 환경변수 그대로          마운트된 파일 자동 갱신
        │                                 │
   Pod 재생성 필요                   Pod 유지 가능

다만 파일 내용이 바뀌어도 애플리케이션이 자동으로 다시 읽어들이지는 않는다. 애플리케이션이 파일 변경을 감지해 재로딩하는 기능을 가지고 있어야 실제로 반영된다.

세 가지 방식 비교

선택 기준

• 값이 짧고 단순한 상수인가 → Env (Literal)
• 파일에 있는 값을 환경변수로 받고 싶은가 → Env (File)
• 애플리케이션이 파일 형태로 읽어야 하는가 → Volume Mount (File)

2-5. Namespace, ResourceQuota, LimitRange

왜 필요한가

문제 상황 — 자원 독점

쿠버네티스 클러스터가 사용할 수 있는 자원(Memory, CPU)은 정해져 있다. 그런데 아무런 제약이 없다면 한 팀이 자원을 전부 가져가는 상황이 발생할 수 있다.

┌──────────────── Kubernetes Cluster ────────────────┐
│                                                     │
│   Memory  ┌─┐┌─┐┌─┐┌─┐┌─┐                          │
│   CPU     └─┘└─┘└─┘└─┘└─┘   ← 클러스터 전체 자원   │
│              │                                      │
│              │ A팀이 전부 사용                      │
│              ▼                                      │
│   ┌──────────────────┐      ┌──────────────────┐  │
│   │  A팀 Pod         │      │  B팀 Pod         │  │
│   │  전체 자원 점유  │      │  자원 부족 ✗     │  │
│   └──────────────────┘      └──────────────────┘  │
│                                                     │
└─────────────────────────────────────────────────────┘

한쪽에서 자원을 독점하면 다른 쪽은 Pod를 아예 생성하지 못한다. 개발 환경의 테스트 Pod가 메모리를 다 써버려서 운영 서비스가 배포되지 못하는 상황이 벌어질 수 있다.

이를 방지하기 위해 세 가지 오브젝트를 사용한다.

세 가지의 관계

┌─────────────────── Kubernetes Cluster ───────────────────┐
│                                                           │
│  Memory ┌─┐┌─┐┌─┐┌─┐┌─┐                                  │
│  CPU    └─┘└─┘└─┘└─┘└─┘                                  │
│      │        │         │                                 │
│      ▼        ▼         ▼                                 │
│  ┌────────┐ ┌────────┐ ┌────────────────────────────┐    │
│  │Resource│ │Resource│ │ ResourceQuota  LimitRange  │    │
│  │ Quota  │ │ Quota  │ │                            │    │
│  │┌──────┐│ │┌──────┐│ │ ┌────────────┐             │    │
│  ││ Pod  ││ ││ Pod  ││ │ │            │   ┌─────┐   │    │
│  ││ Pod  ││ ││ Pod  ││ │ │    Pod     │◀──│ Pod │   │    │
│  │└──────┘│ │└──────┘│ │ │  (큰 Pod)  │   └─────┘   │    │
│  │Namespace│ │Namespace│ │ └────────────┘  ┌─────┐   │    │
│  └────────┘ └────────┘ │      크기 초과 ✗ │ Pod │   │    │
│                        │                  └─────┘   │    │
│                        │      Namespace             │    │
│                        └────────────────────────────┘    │
└───────────────────────────────────────────────────────────┘

ResourceQuota는 Namespace가 쓸 수 있는 총합을 막고, LimitRange는 Namespace에 들어오려는 Pod 하나하나의 크기를 막는다.

두 오브젝트 모두 Namespace에 설정하는 오브젝트다. 클러스터 전체에 한 번에 적용하는 방법은 없으며, 자원을 통제하려는 Namespace마다 각각 만들어야 한다.

2-5-1. Namespace

개념

Namespace는 하나의 클러스터를 여러 개의 논리적인 공간으로 나누는 오브젝트다. 물리적으로 서버를 나누는 것이 아니라, 같은 클러스터 안에서 오브젝트를 그룹으로 구분하는 것이다.

특성 1 — 이름의 중복 허용

같은 Namespace 안에서는 오브젝트 이름이 유일해야 한다. 반대로 말하면, Namespace가 다르면 같은 이름을 써도 된다.

┌──── Namespace-1 ────┐      ┌──── Namespace-2 ────┐
│                      │      │                      │
│   ┌──────────────┐   │      │   ┌──────────────┐   │
│   │   Pod1       │   │      │   │   Pod1       │   │
│   │   nm: pod1   │   │      │   │   nm: pod1   │   │
│   └──────────────┘   │      │   └──────────────┘   │
│                      │      │                      │
│   같은 이름을 또 만들면 ✗  │      │  다른 Namespace라 가능 ✓ │
└──────────────────────┘      └──────────────────────┘

dev 네임스페이스와 production 네임스페이스에 각각 api-server라는 이름의 Pod를 둘 수 있다. 이름을 dev-api-server, prod-api-server처럼 구분해서 지을 필요가 없다.

특성 2 — 다른 Namespace의 자원과 연결되지 않는다

Service의 selector는 같은 Namespace 안의 Pod만 선택한다. Label이 완전히 같아도 Namespace가 다르면 연결되지 않는다.

┌──── Namespace-1 ────┐      ┌──── Namespace-2 ────┐
│                      │      │                      │
│   ┌──────────────┐   │      │   ┌──────────────┐   │
│   │   Pod1       │   │      │   │  Service1    │   │
│   │   nm: pod1   │◀──┼──✗───┼───│ selector:    │   │
│   │              │   │      │   │   nm: pod1   │   │
│   └──────────────┘   │      │   └──────────────┘   │
│                      │      │                      │
└──────────────────────┘      └──────────────────────┘

     Label이 같아도 Namespace가 다르면 선택되지 않는다

다만 이것은 오브젝트 연결이 안 된다는 의미이지, 네트워크가 차단된다는 의미는 아니다. Pod의 IP를 직접 알고 있다면 다른 Namespace의 Pod에도 접근할 수 있다.

   Namespace-2의 Pod  ──── 10.2.3.12 로 직접 호출 ────▶  Namespace-1의 Pod
                                                              접근 가능 ✓

네트워크까지 차단하려면 NetworkPolicy라는 별도의 오브젝트가 필요하다.

특성 3 — Namespace에 속하지 않는 오브젝트가 있다

모든 오브젝트가 Namespace에 속하는 것은 아니다.

        ┌──────────────┐   ┌──────────────┐
        │      PV      │   │     Node     │  ← Namespace에 속하지 않음
        └──────┬───────┘   └──────┬───────┘
               │                  │
     ┌─────────┴──────────────────┴─────────┐
     │                                       │
┌────▼─────────────┐              ┌──────────▼───────┐
│  Namespace-1     │              │  Namespace-2     │
│    Pod, Service  │              │    Pod, Service  │
└──────────────────┘              └──────────────────┘

Node는 물리적인 서버이고 PV는 실제 저장소이므로, 논리적 구분인 Namespace에 종속될 수 없다. 여러 Namespace의 Pod가 같은 Node 위에서 실행된다.

특성 4 — Namespace를 삭제하면 안의 오브젝트가 모두 삭제된다

Namespace를 지우면 그 안에 있던 Pod, Service, ConfigMap이 전부 함께 삭제된다. 정리할 때는 편리하지만 실수하면 되돌릴 수 없으므로 주의해야 한다.

YAML

Namespace 생성

apiVersion: v1
kind: Namespace
metadata:
  name: nm-1

Pod를 특정 Namespace에 생성

apiVersion: v1
kind: Pod
metadata:
  name: pod-1
  namespace: nm-1
  labels:
    nm: pod1
spec:
  containers:
    - name: container
      image: tmkube/init

다른 Namespace의 Service

apiVersion: v1
kind: Service
metadata:
  name: svc-1
  namespace: nm-2
spec:
  selector:
    nm: pod1
  ports:
    - port: 8080

이 Service는 nm-2에 있으므로 nm-1에 있는 Pod를 선택하지 못한다.

자주 쓰는 명령어

# Namespace 목록 조회
kubectl get namespace

# 특정 Namespace의 Pod 조회
kubectl get pods -n nm-1

# 모든 Namespace의 Pod 조회
kubectl get pods --all-namespaces

-n 옵션을 생략하면 default Namespace를 조회한다. Pod를 만들었는데 목록에 안 보인다면 Namespace를 지정하지 않아서인 경우가 많다.

2-5-2. ResourceQuota

개념

ResourceQuota는 하나의 Namespace가 사용할 수 있는 자원의 총량을 제한한다.

┌────────────────── Namespace (nm-1) ──────────────────┐
│                                                       │
│   ResourceQuota                                       │
│   requests.memory : 3Gi   ← 이 Namespace의 총 한도   │
│   limits.memory   : 6Gi                               │
│                                                       │
│   ┌──────────────┐  ┌──────────────┐                 │
│   │ Pod1         │  │ Pod3         │                 │
│   │ requests 2Gi │  │ requests 2Gi │  ← 합계 4Gi     │
│   │ limits   4Gi │  │ limits   2Gi │     한도 3Gi 초과│
│   └──────────────┘  └──────┬───────┘                 │
│                            │                          │
│                            ✗ 생성 거부                │
└───────────────────────────────────────────────────────┘

Pod1이 이미 2Gi를 요청한 상태에서 Pod3가 2Gi를 추가로 요청하면 합계가 4Gi가 되어 한도인 3Gi를 넘는다. 이 경우 Pod3는 생성되지 않는다.

제한할 수 있는 항목

ResourceQuota는 자원의 양뿐 아니라 오브젝트의 개수도 제한할 수 있다.

Pod 개수를 10개로 제한해두면 그 Namespace에서는 11번째 Pod를 만들 수 없다.

중요한 제약 — Pod에 반드시 resources를 명시해야 한다

ResourceQuota가 설정된 Namespace에서는 모든 Pod가 requests와 limits를 반드시 작성해야 한다.

   ┌──────────────┐
   │ Pod2         │
   │              │  ← resources 항목이 없음
   │ (설정 없음)  │
   └──────┬───────┘
          │
          ✗ 생성 거부

이유는 단순하다. ResourceQuota는 "현재 사용량의 합계"를 계산해서 한도와 비교하는데, Pod가 자기 사용량을 밝히지 않으면 계산이 불가능하기 때문이다.

이 제약 때문에 실무에서는 ResourceQuota를 걸어두면 개발자가 resources를 깜빡해 Pod 생성이 실패하는 일이 자주 발생한다. 뒤에 나오는 LimitRange의 default 설정으로 이 문제를 해결할 수 있다.

YAML

ResourceQuota

apiVersion: v1
kind: ResourceQuota
metadata:
  name: rq-1
  namespace: nm-1
spec:
  hard:
    requests.memory: 3Gi
    limits.memory: 6Gi

Pod

apiVersion: v1
kind: Pod
metadata:
  name: pod-2
  namespace: nm-1
spec:
  containers:
    - name: container
      image: tmkube/app
      resources:
        requests:
          memory: 2Gi
        limits:
          memory: 2Gi

사용 예시

spec:
  hard:
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.cpu: "8"
    limits.memory: 16Gi
    pods: "20"
    services: "5"
    persistentvolumeclaims: "3"

개발 팀에 이런 Quota를 설정하면, 그 팀은 CPU 4코어와 메모리 8Gi 안에서 최대 20개의 Pod를 운영할 수 있다. 아무리 많이 배포해도 다른 팀의 자원을 침범할 수 없다.

2-5-3. LimitRange

개념

ResourceQuota가 Namespace 전체 합계를 막는다면, LimitRange는 Pod 하나하나의 크기를 검사한다.

   ┌──────────────┐                    LimitRange
   │ Pod1         │                    ┌──────────────────────┐
   │ limits 5Gi   │────✗──▶ Namespace  │ min : 1Gi            │
   └──────────────┘                    │ max : 4Gi            │
                                       │ maxLimitRequestRatio │
   ┌──────────────┐                    │       : 3            │
   │ Pod2         │                    └──────────────────────┘
   │ requests 1Gi │────✗──▶ Namespace
   │ limits   4Gi │
   └──────────────┘

   ┌──────────────┐
   │ Pod3         │────✓──▶ Namespace
   │ requests 1Gi │           들어감
   │ limits   2Gi │
   └──────────────┘

Namespace에 들어오려는 Pod를 문 앞에서 검사해, 조건에 맞지 않으면 들여보내지 않는 방식이다.

검사 항목

각 Pod가 거부되는 이유

Pod1 — max 초과

   limits: 5Gi  >  max: 4Gi        ✗ 거부

한 Pod가 너무 큰 자원을 가져가는 것을 막는다.

Pod2 — 비율 초과

   limits 4Gi ÷ requests 1Gi = 4  >  maxLimitRequestRatio: 3   ✗ 거부

이 항목은 처음 보면 이해하기 어려우므로 의미를 짚고 넘어가는 것이 좋다.

requests는 스케줄러가 Node를 고를 때 쓰는 값이고, limits는 실제로 쓸 수 있는 상한이다. 둘의 차이가 너무 크면 문제가 생긴다.

   requests 1Gi 로 Node에 배치됨
        │
        │  스케줄러는 이 Pod가 1Gi만 쓸 것으로 예상
        ▼
   실제로는 limits 4Gi 까지 사용
        │
        ▼
   Node의 메모리가 예상보다 빨리 고갈됨
   → 같은 Node의 다른 Pod가 영향을 받음

maxLimitRequestRatio: 3은 "실제 사용량이 신고한 값의 3배를 넘지 못하게 하라"는 뜻이다. 신고한 값과 실제 사용량의 격차를 줄여 Node의 자원 예측을 정확하게 만든다.

Pod3 — 통과

   min 1Gi ≤ requests 1Gi ≤ max 4Gi        ✓
   min 1Gi ≤ limits   2Gi ≤ max 4Gi        ✓
   limits 2Gi ÷ requests 1Gi = 2  ≤  3     ✓

default와 defaultRequest — 값을 자동으로 채워준다

LimitRange에는 검사 외에 값을 대신 넣어주는 기능도 있다.

   ┌──────────────┐                    LimitRange
   │ Pod3         │                    ┌──────────────────────┐
   │ (resources   │────▶ Namespace ────│ defaultRequest       │
   │  미작성)     │                    │   memory : 1Gi       │
   └──────────────┘                    │ default              │
                                       │   memory : 2Gi       │
          │                            └──────────────────────┘
          ▼
   ┌──────────────┐
   │ Pod3         │
   │ requests 1Gi │  ← 자동으로 채워짐
   │ limits   2Gi │
   └──────────────┘

앞서 ResourceQuota를 걸면 모든 Pod가 resources를 반드시 작성해야 한다고 했다. LimitRange의 이 설정을 함께 걸어두면, 개발자가 작성하지 않아도 기본값이 자동으로 들어가므로 Pod 생성이 실패하지 않는다. 두 오브젝트를 함께 사용하는 이유가 여기에 있다.

YAML

apiVersion: v1
kind: LimitRange
metadata:
  name: lr-1
  namespace: nm-1
spec:
  limits:
    - type: Container
      min:
        memory: 1Gi
      max:
        memory: 4Gi
      defaultRequest:
        memory: 1Gi
      default:
        memory: 2Gi
      maxLimitRequestRatio:
        memory: 3

type에는 Container 외에 Pod(Pod 안 컨테이너들의 합계 기준)와 PersistentVolumeClaim(요청 가능한 저장 용량 기준)도 지정할 수 있다.

세 오브젝트 비교

   Namespace              ResourceQuota           LimitRange
   ─────────              ─────────────           ──────────
   ┌──────────┐          ┌──────────────┐        ┌──────────────┐
   │          │          │  총합 3Gi    │        │ Pod 하나당   │
   │  구역을  │          │  ┌────┐┌────┐│        │ 1Gi ~ 4Gi    │
   │  나눈다  │          │  │Pod ││Pod ││        │              │
   │          │          │  └────┘└────┘│   ✗◀──│ [ 5Gi Pod ]  │
   └──────────┘          │  합계 초과 ✗ │        └──────────────┘
                         └──────────────┘

   논리적 분리            총량 제한               개별 크기 제한

함께 사용하는 이유

세 오브젝트는 하나씩 쓰기보다 조합해서 쓸 때 효과가 있다.

• Namespace로 팀이나 환경별 구역을 나눈다
• ResourceQuota로 각 구역이 클러스터 자원을 독점하지 못하게 막는다
• LimitRange로 구역 안에서 하나의 Pod가 지나치게 커지는 것을 막고, 값을 빠뜨린 Pod에는 기본값을 채워준다

1-0. 이름의 유래

Kubernetes는 고대 그리스어로 배의 조타수(Helmsman) 를 의미한다. 컨테이너라는 화물을 실은 배를 조종하는 역할에서 따온 이름이다.

1-0-0. 쿠버네티스란

1-0-1. 쿠버네티스가 해결하는 문제

서버의 확장 관리는 어떻게 하는가

코드 한 줄을 바꾸거나 명령어 하나를 입력하면 몇 초 만에 똑같은 파드가 수십 개로 늘어난다. CPU 사용량이 올라가면 알아서 자동으로 늘려준다.

HPA (Horizontal Pod Autoscaler), Auto-scaling

문제가 생긴 서버의 재시작은

쿠버네티스는 의심이 많고 부지런한 감시자다. 파드가 응답이 없거나 죽으면 사람이 개입하기 전에 기존 파드를 버리고 새 파드를 만들어 교체해 둔다. 엔지니어는 아침에 출근해서 복구 이력 로그만 확인하면 된다.

Self-Healing

매번 패치할 때마다 야근과 주말 근무를 해야 하는가

무중단 배포 기능 덕분에 대낮에 서비스가 정상적으로 돌아가는 중에도 패치를 진행할 수 있다.

Rolling Update

기능 하나 때문에 서버 전체가 죽는 상황

기능별로 컨테이너와 파드를 쪼개 놓았기 때문에, 결제 파드가 터지더라도 로그인이나 장바구니 파드는 아무런 영향을 받지 않게 구성할 수 있다.

MSA 구조

새로운 환경으로 이전하려면

애플리케이션과 환경을 통째로 박스(컨테이너 이미지)에 담아 코드로 정의해 두었기 때문에, 밑바닥이 AWS든 네이버 클라우드든 상관없이 K8s 클러스터만 준비되어 있다면 그 코드를 그대로 가져다 실행할 수 있다.

핵심 기능 정리

1-1. 왜 쿠버네티스가 필요한가

AS-IS: 쿠버네티스 도입 이전

컨테이너(또는 서버)를 운영자가 직접 관리하는 방식이었다. 트래픽이 몰려도 수동으로 서버를 늘려야 했고, 프로세스가 죽으면 사람이 알아채고 재시작해야 했으며, 배포도 수동 스크립트나 순차 작업에 의존했다.

이 방식의 한계:

• 트래픽 급증 시 즉각적인 대응이 어려움 (스케일 아웃에 사람 손이 필요)
• 장애 발생 시 감지와 복구까지의 시간(MTTR)이 길어짐
• 배포 중 서비스 중단이 발생하기 쉬움
• 운영 리소스가 반복 작업(재시작, 스케일링)에 소모됨

TO-BE: 쿠버네티스 도입 이후

쿠버네티스는 이런 반복적인 운영 작업을 선언적(Declarative)으로 자동화한다. "몇 개의 파드를 어떤 상태로 유지할지"만 정의하면, 나머지는 쿠버네티스 컨트롤 플레인이 지속적으로 감시하고 스스로 맞춰준다.

• Deployment: 애플리케이션의 배포와 버전 관리를 선언적으로 처리한다. 원하는 상태(replica 수, 이미지 버전 등)를 명세하면 쿠버네티스가 실제 상태를 그 상태로 맞춰주고, 롤링 업데이트를 통해 무중단 배포가 가능해진다. AS-IS에서 수동으로 순차 배포하던 것과 달리, 배포 전략(RollingUpdate, Recreate 등)을 코드로 관리할 수 있다.
• Auto Scaling: HPA(Horizontal Pod Autoscaler) 등을 통해 CPU/메모리 사용률이나 커스텀 메트릭 기준으로 파드 수를 자동으로 늘리고 줄인다. AS-IS에서는 트래픽 예측과 수동 증설이 필요했지만, 쿠버네티스는 실시간 지표를 기반으로 즉각 대응한다.
• Auto Healing: 컨테이너나 파드가 비정상 상태(Liveness/Readiness Probe 실패, 크래시 등)가 되면 쿠버네티스가 자동으로 감지해 재시작하거나 새 파드로 교체한다. 사람이 장애를 인지하고 조치하기 전에 시스템이 스스로 복구하므로 장애 대응 시간이 크게 줄어든다.

핵심 차이점 요약

1-2. 클라우드 자동화 도구 전반과 비교한 쿠버네티스의 핵심 장점

• 관리 단위: 클라우드의 Auto Scaling(예: 인스턴스 그룹, 관리형 컨테이너 서비스 등)은 인스턴스·태스크 단위 관리에 머무르지만, 쿠버네티스는 배포·네트워크·스토리지·설정까지 애플리케이션 전체를 하나의 API로 관리
• 벤더 종속성: 각 클라우드의 자동화 도구는 해당 클라우드 생태계에 종속되지만, 쿠버네티스는 오픈소스 표준이라 어떤 클라우드·온프레미스에서도 동일한 방식으로 동작
• 선언적 API 범용성: 클라우드 관리형 서비스는 제공사가 정한 정책 범위 안에서만 동작하지만, 쿠버네티스는 Controller/CRD로 사실상 어떤 리소스든 같은 방식으로 정의하고 관리 가능
• 스케줄링 정교함: 대부분의 자동화 도구는 단순 규칙 기반 배치에 그치지만, 쿠버네티스는 어피니티·taint·토폴로지 분산 등 세밀한 조건으로 워크로드 배치를 제어
• 생태계: 각 벤더의 도구는 자사 생태계 안에서만 확장 가능하지만, 쿠버네티스는 Helm·Istio·Prometheus·ArgoCD 등 벤더 중립적인 표준 생태계를 보유

1-3. VM과 Container 비교

구조 비교

        [ VM 방식 ]                          [ Container 방식 ]

┌──────┬──────┬──────┐              ┌──────┬──────┬──────┐
│ App  │ App  │ App  │              │ App  │ App  │ App  │
│ Bin  │ Bin  │ Bin  │              │ Bin  │ Bin  │ Bin  │
│ /Lib │ /Lib │ /Lib │              │ /Lib │ /Lib │ /Lib │
├──────┼──────┼──────┤              └──────┴──────┴──────┘
│Guest │Guest │Guest │                  ← 컨테이너 이미지
│  OS  │  OS  │  OS  │              ┌─────────────────────┐
├──────┴──────┴──────┤              │  Container Engine   │
│    Hypervisor      │              ├─────────────────────┤
├────────────────────┤              │      Host OS        │
│      Host OS       │              │  namespace + cgroups│
├────────────────────┤              ├─────────────────────┤
│    Host Server     │              │    Host Server      │
└────────────────────┘              └─────────────────────┘

       커널 N개                            커널 1개

VM의 구조

계층 구성

특징

• 독립성: Guest OS마다 커널이 분리되어 있어 서로 영향을 주지 않는다
• 환경 자유도: Guest OS마다 다른 언어 런타임과 도구를 설치할 수 있다
  • 예: 동일 물리 서버에서 Guest OS A는 Java 17 + Gradle, Guest OS B는 Python 3.11 + pip

비용

• 자원 중복: Guest OS 개수만큼 운영체제가 중복 실행된다
• 기동 시간: 커널 부팅부터 수행하므로 수십 초 ~ 수 분 소요
• 이미지 크기: OS 전체가 포함되어 수 GB 단위

Container의 구조

계층 구성

특징

• Guest OS 없음: Hypervisor와 Guest OS 계층이 존재하지 않는다
• 커널 공유: 별도 OS를 부팅하지 않고 Host OS의 커널을 공유한다
• 프로세스 단위 실행: 커널 입장에서 컨테이너는 하나의 프로세스다

격리 방식

컨테이너는 리눅스 커널의 두 기능으로 격리와 자원 제어를 수행한다.

namespace — 커널 자원의 격리

정의

커널이 관리하는 시스템 자원을 프로세스 그룹 단위로 분리하는 커널 기능이다. 특정 namespace에 속한 프로세스는 해당 namespace에 할당된 자원만 인식하고 접근할 수 있다.

종류

namespace의 역할 — 자원 격리

컨테이너는 Host OS의 커널을 공유한다. 별도 조치가 없다면 모든 컨테이너가 동일한 파일시스템, 동일한 포트, 동일한 프로세스 공간을 사용하게 되어 서로 충돌한다.

namespace는 커널이 관리하는 자원을 프로세스 그룹별로 분리해, 각 컨테이너가 자신에게 할당된 자원만 인식하도록 만든다. 그 결과 하나의 커널 위에서 여러 컨테이너가 독립된 환경처럼 동작할 수 있다.

cgroups — 자원 사용량의 제어

정의

프로세스 그룹이 사용할 수 있는 시스템 자원의 양을 할당하고 제한하는 커널 기능이다. namespace가 자원의 접근 범위를 결정한다면, cgroups는 자원의 사용량 상한을 결정한다.

제어 자원

적용 효과

• 컨테이너에 메모리 512MB 제한을 설정하면 cgroups가 이를 강제한다
• 제한을 초과하면 해당 프로세스가 종료된다
• 컨테이너 단위로 적용되므로 하나의 컨테이너가 호스트 전체 자원을 점유하는 상황을 방지한다

핵심 차이 정리

1-4. Pod와 Container — 쿠버네티스에서의 역할

Pod의 정의

개념

• 쿠버네티스가 생성하고 관리하는 가장 작은 배포 단위
• 하나 이상의 컨테이너로 구성된다
• 쿠버네티스는 개별 컨테이너가 아닌 Pod 단위로 스케줄링, 배포, 확장, 삭제를 수행한다

Pod 내 컨테이너의 제약

• 항상 동일한 노드에 배치된다
• 동일한 생명주기를 갖는다 (함께 생성되고 함께 종료된다)

Pod 단위로 묶는 이유

애플리케이션과 그 애플리케이션에 종속된 보조 프로세스를 하나의 논리적 단위로 다루기 위해서다.

Pod와 Container의 역할

Pod 내부의 공유 범위

┌─────────── Pod (IP: 10.244.1.7) ───────────┐
│                                             │
│  ┌──────────────┐      ┌──────────────┐    │
│  │ Container A  │      │ Container B  │    │
│  │              │      │              │    │
│  │ 개별 소유:   │      │ 개별 소유:   │    │
│  │  파일시스템  │      │  파일시스템  │    │
│  │  프로세스    │      │  프로세스    │    │
│  └──────┬───────┘      └──────┬───────┘    │
│         │                     │             │
│    ─────┴─────────────────────┴─────        │
│      공유: net namespace (동일 IP)          │
│            ipc namespace                    │
│            Volume                           │
└─────────────────────────────────────────────┘

공유되는 자원

공유되지 않는 자원

컨테이너 구성 예시

컨테이너 1개로 구성된 Pod

가장 일반적인 형태로, 하나의 애플리케이션을 하나의 Pod로 배포한다.

apiVersion: v1
kind: Pod
metadata:
  name: forday-api
spec:
  containers:
    - name: app
      image: forday-api:1.2.0
      ports:
        - containerPort: 8080

사이드카 — 메인 컨테이너에 보조 기능을 추가

• 구성: 애플리케이션 컨테이너 + 로그 수집 컨테이너
• 동작: 애플리케이션이 볼륨에 로그를 기록하면, 로그 수집 컨테이너가 같은 볼륨을 읽어 외부로 전송
• 하나의 Pod로 묶는 이유: 두 컨테이너가 같은 노드에서 같은 볼륨을 바라봐야 하기 때문

apiVersion: v1
kind: Pod
metadata:
  name: forday-api
spec:
  volumes:
    - name: log-volume
      emptyDir: {}
  containers:
    - name: app
      image: forday-api:1.2.0
      ports:
        - containerPort: 8080
      volumeMounts:
        - name: log-volume
          mountPath: /var/log/app
    - name: log-collector
      image: fluent-bit:2.1
      volumeMounts:
        - name: log-volume
          mountPath: /var/log/app

Init Container — 메인 컨테이너보다 먼저 실행

• 동작: 메인 컨테이너보다 먼저 실행되고, 정상 종료되어야만 메인 컨테이너가 시작된다
• 용도: 데이터베이스 스키마 마이그레이션 등 애플리케이션 기동 전에 반드시 완료되어야 하는 작업

spec:
  initContainers:
    - name: db-migration
      image: forday-migration:1.2.0
  containers:
    - name: app
      image: forday-api:1.2.0

구성 시 판단 기준

• 여러 컨테이너를 하나의 Pod에 넣는 경우: 보조 컨테이너가 메인 컨테이너와 생명주기를 완전히 공유해야 할 때
• 분리해야 하는 경우: 독립적으로 확장되고 독립적으로 재시작되어야 할 때
  • 예: 애플리케이션 서버와 데이터베이스는 서로 다른 Pod로 구성한다

배포 시 Pod의 동작

전제 — Pod는 수정하지 않고 교체한다

Pod는 생성된 이후 내용을 변경하지 않는 것을 원칙으로 한다. 새로운 버전의 배포는 다음을 의미한다.

• 기존 Pod의 이미지를 교체하는 것이 아니다
• 새로운 Pod를 생성하고 기존 Pod를 삭제하는 것이다

동작 흐름 (forday-api:1.2.0 → 1.3.0)

[1] Deployment의 이미지 버전을 1.3.0으로 변경
        ↓
[2] 새 버전의 Pod 생성
      스케줄러가 배치할 노드를 선택
      → 이미지 다운로드 → 컨테이너 실행
        ↓
[3] 새 Pod가 정상 상태(Ready)가 될 때까지 대기
      Ready가 되어야 Service를 통해 트래픽을 전달받음
        ↓
[4] 기존 버전의 Pod 삭제
      Service에서 먼저 제외한 뒤 종료
        ↓
[5] Pod 개수만큼 [2]~[4]를 반복

롤링 업데이트(Rolling Update)

• 새 Pod가 정상 동작을 확인받은 뒤에 기존 Pod를 제거한다
• 배포 중에도 서비스 가능한 Pod가 항상 유지된다
• 이것이 쿠버네티스가 무중단 배포를 제공하는 기본 원리다

Pod IP 변경과 Service

따라서 애플리케이션 간 통신은 항상 Service를 통해 이루어져야 한다.

1-5. 클러스터 구조와 Pod 관리

Master Node와 Worker Node

┌──────────────── Master Node (Control Plane) ────────────────┐
│  API Server    스케줄러    컨트롤러                          │
│  = 명령을 받고, 배치를 결정하고, 상태를 감시               │
└─────────────────────────┬───────────────────────────────────┘
                          │ 지시
        ┌─────────────────┼─────────────────┐
        ▼                 ▼                 ▼
┌──────────────┐  ┌──────────────┐  ┌──────────────┐
│ Worker Node1 │  │ Worker Node2 │  │ Worker Node3 │
│  Pod  Pod    │  │  Pod         │  │  Pod  Pod    │
└──────────────┘  └──────────────┘  └──────────────┘
        = 실제로 Pod(컨테이너)가 실행되는 서버

사용자는 Worker Node를 직접 조작하지 않는다. Master에게 "이렇게 해달라"고 선언하면 Master가 Worker에 배분한다.

ReplicaSet

역할: Pod의 개수를 지정한 수만큼 유지한다

ReplicaSet (replicas: 3)
        │
        ├── Pod A  (Running)
        ├── Pod B  (Running)
        └── Pod C  (Running)

  Pod C 가 죽으면 ↓

        ├── Pod A  (Running)
        ├── Pod B  (Running)
        └── Pod D  (새로 생성)   ← ReplicaSet이 자동 생성

• Pod가 죽거나 노드에 장애가 나면 새 Pod를 만들어 개수를 채운다 → Auto Healing
• Pod 개수를 늘리라고 지시하면 그만큼 새로 생성한다 → Auto Scaling
• 죽은 Pod를 되살리는 것이 아니라, 항상 새 Pod를 생성한다

계층 관계

Deployment  →  ReplicaSet  →  Pod  →  Container
   배포/버전 관리    개수 유지     배포 단위    실행 단위

사용자는 보통 ReplicaSet을 직접 만들지 않고 Deployment를 만든다. Deployment가 ReplicaSet을 생성하고, ReplicaSet이 Pod를 관리한다. 새 버전을 배포하면 Deployment가 새 ReplicaSet을 만들어 Pod를 교체한다.

목차

1. Blue-Green 배포란?
2. 단일 EC2에서 Blue-Green을 구성하는 이유
3. 전체 아키텍처
4. 트래픽 전환 흐름
5. 구현 과정
6. 마무리

1. Blue-Green 배포란?

Blue-Green 배포는 동일한 서비스를 두 개의 환경(Blue / Green)으로 나눠 운영하다가, 배포 시점에 트래픽을 한쪽에서 다른 쪽으로 전환하는 방식이다.

• 평소에는 두 환경 중 하나(예: Blue)만 실제 트래픽을 받는다.
• 새 버전을 배포할 때는 반대편 환경(Green)에 새 버전을 띄운다.
• Green이 정상 동작하는지 헬스체크로 확인한다.
• 문제가 없으면 트래픽을 Green으로 전환한다.
• 이전 환경(Blue)은 종료하거나 다음 배포를 위한 대기 상태로 남긴다.

핵심은 "새 버전을 미리 켜두고, 준비가 끝난 뒤에 트래픽만 옮긴다"는 점이다. 기존 버전을 내리고 새 버전을 올리는 방식(Rolling 없는 단순 재배포)과 달리 서비스 중단 구간이 없다.

2. 단일 EC2에서 Blue-Green을 구성하는 이유

Blue-Green 배포는 보통 ALB(Application Load Balancer)와 여러 대의 EC2, 또는 ECS/Kubernetes 같은 오케스트레이션 도구를 이용해 구성한다. 하지만 이런 구성은 비용과 운영 복잡도가 올라간다.

이번 구조는 EC2 한 대 안에서 Docker 컨테이너 두 개(Blue/Green)를 서로 다른 포트로 띄우고, 그 앞단의 Nginx가 리버스 프록시 역할을 하면서 트래픽을 전환하는 방식이다. 서버 한 대만으로도 무중단 배포가 가능하다는 점에서, 초기 단계의 서비스나 비용에 민감한 프로젝트에 적합하다.

물론 트레이드오프도 있다. EC2 한 대에 의존하기 때문에 해당 인스턴스 자체가 죽으면 서비스 전체가 중단되고, 두 컨테이너가 동시에 떠 있는 시점에는 CPU/메모리 자원을 동시에 소모한다. 인스턴스 사양을 여유 있게 잡아야 하는 이유다.

3. 전체 아키텍처

포트 구조를 정리하면 다음과 같다.

Docker의 포트 매핑 문법은 "호스트포트:컨테이너포트"이다. Spring Boot는 컨테이너 내부에서 항상 8080번을 리슨하고, 이 포트가 호스트(EC2)의 8080 또는 8081번으로 노출되는 구조다. Nginx는 컨테이너 내부 포트를 알 필요가 없고, EC2 호스트 기준 포트(localhost:8080, localhost:8081)만 바라본다.

Spring Boot (컨테이너 내부 8080)
   ↑
Docker 포트 매핑 (8080:8080 또는 8081:8080)
   ↑
EC2 Host Port (8080 / 8081)
   ↑
Nginx (upstream이 localhost:8080 또는 localhost:8081 참조)

4. 트래픽 전환 흐름

배포 스크립트가 실행됐을 때 내부적으로 일어나는 순서는 다음과 같다.

여기서 핵심은 Nginx 설정 자체를 바꾸는 게 아니라, service-env.inc라는 변수 파일 하나만 갈아끼운다는 것이다. 이 파일에는 $service_url 변수 값(blue 또는 green)만 들어 있고, nginx -s reload는 워커 프로세스를 무중단으로 재시작하기 때문에 서비스가 끊기지 않는다.

5. 구현 과정

5.1 EC2 초기 설정 - JDK 설치

# 우분투 버전
sudo apt update

# jdk 17 설치
sudo apt install openjdk-17-jdk -y

# 설치 확인
java -version

Spring Boot 애플리케이션을 EC2에서 직접 빌드/실행할 일은 없지만(빌드는 GitHub Actions에서, 실행은 Docker 컨테이너로), Docker 이미지 빌드나 로컬 디버깅을 대비해 JDK를 설치해둔다.

5.2 Docker / Docker Compose 설치

sudo apt-get update && \
    sudo apt-get install -y apt-transport-https ca-certificates curl software-properties-common && \
    curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add - && \
    sudo apt-key fingerprint 0EBFCD88 && \
    sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" && \
    sudo apt-get update && \
    sudo apt-get install -y docker-ce && \
    sudo usermod -aG docker ubuntu && \
    sudo curl -L "https://github.com/docker/compose/releases/download/1.23.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose && \
    sudo chmod +x /usr/local/bin/docker-compose && \
    sudo ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose

# 설치 확인
docker -v
docker compose version

# 데몬 상태 확인
systemctl status docker

Docker 저장소를 apt에 등록하고 docker-ce를 설치한 뒤, ubuntu 유저를 docker 그룹에 추가해 매번 sudo 없이 명령어를 쓸 수 있게 한다. 이 스크립트는 EC2를 새로 띄울 때마다 반복하기보다, User Data(EC2 초기 실행 스크립트)에 등록해두면 인스턴스 생성과 동시에 자동으로 설치되도록 할 수 있다.

5.3 Nginx 설치

# 패키지 목록 최신화
sudo apt update

# nginx 설치에 필요한 라이브러리
sudo apt install curl gnupg2 ca-certificates lsb-release ubuntu-keyring

# nginx 공식 서명 키 등록
curl https://nginx.org/keys/nginx_signing.key | gpg --dearmor \
    | sudo tee /usr/share/keyrings/nginx-archive-keyring.gpg >/dev/null

# 저장소 등록
echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] \
http://nginx.org/packages/ubuntu $(lsb_release -cs) nginx" \
    | sudo tee /etc/apt/sources.list.d/nginx.list

# nginx 설치
sudo apt update
sudo apt install nginx

nginx.org의 공식 패키지를 쓰기 위해 서명 키를 등록하고 저장소를 추가하는 과정이다. Ubuntu 기본 저장소의 nginx보다 최신 버전을 안전하게 받을 수 있다.

sudo systemctl start nginx
sudo systemctl status nginx

설치 후 systemctl로 서비스를 시작하고 상태를 확인한다.

5.4 Nginx 설정 - Blue/Green 업스트림 구성

/etc/nginx/conf.d/default.conf를 아래와 같이 수정한다.

# =========================
# Blue / Green Upstream
# =========================

# 운영 중인 서버 (localhost:8080)
upstream blue {
    server localhost:8080;
}

# 대기 또는 신규 배포 서버 (localhost:8081)
upstream green {
    server localhost:8081;
}

# =========================
# Nginx Server
# =========================

server {
    listen 80;
    server_name localhost;

    # 현재 트래픽을 어디로 보낼지는 이 파일에서 결정한다.
    # nginx 재시작 없이 이 include 파일만 바꾸면 Blue/Green 전환이 가능하다.
    include /etc/nginx/conf.d/service-env.inc;

    location / {
        # 핵심: $service_url 값에 따라 blue 또는 green으로 프록시
        proxy_pass http://$service_url;

        # 클라이언트 실제 IP 전달
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        # 원본 Host 유지 (OAuth, CORS 대응에 필요)
        proxy_set_header Host $http_host;

        # 타임아웃 (Spring Boot 권장값)
        proxy_connect_timeout 5s;
        proxy_send_timeout 30s;
        proxy_read_timeout 30s;
    }

    error_page 500 502 503 504 /50x.html;
    location = /50x.html {
        root /usr/share/nginx/html;
    }
}

이 설정의 포인트는 proxy_pass http://$service_url;이다. $service_url이 blue면 upstream blue(즉 localhost:8080)로, green이면 upstream green(localhost:8081)으로 요청이 전달된다. 어느 쪽으로 보낼지는 아래 service-env.inc 파일 하나가 결정한다.

5.5 트래픽 스위치 변수 파일

/etc/nginx/conf.d/service-env.inc

# 최초 기동 시에는 blue 환경으로 시작
set $service_url blue;

배포 스크립트가 이 한 줄을 set $service_url green;으로 바꾸고 nginx -s reload만 실행하면, Nginx 프로세스를 새로 켜지 않고도 트래픽 대상이 바뀐다.

# 문법 검사
sudo nginx -t

# 무중단 반영
sudo nginx -s reload

nginx -s reload는 기존 연결을 끊지 않고 워커 프로세스만 교체하기 때문에, 이 시점에 들어오는 요청도 유실되지 않는다.

참고: 로드밸런서(ALB)를 앞단에 둔다면, ALB의 리스너 포트(80)와 대상 그룹 포트(80)를 맞추고, EC2 보안 그룹에서 ALB 보안 그룹으로부터의 80번 포트 인바운드를 허용해야 한다.

5.6 헬스체크 엔드포인트

배포 스크립트가 새로 띄운 컨테이너(Green)가 정상 기동됐는지 확인하는 용도로 헬스체크 API를 둔다.

@Slf4j
@RestController
public class TestController {

    @Value("${server.port}")
    private int serverPort;

    @Value("${server.env}")
    private String serverEnv;

    @Value("${serverName}")
    private String serverName;

    @GetMapping("/health_check")
    public TestResponseDto healthCheck() {
        return new TestResponseDto("테스트에 성공하였습니다.", serverPort, serverEnv, serverName);
    }

    @GetMapping("/env")
    public String env() {
        return serverEnv;
    }
}

server.env, serverName 같은 값은 Spring 프로필(blue/green)에 따라 다르게 주입되며, 지금 응답하는 컨테이너가 blue인지 green인지 확인하는 용도로 쓴다. /health_check는 배포 스크립트가 새 컨테이너의 기동 완료 여부를 폴링하는 엔드포인트로 사용된다.

5.7 Spring Boot 설정 - 프로필 분리

application.yml에서 blue/green/common 세 프로필로 나눠 관리한다. 아래 값 중 자격 증명, 엔드포인트 등 민감한 정보는 실제 값 대신 환경변수/플레이스홀더로 표시했다.

spring:
  profiles:
    group:
      blue: blue, common
      green: green, common
  application:
    name: ForDay

---
# Blue
spring:
  config:
    activate:
      on-profile: blue

server:
  port: 8080   # 컨테이너 내부 포트 (blue/green 모두 동일)
  env: blue
serverName: blue_server

---
# Green
spring:
  config:
    activate:
      on-profile: green

server:
  port: 8080
  env: green
serverName: green_server

---
# 공통 설정
spring:
  config:
    activate:
      on-profile: common

  datasource:
    url: jdbc:mysql://${DB_HOST}:3306/${DB_NAME}
    username: ${DB_USERNAME}
    password: ${DB_PASSWORD}

  jpa:
    database: mysql
    database-platform: org.hibernate.dialect.MySQLDialect
    generate-ddl: false
    hibernate:
      ddl-auto: update
    show-sql: false

  data:
    redis:
      host: ${REDIS_HOST}
      port: 6379

  jwt:
    secret: ${JWT_SECRET}
    access-expiration: 180
    refresh-expiration: 14

server:
  address: 0.0.0.0

management:
  endpoints:
    web:
      exposure:
        include: health

blue/green 프로필은 server.env와 serverName만 다르고, 둘 다 컨테이너 내부에서는 동일하게 8080 포트를 리슨한다(외부 노출 포트만 Docker 실행 시 8080/8081로 갈린다). DB, Redis, JWT 같은 민감한 값은 코드/설정 파일에 하드코딩하지 않고 환경변수나 GitHub Actions Secrets로 주입하는 것을 권장한다.

5.8 Dockerfile

FROM eclipse-temurin:17-jdk

WORKDIR /app

COPY build/libs/*SNAPSHOT.jar app.jar

EXPOSE 8080

ENTRYPOINT ["java", "-jar", "app.jar"]

Gradle로 빌드된 jar를 컨테이너에 복사하고 8080 포트로 실행하는 단순한 구조다. blue/green 이미지는 완전히 동일하며, 차이는 실행 시 SPRING_PROFILES_ACTIVE 환경변수와 호스트 포트 매핑에서만 발생한다.

5.9 docker-compose 파일 (참고용)

로컬 테스트나 수동 배포 시 참고할 수 있는 compose 파일이다. (실제 CI/CD 배포는 5.10의 deploy.yml에서 docker run으로 직접 처리한다.)

# docker-compose-blue.yml
version: '3.8'

services:
  blue:
    image: <ECR_REPOSITORY_URI>:latest
    container_name: blue
    ports:
      - "8080:8080"   # EC2 외부 노출 : 컨테이너 내부(Spring Boot)
    environment:
      - SPRING_PROFILES_ACTIVE=blue
      - ENV=blue
    restart: always

# docker-compose-green.yml
version: '3.8'

services:
  green:
    image: <ECR_REPOSITORY_URI>:latest
    container_name: green
    ports:
      - "8081:8080"
    environment:
      - SPRING_PROFILES_ACTIVE=green
      - ENV=green
    restart: always

두 파일의 차이는 컨테이너 이름, 호스트 포트(8080/8081), SPRING_PROFILES_ACTIVE 값뿐이다.

5.10 GitHub Actions로 CI/CD 자동화

main 브랜치에 푸시되면 빌드 → ECR 푸시 → EC2 SSH 접속 → Blue/Green 전환까지 자동으로 처리한다.

Build Job

name: Deploy To EC2 (Blue-Green)

on:
  push:
    branches: [ "main" ]

permissions:
  contents: read

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: 17

      - name: Create application.yml
        run: echo "${{ secrets.APPLICATION_PROPERTIES }}" > ./src/main/resources/application.yml

      - name: Build Spring Boot
        run: |
          chmod +x ./gradlew
          ./gradlew clean build -x test

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-region: ${{ secrets.AWS_REGION }}
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

      - name: Login to ECR
        run: |
          aws ecr get-login-password --region ${{ secrets.AWS_REGION }} \
          | docker login --username AWS --password-stdin ${{ secrets.ECR_REGISTRY }}

      - name: Build & Push Docker Image
        run: |
          docker build -t forday .
          docker tag forday:latest ${{ secrets.ECR_REGISTRY }}/forday:latest
          docker push ${{ secrets.ECR_REGISTRY }}/forday:latest

application.yml처럼 민감 정보가 담긴 설정 파일은 리포지토리에 커밋하지 않고, GitHub Actions Secrets(APPLICATION_PROPERTIES)에 전체 내용을 저장해뒀다가 빌드 시점에 파일로 복원한다. AWS 계정 ID, ECR 리전 등도 코드에 노출하지 않고 Secrets(ECR_REGISTRY, AWS_REGION)로 관리한다.

Deploy Job

  deploy:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: Configure SSH
        run: |
          mkdir -p ~/.ssh
          echo "${{ secrets.SSH_PRIVATE_KEY }}" > ~/.ssh/id_rsa
          chmod 600 ~/.ssh/id_rsa
          cat <<EOF >> ~/.ssh/config
          Host ec2-server
            HostName ${{ secrets.EC2_PUBLIC_IP }}
            User ubuntu
            IdentityFile ~/.ssh/id_rsa
            StrictHostKeyChecking no
          EOF

      - name: Blue-Green Deploy via SSH
        run: |
          ssh ec2-server << 'EOF'
            set -e

            aws ecr get-login-password --region ${{ secrets.AWS_REGION }} \
              | docker login --username AWS --password-stdin ${{ secrets.ECR_REGISTRY }}

            # 1) service-env.inc 파일이 없으면 blue로 초기화
            if [ ! -f /etc/nginx/conf.d/service-env.inc ]; then
              echo "set \$service_url blue;" | sudo tee /etc/nginx/conf.d/service-env.inc
            fi

            # 2) 현재 트래픽이 blue/green 중 어디로 가고 있는지 확인
            CURRENT_VAL=$(grep -oP '(?<=set \$service_url ).*(?=;)' /etc/nginx/conf.d/service-env.inc || echo "blue")

            # 3) 반대편을 배포 대상으로 지정
            if [ "$CURRENT_VAL" = "blue" ]; then
              TARGET="green"; TARGET_PORT=8081; OLD_TARGET="blue"
            else
              TARGET="blue"; TARGET_PORT=8080; OLD_TARGET="green"
            fi

            echo "배포 대상: $TARGET (포트: $TARGET_PORT)"
            docker pull ${{ secrets.ECR_REGISTRY }}/forday:latest

            # 4) 기존에 같은 이름의 컨테이너가 있다면 정리 후 새로 기동
            docker stop $TARGET || true
            docker rm $TARGET || true

            docker run -d \
              --name $TARGET \
              --restart=always \
              --network forday-net \
              -v /etc/localtime:/etc/localtime:ro \
              -e TZ=Asia/Seoul \
              -e SPRING_PROFILES_ACTIVE=$TARGET \
              -p $TARGET_PORT:8080 \
              ${{ secrets.ECR_REGISTRY }}/forday:latest

            # 5) 헬스체크 - 최대 20회, 5초 간격으로 재시도
            for i in {1..20}; do
              if curl -sf http://localhost:$TARGET_PORT/health_check; then
                HEALTH_OK=true
                break
              fi
              echo "대기 중... ($i/20)"
              sleep 5
            done

            if [ "$HEALTH_OK" != "true" ]; then
              echo "헬스 체크 실패"
              docker logs $TARGET
              exit 1
            fi

            # 6) 헬스체크 통과 시에만 Nginx 트래픽 전환
            echo "set \$service_url $TARGET;" | sudo tee /etc/nginx/conf.d/service-env.inc
            sudo nginx -t && sudo nginx -s reload

            # 7) 이전 컨테이너 정리
            docker stop $OLD_TARGET || true
            docker rm $OLD_TARGET || true
            docker image prune -af
          EOF

이 스크립트에서 배포 실패를 막는 안전장치는 두 가지다.

• 헬스체크를 통과하기 전에는 절대 Nginx 설정을 바꾸지 않는다. HEALTH_OK 플래그가 true가 되지 않으면 exit 1로 종료되고, 기존 컨테이너(트래픽을 받고 있던 쪽)는 그대로 유지된다.
• 이전 컨테이너는 전환이 끝난 뒤에 종료한다. 전환 도중 문제가 생겨도 롤백할 대상이 남아있는 구조다.

민감 정보(AWS 자격 증명, ECR 레지스트리 주소, EC2 IP, SSH 키 등)는 모두 GitHub Actions Secrets로 분리해 워크플로 코드에는 값이 노출되지 않는다.

6. 마무리

이 구조를 한 줄로 요약하면, "Nginx 앞단은 그대로 두고, 뒷단의 upstream 대상만 변수 파일 하나로 바꿔치기한다"는 것이다. 배포 순서는 항상 아래와 같이 진행된다.

1. 반대편(대기) 컨테이너에 새 버전을 띄운다.
2. 헬스체크로 정상 기동을 확인한다.
3. 통과하면 Nginx의 $service_url만 바꾸고 리로드한다.
4. 이전 컨테이너를 종료한다.

서버 한 대로 구현할 수 있어 비용 부담이 적고 구조도 단순하지만, 인스턴스 자체의 장애에는 취약하다는 한계가 있다. 트래픽과 가용성 요구 수준이 올라가면 ALB + 다중 EC2, 혹은 ECS/EKS 기반의 Blue-Green/Canary 배포로 확장하는 것이 다음 단계가 될 것이다.

원래 서버에서 http를 사용하고 있다가 https로 배포한 프론트와의 통신을 위해 가비아 도메인을 ACM을 통해 인증서를 발급받아 새로 https를 적용하였다!

GET 요청으로 health_check를 보냈을 때는 응답이 잘 왔으나

✅ 문제

POST 요청을 보내니 connection timeout이 발생하는 것이다.

나는 서버에서 nginx를 활용한 무중단 배포 blue-green을 사용하고 있었다.

✅ 원인

• 검색해보니
• HTTPS 암호화로 인해 패킷이 무거워지거나, nginx의 기본 타임아웃 설정이 데이터가 포함된 POST 요청을 처리하기에 너무 짧은 것이었다.

✅ 해결

• Nginx 설정 파일 수정하기 (경로 /etc/nginx/conf.d/default.conf)

location / {
    proxy_connect_timeout 300;
    proxy_send_timeout 300;
    proxy_read_timeout 300;
    send_timeout 300;
    client_max_body_size 20M;
    ...
}

• 위 내용 작성 후

sudo systemctl daemon-reload (서비스 설정 변경 인식)

sudo systemctl reload nginx (Nginx 엔진에 설정 반영)

다시 postman으로 요청을 보내면 응답이 정상적으로 온다!!

초기에 개발에 입문 했을 때 사람들이 Docker Docker 하길래 도대체 무슨 기술인지 궁금했다. 백엔드 개발을 시작하면서 다양한 기술들을 배우고 싶었고 인프런 강의를 통해 원하는 기술들을 공부하는데 많은 도움이 되었다.

특히 박재성님 강의 도움을 정말 많이 받았다. 지금 포스팅은 Docker 강의 후기이지만 정말 많은 강의들을 들었다. 말그대로 전반적인 강의들은 필요한 액기스만 압축해놓은 거의 하루종일 시간만 투자하면 해당 기술을 배울 수 있다.

무엇보다 박재성님은 수업 자료를 항상 너무나도 꼼꼼하게 노션, pdf 형식으로 모두 제공해주시는게 정말 좋았다. 그만큼 수업에 더 깊이 집중할 수 있었다.

강의는 다음과 같았다.

• Docker 기본 개념
• 현업에서 자주 사용하는 Docker CLI 익히기
• 도커 볼륨을 활용해 데이터 유실 방지하기
• Dockerfile 활용해 이미지 직접 만들기
• Docker Compose를 활용해 컨테이너 관리하기
• Docker Compose를 활용해 2개 이상의 컨테이너 관리하기
• AWS EC2에 서버 배포해보기
• AWS EC2에서 Docker를 활용해 배포해보기

박재성님의 다른 강의들은 더 깊숙한 개념을 알고 싶다면 추가적인 학습이 필요한 것들도 있지만 Docker강의는 이 강의만으로도 Docker를 정복할 수 있을 정도로 강의 구성이 너무 좋았다.

그래서 Docker 강의 덕분에 서버 배포도 이제 수월하게 할 수 있게 되었다.

https://school.programmers.co.kr/learn/courses/30/lessons/42576

✔️관련 알고리즘 개념

해시

☑️ 문제 분석

• 해당 문제는 HashMap의 key와 value쌍을 이용하여 문제를 해결하는 것이다. 여기서 중요한 것은 예제 3과 같이

  "mislav"는 참여자 명단에는 두 명이 있지만, 완주자 명단에는 한 명밖에 없기 때문에 한명은 완주하지 못했습니다.

  동명이인이 있는 경우를 처리하는 것이다.

• 예제 3에 대해 분석해보자

  • completion 정보를 hashMap에 저장해둔다.
  • 이후 participant를 반복문으로 돌면서 hashMap에 저장된 참가자 정보가 없다면 해당 참가자가 완주하지 못한 것으로 판단하여 해당 참가자의 이름을 반환한다.
  1. completion 정보 저장
     1. stanko 삽입 (여기서 value값은 key에 해당하는 이름을 가진 사람수이다.)

        | key | value |
        | --- | --- |
        | stanko  | 1 |
    2. ana 삽입


        | key | value |
        | --- | --- |
        | stanko  | 1 |
        | ana  | 1 |
    3. mislav 삽입 .


        | key | value |
        | --- | --- |
        | stanko  | 1 |
        | ana  | 1 |
        | mislav  | 1 |
2. participant 정보다 hashMap에 포함된건지 확인


    | key | value |
    | --- | --- |
    | stanko  | 1 |
    | ana  | 1 |
    | mislav  | 1 |
    1. mislav 확인
        1. 현재 hashMap에는 mislav가 존재한다. 해당 참가자를 확인했으므로 hashMap에서 지워준다.


            | key | value |
            | --- | --- |
            | stanko  | 1 |
            | ana  | 1 |
    2. stanko확인
        1. 현재 hashMap에는 stanko가 존재한다. 해당 참가자를 확인했으므로 hashMap에서 지워준다.


            | key | value |
            | --- | --- |
            | ana  | 1 |
    3. mislav 확인
        1. 현재 hashMap에는 mislav이 존재하지 않는다. 즉 완주자 명단에 존재하지 않는 것이므로 해당 참가자의 이름을 반환한다. 

☑️ 코드

import java.util.Arrays;
import java.util.HashMap;
import java.util.HashSet;

class Solution {
    public String solution(String[] participant, String[] completion) {
        HashMap<String, Integer> map = new HashMap<>();
        for (String s : completion) {
            if(map.containsKey(s)) {
                Integer value = map.get(s);
                map.put(s, value+1);
            }else {
                map.put(s, 1);
            }
        }

        String answer = "";
        for (String s : participant) {
            if(map.containsKey(s)) {
                Integer value = map.get(s);
                if(value.equals(1)) map.remove(s);
                else map.put(s, value-1);
            } else {
                answer = s;
                break;
            }
        }

        return answer;
    }

    public static void main(String[] args) {
        String[] participant = {"mislav", "stanko", "mislav", "ana"};
        String[] completion = {"stanko", "ana", "mislav"};
        System.out.println(new Solution().solution(participant, completion));
    }
}

☑️ 채점 결과 : 맞음

☑️ 어려웠던 점

• 동명이인을 처리하기 위한 로직이 어려웠다.

https://www.acmicpc.net/problem/10868

✔️관련 알고리즘 개념

세그먼트 트리

☑️ 문제 분석

• 이 문제는 구간에 해당하는 최솟값을 구하는 문제이다.

• M개의 구간에 대해 최솟값을 각각 구해야 하므로 빠르게 연산을 수행할 수 있는 세그먼트 자료구조를 이용하면 된다.

• 예제입력 1

10 4
75
30
100
38
50
51
52
20
81
5
1 10
3 5
6 9
8 10

• 1단계, 트리 초기화하기 - 리프노드에 원본 데이터 입력

  • 2*i ≥ 10 (N : 데이터 개수)를 만족하는 최솟값 I는 4이다.

  • 배열 size = 2*i *2 = 32이다.

  • 시작 리프노트 = 2*i = 16이므로 인덱스 16부터 N개의 데이터를 채운다.

    

• 2단계, 질의 값 구하기

  • 세그먼트 트리 index = 주어진 질의 index + 2ⁱ -1를 이용하여 세그먼트 트리용 index로 전환한다.

    ① start_index % 2 == 1(짝수)일 때 해당 노드를 선택한다.

    ② end_index % 2 == 0(홀수)일 때 해당 노드를 선택한다.

    ③ start_index depth 변경 → start_index = (start_index + 1) / 2 연산을 실행한다.

    ④ end_index depth 변경 → end_index = (end_index - 1) / 2 연산을 실행한다.

    ⑤ ①~④를 반복하다가 end_index < start_index가 되면 종료한다.

  • 예를 들어, 예시입력1에서 3 5는 3번째 데이터에서 5번째 데이터 중 최솟값을 구하는 것이다.

  • 위의 과정을 통해 범위에 속하는 최솟값을 구하면 아래와 같다.

  • 범위 시작 인덱스 = 3 + 2^4 - 1 = 18

  • 범위 끝 인덱스 = 5 + 2^4 - 1 = 20

    → 최종적으로 선택된 노드는 20번째 노드와 9번째 노드이다. 여기서 9번째 노드는 18번째와 19번째 노드의 최솟값을 지니고 있으므로 20번째와 9번째 노드를 선택한 것은 18~20번째 노드를 잘 선택한 것과 같다.

☑️ 코드

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.*;

public class Main {
    static int[] tree;
    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st = new StringTokenizer(br.readLine());
        int N = Integer.parseInt(st.nextToken());
        int M = Integer.parseInt(st.nextToken());

        int temp = N; // N 보존을 위해 복사
        int treeHeight = 0;
        while(temp != 0) {
            temp /= 2;
            treeHeight++;
        }

        int treeSize = (int) Math.pow(2, treeHeight+1);
        tree = new int[treeSize+1];

        int start_leaf_node_index = (int) Math.pow(2, treeHeight);
        for (int i = start_leaf_node_index; i < start_leaf_node_index + N; i++) {
            tree[i] = Integer.parseInt(br.readLine());
        }

        // 트리 초기화
        setTree(treeHeight);

        for (int i = 0; i < M; i++) {
            st = new StringTokenizer(br.readLine());
            int a = Integer.parseInt(st.nextToken());
            int b = Integer.parseInt(st.nextToken());

            a += (int) Math.pow(2, treeHeight) -1;
            b += (int) Math.pow(2, treeHeight) -1;
            System.out.println(findMin(a, b));
        }

    }

    private static int findMin(int s, int e) {
        // a에서 b까지의 범위 중 최솟값 구하기
        int minValue = Integer.MAX_VALUE;

        while(s <= e) {
            if(s % 2 == 1) {
                minValue = Math.min(minValue, tree[s]);
                s++;
            }
            if(e % 2 == 0) {
                minValue = Math.min(minValue, tree[e]);
                e--;
            }
            s /= 2;
            e /= 2;
        }
        return minValue;
    }

    private static void setTree(int treeHeight) {
        int index = (int) Math.pow(2, treeHeight) - 1;
        for (int i = index; i > 0; i--) {
            tree[i] = Math.min(tree[2*i], tree[2*i+1]);
        }
    }
}

☑️ 채점 결과 : 맞음

☑️ 어려웠던 점

• 없음

https://www.acmicpc.net/problem/5052

✔️관련 알고리즘 개념

트라이

☑️ 문제 분석

• 해당 문제는 트라이 자료구조를 사용하면 된다.
• 우선 일관성이 깨지는 경우는 다음과 같이 두가지이다.

✍️ 첫 번째, 911의 prefix 91이 나중에 나오는 경우

1 // t
2 // n
911
91

• 트라이 자료구조에 911이 있는 상태에서 91을 삽입하는 경우

  • 91에서 1이 삽입되고 isEnd를 true라고 값을 표시한 후

  • 현재 노드에 대해 자식노드가 존재하는지 탐색한다. 만약 자식이 존재하면 일관성이 벗어나는 것이다.

  • 관련 코드

       if(k == phoneNumber.length()-1) {
                              now.isEnd = true;
                              // 자식이 있으면 일관성 위배
                              for (tNode child : now.next) {
                                  if (child != null) {
                                      consistency = false;
                                      break;
                                  }
                              }
                          }

✍️ 두 번째, prefix 911이 먼저 나오고 9112546이 나중에 나오는 경우

2 // t
3 // n
911
97625999
91125426

• 트라이 자료구조에서 911은 이미 삽입되어 있고 91125426을 삽입하고 있는 경우

  • 91125426에서 세번째 숫자인 1을 삽입했는데 해당 숫자를 다 삽입하지 않았는데도 isEnd가 true인 상태이다. 이 경우는 이미 다른 숫자 값이 존재하여 해당 숫자를 prefix로 갖는 경우이므로 일관성에 벗어나는 것이다.

  • 관련 코드

        if(now.isEnd) {
                              consistency = false;
                              break;
                          }

☑️ 코드

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.*;

public class Main {
    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        int t = Integer.parseInt(br.readLine()); // 테스트 케이스 개수

        for (int i = 0; i < t; i++) {
            boolean consistency = true;
            int n = Integer.parseInt(br.readLine()); // 전화번호 수

            tNode root = new tNode(); // 루트노드는 공백으로
            for (int j = 0; j < n; j++) {
                String phoneNumber = br.readLine();
                tNode now = root;
                for (int k = 0; k < phoneNumber.length(); k++) {
                    char ch = phoneNumber.charAt(k);
                    if(now.next[ch - '0'] == null) {
                        now.next[ch - '0'] = new tNode();
                    }
                    if(now.isEnd) {
                        consistency = false;
                        break;
                    }
                    now = now.next[ch - '0'];

                    if(k == phoneNumber.length()-1) {
                        now.isEnd = true;
                        // 자식이 있으면 일관성 위배
                        for (tNode child : now.next) {
                            if (child != null) {
                                consistency = false;
                                break;
                            }
                        }
                    }
                }
            }
            System.out.println(consistency ? "YES" : "NO");
        }
    }

    static class tNode {
        tNode[] next = new tNode[10];
        boolean isEnd;
    }
}

☑️ 채점 결과 : 틀림 → 맞음

☑️ 어려웠던 점

• 아래의 경우를 생각하지 못함

1
2
911
91

https://www.acmicpc.net/problem/1012

✔️관련 알고리즘 개념

깊이 우선 탐색

너비 우선 탐색

☑️ 문제 분석

• 해당 문제는 BFS 혹은 DFS 탐색을 진행하면서 탐색이 진행되는 그룹수를 구하면 된다.

☑️ 코드

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.*;

public class Main {
    static int[][] visited;
    static Queue<Cabbage> queue = new LinkedList<>();
    static int T, M, N, K;

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        T = Integer.parseInt(br.readLine()); // 테스트 케이스 개수

        for (int i = 0; i < T; i++) {
            StringTokenizer st = new StringTokenizer(br.readLine());
            M = Integer.parseInt(st.nextToken()); // 가로 길이 (열)
            N = Integer.parseInt(st.nextToken()); // 세로 길이 (행)
            K = Integer.parseInt(st.nextToken()); // 배추 위치 개수

            visited = new int[N][M];

            for (int j = 0; j < K; j++) {
                st = new StringTokenizer(br.readLine());
                int x = Integer.parseInt(st.nextToken()); // 가로
                int y = Integer.parseInt(st.nextToken()); // 세로
                visited[y][x] = 1; // 좌표 저장
            }

            queue.clear();
            int count = 0;
            for (int r = 0; r < N; r++) {
                for (int c = 0; c < M; c++) {
                    if (visited[r][c] == 1) {
                        BFS(r, c);
                        count++;
                    }
                }
            }
            System.out.println(count);
        }
    }

    static void BFS(int r, int c) {
        visited[r][c] = 0;
        queue.add(new Cabbage(r, c));

        while (!queue.isEmpty()) {
            Cabbage cur = queue.poll();

            // 상
            if (cur.r - 1 >= 0 && visited[cur.r - 1][cur.c] == 1) {
                visited[cur.r - 1][cur.c] = 0;
                queue.add(new Cabbage(cur.r - 1, cur.c));
            }
            // 하
            if (cur.r + 1 < N && visited[cur.r + 1][cur.c] == 1) {
                visited[cur.r + 1][cur.c] = 0;
                queue.add(new Cabbage(cur.r + 1, cur.c));
            }
            // 좌
            if (cur.c - 1 >= 0 && visited[cur.r][cur.c - 1] == 1) {
                visited[cur.r][cur.c - 1] = 0;
                queue.add(new Cabbage(cur.r, cur.c - 1));
            }
            // 우
            if (cur.c + 1 < M && visited[cur.r][cur.c + 1] == 1) {
                visited[cur.r][cur.c + 1] = 0;
                queue.add(new Cabbage(cur.r, cur.c + 1));
            }
        }
    }

    static class Cabbage {
        int r, c;
        Cabbage(int r, int c) {
            this.r = r;
            this.c = c;
        }
    }
}

☑️ 채점 결과 : 맞음

☑️ 어려웠던 점

• 여기서 M은 가로(열), N은 세로(행)
• Java에서 배열은 arr[행][열] 구조라서 new int[N][M] 로 만들어야 한다
• 이전 코드에서는 x=가로, y=세로를 그대로 [x][y]에 넣고 있어서 index가 꼬인다.

👉 visited = new int[N][M];

https://www.acmicpc.net/problem/1647

✔️관련 알고리즘 개념

최소 신장 트리

☑️ 문제 분석

• 이 문제는 집(노드)를 길(에지)로 연결했을 때 비용(가중치)가 최소가 되도록 해야 하므로 최소 신장 트리의 개념을 이용하여 문제에 접근해야 한다.

• 문제에서는 모든 집을 연결하는 것이 아니라 집들을 길로 연결하여 두 개의 마을을 만들어야 한다. 만약 모든 집들을 연결하려면 N-1개의 에지를 사용하면 된다. 하지만 우리는 문제 요구 조건에 따라 두 개의 마을로 나눠야 하므로 N-2개의 에지만 사용하면 된다.

• 예시 입력 1을 분석해보자

  • 집의 개수는 7, 길의 개수는 12이고

  • 그 아래 12개의 줄에 집의 번호들과 비용이 작성되어 있다.

  • 최소 신장 트리를 사용하기 위해서는 우선순위 큐를 이용하여 비용이 낮은 순으로 정렬하고

  • 사이클 여부를 판단하기 위해 유니온 파인드를 수행해야 한다.

    7 12
    1 2 3
    1 3 2
    3 2 1
    2 5 2
    3 4 4
    7 3 6
    5 1 5
    1 6 2
    6 4 1
    6 5 3
    4 5 3
    6 7 4

☑️ 코드

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.*;

public class Main {
    static int N, M; // 집의 개수, 길의 개수
    static int[] parent;
    static PriorityQueue<Edge> queue = new PriorityQueue<>();

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st = new StringTokenizer(br.readLine());
        N = Integer.parseInt(st.nextToken());
        M = Integer.parseInt(st.nextToken());

        // 베열 초기화
        parent = new int[N+1];
        for (int i = 1; i <= N; i++) {
            parent[i] = i;
        }

        for (int i = 0; i < M; i++) {
            st = new StringTokenizer(br.readLine());
            int A = Integer.parseInt(st.nextToken());
            int B = Integer.parseInt(st.nextToken());
            int C = Integer.parseInt(st.nextToken());
            queue.add(new Edge(A, B, C));
        }

        int used_Edge = 0;
        int result = 0;
        while (used_Edge < N-2) {
            Edge poll = queue.poll();
            if(find(poll.A) != find(poll.B)) {
                union(poll.A, poll.B);
                used_Edge++;
                result += poll.C;
            }
        }

        System.out.println(result);

    }

    static int find(int a) {
        if(parent[a] == a) return a;
        else return parent[a] = find(parent[a]);
    }

    static void union(int a, int b) {
        a = find(a);
        b = find(b);

        if(a != b) parent[b] = a;
    }

    static class Edge implements Comparable<Edge>{
        int A;
        int B;
        int C;

        Edge(int A, int B, int C) {
            this.A = A;
            this.B = B;
            this.C = C;
        }

        @Override
        public int compareTo(Edge o) {
            return this.C - o.C;
        }
    }

}

☑️ 채점 결과 : 맞음

☑️ 어려웠던 점

• 없음

https://www.acmicpc.net/problem/14938

✔️관련 알고리즘 개념

플로이드-워셜⭐

☑️ 문제 분석

• 해당 문제는 모든 노드간의 최단거리를 계산을 해야하는 문제이므로 플로이드-워션 개념을 사용하여 문제를 풀면된다.

• 예시입력1을 분석해보면

    5 5 4
    5 7 8 2 3
    1 4 5
    5 2 4
    3 2 3
    1 2 3

  • 첫 째줄에는 지역개수(n), 수색범위(m), 길의 개수(r)가 주어진다.
  • 둘째줄에는 1번에서 n번 지역까지 아이템 개수가 주어진다. 이는 별도의 items배열을 생성하여 지역별 아이템 개수를 저장해두고 최대 아이템 개수를 계산할 때 이용하면 된다.

    | 1 | 2 | 3 | 4 | 5 |
    | --- | --- | --- | --- | --- |
    | 5 | 7 | 8 | 2 | 3 |
- 이후 r개의 줄에는 길 정보가 주어져있으므로 인접행렬에 저장한다.
    - 단, 양방향으로 지역간 이동이 가능하므로 꼭 양방향으로 거리 정보를 저장한다.

• 최종 출력

  • 이제 최종 출력은 예은이가 1번~n번 지역에 떨어졌을 때 각각 경우에서 얻을 수 있는 아이템 개수를 계산하고 각 경우에서 얻을 수 있는 아이템 개수가 제일 큰 값을 출력하면 된다.

    int max_item = Integer.MIN_VALUE; // 최대 아이템 개수
          for (int i = 1; i <= n; i++) {
              int sum = 0;
              for (int j = 1; j <= n; j++) {
                  if(distance[i][j] <= m) {
                      sum += items[j];
                  }
              }
              if(max_item < sum) max_item = sum;
          }

☑️ 코드

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.*;

public class Main {
    static int[][] distance; // 거리 배열
    static int[] items; // 지역별 아이템 개수

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st = new StringTokenizer(br.readLine());
        int n = Integer.parseInt(st.nextToken()); // 지역 개수
        int m = Integer.parseInt(st.nextToken()); // 수색 범위
        int r = Integer.parseInt(st.nextToken()); // 길의 개수

        // 지역별 아이템 개수 저장
        items = new int[n+1];
        st = new StringTokenizer(br.readLine());
        for (int i = 1; i <= n; i++) {
            items[i] = Integer.parseInt(st.nextToken());
        }

        // 인접 행렬 초기화, i와 j의 값이 같은 곳은 0으로 초기화 나머지는 무한대
        distance = new int[n+1][n+1];
        for (int i = 1; i <= n; i++) {
            for (int j = 1; j <= n; j++) {
                if(i == j) distance[i][j] = 0;
                else distance[i][j] = Integer.MAX_VALUE;
            }
        }

        // 길 정보 입력받기
        for (int i = 0; i < r; i++) {
            st = new StringTokenizer(br.readLine());
            int a = Integer.parseInt(st.nextToken());
            int b = Integer.parseInt(st.nextToken());
            int l = Integer.parseInt(st.nextToken());
            if(distance[a][b] > l) {
                distance[a][b] = l;
                distance[b][a] = l;
            }
        }

        // 플로이드-워셜을 적용하여 노드간 최단거리 계산하기
        for (int k = 1; k <= n; k++) {
            for (int i = 1; i <= n; i++) {
                for (int j = 1; j <= n; j++) {
                    if(distance[i][k] != Integer.MAX_VALUE && distance[k][j] != Integer.MAX_VALUE && distance[i][j] > distance[i][k] + distance[k][j])
                        distance[i][j] = distance[i][k] + distance[k][j];
                }
            }
        }

        int max_item = Integer.MIN_VALUE; // 최대 아이템 개수
        for (int i = 1; i <= n; i++) {
            int sum = 0;
            for (int j = 1; j <= n; j++) {
                if(distance[i][j] <= m) {
                    sum += items[j];
                }
            }
            if(max_item < sum) max_item = sum;
        }

        System.out.println(max_item);
    }

}

☑️ 채점 결과 : 틀림 → 맞음

☑️ 어려웠던 점

• 양방향 그래프이므로 거리 정보를 양방향으로 저장했어야 했다.

// 처음엔 단방향 저장
if(distance[a][b] > l) {
    distance[a][b] = l;
}

-------->
// 양방향 거리 
if(distance[a][b] > l) {
    distance[a][b] = l;
    distance[b][a] = l;
}

https://www.acmicpc.net/problem/7040

✔️관련 알고리즘 개념

벨만-포드

☑️ 문제 분석

• 우선 문제 조건에서 1번부터 N번까지의 소들이 번호순대로 줄을 설 때 1번소와 N번 소의 최대 거리를 구해야 한다.
• 예시 입력 1을 분석해보자

4 2 1
1 3 10
2 4 20
2 3 3

• 소는 1번부터 4번까지 4마리가 있고 서로를 좋아하는 소의 쌍은 2쌍, 서로를 싫어하는 소의 쌍은 1쌍이 있다. 1번, 3번 소는 서로를 좋아하므로 최대 10까지만 떨어져 있을 수 있고 2번, 4번 소도 서로를 좋아하므로 최대 20까지만 떨어져 있을 수 있다. 그리고 2번, 3번 소는 서로를 싫어하므로 최소 3만큼 떨어져 있어야 한다.
• 최종적으로 1번과 4번의 최대 거리를 구해야 하므로 최대한 소들이 서로 떨어져 있게끔 한다.

• 위 그림을 보면 2와 4가 최대 20만큼 떨어져 있다. 이제 1과 2가 최대한 멀리 떨어져 있을 수록 1과 4사이의 거리가 최대일 것이다. 또한 1과 3이 최대 2만큼 떨어져 있다. 이제 3과 4가 최대한 멀리 떨어져 있을 수록 1과 4사이의 거리가 최대일 것이다. 예시 입력 1에서는 2와 3의 최소 거리가 나와 있으므로 전자를 이용하여 문제를 풀면된다.
• 따라서 1과 2사이 최대 거리는 7, 2와 4사이 최대 거리는 20이므로 1과 4사이의 최대거리는 27이다.

위의 과정을 벨만-포드를 적용하여 이해해보자

에지리스트 – (c1, c2, d)순

(1, 3, 10)

(2, 4, 20)

(2, 3, 3)

1번째 업데이트

(1)(1, 3, 10)

• 1번소의 distance[1] != ∞ => distance[3] = 10으로 업데이트

(2) (2, 4, 20)

• 2번 소의 distance[2] = ∞ => 업데이트 불가

(3) (2, 3, 3)은 최소 거리이고 우리는 3번 소의 distance[3] = 10 (!= ∞)

라는 것을 이용해서 distance[2] = distance[3] – 10 = 7로 업데이트

여기서

MD배열에서 distance[c2] != ∞이면 distance[c1] = distance[c2] – d로 계산할 수 있다.

ML배열은 일반적인 벨만포드와 같이 계산하면 된다.

2번째 업데이트

(1)(1, 3, 10)

• 업데이트 진행할 것 없음

(2) (2, 4, 20)

• distance[2] != ∞ => distance[4] = distance[2] +20 = 27로 업데이트

(3) (2, 3, 3)

• 업데이트 진행할 것 없음

최종적으로 한번 더 에지리스트를 순회하여

• 업데이트 되는 값이 있으면 음수사이클이 존재하는 것과 같으므로 줄을 서는 것이 불가 -> 1을 출력
• distance[N] = ∞ -> 2출력
• 줄서는것이 가능 & distance[N] != ∞ -> distance[N] 출력

☑️ 코드

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.*;

public class Main {
    static int[] distance; // 거리 배열
    static List<Edge> edge = new ArrayList<>(); // 에지 리스트
    static int N;
    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st = new StringTokenizer(br.readLine());
        N = Integer.parseInt(st.nextToken());
        int ML = Integer.parseInt(st.nextToken());
        int MD = Integer.parseInt(st.nextToken());

        distance = new int[N+1];
        Arrays.fill(distance, Integer.MAX_VALUE);

        // ML 입력받기
        for (int i = 0; i < ML; i++) {
            st = new StringTokenizer(br.readLine());
            int c1 = Integer.parseInt(st.nextToken());
            int c2 = Integer.parseInt(st.nextToken());
            int d = Integer.parseInt(st.nextToken());
            edge.add(new Edge("ML", c1, c2, d));
        }

        // MD 입력받기
        for (int i = 0; i < MD; i++) {
            st = new StringTokenizer(br.readLine());
            int c1 = Integer.parseInt(st.nextToken());
            int c2 = Integer.parseInt(st.nextToken());
            int d = Integer.parseInt(st.nextToken());
            edge.add(new Edge("MD", c1, c2, d));
        }

         // 시작 노드의 거리 배열 값은 0이다.
        distance[1] = 0;
         // N-1번 벨만-포드를 반복한다.
        for (int i = 0; i < N - 1; i++) {
            for (Edge e : edge) {
                if(e.mode.equals("ML")) {
                    if(distance[e.c1] != Integer.MAX_VALUE && distance[e.c2] > distance[e.c1] + e.d) {
                        distance[e.c2] = distance[e.c1] + e.d;
                    }
                } else if(e.mode.equals("MD")) {
                    if(distance[e.c2] != Integer.MAX_VALUE && distance[e.c1] > distance[e.c2] - e.d) {
                        distance[e.c1] = distance[e.c2] - e.d;
                    }
                }
            }
        }

        boolean imPossible = false;
        for (Edge e : edge) {
            if(e.mode.equals("ML")) {
                if(distance[e.c1] != Integer.MAX_VALUE && distance[e.c2] > distance[e.c1] + e.d) {
                    imPossible = true;
                }
            } else if(e.mode.equals("MD")) {
                if(distance[e.c2] != Integer.MAX_VALUE && distance[e.c1] > distance[e.c2] - e.d) {
                    imPossible = true;
                }
            }
        }

        if(imPossible) System.out.println(-1);
        else if(distance[N] == Integer.MAX_VALUE) System.out.println(-2);
        else System.out.println(distance[N]);
    }

    static class Edge {
         String mode;
         int c1;
         int c2;
         int d;

         Edge(String mode, int c1, int c2, int d) {
             this.mode = mode;
             this.c1 = c1;
             this.c2 = c2;
             this.d = d;
         }
    }

}

☑️ 채점 결과 : 틀림 → 맞음

• 처음에는 벨만-포드는 최단거리 문제인데 여기는 최대 거리를 구하라고 해서 Integer.MAX_VALUE가 아닌 Integer,MIN_VALUE를 사용해서 틀렸다.

☑️ 어려웠던 점

• 처음에 문제를 이해하는 것이 어려웠다.

https://www.acmicpc.net/problem/1916

✔️관련 알고리즘 개념

다익스트라

☑️ 문제 분석

• 해당 문제는 최종적으로 출발 도시에서 도착 도시까지 가는데 드는 최소 비용을 출력해야 한다.
• 최소 비용을 구하기 위해서는 다익스트라를 활용하여 출발 도시에서 모든 노드까지 이르는 최소 거리를 구한 후 마지막 출력에서는 최소 거리 중 도착 도시에 이르는 최소 거리만을 출력하면 된다.

☑️ 코드

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.*;

public class Main {
    public static int[] distance; // 최단 거리 저장 배열
    public static boolean[] visited; // 노드 방문 여부 표시
    public static ArrayList<Edge>[] list; // 인접리스트
    public static PriorityQueue<Edge> q = new PriorityQueue<>();

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        int N = Integer.parseInt(br.readLine()); // 도시 개수
        int M = Integer.parseInt(br.readLine()); // 버스 개수

        distance = new int[N+1];
        visited = new boolean[N+1];
        list = new ArrayList[N+1];

        // 인접리스트 초기화
        for (int i = 1; i <= N; i++) {
            list[i] = new ArrayList<>();
        }

        Arrays.fill(distance, Integer.MAX_VALUE);

        StringTokenizer st;
        // 버스 노선 입력받기
        for (int i = 0; i < M; i++) {
            st = new StringTokenizer(br.readLine());
            int a = Integer.parseInt(st.nextToken()); // 출발 도시
            int b = Integer.parseInt(st.nextToken()); // 도착 도시
            int cost = Integer.parseInt(st.nextToken());
            list[a].add(new Edge(b, cost));
        }

        st = new StringTokenizer(br.readLine());
        int start = Integer.parseInt(st.nextToken());
        int end = Integer.parseInt(st.nextToken());

        distance[start] = 0;
        q.add(new Edge(start, 0));

        while (!q.isEmpty()) {
            Edge current = q.poll();
            int c_v = current.vertex;

            if(visited[c_v]) continue; // 이미 방문한 노드라면 넘어감
            visited[c_v] = true;

            for (Edge edge : list[c_v]) {
                int vertex = edge.vertex;
                int weight = edge.weight;

                if(distance[vertex] > distance[c_v] + weight) {
                    distance[vertex] = distance[c_v] + weight;
                    q.add(new Edge(vertex, distance[vertex]));
                }
            }
        }

        System.out.println(distance[end]);
    }

    static class Edge implements Comparable<Edge> {
        int vertex;
        int weight;

        public Edge(int vertex, int weight) {
            this.vertex = vertex;
            this.weight = weight;
        }
        @Override
        public int compareTo(Edge o) {
            return this.weight - o.weight;
        }
    }

}

☑️ 채점 결과 : 맞음

☑️ 어려웠던 점

• 없음

https://www.acmicpc.net/problem/3665

✔️관련 알고리즘 개념

위상 정렬

☑️ 문제 분석

• 그림을 이용하여 문제를 입력하면 다음과 같다.

• 만약 위상 정렬을 적용하여 노드간의 순서가 잘 출력 될 것 같으면 노드간의 순서를 출력한다.
  • 하지만, 진입차수가 0인 차수가 없는 경우에는 정렬이 불가하므로 ‘IMPOSSIBLE’을 출력하고
  • 반면, 진입차수가 0인 차수가 존재하지만 여러개 있는 경우 정확한 순위를 매길 수 없으므로 ‘?’를 출력한다.

☑️ 코드

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.*;

public class Main {
    static int[] lastRank;
    static ArrayList<ArrayList<Integer>> arrayList; 
    static int[] D;                                 // 진입차수
    static int n;

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringBuilder out = new StringBuilder();
        int t = Integer.parseInt(br.readLine()); // 테스트 케이스 개수

        for (int tc = 0; tc < t; tc++) {
            n = Integer.parseInt(br.readLine()); // 팀의 개수

            // 작년 순위
            lastRank = new int[n + 1];
            StringTokenizer st = new StringTokenizer(br.readLine());
            for (int j = 1; j <= n; j++) {
                lastRank[j] = Integer.parseInt(st.nextToken()); j 인덱스에 저장
            }


            arrayList = new ArrayList<>(n + 1);
            for (int j = 0; j <= n; j++) arrayList.add(new ArrayList<>());
            D = new int[n + 1];

            // 작년 순위를 인접리스트에 저장 
            for (int j = 1; j <= n; j++) {
                for (int k = j + 1; k <= n; k++) {
                    int u = lastRank[j]; 
                    int v = lastRank[k]; 
                    arrayList.get(u).add(v);
                    D[v]++;
                }
            }

            // 상대적인 등수가 바뀐 쌍의 수
            int m = Integer.parseInt(br.readLine());
            for (int j = 0; j < m; j++) {
                st = new StringTokenizer(br.readLine());
                int a = Integer.parseInt(st.nextToken());
                int b = Integer.parseInt(st.nextToken());
                changeRank(a, b); 
            }

            // 최종 위상 정렬 적용하여 올해 순위 출력하기
            out.append(topologicalSort()).append('\n');
        }

        System.out.print(out.toString());
    }

    private static String topologicalSort() {
        Queue<Integer> queue = new ArrayDeque<>();
        for (int i = 1; i <= n; i++) if (D[i] == 0) queue.offer(i);

        List<Integer> order = new ArrayList<>(n);
        boolean ambiguous = false;

        for (int step = 0; step < n; step++) {
            if (queue.isEmpty()) return "IMPOSSIBLE";  

            if (queue.size() > 1) ambiguous = true;     // 같은 시점의 후보가 2개 이상 → 모호

            int now = queue.poll();
            order.add(now);

            for (int next : arrayList.get(now)) {
                D[next]--;
                if (D[next] == 0) queue.offer(next);
            }
        }

        if (ambiguous) return "?";

        StringBuilder sb = new StringBuilder();
        for (int i = 0; i < n; i++) {
            if (i > 0) sb.append(' ');
            sb.append(order.get(i));
        }
        return sb.toString();
    }

    // a와 b팀의 상대적 순위 바꾸기 
    private static void changeRank(int a, int b) {
        // a -> b 가 있으면 b -> a 로 뒤집기
        if (arrayList.get(a).contains(b)) {
            arrayList.get(a).remove((Integer) b);
            D[b]--;
            arrayList.get(b).add(a);
            D[a]++;
        }
        // 없으면 b -> a가 있다고 보고 a -> b로 뒤집기
        else if (arrayList.get(b).contains(a)) {
            arrayList.get(b).remove((Integer) a);
            D[a]--;
            arrayList.get(a).add(b);
            D[b]++;
        }
    }
}

☑️ 채점 결과 : 맞음

☑️ 어려웠던 점

• 다양한 예외 상황을 고려하여 코드를 작성하는 것이 어려웠다.

https://www.acmicpc.net/problem/16562

✔️관련 알고리즘 개념

유니온 파인드

☑️ 문제 분석

• 우선 예시입력 1, 2를 직접 확인해보면서 풀이를 파악한다.

• 그런데 위의 과정을 구현하고 나면 우리는 parent배열을 통해 집합 관계를 확인할 수 있다.

• 위 정보를 통해 최소 비용을 계산해야 한다.

• 즉, 배열을 돌면서 각 친구들의 친구비와 대표 노드의 최소 비용을 비교하면서 최소 비용을 업데이트해가면 된다.

☑️ 코드

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;
import java.util.StringTokenizer;

public class Main {
    static int[] parent;
    static int[] friendCost;
    static int[] minCost;
    static  int k;
    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st = new StringTokenizer(br.readLine());
        int N = Integer.parseInt(st.nextToken()); // 학생 수
        int M = Integer.parseInt(st.nextToken()); // 친구 관계수
        k = Integer.parseInt(st.nextToken()); // 가지고 있는 돈

        // 친구 비 저장 배열
        friendCost = new int[N+1];
        st = new StringTokenizer(br.readLine());
        for (int i = 1; i <= N; i++) {
            friendCost[i] = Integer.parseInt(st.nextToken());
        }

        // 대표 노드 저장 배열
        parent = new int[N+1];
        minCost = new int[N+1];

        // 대표 노드 저장 배열 초기화
        for (int i = 1; i <= N; i++) {
            parent[i] = i;
        }

        // 친구 관계수를 입력받고 해당 친구 번호들에 대해 union 연산을 한다.
        for (int i = 0; i < M; i++) {
            st = new StringTokenizer(br.readLine());
            int f1 = Integer.parseInt(st.nextToken());
            int f2 = Integer.parseInt(st.nextToken());

            if(f2 < f1) union(f2, f1);
            else union(f1, f2);
        }

        // 루트별 최소비 계산
        final int INF = 1_000_000_000;
        int[] minCost = new int[N + 1];
        Arrays.fill(minCost, INF);

        for (int i = 1; i <= N; i++) {
            int r = find(i); // 반드시 find로 루트 보정
            minCost[r] = Math.min(minCost[r], friendCost[i]);
        }

        int sum = 0;
        for (int i = 1; i <= N; i++) {
            if (i == find(i) && minCost[i] != INF) sum += minCost[i]; // 대표만 합산
        }

        if (sum <= k) System.out.println(sum);
        else System.out.println("Oh no");

    }

    public static void union(int a, int b) {
        a = find(a);
        b = find(b);

        if(a != b) {
            parent[b] = a;
        }
    }

    public static int find(int a) {
        // 대표 노드 반환 함수
        if(parent[a] == a) return a;
        else return parent[a] = find(parent[a]);
    }
}

☑️ 채점 결과 : 틀림 → 맞음

• 집합 관계를 토대로 최소 비용을 계산하는 부분이 틀렸었다.

☑️ 어려웠던 점

• 최소 비용 계산이 어려웠다.

https://www.acmicpc.net/problem/2166

✔️관련 알고리즘 개념

Shoelace 공식(Shoelace formula)

• 2차원 평면에서 다각형의 면적을 구하는 공식으로, 점들이 순서대로(시계 혹은 반시계 방향) 주어졌을 때 사용할 수 있다.

🥾 Shoelace 공식 (신발끈 공식)

다각형의 꼭짓점이 다음과 같이 순서대로 주어졌다.

$(x1,y1), (x2,y2), (x3,y3), …, (xn,yn)$

이때, 면적 A는 다음과 같은 신발끈 공식으로 계산된다.

단, 여기에 끝 점의 다음 점으로 시작점을 다시 사용해야 하므로:

• $xn+1=x1$
• $yn+1=y1$이 된다.

☑️ 문제 분석

• 해당 문제는 N각형을 나타내는 N개의 좌표가 주어졌을 때 해당 다각형의 면적을 구하는 문제이다.

• 처음에는 N각형을 쪼개서 삼각형을 만든 다음 각 삼각형의 넓이를 |CCW|/2를 이용하여 구한 다음 다 더해서 N각형의 넓이를 구하려고 했는데 이는 좌표가 시계방향 혹은 반시계 순서대로 주어져야 사용할 수 있다.

• N각형의 넓이를 삼각형으로 쪼개지 않고 바로 구할 수 있는 방법은 신발끈 공식을 이용하여 문제를 푼다.

  

• 단 여기서 주의해야 할 것은 i값이 n일 때 i+1값은 존재하지 않으므로 x1, y1값으로 계산해야 한다는 점이다.

☑️ 코드

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.StringTokenizer;

public class Main {
    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        int N = Integer.parseInt(br.readLine());

        Coordinates[] p = new Coordinates[N];
        for (int i = 0; i < N; i++) {
            StringTokenizer st = new StringTokenizer(br.readLine());
            int a = Integer.parseInt(st.nextToken());
            int b = Integer.parseInt(st.nextToken());
            p[i] = new Coordinates(a, b);
        }

        double result = 0;
        for (int i = 0; i < N; i++) {
            int j = (i + 1) % N; // 다음 점, 마지막 → 첫 점으로 순환
            result += (long)p[i].x * p[j].y - (long)p[j].x * p[i].y;
        }

        System.out.printf("%.1f\n", Math.abs(result) / 2.0);
    }

    public static class Coordinates {
        int x, y;
        Coordinates(int x, int y) {
            this.x = x;
            this.y = y;
        }
    }
}

☑️ 채점 결과 : 틀림 → 맞음

☑️ 어려웠던 점

• 신발끈 공식을 떠올리지 못했다.

https://www.acmicpc.net/problem/9095

✔️관련 알고리즘 개념

동적 계획법

☑️ 문제 분석

• 여기서 n의 값은 11보다 작은 양수이다.
• n에 대한 경우의 수는 앞의 세 개의 n값들의 합이다.
  • 왜 앞의 3개의 합이냐면 합을 1, 2, 3의 합으로만 나타낼 수 있기 때문이다.
• 아래 그림을 보면
  • 4를 1, 2, 3의 합으로 나타내는 경우의 수는 총 7가지이다.
    • 1을 나타내는 모든 식에 각각 3을 더해주면 4를 나타내는 식이 된다.
    • 2를 나타내는 모든 식에 각각 2를 더해주면 4를 나타내는 식이 된다.
    • 3을 나타내는 모든 식에 각각 1을 더해주면 4를 나타내는 식이 된다.
  • 따라서 여기서 점화식은 p[i] = p[i-1] + p[i-2] + p[i-3] (i > 3) 이 나온다.

☑️ 코드

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;

public class Main {
    static int[] dp = new int[11]; // n은 11보다 작다고 했으니 0~10까지

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));

        // DP 초기화
        dp[1] = 1;
        dp[2] = 2;
        dp[3] = 4;
        for (int i = 4; i <= 10; i++) {
            dp[i] = dp[i - 1] + dp[i - 2] + dp[i - 3];
        }

        int T = Integer.parseInt(br.readLine());
        for (int i = 0; i < T; i++) {
            int n = Integer.parseInt(br.readLine());
            System.out.println(dp[n]);
        }
    }
}

☑️ 채점 결과 : 맞음

☑️ 어려웠던 점

• 없음