pile·
인프라 / DevOps·LG U+LG U+·

종료했는데 왜 502·504가 날까? K8s 무중단 배포를 위한 팁

Amazon EKS 환경에서 무중단 배포(Rolling Update/Blue-Green)를 적용했음에도 간헐적으로 502 Bad Gateway·504 Gateway Timeout이 발생하는 근본 원인과 해결책을 다룬다. ALB·K8s·Istio·Argo Rollouts의 종료 시퀀스가 어긋나는 타이밍 문제가 핵심이며, terminationGracePeriodSeconds·preStop hook·ALB deregistration_delay 세 축을 정렬해 해결한다.

핵심 포인트
  • 502는 ALB가 종료 중인 Pod로 트래픽을 계속 보내다 TCP RST를 받을 때, 504는 ALB idle timeout 내에 응답을 못 받을 때 발생한다.
  • readinessGate 미주입이 핵심 함정 — ALB Target 상태 변화와 K8s Endpoint 제거가 어긋나 Terminating Pod로 신규 요청이 유입된다.
  • preStop hook에 sleep 30을 넣어 ALB deregistration_delay(30초)와 타이밍을 정렬하는 것이 가장 효과적인 기본 처방이다.
  • terminationGracePeriodSeconds는 preStop 시간 + graceful shutdown 시간 + 여유를 포함해야 한다. 기본값(30초)은 실제 종료 흐름에 부족한 경우가 많다.
  • Spring Boot의 keep-alive-timeout을 ALB idle timeout보다 짧게 설정해야 연결 먼저 끊는 쪽(앱)과 나중에 끊는 쪽(ALB) 불일치로 인한 502를 예방한다.
  • Istio 사이드카는 terminationDrainDuration 미설정 시 앱보다 먼저 종료돼 트래픽이 누락된다.
상세 정리
  • 502 원인 5가지: Target TCP RST 응답, 예상치 못한 네트워크 에러, 연결 중 Target 종료, deregistration delay 초과, 잘못된 응답 형식(헤더 32KB 초과 포함)
  • 504 원인 5가지: 연결 타임아웃(10초 내 수립 실패), 응답 타임아웃(idle timeout 초과), Security Group/NACL 임시 포트 차단, Content-Length 불일치, SSL 핸드셰이크 타임아웃
  • 종료 시퀀스 6단계: API Server deletionTimestamp 설정 → EndpointSlice 업데이트 & ALB deregistration 시작 → kubelet preStop hook 실행 → SIGTERM 전달(앱 graceful shutdown) → Istio Envoy drain → Pod 최종 종료
  • ALB와 Pod 종료 플로우는 거의 동시에 시작된다. 기본 ALB drain은 300초, Pod terminationGracePeriodSeconds는 30초라 크게 어긋난다 — deregistration_delay=30, terminationGracePeriodSeconds=60으로 정렬이 핵심
  • K8s 설정 권장값: terminationGracePeriodSeconds=60, preStop exec sleep 30, readinessProbe failureThreshold=1(빠른 실패 감지로 신규 요청 차단 앞당김)
  • ALB Ingress 설정: deregistration_delay.timeout_seconds=30, healthcheck-interval-seconds=15, unhealthy-threshold-count=2
  • Spring Boot 설정: server.shutdown=graceful, tomcat.keep-alive-timeout=15s(ALB idle timeout보다 짧게), lifecycle.timeout-per-shutdown-phase=30s, management.endpoint.health.probes.enabled=true
  • Istio 환경 필수: namespace label로 readinessGate 주입 — 미주입 시 ALB Target 상태와 K8s readiness가 따로 놀아 Terminating Pod에 신규 요청 유입
  • 트러블슈팅 3건: Istio readinessGate 미주입(ALB-K8s 상태 불일치), Argo Rollouts Blue-Green(이전 버전 Pod drain 시간 부족), Connection Keep-Alive 불일치(앱이 ALB보다 먼저 연결 종료)
왜 읽나Amazon EKS + ALB 환경에서 무중단 배포 중 502/504를 경험한 DevOps·백엔드 엔지니어에게 종료 시퀀스 전체를 정리하고 실제 설정값을 바로 적용할 수 있는 체크리스트를 제공한다.
LG U+
LG U+ 블로그
원문은 여기서 이어서 읽을 수 있어요
원문 읽기
읽음 (0)

이 글과 비슷한

  1. 인프라 / DevOps·AWS KoreaAWS Korea Tech·

    엔터프라이즈 보안 요구사항을 충족하는 프라이빗 Amazon Bedrock AgentCore 구축하기

    Amazon Bedrock AgentCore의 VPC egress 기능(2026년 4월 추가)을 활용해 온프레미스 LLM·사내 IdP·사내 MCP 서버에 인터넷 노출 없이 연결하는 방법을 다룬다. 규제 산업 엔터프라이즈가 기존 사내 자산을 그대로 유지하면서 Bedrock AgentCore를 안전하게 구축하기 위한 구성 가이드다.

    요약 이어보기
    #mcp#amazon-bedrock#vpc+2
  2. 인프라 / DevOps·gitlab-engGitLab Blog·

    OpenTofu와 Argo CD로 구성하는 GitLab 기반 AWS 제어 플레인

    GitLab을 단일 제어 플레인으로 삼아 OpenTofu로 AWS 인프라를 프로비저닝하고, Argo CD로 GitOps 기반 애플리케이션 배포까지 자동화하는 엔드투엔드 튜토리얼이다. VPC·EKS 클러스터 구성부터 Helm 기반 툴 설치, 샘플 앱 배포까지 모든 과정이 GitLab CI/CD 파이프라인으로 연결된다.

    요약 이어보기
    #kubernetes#aws-eks#gitops+2
  3. 인프라 / DevOps·AWS KoreaAWS Korea Tech·

    Amazon Bedrock 기반 사내 LLM, 키 발급부터 비용 차단까지: F&F의 LiteLLM 게이트웨이 운영 사례

    패션 기업 F&F가 Amazon Bedrock과 LiteLLM 프록시를 결합해 구축한 사내 LLM 플랫폼 운영 사례다. API 키 셀프서비스 발급, 모델별 접근 승인 워크플로, 사용자·프로젝트별 예산 자동 차단까지 전 과정을 직접 구현한 아키텍처 결정과 운영 교훈을 공유한다.

    요약 이어보기
    #kubernetes#amazon-bedrock#litellm+2