[Feature] Add default liveness/readiness probes to the generated Robin Deployment
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 65/100
Research direction
The change is in internal/controller/redkey_robin.go, function buildDesiredRobinDeployment. Start by examining how the Robin container is built, particularly around the Ports/Resources block. Look at the existing override logic for SecurityContext/Resources from spec.robin.template to understand precedence. Write unit tests to verify default probes are added and user overrides work. Check drift detection in robinDeploymentNeedsUpdate to include probe fields. Ensure the dependent Robin health endpoint issue is resolved before merging.
Written by the indexing model from the issue text.
Description
Depends on: redkey-robin issue "Expose an HTTP health endpoint (
/healthz,/readyz) for Kubernetes probes". This issue should only be merged once Robin actually serves the health endpoint(s), otherwise the probes point to a non-existent endpoint and the kubelet will kill the pod in a crash loop.
Problem
The operator builds the Robin Deployment in buildDesiredRobinDeployment (internal/controller/redkey_robin.go) without any LivenessProbe or ReadinessProbe. A hung Robin is neither restarted nor flagged unless the user manually defines probes via spec.robin.template. This reduces resilience out of the box.
(The operator's own pod is unaffected — its manager already registers /healthz and /readyz and its Deployment defines probes. This issue is specifically about the Robin pod that the operator generates.)
Proposed solution
In buildDesiredRobinDeployment, set default probes on the Robin container pointing at the health endpoint exposed by Robin:
livenessProbe: HTTP GET/healthzon the metrics port (8080), with sensibleinitialDelaySeconds/periodSeconds/failureThreshold.readinessProbe(optional but recommended for consistency): HTTP GET/readyzon the same port.- Defaults must remain overridable by
spec.robin.template(block-replacement semantics, consistent with how resources/securityContext are already handled). If the user provides probes in the template, they win.
Acceptance criteria
- Generated Robin Deployment includes a default
livenessProbe(HTTP/healthz, port8080). - Generated Robin Deployment includes a default
readinessProbe(HTTP/readyz) — or documented decision to omit readiness. - Probe timings (
initialDelaySeconds,periodSeconds,timeoutSeconds,failureThreshold) are reasonable for a reconciler and documented. - User-supplied probes via
spec.robin.templateoverride the defaults. - Unit tests assert: defaults present when no template; template probes take precedence when provided.
- Drift detection (
robinDeploymentNeedsUpdate) accounts for the probe fields so the operator does not fight the Deployment controller.
Implementation notes
- Add the probe defaults where the base
containeris constructed inbuildDesiredRobinDeployment(internal/controller/redkey_robin.go, around thePorts/Resourcesblock). - Honor the existing override precedence used for
SecurityContext/Resourcesfromspec.robin.template.spec.containers[0]. - Verify probes are included in the fields compared by the deployment-drift check to keep reconciliation idempotent.
Related
- Depends on redkey-robin: https://github.com/InditexTech/redkey-robin/issues/43.
- Dominant language
- Go
- Stars
- 29
- Forks
- 2
- Avg merge
- 13h 32m
- Merged PRs (30d)
- 16
Getting set up
Starts the project's dev container in your browser, under your own GitHub account.
- Ships a Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from InditexTech/redkey-operator
-
[Feature] Set RevisionHistoryLimit on the generated Robin Deployment to bound retained ReplicaSetsOpenenhancement
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
InditexTech/redkey-operator#87 ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
InditexTech/redkey-operator#124 ·
Maintainers usually reply within 1 day
-
[Bug] Operator memory usage scales with cluster size instead of with the number of Redkeys (OOMKilled on startup)Possibly taken @albertompe claimed this 10 days ago. Openbug
Difficulty 4/5 3-5 days Newbie friendliness 38/100
InditexTech/redkey-operator#122 ·
Maintainers usually reply within 1 day
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 22/100
InditexTech/redkey-operator#120 ·
Maintainers usually reply within 1 day
-
enhancement
Difficulty 4/5 3-5 days Newbie friendliness 54/100
InditexTech/redkey-operator#111 · 1 comment ·
Maintainers usually reply within 1 day
All issues in InditexTech/redkey-operator
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
Maintainers usually reply within 1 day
-
kind/features
Difficulty 2/5 1-3 hours Newbie friendliness 73/100
TencentBlueKing/bk-nodemgr#3991 ·
Maintainers usually reply within 1 day
-
meta
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
last9/last9-mcp-server#554 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 85/100
-
Plain-http federation signing external_url fails startup with "invalid federation request signature"Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day