-
Notifications
You must be signed in to change notification settings - Fork 347
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
Direct ingress for default network in SGW mode with route advertisements #4533
Draft
jcaamano
wants to merge
14
commits into
ovn-org:master
Choose a base branch
from
jcaamano:racontroller
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
github-actions
bot
added
the
area/unit-testing
Issues related to adding/updating unit tests
label
Jul 16, 2024
jcaamano
force-pushed
the
racontroller
branch
2 times, most recently
from
July 17, 2024 08:42
ae1dce0
to
6e2fabd
Compare
github-actions
bot
added
the
feature/egress-ip
Issues related to EgressIP feature
label
Jul 18, 2024
jcaamano
force-pushed
the
racontroller
branch
6 times, most recently
from
July 24, 2024 15:11
acea938
to
c8be469
Compare
jcaamano
force-pushed
the
racontroller
branch
2 times, most recently
from
July 30, 2024 12:44
2050511
to
dcbdb32
Compare
jcaamano
force-pushed
the
racontroller
branch
5 times, most recently
from
August 21, 2024 11:34
213b315
to
9c0b8bf
Compare
tssurya
added
feature/bgp
and removed
feature/egress-ip
Issues related to EgressIP feature
labels
Aug 21, 2024
jcaamano
force-pushed
the
racontroller
branch
2 times, most recently
from
September 17, 2024 10:25
4bba83c
to
482559b
Compare
jcaamano
force-pushed
the
racontroller
branch
from
October 10, 2024 09:47
482559b
to
152a5ec
Compare
github-actions
bot
added
kind/documentation
All issues related to documentation
area/e2e-testing
feature/admin-network-policy
feature/egress-service
Issues related to egress service
feature/services&endpoints
All issues related to the Servces/Endpoints API
feature/kubevirt-live-migration
All issues related to kubevirt live migration
feature/egress-gateway
All issues related to ICNI/APBR
feature/egress-firewall
All issues related to egress firewall
feature/egress-qos
labels
Oct 10, 2024
jcaamano
force-pushed
the
racontroller
branch
2 times, most recently
from
October 11, 2024 10:52
09ed1c5
to
30b15b6
Compare
Signed-off-by: Jaime Caamaño Ruiz <[email protected]>
For go-controller: go get k8s.io/[email protected] go get k8s.io/[email protected] go get k8s.io/[email protected] go get k8s.io/[email protected] go get k8s.io/[email protected] go get k8s.io/[email protected] go get k8s.io/[email protected] go get sigs.k8s.io/[email protected] go mod vendor && go mod tidy Fixed API changes Fixed linting Updated codegen For e2e tests: go get k8s.io/[email protected] go get k8s.io/[email protected] go get k8s.io/[email protected] go get k8s.io/[email protected] go get k8s.io/[email protected] go get k8s.io/[email protected] go get k8s.io/[email protected] go get k8s.io/[email protected] go get k8s.io/[email protected] go get k8s.io/[email protected] go get k8s.io/[email protected] go get k8s.io/[email protected] go get k8s.io/[email protected] go get k8s.io/[email protected] go get github.com/ovn-org/ovn-kubernetes/go-controller go mod edit -replace github.com/coreos/go-iptables=github.com/trozet/[email protected] go mod tidy (konnectivity-client is not at 0.31 yet) Fixed API changes Fixed skip for some upstream e2e tests that were added and we don't support Signed-off-by: Jaime Caamaño Ruiz <[email protected]>
Signed-off-by: Jaime Caamaño Ruiz <[email protected]>
Signed-off-by: Jaime Caamaño Ruiz <[email protected]>
Signed-off-by: Jaime Caamaño Ruiz <[email protected]>
Signed-off-by: Jaime Caamaño Ruiz <[email protected]>
Signed-off-by: Jaime Caamaño Ruiz <[email protected]>
Adds to NetInfo the concept of reconcilable network information. This is network information that can change dynamically and network controllers should be able to reconcile. This includes NADs which is information that network controllers should have already been capable of reconciling although they currently don't (for example, for multinetwork policies). Also includes VRFs the network is leaking/advertising to, per node, that network controllers need to be aware of and rec0oncile as it changes. Signed-off-by: Jaime Caamaño Ruiz <[email protected]>
Add the ability for network controllers to reconcile some network information changes. Currently just changes of the VRFs the network is leaking/advertising to. Support for reconciling NAD changes is not included in this commit. Currently reconciles if the network is advertised or not: - for OVN network controller to configure or not the pod IP to node IP SNAT on the GR for a node of its zone - for node network controller to configure or not br-ex flows to redirect pod IP ingress traffic to the OVN network This should be enough to provide direct ingress capabilities for the default network in SGW mode. Note that secondary network controllers don't reconcile anything as route advertising is not supported on them. Also cluster manager network controllers don't reconcile much as they don't have the need. Signed-off-by: Jaime Caamaño Ruiz <[email protected]>
The plan is for the NAD controller to fetch route advertising information on behalf of network controllers. It will have to do so for the default network as well and will need access to its network controller to reconcile that information. Signed-off-by: Jaime Caamaño Ruiz <[email protected]>
As node controllers will need to be informed of related events in new level driven controllers to come. Signed-off-by: Jaime Caamaño Ruiz <[email protected]>
This annotation will be set by a future cluster manager controller on the NADs and will list the names of route advertisements that apply to the given NAD. This will ease processing time of other zone/node controllers that need to track which route advertisements apply to a network avoiding them from processing all route advertisements on each of their reconciliation loops. Note that this will happen for the default network as well. For that probably a dummy NAD on ovn-kubernetes namespace is the best option. Signed-off-by: Jaime Caamaño Ruiz <[email protected]>
jcaamano
force-pushed
the
racontroller
branch
from
October 14, 2024 16:22
30b15b6
to
3590cbe
Compare
The network manager running within the NAD controller will, upon ensuring a network, fetch the VRFs per node a pod network is being leaked/advertised to from the applicable route advertisements configuration, and include it in the network information used when creating a network controller, or triggering a reconciliation if it was already running. This relies on annotations set by cluster manager on NADs pointing to the route advertising configuration that applies to the network which will come in a future PR/commit. This includes the default network for which the ever existing default network controller is used (instead of creating a new network controller). If necessary, it is assumed that cluster manager will create a dummy NAD for the default network in ovn-k namespace to set annotations on. If no NADs for the default network exist or if they have no annotations, network manager will reconcile the default network to a default configuration (instead of destroying the network controller). Signed-off-by: Jaime Caamaño Ruiz <[email protected]>
Signed-off-by: Jaime Caamaño Ruiz <[email protected]>
jcaamano
force-pushed
the
racontroller
branch
from
October 14, 2024 17:17
3590cbe
to
5d6c75b
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
area/e2e-testing
area/unit-testing
Issues related to adding/updating unit tests
feature/admin-network-policy
feature/bgp
feature/egress-firewall
All issues related to egress firewall
feature/egress-gateway
All issues related to ICNI/APBR
feature/egress-ip
Issues related to EgressIP feature
feature/egress-qos
feature/egress-service
Issues related to egress service
feature/kubevirt-live-migration
All issues related to kubevirt live migration
feature/services&endpoints
All issues related to the Servces/Endpoints API
kind/documentation
All issues related to documentation
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The network manager running within the NAD controller will, upon
ensuring a network, fetch the VRFs per node a pod network is being
leaked/advertised to from the applicable route advertisements
configuration, and include it in the network information used when
creating a network controller, or triggering a reconciliation if it was
already running.
This relies on annotations set by cluster manager on NADs pointing to
the route advertising configuration that applies to the network which
will come in a future PR/commit.
This includes the default network for which the ever existing default
network controller is used (instead of creating a new network
controller). If necessary, it is assumed that cluster manager will
create a dummy NAD for the default network in ovn-k namespace to set
annotations on. If no NADs for the default network exist or if they have
no annotations, network manager will reconcile the default network to a
default configuration (instead of destroying the network controller).
Add the ability for network controllers to reconcile some network
information changes. Currently just changes of the VRFs the network is
leaking/advertising to. Support for reconciling NAD changes is not
included in this commit.
Currently reconciles if the network is advertised or not:
SNAT on the GR for a node of its zone
redirect pod IP ingress traffic to the OVN network
This should be enough to provide direct ingress capabilities for the
default network in SGW mode.
Note that secondary network controllers don't reconcile anything as
route advertising is not supported on them. Also cluster manager network
controllers don't reconcile much as they don't have the need.
Currently based on top of #4472