Fix that local traffic cannot be identified in networkPolicyOnly mode #6251
Conversation
hongliangl
added
action/backport
hongliangl
force-pushed
the
20240419-use-regmark-to-identify-svc-traffic-from-pod
branch
2 times, most recently
from
2dd2aad
to
445be39
Compare
Before this commit, in AntreaProxy, to respect short-circuiting, when installing flows for an external Services, an extra flow with higher priority to match traffic sourced from local (local Pods or local Node) and destined for the external Service will be installed. This is achieved by matching the local Pod CIDR obtained from the local Node object. However, when Antrea is deployed in networkPolicyOnly mode, the Pod CIDR in the local Node object is nil, resulting in the failure of install the extra flow mentioned above. To fix the issue, a new reg mark `FromLocalRegMark` identifying traffic from local Pods or the local Node is introduced to mark the traffic from local. This reg mark can be used in all traffic mode. Fix antrea-io#6244 Signed-off-by: Hongliang Liu <lhongliang@vmware.com>
hongliangl
force-pushed
the
20240419-use-regmark-to-identify-svc-traffic-from-pod
branch
from
445be39
to
5ccf210
Compare
|
/test-all |
| @@ -533,7 +533,7 @@ func (f *featurePodConnectivity) gatewayClassifierFlows() []binding.Flow { | |||
| MatchInPort(f.gatewayPort). | |||
| MatchProtocol(ipProtocol). | |||
| MatchSrcIP(gatewayIP). | |||
| Action().LoadRegMark(FromGatewayRegMark). | |||
There was a problem hiding this comment.
I am a bit confused, do you mean that Pod traffic in NetworkPolicyOnly scenario will use antrea gatewayIP as the source? If so, this is an invalid assumption.
There was a problem hiding this comment.
This is used to accommodate with proxyAll enabled. When proxyAll is enabled, the source IP of Service traffic from the local Node is the gateway IP, and such traffic should be also recognized as local. For NetworkPolicyOnly scenario, this flow will never be used as the Service traffic originated from the local Node will never be handled by Antrea.
There was a problem hiding this comment.
the Service traffic originated from the local Node will never be handled by Antrea
It's a bit of an orthogonal discussion but I have a follow up question on this: does that mean that proxyAll can never be used in policyOnly mode? What would prevent that?
There was a problem hiding this comment.
What would prevent that?
So far, nothing prevents that, and antrea-agent gets crashed when proxyAll is enabled in networkPolicyMode.
does that mean that proxyAll can never be used in policyOnly mode?
What I said about this flow will never be used as the Service traffic originated from the local Node will never be handled by Antrea was not rigorous. In fact. the proxyAll can be enabled in networkPolicyMode, but Antrea gets something wrong when setting static neighbor, which is prepared for installing static routes for forwarding Service traffic from the external network or the local Node to antrea-gw0. The root cause of this issue should be that the index of antrea-gw0 in nodeConfig is not initialized in networkPolicyOnly mode.
I have two simple ideas:
- Prevent
proxyAllbeing enabled in networkPolicyMode mode. - Fix the crash issue mentioned above, and
proxyAllcan be enabled in networkPolicyMode mode. However, I'm not sure if the route installed by Antrea for forwarding Service traffic has some "conflicts" with the primary CNI.
There was a problem hiding this comment.
@hongliangl could you another issue for proxyAll with networkPolicyOnly mode?
We can merge the PR first, at least it doesn't worse proxyAll with networkPolicyOnly.
There was a problem hiding this comment.
Sure, will do it.
There was a problem hiding this comment.
Yes at the very least we should fail early when we validate options, and longer term we can investigate supporting proxyAll for policyOnly mode.
|
/test-windows-all |
|
/test-conformance |
hongliangl
deleted the
20240419-use-regmark-to-identify-svc-traffic-from-pod
branch
…antrea-io#6251) Before this commit, in AntreaProxy, to respect short-circuiting, when installing flows for an external Services, an extra flow with higher priority to match traffic sourced from local (local Pods or local Node) and destined for the external Service will be installed. This is achieved by matching the local Pod CIDR obtained from the local Node object. However, when Antrea is deployed in networkPolicyOnly mode, the Pod CIDR in the local Node object is nil, resulting in the failure of install the extra flow mentioned above. To fix the issue, a new reg mark `FromLocalRegMark` identifying traffic from local Pods or the local Node is introduced to mark the traffic from local. This reg mark can be used in all traffic mode. Fix antrea-io#6244 Signed-off-by: Hongliang Liu <lhongliang@vmware.com>
…antrea-io#6251) Before this commit, in AntreaProxy, to respect short-circuiting, when installing flows for an external Services, an extra flow with higher priority to match traffic sourced from local (local Pods or local Node) and destined for the external Service will be installed. This is achieved by matching the local Pod CIDR obtained from the local Node object. However, when Antrea is deployed in networkPolicyOnly mode, the Pod CIDR in the local Node object is nil, resulting in the failure of install the extra flow mentioned above. To fix the issue, a new reg mark `FromLocalRegMark` identifying traffic from local Pods or the local Node is introduced to mark the traffic from local. This reg mark can be used in all traffic mode. Fix antrea-io#6244 Signed-off-by: Hongliang Liu <lhongliang@vmware.com>
…antrea-io#6251) Before this commit, in AntreaProxy, to respect short-circuiting, when installing flows for an external Services, an extra flow with higher priority to match traffic sourced from local (local Pods or local Node) and destined for the external Service will be installed. This is achieved by matching the local Pod CIDR obtained from the local Node object. However, when Antrea is deployed in networkPolicyOnly mode, the Pod CIDR in the local Node object is nil, resulting in the failure of install the extra flow mentioned above. To fix the issue, a new reg mark `FromLocalRegMark` identifying traffic from local Pods or the local Node is introduced to mark the traffic from local. This reg mark can be used in all traffic mode. Fix antrea-io#6244 Signed-off-by: Hongliang Liu <lhongliang@vmware.com>
…#6251) (#6268) Before this commit, in AntreaProxy, to respect short-circuiting, when installing flows for an external Services, an extra flow with higher priority to match traffic sourced from local (local Pods or local Node) and destined for the external Service will be installed. This is achieved by matching the local Pod CIDR obtained from the local Node object. However, when Antrea is deployed in networkPolicyOnly mode, the Pod CIDR in the local Node object is nil, resulting in the failure of install the extra flow mentioned above. To fix the issue, a new reg mark `FromLocalRegMark` identifying traffic from local Pods or the local Node is introduced to mark the traffic from local. This reg mark can be used in all traffic mode. Fix #6244 Signed-off-by: Hongliang Liu <lhongliang@vmware.com>
…#6251) (#6269) Before this commit, in AntreaProxy, to respect short-circuiting, when installing flows for an external Services, an extra flow with higher priority to match traffic sourced from local (local Pods or local Node) and destined for the external Service will be installed. This is achieved by matching the local Pod CIDR obtained from the local Node object. However, when Antrea is deployed in networkPolicyOnly mode, the Pod CIDR in the local Node object is nil, resulting in the failure of install the extra flow mentioned above. To fix the issue, a new reg mark `FromLocalRegMark` identifying traffic from local Pods or the local Node is introduced to mark the traffic from local. This reg mark can be used in all traffic mode. Fix #6244 Signed-off-by: Hongliang Liu <lhongliang@vmware.com>
Before this commit, in AntreaProxy, to respect short-circuiting, when installing flows for an external Services, an extra flow with higher priority to match traffic sourced from local (local Pods or local Node) and destined for the external Service will be installed. This is achieved by matching the local Pod CIDR obtained from the local Node object. However, when Antrea is deployed in networkPolicyOnly mode, the Pod CIDR in the local Node object is nil, resulting in the failure of install the extra flow mentioned above. To fix the issue, a new reg mark
FromLocalRegMarkidentifying traffic from local Pods or the local Node is introduced to mark the traffic from local. This reg mark can be used in all traffic mode.Fix #6244