Record Status when EgressIP is not available on any Node incase of static Egress

[Atish-iaf]

Describe the problem/challenge you have
In case of static egress, sometimes user may provide EgressIP which isn't assigned to any Node by mistake or EgressIP was later removed from the assigned Node. Currently, there is no useful info for troubleshooting this.

kubectl get egress                     
NAME            EGRESSIP   AGE     NODE
egress-static              2m16s   

kubectl describe egress egress-static  
Name:         egress-static
Namespace:    
Labels:       app=egress
Annotations:  <none>
API Version:  crd.antrea.io/v1beta1
Kind:         Egress
Metadata:
  Creation Timestamp:  2024-04-16T06:10:11Z
  Generation:          1
  Resource Version:    52666
  UID:                 985974d8-b98f-443d-bcf3-c1b5c8cfc95c
Spec:
  Applied To:
    Pod Selector:
      Match Labels:
        App:  nginx1
  Egress IP:  172.18.0.6
Events:       <none>

Describe the solution you'd like
It may be useful to provide Status for static Egress case as well like we provide for Egress with externalippool.

Status:
  Conditions:
    Last Transition Time:  2024-04-16T05:57:47Z
    Message:               Failed to assign the IP to EgressNode: no Node available
    Reason:                AssignmentError
    Status:                False
    Type:                  IPAssigned

Anything else you would like to add?
For Egress with ExternalIPPool, when EgressIP isn't assigned to any Node, Egress is not applied to Pod. Pod to external traffic goes via host NodeIP SNAT (Normal encap mode).
But this is not the case for static Egress, when EgressIP isn't available on any Node, still Egress is applicable to Pod and Pod to external traffic is unsuccessful. We can take reference from egress with externalIPPool and not apply egress to pod until egressIP is available on a Node for static egress as well.

[rajnkamr]

Usually Egress with ExternalIPPool should be in same subnet as node's interface, however it is not mandatory case, and ExternalIPPool could also be in different subnet than node's network, However the egress interface and ip will be assigned to egress dummy interface with the given subnet which leads to traffic going via actual node interface which could be in different subnet. In that case, does egress apply to pod if dummy interface is created and down !
Same for static egress , there might be case where static egress ip might not be same as node's ip.

[tnqn]

Currently, there is no useful info for troubleshooting this.

I think the empty EgressIP and EgressNode already mean the IP is not on any Node, which is everything users need to know?

It may be useful to provide Status for static Egress case as well like we provide for Egress with externalippool.

It's kind of by design and I can't think of how we can make it more friendly. The point of static Egress is that user have full control on the Egress IPs, and none of the agent knows which Node the Egress IP should be on, then how they know when and which agent should update the condition to be False? And the point of the condition is to reduce the ambiguity of empty Node and to distinguish between "agent haven't tried to assign the IP" and "agent fail to assign the IP". For static Egress, I think there is no ambiguity, empty Node just means users the IP isn't assigned to any Node and agents are not going to do anything with it.

For Egress with ExternalIPPool, when EgressIP isn't assigned to any Node, Egress is not applied to Pod. Pod to external traffic goes via host NodeIP SNAT (Normal encap mode).
But this is not the case for static Egress, when EgressIP isn't available on any Node, still Egress is applicable to Pod and Pod to external traffic is unsuccessful. We can take reference from egress with externalIPPool and not apply egress to pod until egressIP is available on a Node for static egress as well.

This sounds reasonable to me. I'm not sure which behavior is better but we should make them consistent, and perhaps even make the behavior configurable, as some users may expect strict enforcement while some may expect best-effort.