Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#1,696 1 comentario 0 reacciones 0 asignados Ver en GitHub

@caiconkhicon ya está trabajando en esto.

Desde el 9/10/2026.

  • #1698 de @caiconkhicon — abierto

Evaluación

Dificultad
3/5
Tiempo estimado
Medio día
Aptitud para principiantes
62/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
go, kubernetes
Área
devops

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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
Lenguaje dominante
Go
Estrellas
88
Forks
69
Merge medio
3 d 3 h
PR fusionados (30 d)
1

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de pulp/pulp-operator

Todos los issues de pulp/pulp-operator

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.