Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Initial egress connections from Pods go out with node IP rather than Egress IP assigned #3361

Closed
tnqn opened this issue Feb 25, 2022 · 0 comments · Fixed by #3360
Closed

Initial egress connections from Pods go out with node IP rather than Egress IP assigned #3361

tnqn opened this issue Feb 25, 2022 · 0 comments · Fixed by #3360
Labels
kind/bug Categorizes issue or PR as related to a bug.

Comments

@tnqn
Copy link
Member

tnqn commented Feb 25, 2022

Describe the bug

If a Pod tries to access external right after it's up, Node IP will be used as the SNAT IP even when an Egress applying to it has been created.

To Reproduce

  1. Create an Egress first
  2. Create a Pod the above Egress will apply to. Set the Pod's command to access external server.
  3. Check the access log of external server, the client IP will be the Node IP, instead of the Egress IP.

Expected

A Pod should use Egress IP as source IP when accessing external in its whole lifycycle consistently when the Egress is created in advance.

Actual behavior

A Pod uses Node IP first, then Egress IP even when the Egress is created in advance.

Versions:

  • Antrea version (Docker image tag). 1.5.0
@tnqn tnqn added the kind/bug Categorizes issue or PR as related to a bug. label Feb 25, 2022
tnqn added a commit to tnqn/antrea that referenced this issue Feb 25, 2022
@tnqn
Realize Egress for a Pod once its network is created
8697a9d 
Previously antrea-controller only included a Pod in an EgressGroup only
when its IP has been presented in K8s API. If a Pod tries to access
external right after it's up, Node IP will be used as the SNAT IP even
when an Egress applying to it has been created because its Pod IP may
haven't been reported to K8s API or antrea-controller may haven't
included the Pod in the EgressGroup.

This patch fixes it by making CNIServer notify EgressController that it
has processed CNI ADD request of a Pod, then EgressController can
reconcile the corresponding Egress immediately, instead of waiting for
the Pod to be reported to K8s API. As NetworkPolicyController relies on
that event as well, we introduce a channel implementation which supports
multiple subscribers.

Fixes antrea-io#3361

Signed-off-by: Quan Tian <qtian@vmware.com>
@tnqn tnqn mentioned this issue Feb 25, 2022
Merged
tnqn added a commit to tnqn/antrea that referenced this issue Feb 25, 2022
@tnqn
Realize Egress for a Pod once its network is created
053a48c 
Previously antrea-controller only included a Pod in an EgressGroup only
when its IP has been presented in K8s API. If a Pod tries to access
external right after it's up, Node IP will be used as the SNAT IP even
when an Egress applying to it has been created because its Pod IP may
haven't been reported to K8s API or antrea-controller may haven't
included the Pod in the EgressGroup.

This patch fixes it by making CNIServer notify EgressController that it
has processed CNI ADD request of a Pod, then EgressController can
reconcile the corresponding Egress immediately, instead of waiting for
the Pod to be reported to K8s API. As NetworkPolicyController relies on
that event as well, we introduce a channel implementation which supports
multiple subscribers.

Fixes antrea-io#3361

Signed-off-by: Quan Tian <qtian@vmware.com>
tnqn added a commit to tnqn/antrea that referenced this issue Feb 28, 2022
@tnqn
Realize Egress for a Pod once its network is created
25d0aee 
Previously antrea-controller only included a Pod in an EgressGroup only
when its IP has been presented in K8s API. If a Pod tries to access
external right after it's up, Node IP will be used as the SNAT IP even
when an Egress applying to it has been created because its Pod IP may
haven't been reported to K8s API or antrea-controller may haven't
included the Pod in the EgressGroup.

This patch fixes it by making CNIServer notify EgressController that it
has processed CNI ADD request of a Pod, then EgressController can
reconcile the corresponding Egress immediately, instead of waiting for
the Pod to be reported to K8s API. As NetworkPolicyController relies on
that event as well, we introduce a channel implementation which supports
multiple subscribers.

Fixes antrea-io#3361

Signed-off-by: Quan Tian <qtian@vmware.com>
tnqn added a commit to tnqn/antrea that referenced this issue Mar 1, 2022
@tnqn
Realize Egress for a Pod once its network is created
c24e914 
Previously antrea-controller included a Pod in an EgressGroup only when
its IP has been presented in K8s API. If a Pod tries to access external
right after it's up, Node IP will be used as the SNAT IP even when an
Egress applying to it has been created because its Pod IP may haven't
been reported to K8s API or antrea-controller may haven't included the
Pod in the EgressGroup.

This patch fixes it by making CNIServer notify EgressController that it
has processed CNI ADD request of a Pod, then EgressController can
reconcile the corresponding Egress immediately, instead of waiting for
the Pod to be reported to K8s API. As NetworkPolicyController relies on
that event as well, we introduce a channel implementation which supports
multiple subscribers.

Fixes antrea-io#3361

Signed-off-by: Quan Tian <qtian@vmware.com>
@tnqn tnqn closed this as completed in #3360 Mar 2, 2022
tnqn added a commit that referenced this issue Mar 2, 2022
@tnqn
Realize Egress for a Pod once its network is created (#3360)
24f85ce 
Previously antrea-controller included a Pod in an EgressGroup only when
its IP has been presented in K8s API. If a Pod tries to access external
right after it's up, Node IP will be used as the SNAT IP even when an
Egress applying to it has been created because its Pod IP may haven't
been reported to K8s API or antrea-controller may haven't included the
Pod in the EgressGroup.

This patch fixes it by making CNIServer notify EgressController that it
has processed CNI ADD request of a Pod, then EgressController can
reconcile the corresponding Egress immediately, instead of waiting for
the Pod to be reported to K8s API. As NetworkPolicyController relies on
that event as well, we introduce a channel implementation which supports
multiple subscribers.

Fixes #3361

Signed-off-by: Quan Tian <qtian@vmware.com>
tnqn added a commit to tnqn/antrea that referenced this issue Mar 2, 2022
@tnqn
Realize Egress for a Pod once its network is created
e6c44e1 
Previously antrea-controller included a Pod in an EgressGroup only when
its IP has been presented in K8s API. If a Pod tries to access external
right after it's up, Node IP will be used as the SNAT IP even when an
Egress applying to it has been created because its Pod IP may haven't
been reported to K8s API or antrea-controller may haven't included the
Pod in the EgressGroup.

This patch fixes it by making CNIServer notify EgressController that it
has processed CNI ADD request of a Pod, then EgressController can
reconcile the corresponding Egress immediately, instead of waiting for
the Pod to be reported to K8s API. As NetworkPolicyController relies on
that event as well, we introduce a channel implementation which supports
multiple subscribers.

Fixes antrea-io#3361

Signed-off-by: Quan Tian <qtian@vmware.com>
tnqn added a commit that referenced this issue Mar 3, 2022
@tnqn
Realize Egress for a Pod once its network is created (#3378)
318ccde 
Previously antrea-controller included a Pod in an EgressGroup only when
its IP has been presented in K8s API. If a Pod tries to access external
right after it's up, Node IP will be used as the SNAT IP even when an
Egress applying to it has been created because its Pod IP may haven't
been reported to K8s API or antrea-controller may haven't included the
Pod in the EgressGroup.

This patch fixes it by making CNIServer notify EgressController that it
has processed CNI ADD request of a Pod, then EgressController can
reconcile the corresponding Egress immediately, instead of waiting for
the Pod to be reported to K8s API. As NetworkPolicyController relies on
that event as well, we introduce a channel implementation which supports
multiple subscribers.

Fixes #3361

Signed-off-by: Quan Tian <qtian@vmware.com>
GraysonWu pushed a commit to GraysonWu/antrea that referenced this issue Mar 10, 2022
@tnqn @GraysonWu
Realize Egress for a Pod once its network is created (antrea-io#3360)
f5142bb 
Previously antrea-controller included a Pod in an EgressGroup only when
its IP has been presented in K8s API. If a Pod tries to access external
right after it's up, Node IP will be used as the SNAT IP even when an
Egress applying to it has been created because its Pod IP may haven't
been reported to K8s API or antrea-controller may haven't included the
Pod in the EgressGroup.

This patch fixes it by making CNIServer notify EgressController that it
has processed CNI ADD request of a Pod, then EgressController can
reconcile the corresponding Egress immediately, instead of waiting for
the Pod to be reported to K8s API. As NetworkPolicyController relies on
that event as well, we introduce a channel implementation which supports
multiple subscribers.

Fixes antrea-io#3361

Signed-off-by: Quan Tian <qtian@vmware.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
kind/bug Categorizes issue or PR as related to a bug.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Realize Egress for a Pod once its network is created tnqn/antrea
1 participant
@tnqn