kubernetes 部署rollout状态在使用status.conditions时不可靠,

72qzrwbm 于 10个月前发布在 Kubernetes

关注(0)|答案(5)|浏览(85)

发生了什么？
目前我正在进行一个项目，我们在其中实现了一个Kubernetes操作器，并决定对于某些流程，我们需要等待一些部署完成滚动更新，然后才能继续我们的流程中的其他步骤。
因此，对于旧的部署，我们只需要在pod模板中更新镜像，然后等待更新后的部署完成滚动更新。
如果只考虑status.conditions(如文档中所建议的),那么构建/实现Deployment状态的方式是容易出错且不可靠的。

你期望发生什么？
在更新部署的spec后，当status.ObservedGeneration更改为最新的metadata.Generation时，status.conditions也应该被更新。

我们如何尽可能精确地重现它？
我们发现，如果：

我们从具有status.condition类型为Progressing的Deployment开始，原因为ProgressDeadlineExceeded
更新部署规范(唯一的更改将是来自pod模板容器的图像)
每隔一秒钟启动一个定时器(使用API检索部署并检查状态)

那么，在某些情况下(不是总是这样；这是一个并发/计时问题),第一个status.observedGeneration向新的metadata.generation值的变化，伴随着没有变化(!)的status.conditions(旧条件仍然存在 没有任何单个更改(!))。
根据Kubernetes文档(以及Operator SDK检查此滚动状态的方式),对这些情况的解释将导致说滚动失败，这是不准确的，因为实际的滚动将在几秒钟后开始...
这是一个描述问题的日志示例(请注意，两个块在几毫秒的距离内记录，即使status.conditions相同，status.ObservedGeneration也发生了变化):

# 10:53:18.814 > Metadata.Generation: 2 | Status >> ObservedGeneration: 1, replicas: 1 , readyReplicas: , availableReplicas: , updatedReplicas: 1, unAvailableReplicas: 1
  Conditions:
    @10-Apr-24 10:53:02 | 10-Apr-24 10:53:02 | Available | False | MinimumReplicasUnavailable | Deployment does not have minimum availability.
    @10-Apr-24 10:53:18 | 10-Apr-24 10:53:18 | Progressing | False | ProgressDeadlineExceeded | ReplicaSet "my-deployment-5b8dc498c" has timed out progressing.
 => completed: False, failed: False
# 10:53:18.818 > Metadata.Generation: 2 | Status >> ObservedGeneration: 2, replicas: 1 , readyReplicas: , availableReplicas: , updatedReplicas: , unAvailableReplicas: 1
  Conditions:
    @10-Apr-24 10:53:02 | 10-Apr-24 10:53:02 | Available | False | MinimumReplicasUnavailable | Deployment does not have minimum availability.
    @10-Apr-24 10:53:18 | 10-Apr-24 10:53:18 | Progressing | False | ProgressDeadlineExceeded | ReplicaSet "my-deployment-5b8dc498c" has timed out progressing.
 => completed: False, failed: True

还有什么我们需要知道的吗？
请告知如何可靠地解释Deployment的滚动状态。

Kubernetes版本

$ kubectl version
Client Version: v1.28.8+k3s1
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.28.8+k3s1

云提供商
无云

操作系统版本

# On Linux:
$ cat /etc/os-release
PRETTY_NAME="K3s v1.28.8+k3s1"
$ uname -a
Linux 3432b46b9978 5.15.0-101-generic #111-Ubuntu SMP Tue Mar 5 20:16:58 UTC 2024 x86_64 GNU/Linux
</details>
### Install tools
<details>
</details>
### Container runtime (CRI) and version (if applicable)
<details>
</details>
### Related plugins (CNI, CSI, ...) and versions (if applicable)
<details>
</details>

kubernetes

来源：https://github.com/kubernetes/kubernetes/issues/124264

5条答案

按热度按时间

ltqd579y1#

/sig apps

赞(0）回复(0）举报 10个月前

vxf3dgd42#

我正在尝试修复本地环境中的一些单元测试，以测试此修复。以下是我正在尝试做的事情：
修改 updateDeployment 函数，首先通过比较旧的和当前的规范来检查部署的规范是否已更新。如果规范已更新，我们记录更新，更新部署的规范，将 status.ObservedGeneration 设置为当前的 metadata.Generation ,并根据部署的进展情况更新部署的状态条件。最后，我们将部署加入队列以进行进一步处理。

赞(0）回复(0）举报 10个月前

qyuhtwio3#

这是我的做法：

func (dc *DeploymentController) updateDeployment(logger klog.Logger, old, cur interface{}) {
    oldD := old.(*apps.Deployment)
    curD := cur.(*apps.Deployment)
    if !reflect.DeepEqual(oldD.Spec, curD.Spec) {
        logger.V(4).Info("Updating deployment", "deployment", klog.KObj(oldD))
        oldD.Spec = curD.Spec
        oldD.Status.ObservedGeneration = curD.ObjectMeta.Generation
        if oldD.Status.UpdatedReplicas == *oldD.Spec.Replicas {
            oldD.Status.Conditions = []apps.DeploymentCondition{
                {
                    Type:   apps.DeploymentAvailable,
                    Status: corev1.ConditionTrue,
                },
            }
        } else {
            oldD.Status.Conditions = []apps.DeploymentCondition{
                {
                    Type:   apps.DeploymentAvailable,
                    Status: corev1.ConditionFalse,
                },
            }
        }        
        dc.enqueueDeployment(oldD)
    }
}