manage: only annotate a pod as kmesh managed after xdp/tc attach succ… - #1847
manage: only annotate a pod as kmesh managed after xdp/tc attach succ…#1847Anand-240 wants to merge 1 commit into
Conversation
…eeds Previously the redirection annotation was queued before linkXdp and linkTc ran, and their errors were discarded. A pod could end up marked as managed while no dataplane program was actually attached to it, so traffic would silently bypass Kmesh. This routes the attach and detach steps through the existing workqueue retry path (MaxRetries, backoff) and only queues the annotation change once attach or detach actually succeeds.
|
Caution The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
There was a problem hiding this comment.
Pull request overview
This PR fixes a correctness gap in the Kmesh manage controller by ensuring pods are only annotated as “Kmesh-managed” after the XDP/TC dataplane programs have successfully attached, and by routing attach/detach failures through the controller’s existing rate-limited retry mechanism.
Changes:
- Introduces
ActionAttach/ActionDetachto gate annotation add/delete behind successful dataplane attach/detach. - Refactors
syncPodto perform attach/detach work and enqueue annotation actions only on success. - Updates unit tests to simulate the expanded action switch (including attach/detach → annotation chaining).
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 6 comments.
| File | Description |
|---|---|
| pkg/controller/manage/manage_controller.go | Adds attach/detach actions and gates annotation on successful XDP/TC operations with retry on failure. |
| pkg/controller/manage/manage_controller_test.go | Replaces the queue mock with simulateQueueItem to mirror the new action flow in tests. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| if !utils.ShouldEnroll(pod, namespace) { | ||
| return nil | ||
| } | ||
| nspath, _ := ns.GetPodNSpath(pod) |
| if err := unlinkXdp(nspath, mode); err != nil { | ||
| return fmt.Errorf("xdp: %w", err) | ||
| } | ||
| if err := unlinkTc(nspath, tcProgFd); err != nil { | ||
| return fmt.Errorf("tc: %w", err) | ||
| } | ||
| return nil |
| case ActionDetach: | ||
| nspath, _ := ns.GetPodNSpath(pod) | ||
| if err := detachPod(nspath, c.tcProgFd, c.mode); err != nil { | ||
| return fmt.Errorf("failed to detach kmesh dataplane programs for pod %s/%s: %v", pod.Namespace, pod.Name, err) | ||
| } |
| if err := linkXdp(nspath, xdpProgFd, mode); err != nil { | ||
| return fmt.Errorf("xdp: %w", err) | ||
| } | ||
| if err := linkTc(nspath, tcProgFd); err != nil { | ||
| return fmt.Errorf("tc: %w", err) | ||
| } | ||
| return nil |
| case ActionDetach: | ||
| nspath, _ := kmeshns.GetPodNSpath(pod) | ||
| if err := detachPod(nspath, controller.tcProgFd, controller.mode); err != nil { | ||
| t.Errorf("failed to detach pod %s/%s: %v", pod.Namespace, pod.Name, err) | ||
| return | ||
| } |
| if !utils.ShouldEnroll(pod, namespace) { | ||
| return | ||
| } | ||
| nspath, _ := kmeshns.GetPodNSpath(pod) |
Codecov Report❌ Patch coverage is
❌ Your patch check has failed because the patch coverage (13.88%) is below the target coverage (80.00%). You can increase the patch coverage or adjust the target coverage.
... and 1 file with indirect coverage changes Continue to review full report in Codecov by Harness.
🚀 New features to boost your workflow:
|
Pods are only annotated as managed by Kmesh after the xdp and tc programs that actually redirect their traffic are attached, instead of the annotation being applied unconditionally while attach errors were silently discarded.
What type of PR is this?
/kind bug
What this PR does / why we need it:
In
pkg/controller/manage/manage_controller.go,enableKmeshManagequeued the pod for the Kmesh redirection annotation and then calledlinkXdpandlinkTc, discarding their return values with_ =. If either attach failed, the pod was still patched with the "kmesh redirection enabled" annotation, so the control plane and anyone inspecting the pod would believe it was fully enrolled while no xdp or tc program was actually attached to its interface. Traffic for that pod would then bypass the Kmesh dataplane with no error surfaced anywhere except a daemon log line, and no automatic retry once the pod stopped receiving further updates.This PR makes the annotation step depend on the attach step actually succeeding:
enableKmeshManagenow enqueues anActionAttachitem instead of callinglinkXdp/linkTcdirectly.disableKmeshManageenqueuesActionDetachthe same way.syncPodruns the real attach or detach work through two new helpers,attachPodanddetachPod. Only on success does it enqueueActionAddAnnotationorActionDeleteAnnotation, the actions that actually patch the pod.syncPodreturns an error, so the existingprocessItemsretry path picks it up and retries with the controller's existingMaxRetriesand rate limited backoff, the same mechanism already used for the annotation actions. No new retry logic was added.Which issue(s) this PR fixes:
Fixes #1846
Special notes for your reviewer:
manage_controller_test.gomocksqueue.AddRateLimitedso tests can run synchronously without the real workqueue loop. That mock only understoodActionAddAnnotation/ActionDeleteAnnotation, so it has been replaced with a sharedsimulateQueueItemhelper that mirrorssyncPod's full switch, including theActionAttachtoActionAddAnnotationandActionDetachtoActionDeleteAnnotationchaining.xdpProgFd=0, tcProgFd=-1, mode="". With that configurationlinkXdpreturnsnilimmediately since the mode is not Dual-Engine, andlinkTcreturnsnilimmediately sincetcProgFd == -1, soattachPod/detachPodnever touch a real network namespace in these tests.go build/go teston this package locally since it only compiles on Linux (it pulls innetns,cilium/ebpfringbuf, andethtool, none of which build on macOS). Verified withgofmt -efor syntax and a full manual trace of the changed paths against both existing tests. Would appreciate this being confirmed by CI or a reviewer running it on Linux.Does this PR introduce a user-facing change?: