OCP4.6 - Switch to OVN Container Network Interface

BCDevOps / OpenShift4-RollOut

This is the primary board for all activities related to the roll out of OpenShift 4

Apache License 2.0

0 stars 2 forks source link

OCP4.6 - Switch to OVN Container Network Interface #447

Closed StevenBarre closed 2 years ago

StevenBarre commented 3 years ago

Describe the issue OVN is now GA in OCP4.6. The default remains "OpenShift SDN". We need to determine if we want to make the switch and how to accomplish the switch.

Which Sprint Goal is this issue related to?

Additional context The migration process is disruptive.

While performing the migration, your cluster is unavailable and workloads might be interrupted. Perform the migration only when an interruption in service is acceptable.

Blocked by recommendation from Matt Robson until OVN is standard in Openshift new installs (4.8 or 4.9).

Definition of done Checklist (where applicable)

[x] Determine pros/cons of switching
[x] Decide if we'll make the switch
[ ] Resume work when OVN is the standard in a new OCP release
[ ] Ensure install playbooks for new clusters select the right CNI
[ ] Test and document the switch in LAB
[ ] Plan an outage window for SILVER and make the switch

StevenBarre commented 3 years ago

Pro

Performance improvements from ditching iptables
OVN network stack is the direction of new feature development with RH for networking.

Con

Minor disruption to workloads during upgrade

StevenBarre commented 3 years ago

@mrobson any advice you can provide around deciding if / when we should upgrade? It seems we need a cluster outage to perform this change. Not sure if the benefit is worth the downtime.

StevenBarre commented 3 years ago

@j-pye will OVN impact Aporeto in any way?

StevenBarre commented 3 years ago

Both SDNs can co-exist and communicate with each other. Routes will continue to operate throughout the change and intra-pod communication will still work. Nodes with the old SDN will be unable to accept new workloads. So the first App node evacuated will have no where to send its pods causing a delay in scheduling their replacements until the node is back up and ready. Once the first few app nodes have the new SDN and are rebooted the change should proceed similar to any other patching with nodes being drained serially and pods being rescheduled onto other nodes.

This change can be done during business hours as it is only a little more disruptive than regular patching. Highly available apps should be largely resilient to this change.

StevenBarre commented 3 years ago

The original goal was to migrate to OVN before our production launch, but this was delayed until 4.6 (when OVN is generally available instead of Tech Preview)

We have made the decision to do the upgrade after the 4.6 upgrade as a separate maintenance and after testing Aporeto and Aqua if needed.

wmhutchison commented 2 years ago

The latest from Red Hat is that we should not be considering an upgrade to OVN until we're running an Openshift version that starts using OVN as the default on a new cluster install. This ticket will be revisited for consideration once that's changed.

StevenBarre commented 2 years ago

My understanding from Red Hat is they still don't have a well tested migration path from the old SDN to OVN. And it could be delayed until 4.9 or later.

Will close this and create a new ticket if/when we get an all clear from RH to upgrade.