[Feature] Add default liveness/readiness probes to the generated Robin Deployment

Aperta
  • Qualcosa non va?
#84 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
65/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
go, kubernetes
Ambito
backend, cloud, devops

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement

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 /healthz on the metrics port (8080), with sensible initialDelaySeconds / periodSeconds / failureThreshold.
  • readinessProbe (optional but recommended for consistency): HTTP GET /readyz on 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, port 8080).
  • 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.template override 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 container is constructed in buildDesiredRobinDeployment (internal/controller/redkey_robin.go, around the Ports/Resources block).
  • Honor the existing override precedence used for SecurityContext/Resources from spec.robin.template.spec.containers[0].
  • Verify probes are included in the fields compared by the deployment-drift check to keep reconciliation idempotent.

Related

Lingua principale
Go
Stelle
29
Fork
2
Merge medio
13h 32m
PR unite (30g)
16

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di InditexTech/redkey-operator

Tutte le issue di InditexTech/redkey-operator

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.