Skip to content

Commit 5b2766e

Browse files
ahardin-rhahardin-rh
committed
OSDOCS-4696: Added Optimizations for network policy with OVN module
1 parent b23be7d commit 5b2766e

File tree

3 files changed

+103
-9
lines changed

3 files changed

+103
-9
lines changed

‎modules/nw-networkpolicy-optimize-ovn.adoc

Lines changed: 98 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,98 @@
1+
// Module included in the following assemblies:
2+
//
3+
// * networking/network_policy/about-network-policy.adoc
4+
5+
[id="nw-networkpolicy-optimize-ovn_{context}"]
6+
= Optimizations for network policy with OpenShift OVN
7+
8+
When designing your network policy, refer to the following guidelines:
9+
10+
* For network policies with the same `spec.podSelector` spec, it is more efficient to use one network policy with multiple `ingress` or `egress` rules, than multiple network policies with subsets of `ingress` or `egress` rules.
11+
12+
* Every `ingress` or `egress` rule based on the `podSelector` or `namespaceSelector` spec generates the number of OVS flows proportional to `number of pods selected by network policy + number of pods selected by ingress or egress rule`. Therefore, it is preferable to use the `podSelector` or `namespaceSelector` spec that can select as many pods as you need in one rule, instead of creating individual rules for every pod.
13+
+
14+
For example, the following policy contains two rules:
15+
+
16+
[source,yaml]
17+
----
18+
apiVersion: networking.k8s.io/v1
19+
kind: NetworkPolicy
20+
metadata:
21+
name: test-network-policy
22+
spec:
23+
podSelector: {}
24+
ingress:
25+
- from:
26+
- podSelector:
27+
matchLabels:
28+
role: frontend
29+
- from:
30+
- podSelector:
31+
matchLabels:
32+
role: backend
33+
----
34+
+
35+
The following policy expresses those same two rules as one:
36+
+
37+
[source,yaml]
38+
----
39+
apiVersion: networking.k8s.io/v1
40+
kind: NetworkPolicy
41+
metadata:
42+
name: test-network-policy
43+
spec:
44+
podSelector: {}
45+
ingress:
46+
- from:
47+
- podSelector:
48+
matchExpressions:
49+
- {key: role, operator: In, values: [frontend, backend]}
50+
----
51+
+
52+
The same guideline applies to the `spec.podSelector` spec. If you have the same `ingress` or `egress` rules for different network policies, it might be more efficient to create one network policy with a common `spec.podSelector` spec. For example, the following two policies have different rules:
53+
+
54+
[source,yaml]
55+
----
56+
metadata:
57+
name: policy1
58+
spec:
59+
podSelector:
60+
matchLabels:
61+
role: db
62+
ingress:
63+
- from:
64+
- podSelector:
65+
matchLabels:
66+
role: frontend
67+
68+
metadata:
69+
name: policy2
70+
spec:
71+
podSelector:
72+
matchLabels:
73+
role: client
74+
ingress:
75+
- from:
76+
- podSelector:
77+
matchLabels:
78+
role: frontend
79+
----
80+
+
81+
The following network policy expresses those same two rules as one:
82+
+
83+
[source,yaml]
84+
----
85+
metadata:
86+
name: policy3
87+
spec:
88+
podSelector:
89+
matchExpressions:
90+
- {key: role, operator: In, values: [db, client]}
91+
ingress:
92+
- from:
93+
- podSelector:
94+
matchLabels:
95+
role: frontend
96+
----
97+
+
98+
You can apply this optimization when only multiple selectors are expressed as one. In cases where selectors are based on different labels, it may not be possible to apply this optimization. In those cases, consider applying some new labels for network policy optimization specifically.

‎modules/nw-networkpolicy-optimize.adoc

Lines changed: 2 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -2,16 +2,11 @@
22
//
33
// * networking/network_policy/about-network-policy.adoc
44

5-
[id="nw-networkpolicy-optimize_{context}"]
6-
= Optimizations for network policy
5+
[id="nw-networkpolicy-optimize-sdn_{context}"]
6+
= Optimizations for network policy with OpenShift SDN
77

88
Use a network policy to isolate pods that are differentiated from one another by labels within a namespace.
99

10-
[NOTE]
11-
====
12-
The guidelines for efficient use of network policy rules applies to only the OpenShift SDN network plugin.
13-
====
14-
1510
It is inefficient to apply `NetworkPolicy` objects to large numbers of individual pods in a single namespace. Pod labels do not exist at the IP address level, so a network policy generates a separate Open vSwitch (OVS) flow rule for every possible link between every pod selected with a `podSelector`.
1611

1712
For example, if the spec `podSelector` and the ingress `podSelector` within a `NetworkPolicy` object each match 200 pods, then 40,000 (200*200) OVS flow rules are generated. This might slow down a node.

‎networking/network_policy/about-network-policy.adoc

Lines changed: 3 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -16,11 +16,12 @@ As a cluster administrator, you can define network policies that restrict traffi
1616
Configured network policies are ignored in IPv6 networks.
1717
====
1818

19-
2019
include::modules/nw-networkpolicy-about.adoc[leveloffset=+1]
2120

2221
include::modules/nw-networkpolicy-optimize.adoc[leveloffset=+1]
2322

23+
include::modules/nw-networkpolicy-optimize-ovn.adoc[leveloffset=+1]
24+
2425
[id="about-network-policy-next-steps"]
2526
== Next steps
2627

@@ -35,4 +36,4 @@ ifndef::openshift-rosa,openshift-dedicated[]
3536
* xref:../../authentication/using-rbac.adoc#rbac-projects-namespaces_using-rbac[Projects and namespaces]
3637
* xref:../../networking/network_policy/multitenant-network-policy.adoc#multitenant-network-policy[Configuring multitenant network policy]
3738
* xref:../../rest_api/network_apis/networkpolicy-networking-k8s-io-v1.adoc#networkpolicy-networking-k8s-io-v1[NetworkPolicy API]
38-
endif::[]
39+
endif::[]

0 commit comments

Comments
 (0)