Post

Kubernetes/GKE 배포 체크리스트

K8s/GKE에서 네트워크·상태·확장·장애 가정을 검증하고 Helm/HPA/프로브로 운영 신뢰성을 확보하는 배포 가이드

Posted
Preview Image
By okorion
9 min read 게시글 조회수
Kubernetes/GKE 배포 체크리스트

이 글의 결론: K8s/GKE는 기능을 추가하는 도구가 아니라 설계가 운영에서도 성립하는지 검증하는 환경이다.

배포는 YAML을 적용하는 행위가 아니라, 네트워크·상태·확장·장애가 설계 의도대로 동작하는지 확인하는 과정이다. 이 글은 로컬 K8s에서 GKE까지 반드시 확인해야 할 최소 항목만 고정한다.

로컬 Kubernetes에서 확인해야 할 것 결론: 로컬은 “문제 재현기”다.

네트워킹

  • Service(DNS)로 서비스 디스커버리가 되는가
  • Pod IP 변경에도 통신이 유지되는가

환경변수

  • ConfigMap 변경이 재배포 없이 반영되는지
  • 환경별 설정 분리가 되는지(dev/stage/prod)

시크릿

  • Secret이 이미지/리포지토리에 절대 포함되지 않는지
  • 로그에 노출되지 않는지

로컬에서 안 되는 것은 클러스터에서 절대 안 된다.

Kafka/Postgres를 K8s에 올리는 의미 결론: 상태ful 워크로드는 “운영 부담”을 K8s로 옮기는 선택이다.

  • StatefulSet, PV/PVC, 디스크 성능, 백업/복구까지 고려 필요
  • Pod 재시작 = 상태 안정성 시험

의미:

  • 장점: 환경 통합, 자동화
  • 단점: 운영 난이도 상승

결론: 학습/검증용은 OK, 프로덕션은 Managed 서비스와 비교해야 한다.

Helm으로 Kafka를 배포하는 이유 결론: Helm은 편의가 아니라 재현성과 표준화 도구다.

  • values.yaml로 설정을 코드화
  • 동일 설정을 로컬/스테이징/프로덕션에 재현
  • 롤백 가능

Helm이 없으면:

  • “이번엔 왜 다르지?”를 설명할 방법이 없다.

GKE 배포 흐름 결론: 배포는 선형 파이프라인이어야 한다.

1
2
3
4
5
6

코드 변경
 → 이미지 빌드
   → 레지스트리 푸시
     → Deployment 적용
       → Pod 기동
         → Readiness 통과

핵심 확인:

  • 이미지 태그가 불변인가
  • 클러스터가 최신 이미지를 실제로 받았는가
  • 적용 후 롤백 가능한가

HPA가 의미 있는 조건 결론: CPU는 조건이지, 답이 아니다.

CPU만으로 충분한 경우

  • CPU-bound 작업
  • 요청당 계산 비용이 일정

한계가 드러나는 경우

  • 병목이 DB/Kafka
  • I/O 대기 중심 워크로드

대응:

  • HPA 전에 병목 지점 식별
  • DB/Kafka 확장성 고려 없으면 HPA는 착시

장애 대응 최소 체크 결론: Probe 설정이 곧 장애 전략이다.

readiness / liveness

  • readiness: 트래픽을 받아도 되는가
  • liveness: 재기동이 필요한가

롤링 업데이트 위험

  • readiness 늦음 → 트래픽 손실
  • 상태ful 서비스 → 동시 재기동 금지

규칙:

  • readiness 통과 전 트래픽 ❌
  • 롤링 중 최소 가용 Pod 수 보장

리소스별 핵심 표 결론: “목적–실수–검증”을 고정하라.

리소스목적실수 포인트검증 방법
Deployment무상태 앱 배포이미지 태그 재사용Pod 이미지 확인
Service내부 통신포트/셀렉터 불일치DNS 접근 테스트
ConfigMap설정 분리코드에 하드코딩변경 반영 확인
Secret민감정보로그 노출마스킹 여부
HPA자동 확장병목 미고려부하 테스트

흔한 오해 / 실수 3가지

  1. Kubernetes를 “배포 도구”로만 보는 오해
    • 문제: kubectl apply가 되면 끝이라고 판단
    • 결과: 장애·확장·재기동 시 설계 가정 붕괴
    • 교정 기준: K8s는 운영 검증 환경이다. 설계의 약점이 반드시 드러난다.
  2. HPA를 켜면 자동으로 확장 문제가 해결된다는 착각
    • 문제: CPU 기준 HPA만 설정
    • 결과: 병목이 DB/Kafka일 때 스케일만 늘고 장애는 심화
    • 교정 기준: HPA는 병목이 애플리케이션일 때만 의미 있다.
  3. readiness/liveness를 형식적으로 넣는 실수
    • 문제: 단순 HTTP 200 체크
    • 결과: 준비 안 된 Pod로 트래픽 유입, 롤링 중 장애
    • 교정 기준: readiness는 “업무 처리 가능 여부”를 판단해야 한다.

대표 실패 시나리오 3가지

  1. 롤링 업데이트 중 트래픽 손실
    • 상황: 새 Pod가 기동되자마자 트래픽 유입
    • 원인: readiness 통과 조건 부정확
    • 결과: 초기 요청 실패, 오류율 급증
    • 대응: 의존 서비스/Kafka 연결 완료 후 readiness 통과
  2. 상태ful 워크로드 재기동 후 데이터 손실
    • 상황: Kafka/Postgres Pod 재시작
    • 원인: PV/PVC 설정 부실 또는 로컬 디스크 사용
    • 결과: 메시지/데이터 유실
    • 대응: 영속 볼륨 검증 + 재기동 시나리오 사전 테스트
  3. 확장은 됐지만 처리량은 늘지 않는 경우
    • 상황: HPA로 Pod 수 증가
    • 원인: 병목이 DB/Kafka/네트워크
    • 결과: 리소스 낭비, 지연 증가
    • 대응: 병목 계측 후 확장 대상 재설정

실무 체크리스트 (K8s/GKE 배포 검증)

  1. 로컬 K8s에서 서비스 디스커버리가 정상 동작하는가
  2. ConfigMap/Secret이 코드·이미지에 포함되지 않았는가
  3. 환경별 설정(dev/stage/prod)이 분리돼 있는가
  4. Kafka/Postgres의 영속성 설정이 검증됐는가
  5. Helm values로 배포 설정이 재현 가능한가
  6. 이미지 태그가 불변이며 롤백 가능한가
  7. Deployment 적용 후 실제 Pod 이미지가 갱신됐는가
  8. readiness가 “업무 가능 상태”를 정확히 반영하는가
  9. liveness가 불필요한 재기동을 유발하지 않는가
  10. 롤링 업데이트 중 최소 가용 Pod 수가 보장되는가
  11. HPA 트리거가 병목 지점과 일치하는가
  12. DB/Kafka 지표를 함께 모니터링하는가
  13. 장애 시 자동 재기동이 의도대로 동작하는가
  14. 재기동이 데이터/이벤트 유실을 유발하지 않는가
  15. 배포 실패 시 즉시 롤백 가능한가
  16. 로그/메트릭/트레이싱이 연동돼 있는가
  17. 권한(RBAC)이 최소 권한 원칙을 지키는가
  18. 상태ful 서비스의 재기동을 제한하고 있는가
  19. “지금 장애 나면 무엇부터 볼지”가 합의돼 있는가
  20. 로컬 K8s에서 동일 장애를 재현할 수 있는가
🧭 MSA Playbook
Kubernetes GKE Deployment Observability
This post is licensed under CC BY 4.0 by the author.