Kubernetes 프로덕션 클러스터: HA·보안·관측 체크리스트

프로덕션 K8s, 개발 환경과 다른 점

로컬 Minikube와 프로덕션 운영은 완전히 다른 문제입니다. 고가용성, 보안, 모니터링, 비용 최적화까지 고려해야 합니다.

관리형 vs 자체 구축

노드 그룹 설계

nodeGroups:
  - name: system
    instanceType: m5.large
    desiredCapacity: 3
    minSize: 3
    maxSize: 5

  - name: app-general
    instanceType: c5.2xlarge
    desiredCapacity: 3
    minSize: 2
    maxSize: 20
    spot: true  # 비용 절감

Pod Anti-Affinity (고가용성)

affinity:
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
    - labelSelector:
        matchLabels:
          app: my-app
      topologyKey: kubernetes.io/hostname
topologySpreadConstraints:
- maxSkew: 1
  topologyKey: topology.kubernetes.io/zone
  whenUnsatisfiable: DoNotSchedule

PodDisruptionBudget

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: my-app

리소스 설정 (필수)

resources:
  requests:
    cpu: "250m"
    memory: "256Mi"
  limits:
    cpu: "500m"
    memory: "512Mi"

requests와 limits를 반드시 설정하세요. 미설정 시 노이지 네이버 문제로 전체 노드 장애가 발생할 수 있습니다.

보안 강화

securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  fsGroup: 2000
containers:
- name: app
  securityContext:
    allowPrivilegeEscalation: false
    readOnlyRootFilesystem: true
    capabilities:
      drop: ["ALL"]

모니터링 스택

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install monitoring prometheus-community/kube-prometheus-stack \
  --namespace monitoring --create-namespace

필수 알람: 노드 CPU > 80%, 메모리 > 85%, Pod 재시작 > 5회/시간, PVC 사용률 > 80%

쿠버네티스 프로덕션 운영의 핵심은 자동화입니다. HPA, Cluster Autoscaler, GitOps로 셀프힐링 환경을 구축하세요.

노드 드레인·업그레이드 중 서비스가 끊길 때

프로덕션 클러스터에서 계획된 작업(노드 교체, 버전 업그레이드) 중 장애가 나는 원인은 대부분 설정 누락입니다.

원인

• 레플리카가 1개인 Deployment: 드레인 시 대체 Pod가 뜨기 전까지 서비스 공백
• PDB의 minAvailable이 레플리카 수와 같아 허용 중단(ALLOWED DISRUPTIONS)이 0 → 드레인이 무한 대기
• readinessProbe가 없어 준비되지 않은 새 Pod로 트래픽이 들어감
• 애플리케이션이 SIGTERM을 처리하지 않아 진행 중 요청이 끊김

재현·검증 명령

# 허용 중단이 0인 PDB 찾기
kubectl get pdb -A
# 드레인 시뮬레이션(실제 축출 없이 확인)
kubectl drain <node> --ignore-daemonsets --delete-emptydir-data --dry-run=server
# 레플리카 1개짜리 워크로드
kubectl get deploy -A -o jsonpath='{range .items[?(@.spec.replicas==1)]}{.metadata.namespace}/{.metadata.name}{"\n"}{end}'
# readinessProbe 누락 확인
kubectl get deploy <name> -o jsonpath='{.spec.template.spec.containers[*].readinessProbe}'

해결

• 사용자 트래픽을 받는 워크로드는 레플리카 2개 이상 + maxUnavailable: 1 형태의 PDB를 둡니다.
• readinessProbe와 terminationGracePeriodSeconds를 설정하고, 필요하면 preStop에 짧은 sleep을 넣어 로드밸런서에서 엔드포인트가 빠질 시간을 확보합니다.
• 버전 확인은 kubectl version을 사용합니다(--short 플래그는 최신 kubectl에서 제거됨).

재발 방지

• 위 점검을 정책 엔진(Kyverno, OPA Gatekeeper)의 규칙으로 만들어, 레플리카 1개·probe 누락 매니페스트를 배포 단계에서 경고하거나 거부합니다.

참고: 공식 문서

이 글에서 다루는 동작·설정·에러의 1차 출처는 다음 공식 문서입니다. 버전별 옵션과 정확한 동작은 여기서 확인하세요.

• Kubernetes 공식 문서

프로덕션 최소 요구

# 노드·PDB·버전 빠른 점검
kubectl get nodes -o wide
kubectl get pdb -A
kubectl version --short

보안 하드닝 (첫 주)

1. 익명 인증 비활성, RBAC 최소 권한
2. Pod Security Admission(restricted/baseline) 네임스페이스별 적용
3. 시크릿은 CSI Secrets Store / External Secrets
4. etcd·API 서버 감사 로그 활성화(관리형은 클라우드 감사와 연계)

참고 자료

• Kubernetes Production Checklist (커뮤니티)
• CIS Kubernetes Benchmark
• EKS Best Practices

자주 묻는 질문 (FAQ)

Q. 작은 팀도 자체 kubeadm이 나을까요?
대개 아닙니다. 관리형 컨트롤 플레인 비용이 운영 인력보다 저렴한 경우가 많습니다.

Q. 언제 멀티 클러스터로 가나요?
환경(dev/stage/prod) 분리·규제 격리가 필요할 때. 단일 클러스터 네임스페이스만으로 수년간 운영하는 팀도 많습니다.

검증 환경·편집자 주

• 검증 시점: 2026-09 (문서·CLI 플래그는 벤더 업데이트에 따라 달라질 수 있음)
• 명령어는 읽기 전용 조회 위주이며, 프로덕션 적용 전 스테이징에서 plan/dry-run을 권장합니다.
• 본문은 공식 문서 링크와 운영에서 반복되는 실패 패턴을 기준으로 편집 검토했습니다.

실무 적용 순서 (요약)

1. 현재 상태 측정(메트릭·비용·오류율) 없이 도구부터 바꾸지 말 것
2. 가장 작은 범위에서 변경 → 롤백 조건 명시
3. 체크리스트를 런북/티켓 템플릿에 옮겨 팀 공유
4. 한 달 뒤 지표로 효과 재평가 후 확대