Use /livez/ for the API liveness probe and a cheaper readiness probe
評価
調査の方向性
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.
索引モデルが issue の本文から書いたものです。
説明
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:
httpGetto<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:
- Database load. The load grows with the number of API replicas and the number of artifacts.
- 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 andfailureThresholdabove 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.pycommand, 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
- 主要言語
- Go
- スター
- 88
- フォーク
- 69
- 平均マージ
- 3日 3時間
- マージ済み PR（30日）
- 1
環境構築
- Dockerfile または Docker Compose ファイルあり
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
pulp/pulp-operator のほかの issue
-
settings.py flaps between reconciles: needsMigrationSetting depends on map iteration order対応中かも @fontaineajulien が 25 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
pulp/pulp-operator#1691 ·
-
Documentation for metadata signing (APT/RPM) removed but still relevant再び着手できるかも このイシューのプルリクエストはマージされずにクローズされました。 オープンIssue Triage-Needed
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
pulp/pulp-operator#1644 ·
-
Feature Triage-Needed
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
pulp/pulp-operator#1697 · リアクション 2 件 ·
-
Issue Triage-Needed
難易度 3/5 1〜2日 初心者へのやさしさ 74/100
pulp/pulp-operator#1685 ·
-
Feature Triage-Needed
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
pulp/pulp-operator#1682 ·
pulp/pulp-operator の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
microcks/microcks-cli#608 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
bug from-studio
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
esengine/DeepSeek-Reasonix#14868 ·
メンテナーはふだん 1 日以内に返信
-
Install notes print "Camunda REST API: https://" without a host when global.host is set対応中かも @irisfield が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
camunda/camunda-platform-helm#7790 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
wso2/agent-manager#2220 ·
メンテナーはふだん 1 日以内に返信
-
[Bug]: zot exits with code 0 when it can't start対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 80/100
project-zot/zot#4636 ·
メンテナーはふだん 1 日以内に返信