fix(kubernetes): recover BatchSandbox after Pod restart - #1523
Conversation
Persist failed Pod UIDs so a recovered original Pod can clear a stale Failed phase without treating a replacement Pod as recovery. Fixes opensandbox-group#1497
github-actions
Bot
added
component/k8s
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1e29c5ea28
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| } | ||
| } | ||
|
|
||
| status.FailedPodUIDs = nil |
There was a problem hiding this comment.
When a failed pod recovers, setting FailedPodUIDs to nil is not enough to remove the persisted status field because updateStatus marshals the struct into a JSON merge patch and the field is tagged omitempty, so failedPodUIDs is omitted rather than sent as null. After recovery, the API server keeps the old UID list, the desired status keeps comparing unequal to the stored status, and the reconciler will keep trying to patch the same object instead of becoming idempotent.
AGENTS.md reference: kubernetes/AGENTS.md:L166-L166
Useful? React with 👍 / 👎.
| // current Failed phase. The controller uses these UIDs to distinguish an | ||
| // in-place recovery from a replacement Pod that reuses the same name. | ||
| // +optional | ||
| FailedPodUIDs []types.UID `json:"failedPodUIDs,omitempty"` |
There was a problem hiding this comment.
This status field is added to the Go type and the Kustomize CRD, but the bundled Helm CRD copy at kubernetes/charts/opensandbox-controller/templates/crds/batchsandboxes.yaml still lacks status.failedPodUIDs. In Helm-installed clusters, that unknown status field is pruned by the CRD schema, so the controller cannot persist pod UID provenance and the transient Pod recovery path remains ineffective for Helm users.
AGENTS.md reference: kubernetes/AGENTS.md:L164-L164
Useful? React with 👍 / 👎.
|
@Pangjiping Could you please review this PR when you have time? If the changes look correct and the required checks pass, would you be willing to merge it? I will address any requested changes promptly. 简体中文@Pangjiping 方便时能否帮忙审核一下这个 PR？如果修改没有问题且必要检查通过，麻烦帮忙合并；如果需要调整，我会及时跟进。 |
1 participant
Summary
BatchSandboxwhen the original failed Pod returns to Running and Ready.Testing
cd docs && pnpm docs:build)make test)Breaking Changes
Checklist