M3. Pod·Deployment·ReplicaSet와 원하는 상태

1. 왜 필요한가

NKS에서 web-app Pod 하나가 사라졌을 때 운영자가 새 Pod를 직접 만드는 것이 아니라, 어떤 owner가 원하는 replica 수를 복구하는지 알아야 올바른 객체를 수정할 수 있습니다. 이 모듈에서는 Deployment→ReplicaSet→Pod 관계를 실제 이름과 ownerReferences로 확인하고, 삭제·scale·Pod template 변경 뒤의 수렴을 관찰합니다.

개념 정의의 정본은 Kubernetes Basics입니다. 원본 경로는 content/topics/L5/kubernetes-basics.mdx이며, 이 모듈은 Pod·Deployment·ReplicaSet과 reconciliation을 다시 정의하지 않고 owner chain, 일회용 Pod identity와 controller 동작을 실행으로 검증합니다. M2에서 익힌 context·namespace guard와 get, logs, apply를 그대로 사용합니다.

2. 핵심 개념

선언한 상태가 Pod로 수렴하는 owner chain

flowchart TD
Manifest["Deployment spec: replicas + Pod template"] -->|apply| Deployment
Deployment -->|새 template마다 생성·조정| ReplicaSet
ReplicaSet -->|replica 수를 맞춤| PodA["Pod A"]
ReplicaSet -->|replica 수를 맞춤| PodB["Pod B"]
PodA -. "삭제됨" .-> Gap["현재 1 / 원하는 2"]
Gap -->|ReplicaSet controller 수렴| PodC["새 Pod C"]

객체	이 모듈에서 선언·관찰하는 상태	직접 다루는 경우	owner 확인
Deployment	replica 수와 Pod template	배포 의도·scale·template 변경	최상위 workload owner
ReplicaSet	한 Pod template의 원하는 Pod 수	보통 관찰만 함	ownerReferences[0]이 Deployment
Pod	실제 container가 실행되는 일회용 instance	log·상태·일시 진단	ownerReferences[0]이 ReplicaSet

변화	바뀌는 desired state	controller가 만드는 결과
관리 중인 Pod 하나 삭제	Deployment/ReplicaSet spec은 그대로	같은 template의 새 Pod가 다른 이름으로 생성
replicas: 2 → 3	기존 ReplicaSet의 desired replica가 3	Pod 한 개 추가
Pod template annotation 변경	Deployment의 template hash가 달라짐	새 ReplicaSet 생성, 이전 ReplicaSet replica 감소

Deployment의 숫자는 이름이 비슷해도 같은 질문에 답하지 않습니다. 수렴이 끝나면 모두 2처럼 보일 수 있으므로 전환 중 어떤 값이 먼저 움직이는지를 구분해야 합니다.

필드	desired/current	답하는 질문
spec.replicas	desired	사용자가 최종적으로 몇 개를 원한다고 선언했는가?
status.replicas	current	old·new ReplicaSet을 합쳐 현재 생성된 Pod가 몇 개인가?
status.updatedReplicas	current	현재 Pod template을 쓰는 Pod가 몇 개인가?
status.readyReplicas	current	Ready condition이 true인 Pod가 몇 개인가?
status.availableReplicas	current	최소 준비 시간 조건까지 만족해 가용하다고 판정된 Pod가 몇 개인가?

Pod 이름은 실행 instance의 identity이고 Deployment 이름은 지속되는 배포 의도입니다. ReplicaSet 이름과 Pod 이름에 붙는 hash·suffix는 controller가 만든 변동값이므로 운영 자동화가 전체 이름에 의존하면 안 됩니다. label selector로 집합을 고르고 owner chain으로 책임 객체를 찾습니다.

시점 의존 설명은 2026-07-15에 다음 공식 1차 자료로 확인했습니다.

• Pods: Pod의 일회용성, controller를 통한 관리
• Deployments: replica와 Pod template 선언, rollout과 ReplicaSet 관리
• ReplicaSet: selector에 맞는 Pod 수 유지와 Deployment 사용 권장
• kubectl rollout status: rollout 완료 상태 관찰
• Labels and selectors: 느슨하게 결합된 객체 집합 선택

3. 직관 비유

개념	비유	비유의 경계
Pod	교대 가능한 작업자 한 명과 그날의 이름표	사람과 달리 내부 상태를 보존한 채 교체되는 존재가 아닙니다.
ReplicaSet	특정 업무 지시서를 받은 작업자 수를 맞추는 반장	새 업무 지시서 버전과 배포 순서까지 직접 관리하지는 않습니다.
Deployment	인원수와 새 업무 지시서 전환 계획을 가진 책임자	application 데이터·DB migration까지 되돌리는 관리자는 아닙니다.
selector	같은 업무 표식을 가진 작업자 집합을 고르는 조건	물리 node나 namespace 자체를 선택하는 조건은 아닙니다.

4. 핸즈온 랩

검증 환경

항목	검증값
기준일	2026-07-15
host	macOS arm64
Docker client / engine	29.6.1 / 29.6.1
k3d	5.9.0
K3s image / API server	rancher/k3s:v1.36.2-k3s1 / v1.36.2+k3s1
kubectl	1.36.1
Helm	4.2.3 — 이 모듈에서는 사용하지 않음
container image	busybox:1.37.0 + Setup의 고정 multi-platform digest
evidence 환경	local-cluster; 고정 context + k8s-wb-m3-<UTC run ID>

모든 실행 명령 묶음은 executed-local입니다. k3d의 controller 수렴 결과를 NKS 성능·가용성 실측으로 표현하지 않습니다. 실제 NKS workload 변경은 승인된 non-production 환경이 없으므로 official-doc-only이며 실제 kubeconfig, namespace, registry와 Secret을 사용하지 않습니다.

사전 조건

• 저장소 root에서 실행하며 M0~M2를 완료한 상태여야 합니다.
• Docker Desktop과 M2의 cs-study-workbook cluster가 실행 중이어야 합니다.
• 모든 API 명령은 --context k3d-cs-study-workbook과 고유 namespace를 명시합니다.
• fixture의 terminationGracePeriodSeconds: 3은 랩 시간을 줄이기 위한 local 값입니다. 실제 예시 서비스의 종료 유예 시간은 application의 SIGTERM 처리 시간을 측정해 M9에서 결정합니다.
• 실제 image update, probe, rollback과 무중단 판정은 M9에서 다룹니다. 여기서는 Pod template annotation만 바꿔 새 ReplicaSet이 생기는 객체 관계를 관찰합니다.
• 예상 소요 시간은 95분입니다.

Setup

고유 namespace에 Deployment 적용하기

preflight와 exact context guard를 먼저 통과한 뒤 replica 2개의 fixture Deployment를 적용합니다. template.metadata.labels는 selector.matchLabels의 모든 조건을 만족해야 하며, selector와 무관한 추가 label을 가질 수 있습니다.

set -euo pipefail
rm -rf /tmp/k8s-wb-m3
mkdir -p /tmp/k8s-wb-m3
node automation/k8s-workbook/preflight.mjs --require-cluster
test "$(kubectl config current-context)" = "k3d-cs-study-workbook"
NS="k8s-wb-m3-$(date -u +%Y%m%d%H%M%S)"
printf '%s' "$NS" > /tmp/k8s-wb-m3/namespace
if kubectl --context k3d-cs-study-workbook get namespace "$NS" >/dev/null 2>&1; then
  echo "namespace collision: $NS" >&2
  exit 1
fi
kubectl --context k3d-cs-study-workbook create namespace "$NS"
kubectl --context k3d-cs-study-workbook -n "$NS" apply -f - <<'YAML'
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      terminationGracePeriodSeconds: 3
      containers:
        - name: app
          image: busybox:1.37.0@sha256:9532d8c39891ca2ecde4d30d7710e01fb739c87a8b9299685c63704296b16028
          imagePullPolicy: IfNotPresent
          command: ["sh", "-c"]
          args:
            - |
              echo "READY version=v1 pod=$(hostname)"
              while true; do sleep 30; done
YAML
if ! kubectl --context k3d-cs-study-workbook -n "$NS" \
  rollout status deployment/web-app --timeout=90s \
  > /tmp/k8s-wb-m3/setup-rollout.log 2>&1; then
  cat /tmp/k8s-wb-m3/setup-rollout.log
  exit 1
fi
echo 'deployment=web-app rolled-out=2/2'

예상 출력:

PASS platform: darwin/arm64
PASS architecture: arm64
PASS docker-cli: v29.6.1
PASS docker-engine: v29.6.1
PASS k3d: v5.9.0
PASS kubectl-skew: v1.36.1
PASS helm: v4.2.3
PASS context: k3d-cs-study-workbook
PASS kubernetes-server: v1.36.2+k3s1
namespace/k8s-wb-m3-<UTC 14자리 run ID> created
deployment.apps/web-app created
deployment=web-app rolled-out=2/2

host architecture, Docker patch version과 namespace run ID는 변동 필드입니다. image를 처음 받는 node에서는 rollout 대기 시간이 늘어날 수 있지만 90초 안에 replica 2개가 수렴해야 다음 단계로 진행합니다.

Lab 1 — owner chain을 실제 이름으로 따라가기

Deployment의 상태, 그 Deployment가 소유한 ReplicaSet, ReplicaSet이 소유한 Pod를 차례로 출력합니다. hash와 suffix는 실행마다 달라질 수 있습니다.

set -euo pipefail
test "$(kubectl config current-context)" = "k3d-cs-study-workbook"
NS="$(cat /tmp/k8s-wb-m3/namespace)"
kubectl --context k3d-cs-study-workbook -n "$NS" get deployment web-app \
  -o jsonpath='deployment={.metadata.name} desired={.spec.replicas} current={.status.replicas} updated={.status.updatedReplicas} ready={.status.readyReplicas} available={.status.availableReplicas}{"\n"}'
kubectl --context k3d-cs-study-workbook -n "$NS" get replicaset \
  -l app=web-app \
  -o jsonpath='{range .items[*]}replicaset={.metadata.name} desired={.spec.replicas} owner={.metadata.ownerReferences[0].name}{"\n"}{end}' \
  | sort
kubectl --context k3d-cs-study-workbook -n "$NS" get pod \
  -l app=web-app \
  -o jsonpath='{range .items[*]}pod={.metadata.name} owner={.metadata.ownerReferences[0].name} phase={.status.phase}{"\n"}{end}' \
  | sort

예상 출력:

deployment=web-app desired=2 current=2 updated=2 ready=2 available=2
replicaset=web-app-<template hash> desired=2 owner=web-app
pod=web-app-<template hash>-<suffix> owner=web-app-<template hash> phase=Running
pod=web-app-<template hash>-<suffix> owner=web-app-<template hash> phase=Running

template hash, 두 Pod suffix와 출력 순서는 변동 필드입니다. 이 출력은 rollout 완료 후라 다섯 숫자가 모두 2지만 desired는 spec의 목표이고 나머지는 controller가 보고한 current status입니다. 이름의 공통 접두어가 아니라 ownerReferences가 실제 소유 관계의 근거입니다.

Lab 2 — Pod 하나를 삭제하고 자동 대체 관찰하기

삭제 전 Pod 이름 집합을 저장하고, 삭제 후 집합과 비교해 새로 생긴 Pod를 식별합니다. 기존 두 번째 Pod를 새 Pod로 잘못 세지 않도록 단순히 “삭제한 이름이 아닌 것”만 고르지 않습니다.

set -euo pipefail
test "$(kubectl config current-context)" = "k3d-cs-study-workbook"
NS="$(cat /tmp/k8s-wb-m3/namespace)"
BEFORE=/tmp/k8s-wb-m3/pods-before
AFTER=/tmp/k8s-wb-m3/pods-after
kubectl --context k3d-cs-study-workbook -n "$NS" get pod \
  -l app=web-app \
  -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{end}' \
  | sort > "$BEFORE"
OLD_POD="$(awk 'NR == 1' "$BEFORE")"
printf '%s' "$OLD_POD" > /tmp/k8s-wb-m3/deleted-pod
kubectl --context k3d-cs-study-workbook -n "$NS" \
  delete pod "$OLD_POD" --wait=true
attempt=1
NEW_POD=''
while test "$attempt" -le 30; do
  kubectl --context k3d-cs-study-workbook -n "$NS" get pod \
    -l app=web-app \
    -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{end}' \
    | sort > "$AFTER"
  COUNT="$(wc -l < "$AFTER" | tr -d ' ')"
  READY="$(kubectl --context k3d-cs-study-workbook -n "$NS" get pod \
    -l app=web-app \
    -o jsonpath='{range .items[*]}{.status.containerStatuses[0].ready}{"\n"}{end}' \
    | awk '$0 == "true" { count++ } END { print count+0 }')"
  NEW_POD="$(comm -13 "$BEFORE" "$AFTER" | awk 'NR == 1')"
  if test "$COUNT" = 2 && test "$READY" = 2 && test -n "$NEW_POD"; then
    break
  fi
  sleep 1
  attempt=$((attempt + 1))
done
test "$COUNT" = 2
test "$READY" = 2
test -n "$NEW_POD"
printf '%s' "$NEW_POD" > /tmp/k8s-wb-m3/replacement-pod
echo "deleted=${OLD_POD}"
echo "replacement=${NEW_POD} ready=${READY}/2"

예상 출력:

pod "web-app-<template hash>-<옛 suffix>" deleted from k8s-wb-m3-<UTC 14자리 run ID> namespace
deleted=web-app-<template hash>-<옛 suffix>
replacement=web-app-<template hash>-<새 suffix> ready=2/2

namespace, hash, 옛·새 suffix와 교체 시간은 변동 필드입니다. Deployment나 ReplicaSet을 다시 apply하지 않았는데도 새 Pod가 생긴 것이 reconciliation의 관찰 증거입니다.

Lab 3 — 옛 Pod identity가 사라졌음을 실패로 확인하기

삭제한 Pod 이름으로 log를 다시 요청합니다. 이 명령은 실제 exit code 1로 실패해야 합니다.

NS="$(cat /tmp/k8s-wb-m3/namespace)"
OLD_POD="$(cat /tmp/k8s-wb-m3/deleted-pod)"
kubectl --context k3d-cs-study-workbook -n "$NS" logs "$OLD_POD"

예상 출력과 exit code:

error: error from server (NotFound): pods "web-app-<template hash>-<옛 suffix>" not found in namespace "k8s-wb-m3-<UTC 14자리 run ID>"
exit code: 1

NotFound는 application 전체가 사라졌다는 뜻이 아니라, 그 일회용 Pod identity가 더 이상 없다는 뜻입니다. Deployment와 label로 현재 Pod 집합을 다시 찾아야 합니다.

Lab 4 — 새 Pod를 찾아 log로 복구 확인하기

집합 차이로 찾은 replacement Pod의 stdout을 확인합니다.

set -euo pipefail
test "$(kubectl config current-context)" = "k3d-cs-study-workbook"
NS="$(cat /tmp/k8s-wb-m3/namespace)"
NEW_POD="$(cat /tmp/k8s-wb-m3/replacement-pod)"
kubectl --context k3d-cs-study-workbook -n "$NS" logs "$NEW_POD"

예상 출력:

READY version=v1 pod=web-app-<template hash>-<새 suffix>

Pod 이름은 변동 필드이며 version=v1은 실제 application version이 아닌 실습용 fixture 값입니다.

Lab 5 — Deployment replica를 2에서 3으로 늘리기

Pod나 ReplicaSet을 직접 수정하지 않고 Deployment의 desired replica를 바꿉니다. 이 수동 scale은 HPA·KEDA가 판단하는 자동 scale과 다르며 자동화 계층은 M8에서 다룹니다.

set -euo pipefail
test "$(kubectl config current-context)" = "k3d-cs-study-workbook"
NS="$(cat /tmp/k8s-wb-m3/namespace)"
kubectl --context k3d-cs-study-workbook -n "$NS" \
  scale deployment/web-app --replicas=3
if ! kubectl --context k3d-cs-study-workbook -n "$NS" \
  rollout status deployment/web-app --timeout=90s \
  > /tmp/k8s-wb-m3/scale-rollout.log 2>&1; then
  cat /tmp/k8s-wb-m3/scale-rollout.log
  exit 1
fi
kubectl --context k3d-cs-study-workbook -n "$NS" get deployment web-app \
  -o jsonpath='deployment={.metadata.name} desired={.spec.replicas} ready={.status.readyReplicas}{"\n"}'
kubectl --context k3d-cs-study-workbook -n "$NS" get replicaset \
  -l app=web-app \
  -o jsonpath='{range .items[*]}replicaset={.metadata.name} desired={.spec.replicas}{"\n"}{end}' \
  | sort

예상 출력:

deployment.apps/web-app scaled
deployment=web-app desired=3 ready=3
replicaset=web-app-<template hash> desired=3

template hash와 Pod 준비 시간은 변동 필드입니다. 기존 ReplicaSet의 desired 수가 3으로 바뀌고 Pod가 한 개 추가되며, 이 단계에서는 새 ReplicaSet이 생기지 않습니다.

Lab 6 — Pod template 변경과 새 ReplicaSet 관찰하기

Pod template annotation을 v2로 바꾸면 container bytes가 같아도 template hash가 달라져 새 ReplicaSet이 생깁니다. annotation은 객체 관계를 관찰하기 위한 fixture marker이며 application version이나 배포 승인 증거가 아닙니다.

set -euo pipefail
test "$(kubectl config current-context)" = "k3d-cs-study-workbook"
NS="$(cat /tmp/k8s-wb-m3/namespace)"
BEFORE_RS="$(kubectl --context k3d-cs-study-workbook -n "$NS" get replicaset \
  -l app=web-app --no-headers | wc -l | tr -d ' ')"
test "$BEFORE_RS" = 1
kubectl --context k3d-cs-study-workbook -n "$NS" patch deployment web-app \
  --type=merge \
  -p '{"spec":{"template":{"metadata":{"annotations":{"workbook.cs-study/version":"v2"}}}}}'
kubectl --context k3d-cs-study-workbook -n "$NS" \
  rollout status deployment/web-app --timeout=90s
VERSION="$(kubectl --context k3d-cs-study-workbook -n "$NS" \
  get deployment web-app \
  -o jsonpath='{.spec.template.metadata.annotations.workbook\.cs-study/version}')"
READY="$(kubectl --context k3d-cs-study-workbook -n "$NS" \
  get deployment web-app -o jsonpath='{.status.readyReplicas}')"
RS_COUNT="$(kubectl --context k3d-cs-study-workbook -n "$NS" \
  get replicaset -l app=web-app --no-headers | wc -l | tr -d ' ')"
test "$VERSION" = v2
test "$READY" = 3
test "$RS_COUNT" = 2
echo "template-version=${VERSION} deployment-ready=${READY}/3 replicasets=${RS_COUNT}"
kubectl --context k3d-cs-study-workbook -n "$NS" get replicaset \
  -l app=web-app \
  -o jsonpath='{range .items[*]}replicaset={.metadata.name} desired={.spec.replicas} owner={.metadata.ownerReferences[0].name}{"\n"}{end}' \
  | sort

예상 출력:

deployment.apps/web-app patched
Waiting for deployment "web-app" rollout to finish: <0개 이상의 수렴 상태 줄>
deployment "web-app" successfully rolled out
template-version=v2 deployment-ready=3/3 replicasets=2
replicaset=web-app-<이전 template hash> desired=0 owner=web-app
replicaset=web-app-<새 template hash> desired=3 owner=web-app

Waiting 줄의 개수·순서, 두 template hash와 완료 시간은 변동 필드입니다. 이 결과는 새 ReplicaSet으로 수렴했다는 증거이지, 요청 무중단·application readiness·DB 호환성을 입증하지 않습니다.

Cleanup

M3의 고유 namespace를 삭제하면 그 안의 Deployment, ReplicaSet과 Pod도 함께 제거됩니다. M4~M12가 사용할 공용 local cluster는 유지합니다.

set -euo pipefail
test "$(kubectl config current-context)" = "k3d-cs-study-workbook"
NS="$(cat /tmp/k8s-wb-m3/namespace)"
kubectl --context k3d-cs-study-workbook delete namespace "$NS" --wait=true \
  >/dev/null
if kubectl --context k3d-cs-study-workbook get namespace "$NS" >/dev/null 2>&1; then
  echo 'namespace still exists' >&2
  exit 1
fi
rm -rf /tmp/k8s-wb-m3
test ! -e /tmp/k8s-wb-m3
test "$(kubectl config current-context)" = "k3d-cs-study-workbook"
echo 'cleanup=namespace:0,deployment:0,replicaset:0,pod:0,fixture:absent,cluster:retained'

예상 출력:

cleanup=namespace:0,deployment:0,replicaset:0,pod:0,fixture:absent,cluster:retained

cluster:retained는 의도된 공용 기반입니다. module이 만든 API object와 local fixture는 0개여야 합니다.

5. 관찰 포인트

실행 뒤	실제로 보는 변화	운영 판단
초기 apply	Deployment 1 → ReplicaSet 1 → Pod 2	지속 의도는 Deployment에 있고 Pod 이름은 결과입니다.
Pod 하나 삭제	옛 Pod 소멸, 다른 suffix의 새 Pod 생성	직접 Pod 재생성 없이 owner의 desired state가 복구했습니다.
옛 Pod의 logs	NotFound, exit code 1	label로 현재 집합을 찾고 owner chain부터 다시 확인합니다.
replicas=3	같은 ReplicaSet desired 2→3, Pod 한 개 추가	수동 scale의 source는 Deployment입니다.
Pod template annotation 변경	ReplicaSet 1→2, 이전 0·새 3으로 수렴	template 변경과 단순 replica 변경의 결과가 다릅니다.
namespace cleanup	M3 workload object 0, 공용 cluster 유지	다음 모듈은 새 namespace에서 시작합니다.

6. 셀프체크 Q&A

Q1. api-service Pod 하나가 사라졌고 새 Pod가 자동 생성됐습니다. AI가 옛 Pod 이름으로 계속 진단하려 하면 무엇을 바꿔야 할까요?

옛 Pod 이름은 폐기하고 label로 현재 Pod 집합을 다시 조회합니다. 새 Pod의 ownerReferences를 Pod→ReplicaSet→Deployment 순서로 확인한 뒤 새 identity의 Events와 logs를 봅니다. 지속적인 수정은 Pod가 아니라 최상위 Deployment spec에 반영합니다.

Q2. 운영자가 Deployment를 3개로 수동 scale했는데 Git의 선언은 2개입니다. 무엇을 정상 상태로 승인해야 할까요?

즉시 어느 값이 정본인지 결정해야 합니다. GitOps가 owner라면 다음 sync가 2개로 되돌릴 수 있으므로 live 3개만 보고 정상이라 승인하면 안 됩니다. 긴급 scale의 승인·만료 조건을 기록하고 선언 원본도 의도에 맞게 갱신해야 합니다. HPA가 있는 환경의 replica ownership은 M8에서 추가로 판단합니다.

Q3. 이 랩에서 rollout successfully rolled out을 봤으니 NKS 무중단 배포가 증명됐다고 말할 수 있을까요?

말할 수 없습니다. 이 fixture에는 Service 트래픽, readiness probe, 실제 요청, 종료 중 요청 drain과 DB migration이 없습니다. 여기서 증명한 것은 새 Pod template의 ReplicaSet이 desired 3개로 수렴했다는 사실뿐입니다. 무중단 승인 근거는 M9에서 별도로 측정합니다.

7. 흔한 함정

함정 1. Pod를 배포 의도의 정본으로 수정하기

관리 중인 Pod를 직접 고쳐도 교체되면 변경이 사라지고 Deployment template과 drift가 납니다. owner chain을 확인하고 최상위 controller의 선언 원본을 수정합니다.

함정 2. selector와 Pod label을 따로 변경하기

Deployment template labels가 selector 조건을 모두 만족하지 않으면 API가 Deployment 적용을 거부합니다. 반대로 별도 workload의 selector가 같은 label 범위와 겹치면 서로의 Pod를 세거나 관리하려는 충돌이 생길 수 있습니다. 추가 label은 허용되지만 AI가 만든 diff에서는 selector가 어느 Pod 집합까지 포함하는지 함께 검토합니다.

함정 3. Running과 rollout 완료를 application 정상으로 해석하기

container가 시작됐다는 사실과 실제 요청 처리 가능성은 다릅니다. Service, probe, log와 실제 요청 관찰이 없는 이 모듈의 결과로 무중단이나 business readiness를 승인하지 않습니다.

관리형 NKS에서는 control plane·etcd·CNI 내부 구현과 Terraform 작성은 제외합니다. 실제 production Deployment 변경, registry·Secret 사용과 node 장애 실험은 수행하지 않습니다.

8. 다음 모듈 연결 고리

M4에서는 교체되어 IP와 이름이 바뀌는 Pod 집합 앞에 Service와 cluster DNS를 두고, Ingress가 외부 HTTP 요청을 어떤 경로로 전달하는지 관찰합니다.