Skip to content

OSDOCS-16284: Added OVNK and SDNstatements tto nw-networkpolicy-about… #100931

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.

Sign up for GitHub

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

Open
wants to merge 1 commit into
base: enterprise-4.16
Choose a base branch
from
Open

OSDOCS-16284: Added OVNK and SDNstatements tto nw-networkpolicy-about… #100931

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 4 additions & 3 deletions modules/nw-networkpolicy-about.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,12 +6,13 @@
[id="nw-networkpolicy-about_{context}"]
= About network policy

In a cluster using a network plugin that supports Kubernetes network policy, network isolation is controlled entirely by `NetworkPolicy` objects.
In {product-title} {product-version}, OpenShift SDN supports using network policy in its default network isolation mode.
In a cluster that uses a network plugin that supports a Kubernetes network policy, `NetworkPolicy` objects controls network isolation. In {product-title} {product-version}, OpenShift SDN supports using network policy in its default network isolation mode.

[WARNING]
====
* A network policy does not apply to the host network namespace. Pods with host networking enabled are unaffected by network policy rules. However, pods connecting to the host-networked pods might be affected by the network policy rules.
* On OpenShift-SDN, a network policy does not apply to the host network namespace. Network policy rules do not impact pods configured with host networking enabled. Network policy rules might impact pods connected to host-networked pods.

* On Openshift-OVN-Kubernetes, a network policy manages traffic from host subnets separately from traffic on pod networks. Before any other network policies can affect pods with host networking enabled, you must explicitly allow those pods in your network policy rules. If a namespace has any network policy applied, traffic originating from system components, such as `openshift-ingress` or `openshift-kube-apiserver`, get dropped by default; You must explicitly enable this traffic to allow it through.

* Using the `namespaceSelector` field without the `podSelector` field set to `{}` will not include `hostNetwork` pods. You must use the `podSelector` set to `{}` with the `namespaceSelector` field in order to target `hostNetwork` pods when creating network policies.

Expand Down
4 changes: 3 additions & 1 deletion modules/nw-ovn-kubernetes-live-migration-about.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@
[id="nw-ovn-kubernetes-live-migration-about_{context}"]
= Limited live migration to the OVN-Kubernetes network plugin overview

The limited live migration method is the process in which the OpenShift SDN network plugin and its network configurations, connections, and associated resources, are migrated to the OVN-Kubernetes network plugin without service interruption. It is available for {product-title}, and is the preferred method for migrating from OpenShift SDN to OVN-Kubernetes. In the event that you cannot perform a limited live migration, you can use the offline migration method.
The limited live migration method is the process in which the OpenShift SDN network plugin and its network configurations, connections, and associated resources, are migrated to the OVN-Kubernetes network plugin without service interruption. It is available for {product-title}, and is the preferred method for migrating from OpenShift SDN to OVN-Kubernetes. If you cannot perform a limited live migration, you can use the offline migration method.

[IMPORTANT]
====
Expand Down Expand Up @@ -98,3 +98,5 @@ During the limited live migration, both OVN-Kubernetes and OpenShift SDN run in
After migration, manual verification of RBAC resources is required. For information about setting the `aggregate-to-admin` ClusterRole after migration, see the example in link:https://access.redhat.com/solutions/6117301[How to allow project admins to manage Egressfirewall resources in RHOCP4].

* When a cluster depends on static routes or routing policies in the host network so that pods can reach some destinations, users should set `routingViaHost` spec to `true` and `ipForwarding` to `Global` in the `gatewayConfig` object before the migration. This will offload routing decision to host kernel. For more information, see link:https://access.redhat.com/solutions/7070870[Recommended practice to follow before Openshift SDN network plugin migration to OVNKubernetes plugin] (Red Hat Knowledgebase) and, see step five in "Checking cluster resources before initiating the limited live migration".

* To prevent traffic flow issues, check existing network policies in any namespaces that host applications that rely on system components. If a policy exists, enable traffic that originates from `openshift-ingress` or `openshift-kube-apiserver` system services to prevent the default setting from blocking this traffic.
6 changes: 3 additions & 3 deletions modules/nw-ovn-kubernetes-migration-about.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -89,9 +89,9 @@ While the OVN-Kubernetes network plugin implements many of the capabilities pres

* If your `openshift-sdn` cluster with Precision Time Protocol (PTP) uses the User Datagram Protocol (UDP) for hardware time stamping and you migrate to the OVN-Kubernetes plugin, the hardware time stamping cannot be applied to primary interface devices, such as an Open vSwitch (OVS) bridge. As a result, UDP version 4 configurations cannot work with a `br-ex` interface.

* Like OpenShift SDN, OVN-Kubernetes resources require `ClusterAdmin` privileges. Migrating from OpenShift SDN to OVN-Kubernetes does not automatically update role-base access control (RBAC) resources. OpenShift SDN resources granted to a project administrator through the `aggregate-to-admin` `ClusterRole` must be manually reviewed and adjusted, as these changes are not included in the migration process.
+
After migration, manual verification of RBAC resources is required.
* Similar to OpenShift SDN, OVN-Kubernetes resources require `ClusterAdmin` privileges. Migrating from OpenShift SDN to OVN-Kubernetes does not automatically update role-base access control (RBAC) resources. OpenShift SDN resources granted to a project administrator through the `aggregate-to-admin` `ClusterRole` must be manually reviewed and adjusted, as these changes are not included in the migration process. After migration, manual verification of RBAC resources is required.

* To prevent traffic flow issues, check existing network policies in any namespaces that host applications that rely on system components. If a policy exists, enable traffic that originates from `openshift-ingress` or `openshift-kube-apiserver` system services to prevent the default setting from blocking this traffic.

The following sections highlight the differences in configuration between the aforementioned capabilities in OVN-Kubernetes and OpenShift SDN network plugins.

Expand Down