Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

k8s deployer: WaitForDeploymentAvailable errors on a 0-replica Deployment (keda scale-to-zero redeploy)

オープン
#4,068 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 2 日以内に返信

@Elvand-Lie がすでに取り組んでいます。

2026年10月11日 から。

  • #4075 @Elvand-Lie による — オープン

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
72/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
go, kubernetes

調査の方向性

Start by reading WaitForDeploymentAvailable and checkIfDeploymentIsAvailable in pkg/k8s/wait.go, then compare how deployments are applied in pkg/k8s/deployer.go. Add coverage for the zero-replica case and verify the existing wait behavior remains intact; a KEDA-backed redeploy can provide the integration repro if needed.

索引モデルが issue の本文から書いたものです。

説明

Summary

WaitForDeploymentAvailable (pkg/k8s/wait.go) can fail a redeploy with
could not find current pod-template-hash for deployment <name> when the live
Deployment has 0 desired replicas. This is reachable today via the keda
(HTTP-scaler) deployer, whose ScaledObject scales idle functions down to zero.

Note: this is reasoned from the code, not yet reproduced (it's a timing race).
Filing so the analysis is tracked; repro TBD.

Details

WaitForDeploymentAvailable re-fetches the live Deployment on every poll tick:

deployment, err := clientset.AppsV1().Deployments(namespace).Get(ctx, deploymentName, metav1.GetOptions{})
...
return checkIfDeploymentIsAvailable(ctx, clientset, deployment)

checkIfDeploymentIsAvailable finds the active ReplicaSet by looking for one with
*rs.Spec.Replicas > 0. A Deployment sitting at 0 desired replicas has no such
ReplicaSet, so currentPodTemplateHash stays empty and the function returns an error
(pkg/k8s/wait.go):

if currentPodTemplateHash == "" {
    return false, fmt.Errorf("could not find current pod-template-hash for deployment %s", deployment.Name)
}

The func deployer itself always applies replicas >= 1 (pkg/k8s/deployer.go), so
it never creates a 0-replica Deployment. But because the wait inspects live state,
reachability is governed by what KEDA does during the wait, not by what func wrote:

  1. An idle keda-HTTP function has been scaled to 0 replicas by KEDA.
  2. User redeploys. func applies the Deployment with replicas: 1, then starts polling.
  3. If the KEDA controller reasserts 0 replicas on the live Deployment before the poll
    observes it as ready, the live fetch returns spec.replicas == 0, and the wait
    returns the pod-template-hash error — failing the redeploy.
Suggested fix

Short-circuit when there is nothing to wait for:

desiredReplicas := *deployment.Spec.Replicas
if desiredReplicas == 0 {
    return true, nil // no replicas desired; nothing to wait for
}

This also unblocks any future spec-level scale-to-zero on the raw/keda Deployment.

Notes
  • Reasoned from code; not reproduced. A repro needs a cluster with KEDA and an idle,
    scaled-to-zero HTTP function being redeployed.
  • Fix is small and self-contained but likely wants a repro or unit test first, hence
    filing as an issue rather than an immediate PR.
主要言語
Go
スター
365
フォーク
224
平均マージ
1日 13時間
マージ済み PR(30日)
17

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

knative/func のほかの issue

knative/func の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。