在升级服务时,经常新的服务还没启动完成 旧的pod已经变为不可用,导致服务不能正常运行,因此希望延长旧pod的下线时间来达到升级时服务整体可用,需要运维人员修改配置
spec:
# ...
strategy:
failurePolicy: Fail
orderedRecreate: false
terminationGracePeriodSeconds: 30
unreadyGracePeriodSeconds: 3
minStartedSeconds: 10
activeDeadlineSeconds: 300
ttlSecondsAfterFinished: 1800
- failurePolicy:Fail 或 Ignore,默认 Fail;表示一旦有某个容器停止或重建失败,CRR 立即结束。
- orderedRecreate:默认 false;true 表示列表有多个容器时,等前一个容器重建完成了,再开始重建下一个。
- terminationGracePeriodSeconds:等待容器优雅退出的时间,不填默认用 Pod 中定义的时间。
-
unreadyGracePeriodSeconds:在重建之前先把 Pod 设为 not ready,并等待这段时间后再开始执行重建。
- 注:该功能依赖于 KruisePodReadinessGate 这个 feature-gate 要打开,后者会在每个 Pod 创建的时候注入一个 readinessGate。否则,默认只会给 Kruise workload 创建的 Pod 注入 readinessGate,也就是说只有这些 Pod 才能在 CRR 重建时使用 unreadyGracePeriodSeconds。
- minStartedSeconds:重建后新容器至少保持运行这段时间,才认为该容器重建成功。
- activeDeadlineSeconds:如果 CRR 执行超过这个时间,则直接标记为结束(未完成的容器标记为失败)。
- ttlSecondsAfterFinished:CRR 结束后,过了这段时间自动被删除掉。