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

Bug 1937238: Refactor chain setup for NodePort and ExternalIP #457

Conversation

alexanderConstantinescu
Copy link
Contributor

Our iptables rules for NodePort and ExternalIP services were setting
up rules in filter FORWARD, which is a table used for routing packets
which don't have the node IP as neither source nore destination IP.

This is not needed for NodePort and ExternalIP. For NodePort services we
currently DNAT directly to the gatewayIP/clusterIP when a packet hits
a node, and this happens on every node, which thus, does not warrant
setting up filter FORWARD rules. In no case will node port packets
just be forwarded to another node.

For ExternalIP there is one case where routing external IP packets to
another node does occur, but we use routing table rules to do this. Which
means the filter FORWARD rules are not needed in that case either.

The problem with having NodePort and ExternalIP iptables rules in filter
FORWARD is that: every packet on the cluster going from one node to another
will be looked up in those chains. They will never match, but the lookup
can be exteremely costly on cluster with a lot of NodePort services defined,
see: https://bugzilla.redhat.com/show_bug.cgi?id=1923157

Also, remove NAT PREROUTING in shared gateway mode, since we configure OVS
flows on the shared gateway bridge to steer traffic into OVN thus rendering
the iptables rules superflous.

Signed-off-by: Alexander Constantinescu aconstan@redhat.com

Delete stale iptables jump rules for updates

On updates we need to remove the legacy jump rules for each
mode. This will handle that. Unfortunately there's no generic
way to do so depending on the services that we find, so we
still need them hard-coded. For posteriority's sake we should
really always have them, since we don't release ovn-kubernetes
and we never know when someone deploying ovn-kubernetes reaches
N+2 and can remove these.

/assign @trozet

- What this PR does and why is it needed

- Special notes for reviewers

- How to verify it

- Description for the changelog

Our iptables rules for NodePort and ExternalIP services were setting
up rules in filter FORWARD, which is a table used for routing packets
which don't have the node IP as neither source nore destination IP.

This is not needed for NodePort and ExternalIP. For NodePort services we
currently DNAT directly to the gatewayIP/clusterIP when a packet hits
a node, and this happens on every node, which thus, does not warrant
setting up filter FORWARD rules. In no case will node port packets
just be forwarded to another node.

For ExternalIP there is one case where routing external IP packets to
another node does occur, but we use routing table rules to do this. Which
means the filter FORWARD rules are not needed in that case either.

The problem with having NodePort and ExternalIP iptables rules in filter
FORWARD is that: every packet on the cluster going from one node to another
will be looked up in those chains. They will never match, but the lookup
can be exteremely costly on cluster with a lot of NodePort services defined,
see: https://bugzilla.redhat.com/show_bug.cgi?id=1923157

Also, remove NAT PREROUTING in shared gateway mode, since we configure OVS
flows on the shared gateway bridge to steer traffic into OVN thus rendering
the iptables rules superflous.

Signed-off-by: Alexander Constantinescu <aconstan@redhat.com>

Delete stale iptables jump rules for updates

On updates we need to remove the legacy jump rules for each
mode. This will handle that. Unfortunately there's no generic
way to do so depending on the services that we find, so we
still need them hard-coded. For posteriority's sake we should
really always have them, since we don't release ovn-kubernetes
and we never know when someone deploying ovn-kubernetes reaches
N+2 and can remove these.

Signed-off-by: Alexander Constantinescu <aconstan@redhat.com>
@openshift-ci-robot openshift-ci-robot added the bugzilla/severity-high Referenced Bugzilla bug's severity is high for the branch this PR is targeting. label Mar 10, 2021
@openshift-ci-robot
Copy link
Contributor

@alexanderConstantinescu: This pull request references Bugzilla bug 1937238, which is valid. The bug has been moved to the POST state. The bug has been updated to refer to the pull request using the external bug tracker.

6 validation(s) were run on this bug
  • bug is open, matching expected state (open)
  • bug target release (4.7.z) matches configured target release for branch (4.7.z)
  • bug is in the state ASSIGNED, which is one of the valid states (NEW, ASSIGNED, ON_DEV, POST, POST)
  • dependent bug Bugzilla bug 1923157 is in the state VERIFIED, which is one of the valid states (VERIFIED, RELEASE_PENDING, CLOSED (ERRATA))
  • dependent Bugzilla bug 1923157 targets the "4.8.0" release, which is one of the valid target releases: 4.8.0
  • bug has dependents

No GitHub users were found matching the public email listed for the QA contact in Bugzilla (anusaxen@redhat.com), skipping review request.

In response to this:

Bug 1937238: Refactor chain setup for NodePort and ExternalIP

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@openshift-ci-robot openshift-ci-robot added the bugzilla/valid-bug Indicates that a referenced Bugzilla bug is valid for the branch this PR is targeting. label Mar 10, 2021
@trozet
Copy link
Contributor

trozet commented Mar 10, 2021

/lgtm

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Mar 10, 2021
@openshift-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: alexanderConstantinescu, trozet

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci-robot openshift-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Mar 10, 2021
@openshift-bot
Copy link
Contributor

/retest

Please review the full test history for this PR and help us cut down flakes.

1 similar comment
@openshift-bot
Copy link
Contributor

/retest

Please review the full test history for this PR and help us cut down flakes.

@crawford crawford added the cherry-pick-approved Indicates a cherry-pick PR into a release branch has been approved by the release branch manager. label Mar 11, 2021
@openshift-merge-robot openshift-merge-robot merged commit 01ab2cd into openshift:release-4.7 Mar 11, 2021
@openshift-ci-robot
Copy link
Contributor

@alexanderConstantinescu: All pull requests linked via external trackers have merged:

Bugzilla bug 1937238 has been moved to the MODIFIED state.

In response to this:

Bug 1937238: Refactor chain setup for NodePort and ExternalIP

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. bugzilla/severity-high Referenced Bugzilla bug's severity is high for the branch this PR is targeting. bugzilla/valid-bug Indicates that a referenced Bugzilla bug is valid for the branch this PR is targeting. cherry-pick-approved Indicates a cherry-pick PR into a release branch has been approved by the release branch manager. lgtm Indicates that a PR is ready to be merged.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants