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.

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

NetworkPolicy are not enforced correctly during upgrade #1587

Closed
tnqn opened this issue Nov 20, 2020 · 0 comments · Fixed by #1586
Closed

NetworkPolicy are not enforced correctly during upgrade #1587

tnqn opened this issue Nov 20, 2020 · 0 comments · Fixed by #1586
Labels
kind/bug Categorizes issue or PR as related to a bug.

Comments

@tnqn
Copy link
Member

tnqn commented Nov 20, 2020

Describe the bug
During upgrade, Pods on the nodes that haven't been upgraded lost connectivity after Antrea controller is upgraded to v0.11.

To Reproduce

  1. Deploy v0.10.2, create a networkpolicy that allows Pod A to access Pod B
  2. Upgrade controller to v0.11.0 and keep agent as v0.10.2.
  3. Pod A cannot access Pod B

Check openflows, the IP of Pod A was not in openflow.

Expected
NetworkPolicy should be enforced correctly after upgrading antrea-controller.

Actual behavior
NetworkPolicies that are created before upgrading antrea-controller were not enforced correctly after upgrading controller alone.

Versions:
Please provide the following information:

  • Antrea version (Docker image tag). 0.11.0
@tnqn tnqn added the kind/bug Categorizes issue or PR as related to a bug. label Nov 20, 2020
antoninbas pushed a commit that referenced this issue Nov 20, 2020
To be backwards compatible, AddressGroup v1beta1 must not include
PodReferences in its members, otherwise the agents that use v1beta1 will
think the members have changed and will add new IPs to the openflow
entries of relevant NetworkPolicies and delete old IPs from them, while
the old IPs and new IPs are actually the same. In current
implementation, deleting old IPs is executed after adding new IPs, so it
leads to some IPs missing in the openflow entries.

Fixes #1587
antoninbas pushed a commit to antoninbas/antrea that referenced this issue Nov 20, 2020
To be backwards compatible, AddressGroup v1beta1 must not include
PodReferences in its members, otherwise the agents that use v1beta1 will
think the members have changed and will add new IPs to the openflow
entries of relevant NetworkPolicies and delete old IPs from them, while
the old IPs and new IPs are actually the same. In current
implementation, deleting old IPs is executed after adding new IPs, so it
leads to some IPs missing in the openflow entries.

Fixes antrea-io#1587
antoninbas pushed a commit that referenced this issue Nov 21, 2020
To be backwards compatible, AddressGroup v1beta1 must not include
PodReferences in its members, otherwise the agents that use v1beta1 will
think the members have changed and will add new IPs to the openflow
entries of relevant NetworkPolicies and delete old IPs from them, while
the old IPs and new IPs are actually the same. In current
implementation, deleting old IPs is executed after adding new IPs, so it
leads to some IPs missing in the openflow entries.

Fixes #1587
antoninbas pushed a commit that referenced this issue Dec 23, 2020
To be backwards compatible, AddressGroup v1beta1 must not include
PodReferences in its members, otherwise the agents that use v1beta1 will
think the members have changed and will add new IPs to the openflow
entries of relevant NetworkPolicies and delete old IPs from them, while
the old IPs and new IPs are actually the same. In current
implementation, deleting old IPs is executed after adding new IPs, so it
leads to some IPs missing in the openflow entries.

Fixes #1587
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant