Notice
Recent Posts
Recent Comments
Link
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 |
Tags
- aws
- SRE
- web
- frontend
- architecture
- observability
- DevOps
- Ops
- Infra
- react
- PostgreSQL
- Git
- HTTP
- backend
- auth
- JavaScript
- 버전관리
- Performance
- version-control
- CI
- CSS
- API
- 성능
- database
- NextJS
- Debugging
- Security
- Operations
- reliability
- Kubernetes
Archives
- Today
- Total
고민보단 실천을
Kubernetes Ingress 실전: TLS, path rewrite, timeout 설정에서 자주 터지는 문제 본문
카테고리 없음
Kubernetes Ingress 실전: TLS, path rewrite, timeout 설정에서 자주 터지는 문제
Just-Do-It 2026. 3. 27. 14:59Kubernetes Ingress 실전: TLS, path rewrite, timeout 설정에서 자주 터지는 문제
Ingress는 '라우팅 설정' 같지만, 실제로는 운영 사고의 시작점이 되기 쉽습니다.
TLS, rewrite, timeout, body size에서 자주 터지는 포인트를 체크리스트로 정리합니다.
이 글의 목표는 '개념 정리'보다, "어떤 기준으로 결정할지"와 "어떻게 운영에서 사고를 줄일지"를 남기는 것입니다.
왜 이게 어려운가(운영 관점)
운영 이슈는 대부분 한 설정이 아니라 '정렬되지 않은 설정 조합'에서 나옵니다(타임아웃, 종료, 리소스, 재시도).
따라서 증상 -> 원인 -> 검증 루틴을 팀 표준으로 만들면, 장애 대응 시간이 크게 줄어듭니다.
실전 내용(바로 적용)
Ingress는 '라우팅 설정' 같지만, 실제로는 운영 사고의 시작점이 되기 쉽습니다.
TLS, rewrite, timeout, body size에서 자주 터지는 포인트를 체크리스트로 정리합니다.
핵심 요약(결론부터)
- 기준(정책)을 먼저 정하고, 구현/도구는 그 다음에 선택한다
- 실패/예외/회귀를 운영 체크리스트로 막는다
- 공식 문서를 최종 근거로 삼고, 팀 문서로 재가공한다
자주 터지는 증상
- 301/308 리다이렉트 루프
- 업로드 413
- 간헐적 504
- 특정 경로만 404
운영 기준
Ingress 변경은 작은 단위로, 로그/지표를 함께 본다
timeout은 애플리케이션/프록시/클라이언트와 정렬한다
Ingress에서 자주 보는 설정(개념)
proxy-read-timeout
proxy-send-timeout
client-max-body-size
rewrite-target운영 체크리스트(바로 적용)
- TLS 종료 위치(ingress/lb)를 명확히 한다
- body size 제한과 업로드 UX를 합의한다
- 업스트림 타임아웃과 서버 타임아웃을 정렬한다
FAQ
Q. 왜 특정 경로만 404가 나나요?
A. 대부분 pathType/정규식/rewrite 설정 때문에 발생합니다. Ingress 컨트롤러 로그로 실제 라우팅 결과를 확인하는 게 빠릅니다.
마무리: 다음 액션
- 팀의 기본값(정책)을 1페이지로 문서화한다
- 대표 시나리오 1개를 코드/설정 예시로 고정한다
- 배포 전후 지표(p95/p99, 오류율)를 비교해 효과를 확인한다
자주 하는 실수(사고 패턴)
- 증상만 보고 timeout/limit을 크게 늘려 원인을 숨긴다
- 프로브/스케일/리소스를 따로따로 튜닝해 전체 QoS가 흔들린다
- 변경 후 효과를 지표로 검증하지 않아 회귀가 반복된다
- 운영 자동화(CI/CD)에서 권한/보안 경계를 느슨하게 둔다
적용 순서(추천)
- 1) 지표로 증상을 고립한다(오류율/지연/재시도율/리소스)
- 2) 타임아웃을 레이어별로 정렬한다(client > proxy > server > db)
- 3) 스케일(파드/노드)과 워밍업(readiness)을 같이 설계한다
- 4) 변경은 작게/단계적으로 하고, 알람/롤백을 같이 준비한다
- 5) 운영 기준을 문서로 고정하고, 체크리스트로 반복 가능하게 만든다
검증/회귀 방지
- 재현: 스파이크/롤링업데이트/대용량 업다운로드 같은 시나리오를 고정
- 로그: upstream time, 종료 이벤트, 재시도 횟수 같은 필드를 고정
- 알람: OOMKilled, throttling, 5xx burst, p99 spike를 조기 경보로 운영
팀 합의 템플릿(복붙용)
# 장애 대응 템플릿(복붙용)
증상: (오류율/지연/시점/영향 범위)
가설: (타임아웃/리소스/종료/프록시/코드)
검증: (재현/로그/지표 링크)
조치: (설정 변경/배포/롤백)
재발 방지: (알람/체크리스트/문서)FAQ
Q. 왜 특정 경로만 404가 나나요?
A. 대부분 pathType/정규식/rewrite 설정 때문에 발생합니다. Ingress 컨트롤러 로그로 실제 라우팅 결과를 확인하는 게 빠릅니다.
참고/출처
버전/환경에 따라 동작이 달라질 수 있으니, 최종 기준은 공식 문서를 확인합니다.
Comments
