query timeout이 gateway 재시작을 만들었습니다

9월 19일에는 플랫폼 의존성을 업데이트하고 Loki 조회 장애를 복구했습니다. 당시 gateway의 kubelet probe가 backend 조회 API를 호출하고 있어, 조회 지연이 gateway 재시작과 Service endpoint 감소로 확대되었습니다. 반대로 read Pod 하나는 /ready가 200인데 실제 query가 계속 timeout인 상태였습니다.

같은 HTTP probe를 모든 계층에 적용하는 대신 Nginx gateway의 생존과 Loki 조회 가능성을 나눴습니다. gateway는 Nginx 자체의 가벼운 / 응답을 확인하고, 실제 /loki/api/v1/labels 경로는 Blackbox Exporter로 별도 감시합니다. 종단 probe 실패는 경보를 만들지만 gateway를 재시작하지 않습니다.

고착된 read Pod에는 충분히 느린 liveness를 둡니다

아래는 read Pod의 probe 구조를 보여주는 예제입니다. 포트와 threshold는 동작을 설명하기 위한 예제 값입니다.

YAML
readinessProbe:
  httpGet:
    path: /ready
    port: 3100
  timeoutSeconds: 5
livenessProbe:
  httpGet:
    path: /loki/api/v1/labels
    port: 3100
  periodSeconds: 30
  timeoutSeconds: 10
  failureThreshold: 6

readiness는 가벼운 준비 상태를 유지하고 liveness는 반복된 조회 실패를 확인합니다. 짧은 외부 저장소 지연이 모든 read Pod의 재시작으로 번지지 않도록 여러 번의 연속 실패를 요구합니다. 이는 실제 구성의 의도를 축약한 예제이며 모든 Loki 배포에 그대로 적용할 권장값은 아닙니다.

Grafana의 Loki 로그 규칙에는 execErrState=KeepLast를 적용했습니다. 데이터소스 조회 실패를 실제 애플리케이션 오류나 커널 장애로 오인하지 않도록 마지막 평가 상태를 유지하고, 데이터소스 장애는 메트릭 기반 종단 probe가 별도로 알립니다.

오래된 OpenEBS migration hook도 확인했습니다

플랫폼 점검에서는 이미 새 Kubernetes 버전이 적용된 상태에서 관련 차트와 도구의 호환성을 확인했습니다. OpenEBS가 이미 v4인 환경에는 v3에서 v4로 이전하는 hook이 필요하지 않았고, 그 hook의 오래된 kubectl도 현재 API 서버와의 지원 범위를 벗어났습니다.

YAML
# OpenEBS values의 선택한 항목입니다.
preUpgradeHook:
  enabled: false

모든 upgrade hook을 비활성화하는 일반 규칙이 아니라, 완료된 이전 작업과 해당 차트의 hook 목적을 확인한 뒤 선택한 변경입니다.

복구 후에는 각 read Pod의 직접 조회와 gateway 경유 조회를 반복하고, 실제 알림 LogQL 실행과 새 Pod의 재시작 여부를 확인했습니다. 이 과정에서 node-exporter의 steal time과 Alloy의 kernel journal 수집도 별도 관측으로 정리했습니다. 조회 장애와 호스트 자원 경쟁을 하나의 원인으로 단정하지 않았습니다.