发生了什么?
当我使用 Recreate
策略更新一个 Deployment
时,它的条件仍然是 Complete
(当 status.observedGeneration
== spec.generation
时),直到旧的 ReplicaSet 缩放到 0。
你期望发生什么?
根据文档 https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#progressing-deployment,Kubernetes 在 The Deployment is scaling down its older ReplicaSet(s)
I.E. Reason
字段的 Progressing
条件不应该为 NewReplicaSetAvailable
时将 Deployment
标记为 Progressing
。
我们如何尽可能最小精确地重现它?
创建一个简单的部署,使用 Recreate 策略:
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
namespace: test
spec:
selector:
matchLabels:
app: myapp
strategy:
type: Recreate
template:
metadata:
labels:
app: myapp
dummy: dummy
spec:
containers:
- name: myapp
image: nginx:1.15.8
打开另一个控制台查看部署:
kubectl -n test get deploy -o yaml -w
然后更新部署的 podtemplate:
kubectl -n test patch deploy myapp -p '{"spec": {"template": {"metadata": {"labels": {"dummy": "dummy2"}}}}}'
检查 watch 的输出
我们需要知道其他什么吗?
部署的 watch 输出:
watch.log
关于解决方案,也许我们应该添加一个新的原因,如 OldReplicaSetScalingDown
Kubernetes 版本:
$ kubectl version
# paste output here
Client Version: version.Info{Major:"1", Minor:"25", GitVersion:"v1.25.4", GitCommit:"872a965c6c6526caa949f0c6ac028ef7aff3fb78", GitTreeState:"clean", BuildDate:"2022-11-09T13:36:36Z", GoVersion:"go1.19.3", Compiler:"gc", Platform:"darwin/amd64"}
Kustomize Version: v4.5.7
Server Version: version.Info{Major:"1", Minor:"24+", GitVersion:"v1.24.8-eks-ffeb93d", GitCommit:"abb98ec0631dfe573ec5eae40dc48fd8f2017424", GitTreeState:"clean", BuildDate:"2022-11-29T18:45:03Z", GoVersion:"go1.18.8", Compiler:"gc", Platform:"linux/amd64"}
云提供商:
AWS EKS
操作系统版本:
# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here
# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here
安装工具
容器运行时(CRI)和版本(如果适用)
相关插件(CNI,CSI,...)和版本(如果适用)
8条答案
按热度按时间jdgnovmf1#
/sig apps
k2arahey2#
顺便说一下,
status.updatedReplicas
在这段时间里也是错误的。lyfkaqu13#
/assign
ibps3vxo4#
我已经确认了这种行为,并且我认为它与记录的行为不匹配。
目前,使用
Recreate
策略的部署在其缩减过程中不会更新Progressing
类型的条件。我相信这是导致这种行为的原因代码。
kubernetes/pkg/controller/deployment/progress.go
第45行到第52行在 090025f
| | // 如果只有一个活跃的副本集,那么这意味着我们没有运行新的滚动更新,这是一个不需要估计任何进度的重新同步。 |
| | // 在这种情况下,我们应该简单地不对这个部署估计任何进度。 |
| | currentCond:=util.GetDeploymentCondition(d.Status, apps.DeploymentProgressing) |
| | isCompleteDeployment:=newStatus.Replicas==newStatus.UpdatedReplicas&¤tCond!=nil&¤tCond.Reason==util.NewRSAvailableReason |
| | // 仅在设置了进度截止日期且最新的滚动更新尚未完成时检查进度。 |
| | ifutil.HasProgressDeadline(d) &&!isCompleteDeployment { |
如果只有一个活跃的副本集,那么这意味着我们没有运行新的滚动更新,这是一个不需要估计任何进度的重新同步。
在这种情况下,我们应该简单地不对这个部署估计任何进度。
这对于使用
Recreate
策略的部署来说是不正确的,因为它在其缩减过程中只有一个活跃的副本集。xesrikrc5#
哦,问题不仅出现在
Recreate
上,还出现在RollingUpdate
上。当新的ReplicaSet
准备好时,在旧的ReplicaSet
缩减到0之前,条件已经是Complete
了,这也违反了文档中描述的行为。p8ekf7hl6#
对于滚动更新来说是可以接受的,因为我可以通过观察其状态来准确地了解部署是否升级。
g0czyy6m7#
9vw9lbht8#
这个问题已经超过一年没有更新了,应该重新进行优先级评估。
你可以:
/triage accepted
(仅组织成员)相关/close
关闭这个问题有关优先级评估过程的更多详细信息,请参见 https://www.kubernetes.dev/docs/guide/issue-triage/
已接受移除优先级评估