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

Commits on Mar 10, 2021

  1. Refactor chain setup for NodePort and ExternalIP

    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>
    alexanderConstantinescu committed Mar 10, 2021
    Configuration menu
    Copy the full SHA
    d815b1d View commit details
    Browse the repository at this point in the history