Question

我们正在尝试构建一些简单的自动化方法，以检测部署是否已完成滚动更新，或者滚动更新是否失败。天真的方法（我们今天要这样做）是简单地获取用于部署的所有Pod，然后等待它们准备就绪。我们查看所有Pod，如果其中一个Pod重新启动了3次或更多次（自从开始更新以来），我们将回滚更新。在大多数情况下，这都可以正常工作。发生这种情况的时间不是，因为当前部署的当前版本由于某种原因而处于失败状态，以致现有容器持续不断地重新启动，从而触发了从我们这一端的回滚。

因此，我的想法是监视在启动滚动更新后正在推出的新副本集中的Pod。这样，我们就不会将以前版本中的Pod失败检测为滚动更新的失败。我已经找到了如何在副本集中找到豆荚（PS：我使用powershell作为我的shell，但希望可以直接转换为bash或您喜欢的任何东西）：

kubectl get pod -n <namespace> -l <selector> -o json | ConvertFrom-Json | Where {$_.metadata.ownerReferences.name -eq <replicaset-name>}

使用相同的方法，我可以轻松地找到属于某个部署的副本集，只需查询副本集并再次过滤它们的ownerReference。

但是，在滚动更新期间，部署至少具有两个副本集：新副本和旧副本。如果我使用“ kubectl描述部署”，我可以看到这些名称-但是如果不进行一些文本处理的话，这不是非常自动化。这似乎是一种脆弱的方法。如果可以在json中找到相同的信息，那将是很棒的，但是似乎不存在。

所以，我的问题是：如何找到部署与当前/旧副本集之间的连接，最好是JSON格式？是否有其他“资源”将这两者“连接”，或者是否存在一些有关副本集本身的信息，可以用来区分新副本集和旧副本集？

Answer 1

部署将使用deployment.kubernetes.io/revision批注指示副本集的当前“修订”。

metadata:
  annotations:
    deployment.kubernetes.io/revision: "4"

这将同时存在于部署和副本集上。修订版N-1的副本集将是“旧的”副本集。

Answer 2

kubectl 源码中使用的方式是：

sort.Sort(replicaSetsByCreationTimestamp(rsList))

意思是：

选择部署创建的所有副本集；
按创建时间戳排序；
选择最近的一个，也就是当前的新副本集；

kubectl-为json格式的部署检索当前/“新”副本集

2 个答案: