EgressIP for OVN-Kubernetes

[alexanderConstantinescu]

- What this PR does and why is it needed

This PR implements the OpenShift specific feature: "egress IP", for ovn-kubernetes.

In short concerning what this feature does, for those who do not know:

It allows a cluster admin to specify a fixed source IP address for all south -> north traffic, originating from pods/namespaces that the user defines. More detail about the feature is described here: https://github.com/alexanderConstantinescu/enhancements/blob/ovn_egressip/enhancements/network/egressip_for_ovn_kubernetes.md

- Special notes for reviewers

Unfortunately for us, the implementation of this feature depends on the mode ovn-kubernetes is running in. In local gateway mode we will need to use iptables to filter the outgoing node traffic on the correct pods, whereas in shared gateway mode it suffices to create NAT rules in OVN for this to happen. Hence the implementation on both master and node's side need to take this into account.

This PR has been split into as many logical commits as I saw fit. In general the PR does the following:

• Defines the CRD needed for this
• Adds all building blocks for the implementation to happen
• Split the implementation into node / master
• Adds the proper configuration / tools needed to run this from our infrastructure

This feature can be enabled/disabled using the egress-ip-enable flag, in which case the informer is not started and no watchers created - as to not impact the running performance of any ovn-kubernetes instances not wishing to use egress IP.

@dcbw @danwinship @girishmg @trozet

- How to verify it

- Description for the changelog

[coveralls]

Coverage increased (+0.4%) to 59.369% when pulling b56518a on alexanderConstantinescu:egressip_v3 into 7780456 on ovn-org:master.

[trozet]

Thanks for breaking it up into a bunch of commits. It makes it easier to follow for a big patch. Can you also please add a test case for this in the ovn-k8s control plane tests? For example, create an egress IP on a node A, and create a pod on another node B. Verify the packet leaves node A with the correct source IP when going to the internet, and that a response comes back. @nerdalert can help you with creating a test like that if you need some help.

[alexanderConstantinescu]

WARNING: DATA RACE
Write at 0x00c0002b6e00 by goroutine 16:
  github.com/ovn-org/ovn-kubernetes/go-controller/pkg/factory.glob..func1.1()
      /home/runner/work/ovn-kubernetes/ovn-kubernetes/go-controller/pkg/factory/factory_test.go

🤔

/retest

[aojea]

WARNING: DATA RACE
Write at 0x00c0002b6e00 by goroutine 16:
  github.com/ovn-org/ovn-kubernetes/go-controller/pkg/factory.glob..func1.1()
      /home/runner/work/ovn-kubernetes/ovn-kubernetes/go-controller/pkg/factory/factory_test.go

/retest

do you have the full stack trace or the link to the log?

[alexanderConstantinescu]

WARNING: DATA RACE
Write at 0x00c0002b6e00 by goroutine 16:
  github.com/ovn-org/ovn-kubernetes/go-controller/pkg/factory.glob..func1.1()
      /home/runner/work/ovn-kubernetes/ovn-kubernetes/go-controller/pkg/factory/factory_test.go

/retest

do you have the full stack trace or the link to the log?

I see it failed again, so if you click on the red build here in github (or here: https://github.com/ovn-org/ovn-kubernetes/pull/1484/checks?check_run_id=904234163) you should be able to see it

[trozet]

WARNING: DATA RACE
Write at 0x00c0002b6e00 by goroutine 16:
  github.com/ovn-org/ovn-kubernetes/go-controller/pkg/factory.glob..func1.1()
      /home/runner/work/ovn-kubernetes/ovn-kubernetes/go-controller/pkg/factory/factory_test.go

/retest

do you have the full stack trace or the link to the log?

I see it failed again, so if you click on the red build here in github (or here: https://github.com/ovn-org/ovn-kubernetes/pull/1484/checks?check_run_id=904234163) you should be able to see it

@aojea I'm kind of inclined to disable the race detection on testing code on PRs and make it a periodic job. We dont need to test the test code for races on each PR do we? I am all for testing for races in the real ovn-k8s code on PR, but these factory test races seem to just be more of a headache than a help right now.

[aojea]

do you have the full stack trace or the link to the log?

I see it failed again, so if you click on the red build here in github (or here: https://github.com/ovn-org/ovn-kubernetes/pull/1484/checks?check_run_id=904234163) you should be able to see it

I see it now, I think I know the problem 🤔

WARNING: DATA RACE
Write at 0x00c0002b6e00 by goroutine 16:
  github.com/ovn-org/ovn-kubernetes/go-controller/pkg/factory.glob..func1.1()
      /home/runner/work/ovn-kubernetes/ovn-kubernetes/go-controller/pkg/factory/factory_test.go

/retest

do you have the full stack trace or the link to the log?

I see it failed again, so if you click on the red build here in github (or here: https://github.com/ovn-org/ovn-kubernetes/pull/1484/checks?check_run_id=904234163) you should be able to see it

@aojea I'm kind of inclined to disable the race detection on testing code on PRs and make it a periodic job. We dont need to test the test code for races on each PR do we? I am all for testing for races in the real ovn-k8s code on PR, but these factory test races seem to just be more of a headache than a help right now.

seems this is a legit race, I'm not hitting it in master

/usr/bin/go test github.com/ovn-org/ovn-kubernetes/go-controller/pkg/factory -run ^TestFactory$ -race -test.count 100 -ginkgo.failFast -v

[danwinship]

rebased and repushed. I couldn't build without fixing go.mod first; it seems to have been broken by the windows service merge (the vendored version of golang.com/x/sys no longer matched what was required in go.mod)

[dcbw]

@alexanderConstantinescu see #1564 for OVN bump