← 메인으로 돌아가기

🌐 EKS를 둘러싼 네트워크

Docker to K8s 네트워크 아키텍처 구성

📅 2025년 10월 4일 👥 인프라 엔지니어, DevOps 엔지니어 📊 중급 ⏱️ 45분

📖 배경 및 동기

🎯 이 자료가 만들어진 이유

실제 Docker에서 EKS로 마이그레이션 프로젝트를 진행하면서 아키텍처 다이어그램을 그리는 과정에서 여러 시행착오를 겪었습니다. 특히 ALB의 위치, VPC 서비스 구분, HA 구성 등에서 혼란이 있었고, 이런 과정을 통해 얻은 인사이트를 공유하고자 합니다.

🔹 프로젝트 진행 과정

  1. Docker 컨테이너 실습 → 기본 컨테이너 이해
  2. EKS 클러스터 구축 → Kubernetes 환경 구성
  3. 아키텍처 설계 → 네트워크 구조 고민 (현재 단계)
  4. HA 구성 적용 → 실제 운영 환경 준비

🔹 주요 혼란 포인트들

🎯 학습 목표

📁 K8s 설정 진화 과정 비교

🔄 Docker Compose → Kubernetes 변화

🔹 초기 상태 (Docker Compose)

# docker-compose.yml
version: '3.8'
services:
  postgres:
    image: postgres:15
    # ❌ 단일 컨테이너, 재시작 시 데이터 손실
  
  redis:
    image: redis:7-alpine
    # ❌ 단일 컨테이너, 메모리 데이터만
  
  backend:
    build: ./backend
    # ❌ 단일 컨테이너, 로드밸런싱 없음

🔹 최종 상태 (Kubernetes HA)

infrastructure/k8s/
├── namespace.yaml                    # 네임스페이스 분리
├── postgres-deployment.yaml         # StatefulSet + Anti-Affinity
├── redis-statefulset.yaml           # StatefulSet + Anti-Affinity  
├── backend-deployment.yaml          # Deployment + Topology Spread
├── backend-service.yaml             # LoadBalancer Service
└── ingress.yaml                     # ALB Ingress

🎯 단계별 진화 과정

🔹 1단계: 기본 변환

# ❌ 기존: docker-compose.yml (1개 파일)
services:
  postgres: ...
  redis: ...
  backend: ...

# ✅ 변환: K8s manifests (6개 파일)
postgres-deployment.yaml  # Deployment
backend-deployment.yaml   # Deployment  
backend-service.yaml      # Service

🔹 2단계: HA 구성 적용

# ❌ 문제: 단일 인스턴스
spec:
  replicas: 1

# ✅ 해결: Multi-AZ 분산
spec:
  replicas: 2
  affinity:
    podAntiAffinity: ...

🔹 3단계: 상태 관리 개선

# ❌ 문제: Deployment (Stateless)
kind: Deployment

# ✅ 해결: StatefulSet (Stateful)
kind: StatefulSet
volumeClaimTemplates: ...

🔹 4단계: 외부 접근 설정

# ❌ 문제: 외부 접근 불가
type: ClusterIP

# ✅ 해결: ALB Ingress 추가
kind: Ingress
annotations:
  alb.ingress.kubernetes.io/scheme: internet-facing

📊 설정 복잡도 변화

단계 파일 수 설정 복잡도 가용성 확장성
Docker Compose 1개 낮음 ⭐ 낮음 ❌ 낮음 ❌
기본 K8s 3개 중간 ⭐⭐ 중간 ⚠️ 중간 ⚠️
HA K8s 6개 높음 ⭐⭐⭐ 높음 ✅ 높음 ✅

🔧 각 파일의 역할 변화

PostgreSQL 진화

Deployment → StatefulSet
replicas: 1 → replicas: 2
(없음) → podAntiAffinity
(없음) → volumeClaimTemplates

Redis 진화

(없음) → redis-statefulset.yaml
(없음) → replicas: 2
(없음) → podAntiAffinity
(없음) → persistence 설정

FastAPI 진화

Deployment → Deployment (유지)
replicas: 2 → replicas: 2 (유지)
(없음) → topologySpreadConstraints
(없음) → REDIS_URL 환경변수

🏗️ 아키텍처 설계의 진화 과정

📋 설계 과정 개요

실제 EduStack 프로젝트에서 아키텍처 다이어그램을 그리면서 v02부터 v10까지 9번의 수정을 거쳤습니다. 각 버전마다 발견한 문제점과 개선 과정을 단계별로 살펴보겠습니다.

💡 v01은 너무 엉망이라 보이지도 않고, v05는 버전 관리 실수로 빈 파일입니다 😅

🔹 설계 시작점 - 기본 요구사항

✅ 요구사항
- 기존 S3 정적 사이트 유지 (/aiseminar/*)
- 새로운 동적 API 추가 (/api/edustack/*)
- CloudFront로 통합 라우팅
- EKS에서 FastAPI + PostgreSQL + Redis 운영
- 고가용성(HA) 구성

🔹 시행착오의 연속 (v02-v04)

v02: "일단 그려보자" 🤔

EduStack 아키텍처 v02

첫 시도: 기본적인 구조는 있지만 뭔가 부족해...

😅 이때의 고민: "ALB가 어디에 있어야 하지? VPC 안? 밖?"

v03: "뭔가 더 추가해야겠어" 🔧

EduStack 아키텍처 v03

조금 더 구체화했지만 여전히 혼란스러운 상태

🤷‍♂️ 이때의 고민: "서브넷 구조가 맞나? Pod는 어떻게 배치하지?"

v04: "다시 정리해보자" 📝

EduStack 아키텍처 v04

조금씩 나아지고 있지만 아직 완성도가...

💡 깨달음: "체계적으로 접근해야겠다. 하나씩 차근차근!"

🔹 체계적 설계 시작 (v06)

v06: 기본 구조 확립

EduStack 아키텍처 v06

드디어 체계적인 구조가 잡히기 시작!

사용자 → CloudFront → ALB → EKS Pods
                  → S3 (정적 콘텐츠)

⚠️ v06에서 발견한 문제점들

  • ALB 위치 애매: 퍼블릭 서브넷에 제대로 배치되지 않음
  • Pod 배치 불균형: HA 구성이 아닌 단일 장애점 존재
  • 네트워크 경계 불분명: VPC 내부/외부 서비스 구분 모호
  • NAT Gateway 누락: 프라이빗 서브넷 아웃바운드 고려 안됨

🔹 중간 개선 (v07-v09) - 점진적 수정

v07: 네트워크 흐름 분석 및 ALB 배치 개선

VPC 서비스 구분의 중요성을 깨달음:

VPC 외부 서비스 (글로벌/리전):

VPC 내부 서비스 (VPC 종속):

트래픽 라우팅 경로 명확화:

정적 콘텐츠: 사용자 → Internet → WAF → CloudFront → S3
동적 API: 사용자 → Internet → WAF → CloudFront → VPC → ALB → EKS Pods

v08: ALB Multi-AZ 구조 명확화 및 보안 계층 설계

네트워크 보안 계층:

  1. WAF: DDoS 및 웹 공격 차단
  2. CloudFront: 지리적 분산 및 캐싱
  3. ALB: L7 로드밸런싱 및 SSL 종료
  4. Security Groups: 포트 및 프로토콜 제어

v09: Pod HA 배치 구현

기존 문제점:

Private Subnet 1: FastAPI + PostgreSQL
Private Subnet 2: FastAPI + Redis

HA 구성 해결책:

Private Subnet 1 (AZ-2a): FastAPI + PostgreSQL + Redis
Private Subnet 2 (AZ-2c): FastAPI + PostgreSQL + Redis

HA 설계 원칙:

  1. Multi-AZ 배치: 모든 서비스를 여러 AZ에 분산
  2. 무상태 설계: FastAPI는 상태를 저장하지 않음
  3. 데이터 복제: PostgreSQL과 Redis 클러스터링
  4. 로드밸런싱: ALB가 트래픽을 균등 분산

🔹 단계별 개선 과정 (v07-v10)

v07: ALB 퍼블릭 서브넷 배치

EduStack 아키텍처 v07

ALB와 NAT Gateway를 퍼블릭 서브넷에 올바르게 배치

✅ 개선사항: ALB가 퍼블릭 서브넷 1, 2에 각각 배치되고 NAT Gateway도 추가됨

v08: ALB Multi-AZ 구조 명확화

EduStack 아키텍처 v08

ALB를 단일 논리적 엔티티로 표현하면서 Multi-AZ 노드 표시

✅ 개선사항: ALB의 실제 동작 방식(논리적 단일 + 물리적 Multi-AZ)을 정확히 표현

v09: Pod HA 배치 구현

EduStack 아키텍처 v09

각 AZ에 동일한 Pod 구성으로 진정한 HA 달성

✅ 개선사항:
  • Private Subnet 1: FastAPI + PostgreSQL + Redis
  • Private Subnet 2: FastAPI + PostgreSQL + Redis
  • 단일 장애점 완전 제거

v10: VPC 경계 명확화 (최종)

EduStack 아키텍처 v10 - 최종

🎉 완성! VPC 내부/외부 서비스가 명확히 구분된 최종 아키텍처

🎯 최종 완성:
  • VPC 외부: S3, CloudFront, WAF (글로벌 서비스)
  • VPC 내부: ALB, NAT Gateway, EKS (VPC 종속 서비스)
  • 완벽한 HA 구성: Multi-AZ 배치 + Pod Anti-Affinity
🌐 VPC 외부: S3, CloudFront, WAF
🏠 VPC 내부: ALB, NAT Gateway, EKS

🌐 네트워크 흐름 분석

🔹 VPC 서비스 구분의 중요성

VPC 외부 서비스 (글로벌/리전)

VPC 내부 서비스 (VPC 종속)

🔹 트래픽 라우팅 경로

정적 콘텐츠 경로

사용자 → Internet → WAF → CloudFront → S3

동적 API 경로

사용자 → Internet → WAF → CloudFront → VPC → ALB → EKS Pods

🔹 네트워크 보안 계층

  1. WAF: DDoS 및 웹 공격 차단
  2. CloudFront: 지리적 분산 및 캐싱
  3. ALB: L7 로드밸런싱 및 SSL 종료
  4. Security Groups: 포트 및 프로토콜 제어

🔄 HA 구성 설계

🔹 기존 문제점 (v08 이전)

Private Subnet 1: FastAPI + PostgreSQL
Private Subnet 2: FastAPI + Redis
  • PostgreSQL 단일 장애점
  • Redis 단일 장애점

🔹 HA 구성 (v09-v10)

Private Subnet 1 (AZ-2a): FastAPI + PostgreSQL + Redis
Private Subnet 2 (AZ-2c): FastAPI + PostgreSQL + Redis

🔹 HA 설계 원칙

  1. Multi-AZ 배치: 모든 서비스를 여러 AZ에 분산
  2. 무상태 설계: FastAPI는 상태를 저장하지 않음
  3. 데이터 복제: PostgreSQL과 Redis 클러스터링
  4. 로드밸런싱: ALB가 트래픽을 균등 분산

⚙️ Kubernetes 설정 변경

🤔 Pod Anti-Affinity가 왜 필요한가?

🔹 용어 이해: Affinity란?

🔹 현재 문제 상황

# 현재 상태 확인
kubectl get pods -o wide
# 결과: 모든 Pod가 같은 노드에 몰려있음
장애 시나리오:
AZ-2a 장애 발생 → 모든 PostgreSQL Pod 다운 → 서비스 전체 중단 💥

🔹 Anti-Affinity 해결책

📁 실무 적용 가이드

🤔 StatefulSet vs Deployment 이해하기

🔹 용어 분해: StatefulSet
🔹 상태(State)란?
🔹 언제 뭘 사용하나?
📱 FastAPI (웹 서버)     → Deployment (Stateless)
   "요청 처리만 하고 끝, 메모리에 저장 안 함"

💾 PostgreSQL (데이터베이스) → StatefulSet (Stateful)  
   "데이터 파일 저장, 순서대로 시작/종료 필요"

🗄️ Redis (캐시)         → StatefulSet (Stateful)
   "메모리 데이터 보존 필요"

🔹 파일 구조 확인

# edustack 프로젝트 구조
infrastructure/k8s/
├── namespace.yaml
├── postgres-deployment.yaml    # ← 이 파일을 수정
├── backend-deployment.yaml     # ← 이 파일을 수정  
└── backend-service.yaml

🔹 적용 순서

  1. PostgreSQL: postgres-deployment.yaml → StatefulSet으로 변경 ✅
  2. Redis: redis-statefulset.yaml 새로 생성 ← 현재 단계
  3. FastAPI: backend-deployment.yaml에 Topology Spread 추가
  4. 테스트: 로컬 → 서버 순서로 배포

🤔 PostgreSQL StatefulSet 변경 완료

📁 파일 위치: infrastructure/k8s/postgres-deployment.yaml
🔹 변경 전 (Deployment)
apiVersion: apps/v1
kind: Deployment          # ❌ Stateless
metadata:
  name: postgres
spec:
  replicas: 1             # ❌ 단일 인스턴스
  selector:
    matchLabels:
      app: postgres
  template:
    spec:
      # ❌ Anti-Affinity 없음
      containers:
      - name: postgres
        image: postgres:15
        # ❌ 영구 스토리지 없음
🔹 변경 후 (StatefulSet)
apiVersion: apps/v1
kind: StatefulSet         # ✅ Stateful
metadata:
  name: postgres
spec:
  serviceName: postgres   # ✅ StatefulSet 필수
  replicas: 2             # ✅ HA 구성
  selector:
    matchLabels:
      app: postgres
  template:
    spec:
      affinity:           # ✅ Anti-Affinity 추가
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - postgres
            topologyKey: topology.kubernetes.io/zone
      containers:
      - name: postgres
        image: postgres:15
        volumeMounts:     # ✅ 영구 스토리지
        - name: postgres-storage
          mountPath: /var/lib/postgresql/data
  volumeClaimTemplates:   # ✅ 각 Pod마다 독립 스토리지
  - metadata:
      name: postgres-storage
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 10Gi

🤔 Redis StatefulSet 새로 생성 완료

📁 파일 위치: infrastructure/k8s/redis-statefulset.yaml (새 파일)
🔹 생성된 Redis StatefulSet
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: redis
  namespace: edustack
spec:
  serviceName: redis
  replicas: 2             # ✅ HA 구성
  template:
    spec:
      affinity:           # ✅ Anti-Affinity
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - redis
            topologyKey: topology.kubernetes.io/zone
      containers:
      - name: redis
        image: redis:7-alpine
        command: ["redis-server"]
        args: ["--appendonly", "yes"]  # ✅ 데이터 영속성
        volumeMounts:
        - name: redis-storage
          mountPath: /data
        resources:          # ✅ 리소스 제한
          requests:
            memory: "256Mi"
            cpu: "100m"
          limits:
            memory: "512Mi"
            cpu: "200m"
  volumeClaimTemplates:     # ✅ 영구 스토리지
  - metadata:
      name: redis-storage
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 5Gi

🤔 Redis가 왜 필요한가?

사용자 로그인 → 세션 정보를 Redis에 저장
API 응답 → 자주 조회되는 데이터를 Redis에 캐시

🤔 FastAPI Topology Spread Constraints가 왜 필요한가?

Anti-Affinity: "절대 같은 곳에 있으면 안 돼!" (엄격함)
Topology Spread: "가능하면 고르게 분산해줘" (유연함)

🤔 Ingress가 왜 필요한가?

🔹 Service vs Ingress 차이점
Service (ClusterIP): 클러스터 내부에서만 접근 가능
  postgres:5432 ← FastAPI에서만 접근

Ingress: 외부 인터넷에서 접근 가능  
  https://your-domain.com/api → FastAPI로 라우팅
🔹 왜 ALB Ingress를 사용하나?

🤔 ALB Ingress 구현 완료

📁 파일 위치: infrastructure/k8s/ingress.yaml (새 파일)
🔹 생성된 ALB Ingress
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: edustack-ingress
  namespace: edustack
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing  # ✅ 외부 접근
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/ssl-redirect: '443'      # ✅ HTTPS 강제
    alb.ingress.kubernetes.io/healthcheck-path: /health # ✅ 헬스체크
spec:
  rules:
  - http:
      paths:
      - path: /api/edustack          # ✅ API 경로 라우팅
        pathType: Prefix
        backend:
          service:
            name: edustack-backend-service
            port:
              number: 80
      - path: /health                # ✅ 헬스체크 엔드포인트
        pathType: Exact
        backend:
          service:
            name: edustack-backend-service
            port:
              number: 80
🎯 트래픽 흐름:
인터넷 → ALB → FastAPI Service → FastAPI Pod (2개)
https://your-domain.com/api/edustack → 자동 로드밸런싱

🤔 FastAPI Topology Spread Constraints 적용 완료

📁 파일 위치: infrastructure/k8s/backend-deployment.yaml
🔹 변경 전 (기본 Deployment)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: edustack-backend
spec:
  replicas: 2             # ❌ 적은 인스턴스
  template:
    spec:
      # ❌ 분산 정책 없음 → 한 곳에 몰릴 수 있음
      containers:
      - name: backend
        env:
        - name: DATABASE_URL
          value: "postgresql://..."
        # ❌ Redis 연결 없음
🔹 변경 후 (Topology Spread)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: edustack-backend
spec:
  replicas: 2             # ✅ 적절한 인스턴스 수
  template:
    spec:
      topologySpreadConstraints:  # ✅ 균등 분산 정책
      - maxSkew: 1              # ✅ AZ간 최대 1개 차이
        topologyKey: topology.kubernetes.io/zone
        whenUnsatisfiable: DoNotSchedule
        labelSelector:
          matchLabels:
            app: edustack-backend
      - maxSkew: 1              # ✅ 노드간 분산
        topologyKey: kubernetes.io/hostname
        whenUnsatisfiable: ScheduleAnyway
        labelSelector:
          matchLabels:
            app: edustack-backend
      containers:
      - name: backend
        env:
        - name: DATABASE_URL
          value: "postgresql://..."
        - name: REDIS_URL       # ✅ Redis 연결 추가
          value: "redis://redis:6379"
🎯 분산 결과:
2개 Pod → 2개 AZ → 각 AZ마다 1개씩 균등 배치
AZ-2a: [Pod1] | AZ-2c: [Pod2]

🚨 실무 팁과 함정

🔹 흔한 설계 실수들

1. ALB 위치 오해

❌ 잘못된 인식: ALB는 VPC 외부 서비스
✅ 올바른 이해: ALB는 VPC 내부, 퍼블릭 서브넷에 배치

2. 단일 AZ 배치

❌ 위험한 구성: 모든 Pod를 하나의 AZ에 배치
✅ 안전한 구성: Multi-AZ에 균등 분산

🎯 핵심 요약

🔹 설계 원칙

  1. 명확한 경계: VPC 내부/외부 서비스 구분
  2. HA 구성: Multi-AZ 배치 필수
  3. 보안 계층: 다중 보안 장치 적용
  4. 확장성: Auto Scaling 고려

🔹 구현 체크리스트 (단계별 가이드)

1️⃣ 네트워크 아키텍처 설계

  • ALB를 퍼블릭 서브넷에 배치
    💡 ALB는 VPC 내부 서비스입니다. 인터넷에서 접근 가능하려면 퍼블릭 서브넷에 있어야 해요.
  • NAT Gateway를 각 AZ의 퍼블릭 서브넷에 배치
    💡 프라이빗 서브넷의 Pod들이 인터넷에 나가려면 NAT Gateway가 필요합니다.
  • 워커 노드를 프라이빗 서브넷에 배치
    💡 보안을 위해 실제 애플리케이션은 프라이빗 서브넷에서 실행합니다.

2️⃣ Kubernetes HA 구성

  • Pod Anti-Affinity 설정
    💡 같은 종류의 Pod가 다른 AZ에 배치되도록 강제합니다. 한 AZ가 죽어도 서비스 계속 가능!
    topologyKey: topology.kubernetes.io/zone  # AZ별로 분산
  • Topology Spread Constraints 적용
    💡 Pod들이 AZ 간에 균등하게 분산되도록 합니다. 한쪽에 몰리는 것을 방지!
    maxSkew: 1  # AZ 간 Pod 개수 차이를 1개 이하로 제한
  • StatefulSet으로 상태 저장 서비스 관리
    💡 PostgreSQL, Redis 같은 데이터베이스는 StatefulSet을 사용해야 데이터가 안전합니다.

3️⃣ 서비스 연결 설정

  • 적절한 Service 타입 선택
    💡 내부 통신은 ClusterIP, 외부 노출은 ALB Ingress를 사용하세요.
    예시:
    • PostgreSQL → ClusterIP (내부에서만 접근)
    • FastAPI → ClusterIP + ALB Ingress (외부 노출)
  • ALB Ingress에 퍼블릭 서브넷 지정
    💡 annotations에서 subnets을 퍼블릭 서브넷 ID로 설정해야 합니다.
    alb.ingress.kubernetes.io/subnets: subnet-xxx,subnet-yyy

4️⃣ 보안 설정

  • 보안 그룹 최소 권한 원칙
    💡 필요한 포트만 열고, 출발지도 명확히 지정하세요.
    예시:
    • ALB SG: 80, 443 포트만 0.0.0.0/0에서 허용
    • Worker SG: ALB SG에서만 트래픽 허용
    • DB SG: Worker SG에서만 5432 포트 허용

🔹 검증 방법

# 1. Pod가 다른 AZ에 분산되었는지 확인
kubectl get pods -o wide

# 2. ALB가 정상 동작하는지 확인
kubectl get ingress
kubectl describe ingress edustack-ingress

# 3. 서비스 간 통신 테스트
kubectl exec -it fastapi-pod -- curl postgresql-service:5432

# 4. HA 테스트 (한 AZ 장애 시뮬레이션)
kubectl cordon node-in-az-2a
kubectl get pods -o wide  # 다른 AZ로 이동했는지 확인

🔹 다음 단계

🔹 상용 환경 고려사항 (Pro Tips 🚀)

💼 실제 프로덕션에서는 관리형 서비스 권장

이 가이드에서는 학습 목적으로 PostgreSQL과 Redis를 Pod로 운영했지만, 실제 상용 서비스에서는 AWS 관리형 서비스 사용을 강력히 권장합니다!

🔄 권장 아키텍처 (Production Ready)
EKS 클러스터 (애플리케이션만)
├── FastAPI Pods (Stateless)
└── 관리형 서비스 연결
    ├── RDS PostgreSQL (Multi-AZ)
    └── ElastiCache Redis (Cluster Mode)
✅ 관리형 서비스의 장점
  • 자동 백업 & 복구: AWS가 알아서 백업하고 장애 시 복구
  • 자동 패치: 보안 업데이트를 AWS가 관리
  • 모니터링 내장: CloudWatch 메트릭 자동 수집
  • 확장성: 트래픽에 따라 자동 스케일링
  • 고가용성: Multi-AZ 자동 장애조치
  • 운영 부담 감소: DB 관리에 신경 쓸 필요 없음
🏗️ 실제 구현 예시
# RDS PostgreSQL 연결
DATABASE_URL=postgresql://username:password@rds-endpoint.region.rds.amazonaws.com:5432/dbname

# ElastiCache Redis 연결  
REDIS_URL=redis://elasticache-endpoint.cache.amazonaws.com:6379

# FastAPI 환경변수 설정
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  DATABASE_URL: "postgresql://username:password@prod-db.region.rds.amazonaws.com:5432/edustack"
  REDIS_URL: "redis://prod-cache.cache.amazonaws.com:6379"
💰 비용 vs 안정성 트레이드오프
구분 Pod 방식 관리형 서비스
비용 💰 저렴 (컴퓨팅만) 💰💰 비쌈 (관리 비용 포함)
안정성 ⚠️ 직접 관리 필요 ✅ AWS가 보장
운영 부담 😰 높음 (백업, 패치, 모니터링) 😌 낮음 (AWS가 처리)
추천 환경 🧪 개발/테스트 🚀 프로덕션
💡 실무 팁: 스타트업이라면 처음엔 Pod로 시작해서 비용을 절약하고, 서비스가 성장하면서 점진적으로 관리형 서비스로 마이그레이션하는 전략도 좋습니다!

🎉 축하합니다!

이제 여러분은 실제 운영 환경에서 사용할 수 있는 HA Kubernetes 아키텍처를 설계할 수 있습니다. 이 과정에서 겪은 시행착오들이 실무에서 큰 도움이 될 것입니다!

배경 및 동기 학습 목표 아키텍처 진화 네트워크 흐름 HA 구성 K8s 설정 실무 팁 핵심 요약
🏠