云原生容器编排工作流自动化任务调度后端【免费下载链接】argo-workflowsWorkflow Engine for Kubernetes项目地址https://gitcode.com/gh_mirrors/ar/argo-workflows点击查看免费下载Argo Workflows 从 v4.0.0 起引入「失败 Pod 自动重启Automatic Pod Restarts」特性用于自动恢复那些因基础设施问题如节点驱逐、磁盘压力、意外的准入错误而在主容器启动前即失败的 Pod。本文基于官方功能提案.features/released/v4.0.0/pod-restart.md与完整用户指南docs/pod-restarts.md深入讲解该特性的工作原理、配置方式、监控手段与源码实现帮助你无需为每个模板配置retryStrategy即可透明地应对节点级瞬时故障。为什么需要 Pod 自动重启在 Kubernetes 集群中即使工作负载本身完全正常Pod 也可能因为基础设施层面的原因在尚未启动主容器之前就失败节点资源紧张触发驱逐Evicted如DiskPressure、MemoryPressure节点优雅关机NodeShutdown节点亲和性/选择器不再匹配NodeAffinityPod 准入阶段发生意外错误UnexpectedAdmissionError这类失败发生在你的代码真正运行之前属于瞬时的基础设施故障。传统的做法是给每个模板配置retryStrategy但retryStrategy主要面向应用层失败容器已经运行并退出而且部分工作负载不具备幂等性不适合直接重试。功能提案中明确指出This is safe to do even for non-idempotent workloads即使对非幂等工作负载自动重启也是安全的——因为 Pod 从未启动主容器重启不会产生重复的业务副作用。工作原理控制器如何自动恢复失败 Pod当 Pod 在主容器进入Running状态之前失败时workflow-controller 会检查失败原因是否属于基础设施问题。如果是控制器将自动删除并重建该 Pod让工作流继续执行。出于安全考虑该机制只作用于从未启动过的 Poddocs/pod-restarts.md原文For safety this mechanism only works on pods we know never started对于可能已经启动过的 Pod请使用retryStrategy处理。在源码中重启流程发生在 workflow/controller/operator.go 的PodFailed分支控制器检测到 Pod 进入Failed状态调用shouldAutoRestartPod判断是否满足重启条件若满足则递增节点状态的FailedPodRestarts计数记录当前 Pod UID 到RestartingPodUID并将节点状态置回Pending节点消息被更新为类似Pod auto-restarting due to Evicted: The node had condition: [DiskPressure]的提示控制器通过 UID 删除旧 PodDeletePodByUID并重新创建新 Pod。其中的幂等保护值得注意RestartingPodUID字段会记录本次正在重启的 Pod UID定义见 pkg/apis/workflow/v1alpha1/workflow_types.go。当控制器因重启等原因对同一 Pod 的Failed状态进行重复处理时会跳过重复的重启操作避免快速重处理导致的重复重启。此外每次 operate 循环都会按 UID 重新发出删除请求即使控制器中途重启丢失了上次的删除请求Pod 也能被正确清理。可重启的失败原因Restartable Failure Reasons控制器只对以下由 kubelet 写入的基础设施级失败原因触发自动重启ReasonDescriptionEvicted节点压力驱逐DiskPressure、MemoryPressure等NodeShutdown节点优雅关机NodeAffinity节点亲和性/选择器不再匹配UnexpectedAdmissionErrorPod 准入阶段的意外错误这些原因被硬编码在 workflow/controller/pod_restart.go 的isRestartableReason函数中。单元测试 workflow/controller/pod_restart_test.go 专门验证了OOMKilled等非重启类原因不会触发自动重启。重启条件四个条件缺一不可一个 Pod 只有同时满足以下所有条件才会被自动重启Pod 阶段为Failed主容器从未进入过Running状态失败原因属于上表所列的可重启原因该节点workflow node的FailedPodRestarts计数尚未超过配置的上限。这些条件在 workflow/controller/pod_restart.go 的analyzePodForRestart中逐一校验。其中「主容器从未启动」的判断逻辑mainContainerNeverStarted见 workflow/controller/pod_restart.go值得细看如果 Pod 没有任何容器状态从未被调度视为未启动如果主容器当前处于Running或存在启动时间StartedAt非零的终止状态则视为已启动不再重启。单元测试覆盖了主容器处于Waiting如ContainerCreating、从未调度、以及已经运行并终止等场景见 workflow/controller/pod_restart_test.go。配置通过控制器 ConfigMap 启用该特性默认关闭必须在 workflow-controller 的 ConfigMap 中显式开启功能提案原文You need to configure this in your workflow controller configmap for it to take effect。配置方式如下apiVersion: v1 kind: ConfigMap metadata: name: workflow-controller-configmap data: failedPodRestart: | enabled: true maxRestarts: 3配置项说明OptionTypeDefaultDescriptionenabledboolfalse是否启用 Pod 自动重启maxRestartsint3每个节点node放弃前的最大重启次数这两个配置项对应 config/config.go 中的FailedPodRestartConfig结构体IsEnabled()返回false当配置为空或Enabled未设置即默认不启用GetMaxRestarts()在MaxRestarts未设置时返回默认值3用于防止无限重启循环。e2e 测试环境的基础 ConfigMap 已预置该配置可参考 test/e2e/manifests/components/base/workflow-controller-configmap.yamlmaxRestarts上限检查逻辑位于 workflow/controller/operator.go。监控与观测节点状态字段当 Pod 被自动重启时workflow 的节点状态NodeStatus会更新failedPodRestarts记录该节点上的 Pod 被自动重启的次数message更新为重启提示例如Pod auto-restarting due to Evicted: The node had condition: [DiskPressure]。可以通过kubectl直接查看工作流状态中的重启计数kubectl get wf my-workflow -o jsonpath{.status.nodes[*].failedPodRestarts}指标pod_restarts_total控制器每次触发自动重启时都会记录pod_restarts_total计数器调用点见 workflow/controller/operator.go指标定义见 util/telemetry/metrics_list.go详细说明见 docs/metrics.mdattribute说明reason基础设施失败原因Evicted、NodeShutdown、NodeAffinity、UnexpectedAdmissionErrorcondition可选导致重启的节点条件例如DiskPressure、MemoryPressurenamespacePod 所在的命名空间其中condition通过正则从 Pod 状态消息中提取例如The node had condition: [DiskPressure]会解析出DiskPressure实现见 workflow/metrics/counter_pod_restart.go。可以按原因、节点条件和命名空间维度聚合观察集群中被自动重启的 Pod 数量。与 retryStrategy 的对比与协作FeatureAutomatic Pod RestartsretryStrategy触发时机容器启动前的基础设施失败容器运行后的应用失败配置位置全局controller ConfigMap按模板per-template适用场景节点驱逐、磁盘压力、准入错误应用错误、瞬时业务故障状态字段节点状态中的failedPodRestarts节点状态中的retries二者是互补机制可以同时生效如果 Pod 在启动前被驱逐自动重启负责恢复如果容器运行后失败则由retryStrategy处理。关于retryStrategy的完整说明参见 docs/retries.md。关键区别在于安全性retryStrategy重试的是已经运行过业务代码的容器对非幂等工作负载有副作用风险而自动重启的 Pod 主容器从未启动因此即使是非幂等工作负载也可以安全重启。这正是该特性与retryStrategy最本质的差异。完整流程示例磁盘压力下的自动恢复假设一个工作流运行在经历磁盘压力的节点上完整恢复流程如下对应 docs/pod-restarts.mdPod 被调度init 容器开始启动节点出现DiskPressure主容器启动前 Pod 被驱逐控制器检测到驱逐及FailedPodRestarts条件Pod 被删除工作流节点被标记为Pending以便重建 Pod新 Pod 被创建到健康节点上工作流正常继续执行最终成功——全程无需任何模板级重试配置。这一流程被 e2e 测试 test/e2e/pod_restart_test.go 完整验证测试提交 test/e2e/testdata/workflow-pod-restart.yaml含 init 容器和简单的主容器通过 patch Pod 状态模拟驱逐PhaseFailed、ReasonEvicted、MessageThe node had condition: [DiskPressure]主容器仍处于Waiting随后断言工作流最终成功、failedPodRestarts计数为 1、主容器以退出码 0 正常结束。何时应该启用该特性如果你的集群存在以下情况建议在 workflow-controller ConfigMap 中启用failedPodRestart节点经常因压力驱逐 Pod导致工作流大面积失败集群有节点优雅关机或节点维护流程模板没有也不适合配置retryStrategy但希望获得对瞬时基础设施故障的韧性。需要注意的限制该特性全局生效无法按模板单独开关maxRestarts是每个节点的重启上限达到上限后节点会维持Failed状态并给出相应日志提示见 workflow/controller/operator.go。对于需要在应用层面具备重试能力的任务仍需配合retryStrategy使用。赞分享云原生容器编排工作流自动化任务调度后端【免费下载链接】argo-workflowsWorkflow Engine for Kubernetes项目地址https://gitcode.com/gh_mirrors/ar/argo-workflows点击查看免费下载相关推荐iTerm2-Color-Schemes 完整指南605 款终端配色一键导入与切换教程iTerm2 Color Schemes 完整指南605 款终端配色一键导入与切换教程 刚拿到一台 Mac、装好 iTerm2 的开发者最常见的动作就是去搜开发工具LocalAI故障恢复自动重启与容错机制LocalAI故障恢复自动重启与容错机制 概述 LocalAI作为开源OpenAI替代方案在生产环境中需要确保高可用性和稳定性。本文将深入探讨LocalAI人工智能大模型模型推理服务本地部署LLM 网关AI AgentRAG后端nft-mix性能优化终极指南10个降低Gas费用和提高合约效率的实用技巧nft mix性能优化终极指南10个降低Gas费用和提高合约效率的实用技巧 在以太坊生态系统中开发NFT智能合约时 Gas费用优化 和 合约效率提升 是每个上一篇如何构建安全的Web应用架构OWASP Developer Guide设计模式详解下一篇TeXworks协作编辑教程多人团队如何高效协同编写LaTeX文档创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
云原生容器编排工作流自动化任务调度后端【免费下载链接】argo-workflowsWorkflow Engine for Kubernetes项目地址https://gitcode.com/gh_mirrors/ar/argo-workflows点击查看免费下载Argo Workflows 从 v4.0.0 起引入「失败 Pod 自动重启Automatic Pod Restarts」特性用于自动恢复那些因基础设施问题如节点驱逐、磁盘压力、意外的准入错误而在主容器启动前即失败的 Pod。本文基于官方功能提案.features/released/v4.0.0/pod-restart.md与完整用户指南docs/pod-restarts.md深入讲解该特性的工作原理、配置方式、监控手段与源码实现帮助你无需为每个模板配置retryStrategy即可透明地应对节点级瞬时故障。为什么需要 Pod 自动重启在 Kubernetes 集群中即使工作负载本身完全正常Pod 也可能因为基础设施层面的原因在尚未启动主容器之前就失败节点资源紧张触发驱逐Evicted如DiskPressure、MemoryPressure节点优雅关机NodeShutdown节点亲和性/选择器不再匹配NodeAffinityPod 准入阶段发生意外错误UnexpectedAdmissionError这类失败发生在你的代码真正运行之前属于瞬时的基础设施故障。传统的做法是给每个模板配置retryStrategy但retryStrategy主要面向应用层失败容器已经运行并退出而且部分工作负载不具备幂等性不适合直接重试。功能提案中明确指出This is safe to do even for non-idempotent workloads即使对非幂等工作负载自动重启也是安全的——因为 Pod 从未启动主容器重启不会产生重复的业务副作用。工作原理控制器如何自动恢复失败 Pod当 Pod 在主容器进入Running状态之前失败时workflow-controller 会检查失败原因是否属于基础设施问题。如果是控制器将自动删除并重建该 Pod让工作流继续执行。出于安全考虑该机制只作用于从未启动过的 Poddocs/pod-restarts.md原文For safety this mechanism only works on pods we know never started对于可能已经启动过的 Pod请使用retryStrategy处理。在源码中重启流程发生在 workflow/controller/operator.go 的PodFailed分支控制器检测到 Pod 进入Failed状态调用shouldAutoRestartPod判断是否满足重启条件若满足则递增节点状态的FailedPodRestarts计数记录当前 Pod UID 到RestartingPodUID并将节点状态置回Pending节点消息被更新为类似Pod auto-restarting due to Evicted: The node had condition: [DiskPressure]的提示控制器通过 UID 删除旧 PodDeletePodByUID并重新创建新 Pod。其中的幂等保护值得注意RestartingPodUID字段会记录本次正在重启的 Pod UID定义见 pkg/apis/workflow/v1alpha1/workflow_types.go。当控制器因重启等原因对同一 Pod 的Failed状态进行重复处理时会跳过重复的重启操作避免快速重处理导致的重复重启。此外每次 operate 循环都会按 UID 重新发出删除请求即使控制器中途重启丢失了上次的删除请求Pod 也能被正确清理。可重启的失败原因Restartable Failure Reasons控制器只对以下由 kubelet 写入的基础设施级失败原因触发自动重启ReasonDescriptionEvicted节点压力驱逐DiskPressure、MemoryPressure等NodeShutdown节点优雅关机NodeAffinity节点亲和性/选择器不再匹配UnexpectedAdmissionErrorPod 准入阶段的意外错误这些原因被硬编码在 workflow/controller/pod_restart.go 的isRestartableReason函数中。单元测试 workflow/controller/pod_restart_test.go 专门验证了OOMKilled等非重启类原因不会触发自动重启。重启条件四个条件缺一不可一个 Pod 只有同时满足以下所有条件才会被自动重启Pod 阶段为Failed主容器从未进入过Running状态失败原因属于上表所列的可重启原因该节点workflow node的FailedPodRestarts计数尚未超过配置的上限。这些条件在 workflow/controller/pod_restart.go 的analyzePodForRestart中逐一校验。其中「主容器从未启动」的判断逻辑mainContainerNeverStarted见 workflow/controller/pod_restart.go值得细看如果 Pod 没有任何容器状态从未被调度视为未启动如果主容器当前处于Running或存在启动时间StartedAt非零的终止状态则视为已启动不再重启。单元测试覆盖了主容器处于Waiting如ContainerCreating、从未调度、以及已经运行并终止等场景见 workflow/controller/pod_restart_test.go。配置通过控制器 ConfigMap 启用该特性默认关闭必须在 workflow-controller 的 ConfigMap 中显式开启功能提案原文You need to configure this in your workflow controller configmap for it to take effect。配置方式如下apiVersion: v1 kind: ConfigMap metadata: name: workflow-controller-configmap data: failedPodRestart: | enabled: true maxRestarts: 3配置项说明OptionTypeDefaultDescriptionenabledboolfalse是否启用 Pod 自动重启maxRestartsint3每个节点node放弃前的最大重启次数这两个配置项对应 config/config.go 中的FailedPodRestartConfig结构体IsEnabled()返回false当配置为空或Enabled未设置即默认不启用GetMaxRestarts()在MaxRestarts未设置时返回默认值3用于防止无限重启循环。e2e 测试环境的基础 ConfigMap 已预置该配置可参考 test/e2e/manifests/components/base/workflow-controller-configmap.yamlmaxRestarts上限检查逻辑位于 workflow/controller/operator.go。监控与观测节点状态字段当 Pod 被自动重启时workflow 的节点状态NodeStatus会更新failedPodRestarts记录该节点上的 Pod 被自动重启的次数message更新为重启提示例如Pod auto-restarting due to Evicted: The node had condition: [DiskPressure]。可以通过kubectl直接查看工作流状态中的重启计数kubectl get wf my-workflow -o jsonpath{.status.nodes[*].failedPodRestarts}指标pod_restarts_total控制器每次触发自动重启时都会记录pod_restarts_total计数器调用点见 workflow/controller/operator.go指标定义见 util/telemetry/metrics_list.go详细说明见 docs/metrics.mdattribute说明reason基础设施失败原因Evicted、NodeShutdown、NodeAffinity、UnexpectedAdmissionErrorcondition可选导致重启的节点条件例如DiskPressure、MemoryPressurenamespacePod 所在的命名空间其中condition通过正则从 Pod 状态消息中提取例如The node had condition: [DiskPressure]会解析出DiskPressure实现见 workflow/metrics/counter_pod_restart.go。可以按原因、节点条件和命名空间维度聚合观察集群中被自动重启的 Pod 数量。与 retryStrategy 的对比与协作FeatureAutomatic Pod RestartsretryStrategy触发时机容器启动前的基础设施失败容器运行后的应用失败配置位置全局controller ConfigMap按模板per-template适用场景节点驱逐、磁盘压力、准入错误应用错误、瞬时业务故障状态字段节点状态中的failedPodRestarts节点状态中的retries二者是互补机制可以同时生效如果 Pod 在启动前被驱逐自动重启负责恢复如果容器运行后失败则由retryStrategy处理。关于retryStrategy的完整说明参见 docs/retries.md。关键区别在于安全性retryStrategy重试的是已经运行过业务代码的容器对非幂等工作负载有副作用风险而自动重启的 Pod 主容器从未启动因此即使是非幂等工作负载也可以安全重启。这正是该特性与retryStrategy最本质的差异。完整流程示例磁盘压力下的自动恢复假设一个工作流运行在经历磁盘压力的节点上完整恢复流程如下对应 docs/pod-restarts.mdPod 被调度init 容器开始启动节点出现DiskPressure主容器启动前 Pod 被驱逐控制器检测到驱逐及FailedPodRestarts条件Pod 被删除工作流节点被标记为Pending以便重建 Pod新 Pod 被创建到健康节点上工作流正常继续执行最终成功——全程无需任何模板级重试配置。这一流程被 e2e 测试 test/e2e/pod_restart_test.go 完整验证测试提交 test/e2e/testdata/workflow-pod-restart.yaml含 init 容器和简单的主容器通过 patch Pod 状态模拟驱逐PhaseFailed、ReasonEvicted、MessageThe node had condition: [DiskPressure]主容器仍处于Waiting随后断言工作流最终成功、failedPodRestarts计数为 1、主容器以退出码 0 正常结束。何时应该启用该特性如果你的集群存在以下情况建议在 workflow-controller ConfigMap 中启用failedPodRestart节点经常因压力驱逐 Pod导致工作流大面积失败集群有节点优雅关机或节点维护流程模板没有也不适合配置retryStrategy但希望获得对瞬时基础设施故障的韧性。需要注意的限制该特性全局生效无法按模板单独开关maxRestarts是每个节点的重启上限达到上限后节点会维持Failed状态并给出相应日志提示见 workflow/controller/operator.go。对于需要在应用层面具备重试能力的任务仍需配合retryStrategy使用。赞分享云原生容器编排工作流自动化任务调度后端【免费下载链接】argo-workflowsWorkflow Engine for Kubernetes项目地址https://gitcode.com/gh_mirrors/ar/argo-workflows点击查看免费下载相关推荐iTerm2-Color-Schemes 完整指南605 款终端配色一键导入与切换教程iTerm2 Color Schemes 完整指南605 款终端配色一键导入与切换教程 刚拿到一台 Mac、装好 iTerm2 的开发者最常见的动作就是去搜开发工具LocalAI故障恢复自动重启与容错机制LocalAI故障恢复自动重启与容错机制 概述 LocalAI作为开源OpenAI替代方案在生产环境中需要确保高可用性和稳定性。本文将深入探讨LocalAI人工智能大模型模型推理服务本地部署LLM 网关AI AgentRAG后端nft-mix性能优化终极指南10个降低Gas费用和提高合约效率的实用技巧nft mix性能优化终极指南10个降低Gas费用和提高合约效率的实用技巧 在以太坊生态系统中开发NFT智能合约时 Gas费用优化 和 合约效率提升 是每个上一篇如何构建安全的Web应用架构OWASP Developer Guide设计模式详解下一篇TeXworks协作编辑教程多人团队如何高效协同编写LaTeX文档创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
