Kafka sidecar: add a startupProbe so slow-starting functions aren't restart-looped
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 78/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- go, kubernetes
- Domain
- backend, infrastructure
Research direction
Start in pkg/k8s/deployer.go and inspect how the raw and keda deployers configure probes for the injected kafka-runtime sidecar. Check the existing probe behavior added in #4060 and how long the runtime may wait for FUNCTION_TARGET. Done when a startup probe protects the sidecar from liveness restarts during startup, or an initial delay covers the described cold start.
Written by the indexing model from the issue text.
Description
What
The injected Kafka runtime sidecar (kafka-runtime container, added by the
raw/keda deployers in pkg/k8s/deployer.go) has a liveness probe but no
startupProbe (nor an initialDelaySeconds sized for cold start).
Problem
The runtime only begins serving /health/liveness after it finishes waiting for
the function target (an up-to-~60s FUNCTION_TARGET wait). A slow-starting
function — e.g. a JVM cold start that exceeds the liveness threshold — can fail
liveness before it is ever up, so the kubelet restart-loops the sidecar (and the
pod never becomes healthy).
Fix
Add a startupProbe to the sidecar container (or an initialDelaySeconds that
covers the worst-case cold start) so the liveness probe only takes effect after
startup completes. Readiness and liveness themselves landed in #4060; this closes
the remaining startup-probe gap.
/kind bug
Follow-up to #4060.
- Dominant language
- Go
- Stars
- 365
- Forks
- 224
- Avg merge
- 2d 17h
- Merged PRs (30d)
- 21
Getting set up
- No Dockerfile or Docker Compose file
- No 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 knative/func
-
KEDA deployer: default minReplicaCount prevents scale-to-zeroPossibly taken @Tushar-Khandelwal-2004 claimed this 113 days ago. Openlifecycle/stale
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
knative/func#3924 · 1 comment ·
Maintainers usually reply within 1 day
-
git/gitlab: default project webhooks to SSL verification when creating hooksPossibly taken @Vi-shub claimed this 159 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
mcp: config add/remove handlers bypass readonly guardPossibly taken @Elvand-Lie claimed this 162 days ago. Openkind/bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
knative/func#3704 · 1 comment ·
Maintainers usually reply within 1 day
-
kind/cleanup
Difficulty 4/5 3-5 days Newbie friendliness 48/100
Maintainers usually reply within 1 day
-
kind/bug
Difficulty 3/5 1-2 days Newbie friendliness 72/100
Maintainers usually reply within 1 day
Similar issues
-
usage: a custom provider's balance meters ("…%" in the balance path) ignore the Left/Used switchOpen
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
bug iam-service
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
platform-mesh/platform-mesh#425 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
grafana/tempo-operator#1691 ·
Maintainers usually reply within 1 day
-
fix: presentation.go with mcp-table.go: the message for each MCP server comes backPossibly taken @mge1512 claimed this today. Openbug
Difficulty 1/5 1-3 hours Newbie friendliness 78/100
mark3labs/kit#242 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 85/100
slavakurilyak/awesome-ai-agents#827 ·
Maintainers usually reply within 1 day