K8sPatterns.11 Stateless Service

0. Contents

1. Overview

패턴의 정의와 적합한 환경

• Stateless Service 패턴은 동일한 일시적(ephemeral) 복제본들로 구성된 애플리케이션을 만들고 운영하는 방법을 설명한다
• 빠른 확장과 높은 가용성이 필요한 동적 클라우드 환경에 가장 적합한 패턴이다

2. Problem

일시적 서비스의 조건

• 마이크로서비스 아키텍처에서 서비스를 일시적(ephemeral) 으로 만들려면
  • 서비스가 부작용 없이 생성·확장·삭제될 수 있어야 한다
• 이 특성은 서비스가 무상태(Stateless) 일 때 훨씬 쉽게 달성된다

무상태 서비스의 요청 처리

• 내부적으로 어떤 상태도 유지하지 않는다
• 과거 요청에 대한 저장된 지식이나 참조가 없다
  • 그래서 각 요청은 마치 처음부터 새로 시작하는 것처럼 처리된다

무상태 판별 사고 실험

실험 가정

• 서비스 인스턴스들이 서로 다른 노드에 배포된다
• 로드 밸런서가 sticky session 없이 요청을 무작위로 분배한다

판별 기준

• 이 설정에서도 서비스가 제 역할을 다할 수 있다면, 그것은 무상태 서비스다

3. Solution

애플리케이션 = 여러 요소의 집합

• Kubernetes에는 “애플리케이션(Application)“이나 “컨테이너(Container)“를 최상위 개체로 갖는 개념이 없다
• 대신 애플리케이션은 여러 요소들의 집합으로 구성된다

하나의 애플리케이션

• Deployment / ReplicaSet → Pod 생성 및 유지
• ConfigMap / Secret → 설정 및 민감 정보
• Service → 네트워크 진입점
• PersistentVolumeClaim → 영구 저장소

Deployment와 ReplicaSet의 관계

• 무상태 Pod를 관리하는 컨트롤러는 ReplicaSet이다
  • 하지만 이것은 Deployment가 내부적으로 사용하는 하위 레벨 구조다
• Deployment가 사용자가 직접 다루는 권장 추상화다

ReplicaSet 직접 사용: 두 경우로 한정

• Deployment의 업데이트 전략이 맞지 않을 때
• 커스텀 메커니즘이 필요할 때

4. Instances: ReplicaSet

ReplicaSet의 주요 목적

• 언제든지 지정된 수의 동일한 Pod 복제본이 실행되도록 보장하는 것이다

ReplicaSet의 3가지 핵심 구성요소

Example 11-1. ReplicaSet 명세

apiVersion: apps/v1        # ReplicaSet은 apps API 그룹 소속 (core v1이 아님)
kind: ReplicaSet
metadata:
  name: rg                 # ReplicaSet 자체의 이름 — Pod 이름은 이 뒤에 랜덤 접미사가 붙어 생성됨(rg-xxxxx)
  labels:
    app: random-generator  # ReplicaSet 리소스 자체에 붙는 레이블(관리용). selector와는 별개
spec:
  replicas: 3                        # ① 유지할 Pod 복제본의 목표 수 — 컨트롤러가 이 값을 계속 감시
  selector:
    matchLabels:
      app: random-generator          # ② 관리할 Pod를 찾는 레이블 조건 — template.metadata.labels와 반드시 일치해야 함
  template:                          # ③ 새 Pod를 만들 때 사용할 템플릿 (이하는 일반 Pod spec과 동일)
    metadata:
      labels:
        app: random-generator        # selector가 찾는 바로 그 레이블 — 여기서 Pod가 실제로 부여받음
    spec:
      containers:
      - name: random-generator       # 컨테이너 이름 (Pod 안에서 로그/exec 시 식별자로 사용)
        image: k8spatterns/random-generator:1.0   # 3개 Pod 모두 동일한 이미지로 복제됨

자동 복구 동작

selector와 template label이 일치해야 하는 이유

이 둘이 반드시 같아야 함!

• 다르면 ReplicaSet이 자신이 만든 Pod를 관리 대상으로 인식 못함 ❌

ReplicaSet의 범위: 클러스터 전체가 아닌 네임스페이스

동작 범위와 자원 소비

• ReplicaSet은 클러스터 전체가 아니라 특정 네임스페이스 안에서만 동작한다
• 단, Pod들이 실행되면서 클러스터 전체 노드의 CPU/메모리 자원을 소비한다

클러스터 전체

• namespace: default ← ReplicaSet “rg” 여기 있음
  • [Pod1] [Pod2] [Pod3]
• namespace: production ← 여기엔 영향 없음
• namespace: staging ← 여기도 영향 없음

5. Networking: Service

Pod의 근본적인 문제

Pod의 수명: 일시적

• ReplicaSet이 생성한 Pod는 일시적(ephemeral) 이며 언제든지 사라질 수 있다

핵심 문제: 찾아오는 방법

• IP가 바뀌면 클라이언트가 이전 IP로 요청을 보내도 찾을 수 없다
• Stateless라면 어떤 Pod가 요청을 받아도 동일하게 처리할 수 있다
  • 그러므로 문제는 “찾아오는 방법"에 있다

Kubernetes Service가 해결하는 것

Service가 필요한 경우 vs 불필요한 경우

Example 11-2. 무상태 서비스 노출하기

apiVersion: v1              # Service는 core v1 API 그룹 소속
kind: Service
metadata:
  name: random-generator          # ① Pod에 접근할 때 사용하는 서비스 이름 — 클러스터 내부 DNS도 이 이름으로 생성됨
                                   #    (예: random-generator.default.svc.cluster.local)
spec:
  # type을 생략하면 기본값은 ClusterIP — 클러스터 내부에서만 접근 가능(외부 노출은 NodePort/LoadBalancer 필요)
  selector:
    app: random-generator         # ② ReplicaSet의 Pod 레이블과 매칭되는 셀렉터
                                   #    이 레이블을 가진 Pod들이 자동으로 이 Service의 엔드포인트가 됨
  ports:
  - port: 80                      # ③ Service가 클러스터 내부에 노출하는 포트 (클라이언트가 호출하는 포트)
    targetPort: 8080              # ④ Pod 내부 컨테이너가 실제로 listening하는 포트 (컨테이너 spec의 포트와 일치해야 함)
    protocol: TCP                 # ⑤ 기본값이 TCP라 생략 가능하지만 명시적으로 적어두면 의도가 분명해짐

포트 개념: 건물 비유

• 클라이언트가 보내는 곳 → port: 80
• 실제 Pod 안에서 받는 곳 → targetPort: 8080
• “안내데스크(80번 창구)로 오세요 → 실제 담당자는 8080호 사무실에 있어요”

clusterIP: 클러스터 내부 전용 고정 IP

clusterIP 할당과 특성

• Service가 생성되면 clusterIP가 자동으로 할당된다
• 이 IP는 Kubernetes 클러스터 내부에서만 접근 가능하다
• Service가 삭제될 때까지 절대 바뀌지 않는다

비유: 대표 전화번호

• clusterIP는 서로 다른 서비스끼리 통신하는 대표 전화번호 같은 개념이다
• 라벨만으로 직접 찾으려 하면
  • 로드밸런싱이 없다
  • 죽은 Pod의 IP를 추적하기 어렵다

Service의 3가지 핵심 기능

Deployment/ReplicaSet과 Service는 서로 모른다

연결 고리: label/selector

• 이 둘은 label/selector라는 공통 언어를 통해서만 간접적으로 연결된다

6. Storage: PersistentVolumeClaim

PVC란?

PV와 PVC

• PV (PersistentVolume) = 실제 저장 공간 (창고)
• PVC (PersistentVolumeClaim) = 창고 사용 신청서

신청서 방식의 동작

• 개발자가 직접 창고를 만드는 게 아니다
• “이런 창고가 필요해요” 라고 신청서를 내면
  • Kubernetes가 알아서 맞는 창고를 연결해줌

Example 11-3. PersistentVolume 요청(claim)

apiVersion: v1                 # PVC도 core v1 API 그룹 소속
kind: PersistentVolumeClaim
metadata:
  name: random-generator-log   # ① Pod 템플릿에서 참조할 claim 이름 — volumes.persistentVolumeClaim.claimName에 그대로 사용됨
spec:
  storageClassName: "manual"   # 어떤 StorageClass(=어떤 종류의 스토리지 프로비저너)를 쓸지 지정
                                # "manual"은 관리자가 PV를 미리 만들어둔 정적 프로비저닝을 의미
                                # 클라우드 환경이면 보통 "standard", "gp3" 같은 동적 프로비저닝용 클래스를 씀
  accessModes:
  - ReadWriteOnce               # ② 단일 노드에서만 읽기/쓰기 가능 (노드 단위 제한, Pod 단위 아님 — 아래 RWO vs RWOP 참고)
  resources:
    requests:
      storage: 1Gi              # ③ 1GiB 저장 공간 요청 — 실제 PV의 용량이 이보다 크거나 같아야 바인딩됨
# 이 PVC는 template.spec.volumes에서 이름으로 참조되고,
# containers[].volumeMounts에서 컨테이너 내부 경로에 마운트된다.

accessModes 4가지

accessModes의 역할

• PVC의 핵심 필드인 accessModes는 저장소가 노드에 어떻게 마운트되고 Pod에 의해 어떻게 사용되는지를 제어한다

RWO vs RWOP: 미묘하지만 중요한 차이

제한 단위: 노드 vs Pod

• RWO는 노드 단위 제한이라 같은 노드의 여러 Pod가 동시에 쓸 수 있다
• 오직 RWOP만이 단 하나의 Pod만 볼륨에 접근함을 보장한다

RWOP 주의점: 스케일 아웃

• replicas: 3 으로 늘리려 했더니…
  • Pod1 ✅ 실행 중 (PVC 점유 중)
  • Pod2 ❌ Pending! 스케줄러가 노드에 배치하지 못함
  • Pod3 ❌ Pending! 같은 이유
  • kubectl describe pod 이벤트에 FailedScheduling 과 함께 같은 RWOP PVC를 쓰는 Pod가 이미 있다는 메시지가 남음
• → 사실상 싱글톤(1개)으로 고정됨
• → Stateless의 장점인 스케일 아웃이 불가능해짐!

RWOP 주의점: 선점(preemption)

• 처음(알파)에는 RWOP PVC를 쓰는 Pod에 선점이 적용되지 않았다
• Kubernetes 1.27(베타)부터 스케줄러가 RWOP PVC를 쓰는 Pod의 선점을 지원한다 (1.29에서 RWOP와 함께 GA)
• 우선순위 높은 Pod가 같은 PVC를 필요로 하면, 그 PVC를 쓰던 낮은 우선순위 Pod를 밀어낼 수 있다

상황별 추천 모드

ReplicaSet vs StatefulSet의 저장소 차이

무상태 vs 상태 저장: 저장소 방식

• ReplicaSet의 Pod들은 PVC 하나를 함께 쓴다
  • 단, 예제 PVC는 ReadWriteOnce라서 같은 노드에 뜬 Pod끼리만 공유할 수 있다
  • 여러 노드의 Pod가 함께 쓰려면 RWX를 지원하는 스토리지가 필요하다
• 이것이 Kubernetes에서 무상태와 상태 저장 워크로드를 처리하는 방식의 가장 큰 차이점 중 하나다

7. 전체 구조 한눈에 보기

추상화별 해결 문제

8. Discussion

복잡한 분산 시스템의 구성

• 일반적으로 여러 서비스들로 구성된다

무상태 서비스의 4가지 특성

1. 동일함 (Identical): Pod1 = Pod2 = Pod3
2. 교체 가능함 (Swappable): Pod1이 Pod2로 교체되어도 문제 없음
3. 일시적임 (Ephemeral): 언제든 사라져도 괜찮음
4. 대체 가능함 (Replaceable): 죽으면 새걸로 바로 대체

조합의 책임: 개발자

• Kubernetes는 이러한 구성 요소들을 제공한다
• 하지만 이들 사이의 직접적인 관계를 강제하지는 않는다
• 이것들을 애플리케이션의 특성에 맞게 조합하는 것은 개발자의 책임이다

확장 프레임워크와의 결합

• Kubernetes 기본 요소만으로 부족할 때는 Knative Serving, KEDA 같은 프레임워크와 결합할 수 있다

Knative의 구성

• Knative는 Serving(요청 기반 자동확장), Eventing(이벤트 라우팅) 등을 포함하는 서버리스 프로젝트다
• 스케일-투-제로는 그중 Knative Serving의 역할이다

자동확장 기준 비교

관련 장

• 이러한 프레임워크들은 29장 “탄력적 확장(Elastic Scale)“에서 다룬다

Stateless Service는 동일하고 교체 가능한 인스턴스로 구성되며, Deployment + ReplicaSet + Service + PVC의 조합으로 생성·유지·확장·업데이트·복구 전 과정을 자동화할 수 있다. 각 구성 요소는 서로를 직접 알지 못하고 label이라는 공통 언어로만 연결된다.