To support Egress based path in Traceflow Output

[rajnkamr]

Describe what you are trying to solve

Egress Node IP can identify the egress node in traceflow observation, egress ip could vary based on whether it is static/allocated from IPPool.
Egress node ip is the management ip of the cluster/node. When there is only one interface on device, Egress Node IP is both the management and transport interface ip.
To provide complete traceflow path we need to add src pod ip
Describe the solution you have in mind

Add src pod ip and node's packet path
Describe how your solution impacts user flows

N/A
Describe the main design/architecture of your solution

Display Egress Node IP in traceflow output
Alternative solutions that you considered

Test plan

Additional context

To provide a live traffic interface detection tool for Antrea Egress Node

[tnqn]

Before this is implemented, can you share the motivation of the change? I remember we have added Egress Node name to the observation, is it really useful to have a redundant information which can be got by querying the Node API and IMO the Node IP doesn't seem helpful to analyze the traceflow result.

Same for Pod IP: users need to provide Pod name or Pod IP to trigger a Traceflow, I'm not sure how returning the Pod IP in status helps here.

[rajnkamr]

In case of static egress ip, egress ip and egress node ip are same, however when ip pool is used, egress ip and egress node ip could be different. It is better to support having egress node ip field in traceflow egress observation for user clarity.

Usually tracflow user preferably uses pod name, main motivation is driven from req where pod ip should be displayed in status to let software managing antrea to have src ip info before SNAT. (Egress)

[tnqn]

In case of static egress ip, egress ip and egress node ip are same, however when ip pool is used, egress ip and egress node ip could be different. It is better to support having egress node ip field in traceflow egress observation for user clarity.

Usually tracflow user preferably uses pod name, main motivation is driven from req where pod ip should be displayed in status to let software managing antrea to have src ip info before SNAT. (Egress)

Got it, thanks.

[rajnkamr]

Usually if one wish to communicate from the k8s Pods to an external Service outside the Cluster, user will have to allow traffic from all the Cluster Node IPs, providing no node affinityrules in place. It may potentially create security concerns with externally configured ACLs.

SNAT external IP Pool / Static SNAT IP are assigned for the outgoing network traffic from the Pods. Antrea Egress feature selectively assign the SNAT IP based on Pod Labels / Namespace Labels or both. Externalippoolresource has specification field to define the Nodes from which the SNATed traffic originates.

Even though the src pod ip can keep on changing, however src pod ip can help to provide complete packet path during traceflow

[antoninbas]

The source Pod IP has been added to the Traceflow observations in #6247.
The other item is tracked separately in #6273.