kubernetes 部署时,使用Recreate策略进行滚动更新时状态不正确,

x6492ojm  于 5个月前  发布在  Kubernetes
关注(0)|答案(8)|浏览(115)

发生了什么?
当我使用 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,...)和版本(如果适用)

k2arahey

k2arahey2#

顺便说一下,status.updatedReplicas在这段时间里也是错误的。

ibps3vxo

ibps3vxo4#

我已经确认了这种行为,并且我认为它与记录的行为不匹配。
目前,使用 Recreate 策略的部署在其缩减过程中不会更新 Progressing 类型的条件。
我相信这是导致这种行为的原因代码。
kubernetes/pkg/controller/deployment/progress.go
第45行到第52行在 090025f
| | // 如果只有一个活跃的副本集,那么这意味着我们没有运行新的滚动更新,这是一个不需要估计任何进度的重新同步。 |
| | // 在这种情况下,我们应该简单地不对这个部署估计任何进度。 |
| | currentCond:=util.GetDeploymentCondition(d.Status, apps.DeploymentProgressing) |
| | isCompleteDeployment:=newStatus.Replicas==newStatus.UpdatedReplicas&&currentCond!=nil&&currentCond.Reason==util.NewRSAvailableReason |
| | // 仅在设置了进度截止日期且最新的滚动更新尚未完成时检查进度。 |
| | ifutil.HasProgressDeadline(d) &&!isCompleteDeployment { |
如果只有一个活跃的副本集,那么这意味着我们没有运行新的滚动更新,这是一个不需要估计任何进度的重新同步。
在这种情况下,我们应该简单地不对这个部署估计任何进度。
这对于使用 Recreate 策略的部署来说是不正确的,因为它在其缩减过程中只有一个活跃的副本集。

xesrikrc

xesrikrc5#

哦,问题不仅出现在Recreate上,还出现在RollingUpdate上。当新的ReplicaSet准备好时,在旧的ReplicaSet缩减到0之前,条件已经是Complete了,这也违反了文档中描述的行为。

p8ekf7hl

p8ekf7hl6#

对于滚动更新来说是可以接受的,因为我可以通过观察其状态来准确地了解部署是否升级。

g0czyy6m

g0czyy6m7#

/unassign
抱歉,由于资源不足,我将把自己从这个任务中解除分配。
FYI: [#115585](https://github.com/kubernetes/kubernetes/pull/115585)
cc @soltysh (sig-apps)
9vw9lbht

9vw9lbht8#

这个问题已经超过一年没有更新了,应该重新进行优先级评估。
你可以:

  • 确认这个问题仍然与 /triage accepted (仅组织成员)相关
  • /close 关闭这个问题

有关优先级评估过程的更多详细信息,请参见 https://www.kubernetes.dev/docs/guide/issue-triage/
已接受移除优先级评估

相关问题