Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

Kafka sidecar: add a startupProbe so slow-starting functions aren't restart-looped

未关闭 适合新手
#4,097 0 条评论 0 个 reaction 已指派 1 人 在 GitHub 查看

维护者通常 1 天内回复

@aliok 已经在做这个了。

开始于 2026年10月21日。

  • #20 来自 @aliok —— 未关闭
  • #4103 来自 @aliok —— 未关闭

评估

难度
2/5
预计耗时
1-3 小时
新手友好度
78/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
go, kubernetes

调研方向

从pkg/k8s/deployer.go开始,检查raw和keda部署器如何为注入的kafka-runtime边车配置探针。检查#4060中添加的现有探针行为,以及runtime可能等待FUNCTION_TARGET多长时间。当startup probe能在启动期间保护边车免受liveness重启,或初始延迟能够覆盖所描述的冷启动时,任务即完成。

由索引模型根据 Issue 内容生成。

描述

kind/bug

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.

主要语言
Go
星标
366
派生
226
平均合并
1 天 10 小时
30 天内合并 PR
20

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

knative/func 的其他 Issue

查看 knative/func 的全部 Issue

相似的 Issue

更多 Go Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。