Merge pull request #63236 from jab-rh/fixup-netpol-yaml

Fix YAML indentation for network policy optimization

Author: jab-rh

modules/nw-networkpolicy-optimize-ovn.adoc

@@ -3,11 +3,11 @@
 // * networking/network_policy/about-network-policy.adoc
 
 [id="nw-networkpolicy-optimize-ovn_{context}"]
-= Optimizations for network policy with OpenShift OVN
+= Optimizations for network policy with OVN-Kubernetes network plugin
 
 When designing your network policy, refer to the following guidelines:
 
-* 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.
+* 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.
 
 * 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.
 +
@@ -18,18 +18,18 @@ For example, the following policy contains two rules:
 apiVersion: networking.k8s.io/v1
 kind: NetworkPolicy
 metadata:
- name: test-network-policy
+  name: test-network-policy
 spec:
   podSelector: {}
   ingress:
-    - from:
-       - podSelector:
-           matchLabels:
-             role: frontend
-    - from:
-       - podSelector:
-           matchLabels:
-             role: backend
+  - from:
+    - podSelector:
+        matchLabels:
+          role: frontend
+  - from:
+    - podSelector:
+        matchLabels:
+          role: backend
 ----
 +
 The following policy expresses those same two rules as one:
@@ -39,60 +39,66 @@ The following policy expresses those same two rules as one:
 apiVersion: networking.k8s.io/v1
 kind: NetworkPolicy
 metadata:
- name: test-network-policy
+  name: test-network-policy
 spec:
   podSelector: {}
   ingress:
-    - from:
-       - podSelector:
-           matchExpressions:
-             - {key: role, operator: In, values: [frontend, backend]}
+  - from:
+    - podSelector:
+        matchExpressions:
+        - {key: role, operator: In, values: [frontend, backend]}
 ----
 +
 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:
 +
 [source,yaml]
 ----
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
 metadata:
- name: policy1
+  name: policy1
 spec:
- podSelector:
-   matchLabels:
-     role: db
+  podSelector:
+    matchLabels:
+      role: db
   ingress:
-    - from:
-       - podSelector:
-           matchLabels:
-             role: frontend
-
+  - from:
+    - podSelector:
+        matchLabels:
+          role: frontend
+---
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
 metadata:
- name: policy2
+  name: policy2
 spec:
- podSelector:
-   matchLabels:
-     role: client
+  podSelector:
+    matchLabels:
+      role: client
   ingress:
-    - from:
-       - podSelector:
-           matchLabels:
-             role: frontend
+  - from:
+    - podSelector:
+        matchLabels:
+          role: frontend
 ----
 +
 The following network policy expresses those same two rules as one:
 +
 [source,yaml]
 ----
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
 metadata:
- name: policy3
+  name: policy3
 spec:
- podSelector:
-   matchExpressions:
-     - {key: role, operator: In, values: [db, client]}
+  podSelector:
+    matchExpressions:
+    - {key: role, operator: In, values: [db, client]}
   ingress:
-    - from:
-       - podSelector:
-           matchLabels:
-             role: frontend
+  - from:
+    - podSelector:
+        matchLabels:
+          role: frontend
 ----
 +
 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.