본문으로 건너뛰기

Traefik Zot Blob 푸시 시간 초과

이 페이지는 Traefik을 통해 실패한 Zot에 대한 대규모 OCI 업로드에 대한 troubleshooting 문서입니다. 정상 수신 및 레지스트리 계약은 인프라 네트워킹 Traefik 및 인프라 GitOps Zot 참조 페이지에 있습니다.

증상

https://zot.lumie-infra.com에 대한 대규모 푸시는 특히 멀티 기가바이트 계층에서 도중에 실패하며 Traefik 또는 클라이언트는 HTTP 499와 같은 연결 끊김을 보고합니다.

수정 사항을 생성한 사건은 report-svc에서 대략 1.2GB 크롬 레이어를 밀어서 발생했습니다.

가능한 원인

k3s 번들 Traefik 애드온은 여전히 짧은 진입점 시간 초과를 사용하므로 Traefik은 Zot가 Blob을 MinIO로 스트리밍하는 것을 마치기 전에 대기를 중지합니다.

이것은 Zot 전용 설정값이 아닙니다. webwebsecure 진입점 시간 초과는 클러스터 전체에 적용됩니다.

수정

ca6c511fplatform/traefik-config/argocd.yamlplatform/traefik-config/helmchartconfig.yaml를 추가하여 저장소가 제한된 업로드 친화적 시간 제한을 사용하여 번들 애드온을 패치합니다.

ports:
web:
transport:
respondingTimeouts:
readTimeout: 1200s
writeTimeout: 1200s
idleTimeout: 600s

websecure에도 동일한 값이 적용됩니다.

0는 의도적으로 readTimeout에 사용되지 않았습니다. 시간 초과를 완전히 비활성화하면 해당 진입점의 모든 수신에 대한 슬로우 바디 및 슬로우로리스 보호도 제거되기 때문입니다.

진단 경로

  1. platform/kustomization.yaml를 검사하여 traefik-config/argocd.yaml를 등록하는지 확인합니다.
  2. platform/traefik-config/helmchartconfig.yaml를 검사하고 webwebsecure가 모두 readTimeoutwriteTimeout1200s로 설정하고 idleTimeout600s로 설정했는지 확인합니다.
  3. 클러스터 액세스가 가능한 경우 kube-system에서 라이브 HelmChartConfig를 검사하고 푸시를 재현하는 동안 Traefik 로그를 확인합니다.

예방

  • 예상되는 가장 큰 Blob과 예상되는 가장 느린 MinIO 지원 업로드 경로에 대해 진입점 시간 제한을 충분히 크게 유지하십시오.
  • Traefik이 동일한 진입점에서 일반 웹 트래픽을 계속 제공하는 동안 비활성화되지 않고 값을 제한적으로 유지합니다.
  • Zot가 클러스터의 나머지 부분보다 더 느슨한 제한이 필요한 경우 기본 웹 진입점을 더 확장하는 대신 전용 레지스트리 전용 진입점으로 분할합니다.

확인

cd lumie-infra
rg -n "traefik-config/argocd.yaml|readTimeout: 1200s|writeTimeout: 1200s|idleTimeout: 600s" \
platform/kustomization.yaml \
platform/traefik-config/argocd.yaml \
platform/traefik-config/helmchartconfig.yaml
kubectl get helmchartconfig -n kube-system traefik -o yaml
kubectl logs -n kube-system deploy/traefik

성공은 저장소와 라이브 HelmChartConfig 모두 제한된 시간 초과 패치를 표시하고 대규모 Zot 업로드가 더 이상 Traefik 레이어에서 조기에 종료되지 않음을 의미합니다.

운영 세부사항

구분되는 증상은 registry 자체가 건강해도 upload path가 실패한다는 점입니다. Zot는 요청을 받을 수 있지만, Traefik이 Zot와 MinIO가 blob write를 끝내기 전에 긴 body stream을 종료할 수 있습니다.

계층확인할 것실패 단서
Clientpush output과 layer size.auth 실패가 아니라 large layer 중 disconnect됩니다.
Traefikaccess log와 entrypoint timeout config.같은 시각에 499, timeout, early close가 보입니다.
Zotregistry log.upload는 시작하지만 complete blob을 받지 못합니다.
MinIOobject write latency 또는 error.느린 backing write가 Traefik 대기 시간을 늘립니다.

timeout은 shared entrypoint에 적용되므로 모든 변경은 platform-wide ingress 결정입니다.

복구 절차

  1. 실패한 layer size와 disconnect까지의 elapsed time을 캡처합니다.
  2. authentication 또는 repository permission 오류가 아닌지 확인합니다.
  3. live HelmChartConfigwebwebsecure 모두에 bounded timeout 값을 가지고 있는지 확인합니다.
  4. 작은 manifest push가 아니라 representative large layer로 재현합니다.
  5. bounded 값으로도 부족하면 shared entrypoint를 더 넓히기 전에 dedicated registry entrypoint를 검토합니다.

검증 증거

다음으로 사고를 닫습니다.

  • 이전에 실패한 layer size push가 성공합니다.
  • Traefik log에 해당 request의 early timeout이 없습니다.
  • Zot log에 blob completion이 보입니다.
  • live HelmChartConfig가 Git과 일치합니다.
  • 검증에 사용한 최대 layer size를 기록합니다.

피해야 할 패턴

  • security review 없이 shared entrypoint에 readTimeout: 0을 설정하는 것.
  • Traefik이 먼저 요청을 끊는데 Zot storage부터 디버깅하는 것.
  • timeout behavior 변경 후 작은 image push만으로 검증하는 것.
  • registry-specific workload를 해결하려고 dedicated entrypoint 검토 없이 모든 ingress timeout을 늘리는 것.