Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Use /livez/ for the API liveness probe and a cheaper readiness probe

Đang mở
  • Có gì không ổn?
#1,696 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

@caiconkhicon đang làm issue này rồi.

Từ ngày 9/10/2026.

  • #1698 của @caiconkhicon — đang mở

Đánh giá

Độ khó
3/5
Thời gian dự kiến
Nửa ngày
Mức phù hợp với người mới
62/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
go, kubernetes
Lĩnh vực
devops

Hướng nghiên cứu

The default probes are defined in controllers/deployment.go: the liveness httpGet and the readiness exec of /usr/bin/readyz.py, both pointing at api/v3/status/. Start there and change the liveness path to api/v3/livez/ with the existing timings, then decide the readiness timings or endpoint with a maintainer. Done means the defaults match the issue and the Pulp CR overrides still apply.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Feature Triage-Needed

Is your feature request related to a problem? Please describe.

The default API probes call /status/. This is the same in 2.0.0 and on main, in controllers/deployment.go:

  • Liveness: httpGet to <API_ROOT>api/v3/status/, every 20s, timeout 10s, failureThreshold: 10.
  • Readiness: exec /usr/bin/readyz.py <API_ROOT>api/v3/status/, every 10s, timeout 10s, failureThreshold: 1.

/status/ is not a light check. It runs some database queries, and with object storage it runs SUM(size) over all artifacts (pulp/pulpcore#8196). Because the probes call it on every API pod all the time, this causes two problems:

  1. Database load. The load grows with the number of API replicas and the number of artifacts.
  2. Restarts that do not help. When the database is slow, /status/ takes more than 10s, and the liveness probe restarts API pods that are healthy. A restart does not make the database faster, and requests in progress fail.

Describe the solution you'd like

  • Liveness: use <API_ROOT>api/v3/livez/. Since pulp/pulpcore#7721, /livez/ does not use the database, so it checks only that the API process answers. This is the correct check for a liveness probe.
  • Readiness: keep the database and Redis check, but make it cheaper. For example, call /status/ less often, with a longer timeout and failureThreshold above 1. Or add a light endpoint in pulpcore that checks only the database and Redis connections.

Describe alternatives you've considered

We override the probes in the Pulp CR (spec.api.livenessProbe, spec.api.readinessProbe):

  • Liveness: httpGet <API_ROOT>api/v3/livez/, with the default timings.
  • Readiness: the default readyz.py command, every 60s, timeout 30s, failureThreshold: 3.

This works for us, but every user of the defaults has the same problem.

Additional context

  • /status/ cost in pulpcore: pulp/pulpcore#8196
  • Similar aggregate in the telemetry task: pulp/pulpcore#7475
  • /livez/ without the database: pulp/pulpcore#7721
Ngôn ngữ chính
Go
Star
88
Fork
69
Merge trung bình
3 ngày 3 giờ
Pull request đã merge (30 ngày)
1

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của pulp/pulp-operator

Tất cả issue của pulp/pulp-operator

Issue tương tự

Thêm issue về Go

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.