openshift/openshift-docs
1
0
Fork 0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 12:46:18 +01:00
Code Issues Releases Activity

OSDOCS-16835: Completed the CQA2.0 for Secondary Network Advanced Config, VRF, and Policy

Browse Source
This commit is contained in:
dfitzmau
2025-11-19 09:59:45 +00:00
committed by openshift-cherrypick-robot
parent eaa460310a
commit e877abf380
77 changed files with 866 additions and 787 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
microshift_networking/microshift_network_policy/microshift-creating-network-policy.adoc
View File

@@ -7,9 +7,9 @@ include::_attributes/common-attributes.adoc[]
toc::[] toc::[]
[role="_abstract"]
You can create a network policy for a namespace. You can create a network policy for a namespace.
//OCP modules, edit using conditions and with care (check OCP previews, too)
include::modules/nw-networkpolicy-object.adoc[leveloffset=+1] include::modules/nw-networkpolicy-object.adoc[leveloffset=+1]
include::modules/nw-networkpolicy-create-cli.adoc[leveloffset=+1] include::modules/nw-networkpolicy-create-cli.adoc[leveloffset=+1]

1
microshift_networking/microshift_network_policy/microshift-deleting-network-policy.adoc
View File

@@ -7,6 +7,7 @@ include::_attributes/attributes-microshift.adoc[]
toc::[] toc::[]
[role="_abstract"]
You can delete a network policy from a namespace. You can delete a network policy from a namespace.
include::modules/nw-networkpolicy-delete-cli.adoc[leveloffset=+1] include::modules/nw-networkpolicy-delete-cli.adoc[leveloffset=+1]

6
microshift_networking/microshift_network_policy/microshift-editing-network-policy.adoc
View File

@@ -7,9 +7,11 @@ include::_attributes/common-attributes.adoc[]
toc::[] toc::[]
You can edit an existing network policy for a namespace. Typical edits might include changes to the pods to which the policy applies, allowed ingress traffic, and the destination ports on which to accept traffic. The `apiVersion`, `kind`, and `name` fields must not be changed when editing `NetworkPolicy` objects, as these define the resource itself. [role="_abstract"]
You can edit an existing network policy for a namespace.
Typical edits might include changes to the pods to which the policy applies, allowed ingress traffic, and the destination ports on which to accept traffic. The `apiVersion`, `kind`, and `name` fields must not be changed when editing `NetworkPolicy` objects, as these define the resource itself.
//OCP modules, edit using conditionals
include::modules/nw-networkpolicy-edit.adoc[leveloffset=+1] include::modules/nw-networkpolicy-edit.adoc[leveloffset=+1]
include::modules/nw-networkpolicy-object.adoc[leveloffset=+1] include::modules/nw-networkpolicy-object.adoc[leveloffset=+1]

1
microshift_networking/microshift_network_policy/microshift-viewing-network-policy.adoc
View File

@@ -7,6 +7,7 @@ include::_attributes/attributes-microshift.adoc[]
toc::[] toc::[]
[role="_abstract"]
Use the following procedure to view a network policy for a namespace. Use the following procedure to view a network policy for a namespace.
include::modules/nw-networkpolicy-view-cli.adoc[leveloffset=+1] include::modules/nw-networkpolicy-view-cli.adoc[leveloffset=+1]

51
modules/cnf-assigning-a-secondary-network-to-a-vrf.adoc
View File

@@ -6,23 +6,22 @@
[id="cnf-creating-an-additional-network-attachment-with-the-cni-vrf-plug-in_{context}"] [id="cnf-creating-an-additional-network-attachment-with-the-cni-vrf-plug-in_{context}"]
= Creating a secondary network attachment with the CNI VRF plugin = Creating a secondary network attachment with the CNI VRF plugin
The Cluster Network Operator (CNO) manages secondary network definitions. When you specify a secondary network to create, the CNO creates the `NetworkAttachmentDefinition` custom resource (CR) automatically. [role="_abstract"]
The Cluster Network Operator (CNO) manages secondary network definitions. When you specify a secondary network in the cluster-scoped `Network` custom resource (CR), the CNO automatically creates the `NetworkAttachmentDefinition` CR.
[NOTE] [NOTE]
==== ====
Do not edit the `NetworkAttachmentDefinition` CRs that the Cluster Network Operator manages. Doing so might disrupt network traffic on your secondary network. Do not edit the `NetworkAttachmentDefinition` CRs that the Cluster Network Operator manages. Doing so might disrupt network traffic on your secondary network.
==== ====
To create a secondary network attachment with the CNI VRF plugin, perform the following procedure.
.Prerequisites .Prerequisites
* Install the {product-title} CLI (oc). * Install the {oc-first}.
* Log in to the OpenShift cluster as a user with cluster-admin privileges. * Log in to the cluster as a user with `cluster-admin` privileges.
.Procedure .Procedure
. Create the `Network` custom resource (CR) for the additional network attachment and insert the `rawCNIConfig` configuration for the secondary network, as in the following example CR. Save the YAML as the file `additional-network-attachment.yaml`. . Create the `Network` CR for the additional network attachment and insert the `rawCNIConfig` configuration for the secondary network. Save as the `additional-network-attachment.yaml` file.
+ +
[source,yaml] [source,yaml]
---- ----
@@ -38,7 +37,7 @@ spec:
rawCNIConfig: '{ rawCNIConfig: '{
"cniVersion": "0.3.1", "cniVersion": "0.3.1",
"name": "macvlan-vrf", "name": "macvlan-vrf",
"plugins": [ <1> "plugins": [
{ {
"type": "macvlan", "type": "macvlan",
"master": "eth1", "master": "eth1",
@@ -52,16 +51,19 @@ spec:
} }
}, },
{ {
"type": "vrf", <2> "type": "vrf",
"vrfname": "vrf-1", <3> "vrfname": "vrf-1",
"table": 1001 <4> "table": 1001
}] }]
}' }'
---- ----
<1> `plugins` must be a list. The first item in the list must be the secondary network underpinning the VRF network. The second item in the list is the VRF plugin configuration. +
<2> `type` must be set to `vrf`. where:
<3> `vrfname` is the name of the VRF that the interface is assigned to. If it does not exist in the pod, it is created. +
<4> Optional. `table` is the routing table ID. By default, the `tableid` parameter is used. If it is not specified, the CNI assigns a free routing table ID to the VRF. `plugins`:: You must specify a list. The first item in the list must be the secondary network underpinning the VRF network. The second item in the list is the VRF plugin configuration.
`type`:: You must set this parameter to `vrf`.
`vrfname`:: The name of the VRF that the interface is assigned to. If the VRF does not exist in the pod, the CNI creates the VRF.
`table`:: Optional parameter. Specify the routing table ID. By default, the `tableid` parameter is used. If you do not specify a table ID, the CNI assigns a free routing table ID to the VRF.
+ +
[NOTE] [NOTE]
==== ====
@@ -84,16 +86,15 @@ $ oc get network-attachment-definitions -n <namespace>
+ +
[NOTE] [NOTE]
==== ====
There might be a delay before the CNO creates the CR. A delay might exist before the CNO creates the CR.
==== ====
.Verification .Verification
. Create a pod and assign it to the secondary network with the VRF instance: . Create a pod and assign the pod to the secondary network that includes the VRF plugin configuration.
+
.. Create a YAML file that defines the `Pod` resource: .. Create a YAML file that defines the `Pod` resource, as demonstrated in the following `pod-additional-net.yaml` file:
+ +
.Example `pod-additional-net.yaml` file
[source,yaml] [source,yaml]
---- ----
apiVersion: v1 apiVersion: v1
@@ -112,8 +113,11 @@ spec:
command: ["/bin/bash", "-c", "sleep 9000000"] command: ["/bin/bash", "-c", "sleep 9000000"]
image: centos:8 image: centos:8
---- ----
<1> Specify the name of the secondary network with the VRF instance. +
where:
+
`name`:: Specify the name of the secondary network that includes the VRF plugin configuration.
+
.. Create the `Pod` resource by running the following command. The expected output shows the name of the `Pod` resource and the creation age in minutes. .. Create the `Pod` resource by running the following command. The expected output shows the name of the `Pod` resource and the creation age in minutes.
+ +
[source,terminal] [source,terminal]
@@ -121,21 +125,20 @@ spec:
$ oc create -f pod-additional-net.yaml $ oc create -f pod-additional-net.yaml
---- ----
. Verify that the pod network attachment is connected to the VRF secondary network. Start a remote session with the pod and run the following command. The expected output shows the name of the VRF interface and its unique ID in the routing table. . Verify that the pod network attachment connects to the VRF secondary network. Start a remote session with the pod and run the following command. The expected output shows the name of the VRF interface and its unique ID in the routing table.
+ +
[source,terminal] [source,terminal]
---- ----
$ ip vrf show $ ip vrf show
---- ----
. Confirm that the VRF interface is the controller for the secondary interface: . Confirm that the VRF interface is the controller for the secondary interface by entering the following command:
+ +
[source,terminal] [source,terminal]
---- ----
$ ip link $ ip link
---- ----
+ +
.Example output
[source,terminal] [source,terminal]
---- ----
5: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master red state UP mode 5: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master red state UP mode

44
modules/cnf-creating-an-additional-sriov-network-with-vrf-plug-in.adoc
View File

@@ -6,6 +6,7 @@
[id="cnf-creating-an-additional-sriov-network-with-vrf-plug-in_{context}"] [id="cnf-creating-an-additional-sriov-network-with-vrf-plug-in_{context}"]
= Creating an additional SR-IOV network attachment with the CNI VRF plugin = Creating an additional SR-IOV network attachment with the CNI VRF plugin
[role="_abstract"]
The SR-IOV Network Operator manages additional network definitions. When you specify an additional SR-IOV network to create, the SR-IOV Network Operator creates the `NetworkAttachmentDefinition` custom resource (CR) automatically. The SR-IOV Network Operator manages additional network definitions. When you specify an additional SR-IOV network to create, the SR-IOV Network Operator creates the `NetworkAttachmentDefinition` custom resource (CR) automatically.
[NOTE] [NOTE]
@@ -17,14 +18,13 @@ To create an additional SR-IOV network attachment with the CNI virtual routing a
.Prerequisites .Prerequisites
* Install the {product-title} CLI (oc). * Install the {oc-first}.
* Log in to the {product-title} cluster as a user with cluster-admin privileges. * Log in to the {product-title} cluster as a user with cluster-admin privileges.
.Procedure .Procedure
. Create the `SriovNetwork` custom resource (CR) for the additional SR-IOV network attachment and insert the `metaPlugins` configuration, as in the following example CR. Save the YAML as the file `sriov-network-attachment.yaml`. . Create the `SriovNetwork` custom resource (CR) for the additional SR-IOV network attachment and insert the `metaPlugins` configuration, as in the following example CR. Save the YAML as the file `sriov-network-attachment.yaml`.
+ +
.Example `SriovNetwork` custom resource (CR) example
[source,yaml] [source,yaml]
---- ----
apiVersion: sriovnetwork.openshift.io/v1 apiVersion: sriovnetwork.openshift.io/v1
@@ -49,11 +49,14 @@ spec:
metaPlugins : | metaPlugins : |
{ {
"type": "vrf", <1> "type": "vrf", <1>
"vrfname": "example-vrf-name" <2> "vrfname": "example-vrf-name"
} }
---- ----
<1> Set the `type` parameter to `vrf`. +
<2> Specify a name for the VRF in the `vrfname` parameter. An interface gets assigned to the VRF. If you do not specify a name for the VRF in a pod, the SR-IOV Network Operator automatically generates a name for the VRF. where:
+
`metaPlugins.type`:: Set the `type` parameter to `vrf`.
`metaPlugins.vrfname`:: Specify a name for the VRF in the `vrfname` parameter. An interface gets assigned to the VRF. If you do not specify a name for the VRF in a pod, the SR-IOV Network Operator automatically generates a name for the VRF.
. Create the `SriovNetwork` resource: . Create the `SriovNetwork` resource:
+ +
@@ -62,42 +65,39 @@ spec:
$ oc create -f sriov-network-attachment.yaml $ oc create -f sriov-network-attachment.yaml
---- ----
.Verifying that the `NetworkAttachmentDefinition` CR is successfully created .Verification
* Confirm that the SR-IOV Network Operator created the `NetworkAttachmentDefinition` CR by running the following command. The expected output shows the name of the NAD CR and the creation age in minutes. . Confirm that the SR-IOV Network Operator created the `NetworkAttachmentDefinition` CR by running the following command. The expected output shows the name of the NAD CR and the creation age in minutes.
+ +
[source,terminal] [source,terminal]
---- ----
$ oc get network-attachment-definitions -n <namespace> <1> $ oc get network-attachment-definitions -n <namespace>
---- ----
<1> Replace `<namespace>` with the namespace that you specified when configuring the network attachment, for example, `additional-sriov-network-1`. +
* `<namespace>`: Replace `<namespace>` with the namespace that you specified when configuring the network attachment, for example, `additional-sriov-network-1`.
+ +
[NOTE] [NOTE]
==== ====
There might be a delay before the SR-IOV Network Operator creates the CR. There might be a delay before the SR-IOV Network Operator creates the CR.
==== ====
.Verifying that the additional SR-IOV network attachment is successful . To verify that the VRF CNI is correctly configured and that the additional SR-IOV network attachment is attached, do the following:
+
To verify that the VRF CNI is correctly configured and that the additional SR-IOV network attachment is attached, do the following: .. Create an SR-IOV network that uses the VRF CNI.
+
. Create an SR-IOV network that uses the VRF CNI. .. Assign the network to a pod.
+
. Assign the network to a pod. .. Verify that the pod network attachment connects to the SR-IOV additional network. Ensure that you remote shell login into the pod and run the following command. The expected output shows the name of the VRF interface and its unique ID in the routing table.
. Verify that the pod network attachment connects to the SR-IOV additional network. Ensure that you remote shell login into the pod and run the following command. The expected output shows the name of the VRF interface and its unique ID in the routing table.
+ +
[source,terminal] [source,terminal]
---- ----
$ ip vrf show $ ip vrf show
---- ----
+
. Confirm that the VRF interface is `master` of the secondary interface by running the following command: .. Confirm that the VRF interface is `master` for the secondary interface by running the following command. Example output shows `5: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master red state UP mode`.
+ +
[source,terminal] [source,terminal]
---- ----
$ ip link $ ip link
---- ----
+
Example output: `5: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master red state UP mode`

15
modules/configuration-ovnk-multi-network-policy.adoc
View File

@@ -2,13 +2,17 @@
// //
// * networking/multiple_networks/secondary_networks/creating-secondary-nwt-ovnk.adoc // * networking/multiple_networks/secondary_networks/creating-secondary-nwt-ovnk.adoc
:_mod-docs-content-type: CONCEPT :_mod-docs-content-type: REFERENCE
[id="compatibility-with-multi-network-policy_{context}"] [id="compatibility-with-multi-network-policy_{context}"]
= Compatibility with multi-network policy = Compatibility with multi-network policy
The multi-network policy API, which is provided by the `MultiNetworkPolicy` custom resource definition (CRD) in the `k8s.cni.cncf.io` API group, is compatible with an OVN-Kubernetes secondary network. When defining a network policy, the network policy rules that can be used depend on whether the OVN-Kubernetes secondary network defines the `subnets` field. Refer to the following table for details: [role="_abstract"]
When defining a network policy, the network policy rules that can be used depend on whether the OVN-Kubernetes secondary network defines the `subnets` field.
The multi-network policy API, which is provided by the `MultiNetworkPolicy` custom resource definition (CRD) in the `k8s.cni.cncf.io` API group, is compatible with an OVN-Kubernetes secondary network.
Refer to the following table that details supported multi-network policy selectors that are based on a `subnets` CNI configuration:
.Supported multi-network policy selectors based on `subnets` CNI configuration
[cols=".^3,.^7",options="header"] [cols=".^3,.^7",options="header"]
|==== |====
a|`subnets` field specified|Allowed multi-network policy selectors a|`subnets` field specified|Allowed multi-network policy selectors
@@ -26,9 +30,8 @@ a|
|==== |====
You can use the `k8s.v1.cni.cncf.io/policy-for` annotation on a `MultiNetworkPolicy` object to point to a `NetworkAttachmentDefinition` (NAD) custom resource (CR). The NAD CR defines the network to which the policy applies. The following example multi-network policy is valid only if the `subnets` field is defined in the secondary network CNI configuration for the secondary network named `blue2`: You can use the `k8s.v1.cni.cncf.io/policy-for` annotation on a `MultiNetworkPolicy` object to point to a `NetworkAttachmentDefinition` (NAD) custom resource (CR). The NAD CR defines the network to which the policy applies. The following example multi-network policy that uses a pod selector is valid only if the `subnets` field is defined in the secondary network CNI configuration for the secondary network named `blue2`:
.Example multi-network policy that uses a pod selector
[source,yaml] [source,yaml]
---- ----
apiVersion: k8s.cni.cncf.io/v1beta1 apiVersion: k8s.cni.cncf.io/v1beta1
@@ -44,7 +47,7 @@ spec:
- podSelector: {} - podSelector: {}
---- ----
The following example uses the `ipBlock` network policy selector, which is always valid for an OVN-Kubernetes secondary network: The following example uses the `ipBlock` network multi-network policy that is always valid for an OVN-Kubernetes secondary network:
.Example multi-network policy that uses an IP block selector .Example multi-network policy that uses an IP block selector
[source,yaml] [source,yaml]

10
modules/configuration-ovnk-network-plugin-json-object.adoc
View File

@@ -6,7 +6,8 @@
[id="configuration-ovnk-network-plugin-json-object_{context}"] [id="configuration-ovnk-network-plugin-json-object_{context}"]
= OVN-Kubernetes network plugin JSON configuration table = OVN-Kubernetes network plugin JSON configuration table
The following table describes the configuration parameters for the OVN-Kubernetes CNI network plugin: [role="_abstract"]
The OVN-Kubernetes network plugin JSON configuration object describes the configuration parameters for the OVN-Kubernetes CNI network plugin. The following table details these parameters:
.OVN-Kubernetes network plugin JSON configuration table .OVN-Kubernetes network plugin JSON configuration table
[cols=".^2,.^2,.^6",options="header"] [cols=".^2,.^2,.^6",options="header"]
@@ -21,9 +22,7 @@ The CNI specification version. The required value is `0.3.1`.
|`name` |`name`
|`string` |`string`
| |
The name of the network. These networks are not namespaced. For example, a network named `l2-network` can be referenced by `NetworkAttachmentDefinition` custom resources (CRs) that exist in different namespaces. The name of the network. These networks are not namespaced. For example, a network named `l2-network` can be referenced by `NetworkAttachmentDefinition` custom resources (CRs) that exist in different namespaces. This configuration allows pods that use the `NetworkAttachmentDefinition` CR in different namespaces to communicate over the same secondary network. However, the `NetworkAttachmentDefinition` CRs must share the same network-specific parameters, such as `topology`, `subnets`, `mtu`, `excludeSubnets`, and `vlanID`. The `vlanID` parameter applies only when the `topology` field is set to `localnet`.
This configuration allows pods that use the `NetworkAttachmentDefinition` CR in different namespaces to communicate over the same secondary network.
However, the `NetworkAttachmentDefinition` CRs must share the same network-specific parameters, such as `topology`, `subnets`, `mtu`, `excludeSubnets`, and `vlanID`. The `vlanID` parameter applies only when the `topology` field is set to `localnet`.
|`type` |`type`
|`string` |`string`
@@ -52,8 +51,7 @@ The maximum transmission unit (MTU). If you do not set a value, the Cluster Netw
|`netAttachDefName` |`netAttachDefName`
|`string` |`string`
| |
The metadata `namespace` and `name` of the network attachment definition CRD where this The metadata `namespace` and `name` of the network attachment definition CRD where this configuration is included. For example, if this configuration is defined in a `NetworkAttachmentDefinition` CRD in namespace `ns1` named `l2-network`, this should be set to `ns1/l2-network`.
configuration is included. For example, if this configuration is defined in a `NetworkAttachmentDefinition` CRD in namespace `ns1` named `l2-network`, this should be set to `ns1/l2-network`.
|`excludeSubnets` |`excludeSubnets`
|`string` |`string`

1
modules/configuring-layer-two-switched-topology.adoc
View File

@@ -6,6 +6,7 @@
[id="configuration-layer-two-switched-topology_{context}"] [id="configuration-layer-two-switched-topology_{context}"]
= Configuration for a layer 2 switched topology = Configuration for a layer 2 switched topology
[role="_abstract"]
The switched (layer 2) topology networks interconnect the workloads through a cluster-wide logical switch. This configuration can be used for IPv6 and dual-stack deployments. The switched (layer 2) topology networks interconnect the workloads through a cluster-wide logical switch. This configuration can be used for IPv6 and dual-stack deployments.
[NOTE] [NOTE]

86
modules/configuring-localnet-switched-topology.adoc
View File

@@ -6,50 +6,48 @@
[id="configuration-localnet-switched-topology_{context}"] [id="configuration-localnet-switched-topology_{context}"]
= Configuration for a localnet switched topology = Configuration for a localnet switched topology
// To accommodate a link to the NMstate Operator, the content in this module [role="_abstract"]
// is split with tags. The tag includes don't pull in the module header above.
// tag::localnet-intro[]
The switched `localnet` topology interconnects the workloads created as Network Attachment Definitions (NADs) through a cluster-wide logical switch to a physical network. The switched `localnet` topology interconnects the workloads created as Network Attachment Definitions (NADs) through a cluster-wide logical switch to a physical network.
// end::localnet-intro[]
// tag::localnet-content[] You must map a secondary network to the OVS bridge to use it as an OVN-Kubernetes secondary network. Bridge mappings allow network traffic to reach the physical network. A bridge mapping associates a physical network name, also known as an interface label, to a bridge created with Open vSwitch (OVS).
You must map a secondary network to the ovs-bridge to use it as an OVN-Kubernetes secondary network. Bridge mappings allow network traffic to reach the physical network. A bridge mapping associates a physical network name, also known as an interface label, to a bridge created with Open vSwitch (OVS).
You can create an `NodeNetworkConfigurationPolicy` (NNCP) object, part of the `nmstate.io/v1` API group, to declaratively create the mapping. This API is provided by the NMState Operator. By using this API you can apply the bridge mapping to nodes that match your specified `nodeSelector` expression, such as `node-role.kubernetes.io/worker: ''`. With this declarative approach, the NMState Operator applies secondary network configuration to all nodes specified by the node selector automatically and transparently. You can create an `NodeNetworkConfigurationPolicy` (NNCP) object, part of the `nmstate.io/v1` API group, to declaratively create the mapping. This API is provided by the NMState Operator. By using this API you can apply the bridge mapping to nodes that match your specified `nodeSelector` expression, such as `node-role.kubernetes.io/worker: ''`. With this declarative approach, the NMState Operator applies secondary network configuration to all nodes specified by the node selector automatically and transparently.
When attaching a secondary network, you can either use the existing `br-ex` bridge or create a new bridge. Which approach to use depends on your specific network infrastructure. Consider the following approaches: When attaching a secondary network, you can either use the existing `br-ex` bridge or create a new bridge. Which approach to use depends on your specific network infrastructure. Consider the following approaches:
- If your nodes include only a single network interface, you must use the existing bridge. This network interface is owned and managed by OVN-Kubernetes and you must not remove it from the `br-ex` bridge or alter the interface configuration. If you remove or alter the network interface, your cluster network will stop working correctly. - If your nodes include only a single network interface, you must use the existing bridge. This network interface is owned and managed by OVN-Kubernetes and you must not remove it from the `br-ex` bridge or alter the interface configuration. If you remove or alter the network interface, your cluster network stops working correctly.
- If your nodes include several network interfaces, you can attach a different network interface to a new bridge, and use that for your secondary network. This approach provides for traffic isolation from your primary cluster network. - If your nodes include several network interfaces, you can attach a different network interface to a new bridge, and use that for your secondary network. This approach provides for traffic isolation from your primary cluster network.
The `localnet1` network is mapped to the `br-ex` bridge in the following example: The `localnet1` network is mapped to the `br-ex` bridge in the following sharing-a-bridge example:
.Example mapping for sharing a bridge
[source,yaml] [source,yaml]
---- ----
apiVersion: nmstate.io/v1 apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy kind: NodeNetworkConfigurationPolicy
metadata: metadata:
name: mapping <1> name: mapping
spec: spec:
nodeSelector: nodeSelector:
node-role.kubernetes.io/worker: '' <2> node-role.kubernetes.io/worker: ''
desiredState: desiredState:
ovn: ovn:
bridge-mappings: bridge-mappings:
- localnet: localnet1 <3> - localnet: localnet1
bridge: br-ex <4> bridge: br-ex
state: present <5> state: present
# ...
---- ----
<1> The name for the configuration object.
<2> A node selector that specifies the nodes to apply the node network configuration policy to. where:
<3> The name for the secondary network from which traffic is forwarded to the OVS bridge. This secondary network must match the name of the `spec.config.name` field of the `NetworkAttachmentDefinition` CRD that defines the OVN-Kubernetes secondary network.
<4> The name of the OVS bridge on the node. This value is required only if you specify `state: present`. `name`:: The name for the configuration object.
<5> The state for the mapping. Must be either `present` to add the bridge or `absent` to remove the bridge. The default value is `present`. `node-role.kubernetes.io/worker`:: A node selector that specifies the nodes to apply the node network configuration policy to.
+ `localnet`:: The name for the secondary network from which traffic is forwarded to the OVS bridge. This secondary network must match the name of the `spec.config.name` field of the `NetworkAttachmentDefinition` CRD that defines the OVN-Kubernetes secondary network.
`bridge`:: The name of the OVS bridge on the node. This value is required only if you specify `state: present`.
`state`:: The state for the mapping. Must be either `present` to add the bridge or `absent` to remove the bridge. The default value is `present`.
The following JSON example configures a localnet secondary network that is named `localnet1`. Note that the value for the `mtu` parameter must match the MTU value that was set for the secondary network interface that is mapped to the `br-ex` bridge interface. The following JSON example configures a localnet secondary network that is named `localnet1`. Note that the value for the `mtu` parameter must match the MTU value that was set for the secondary network interface that is mapped to the `br-ex` bridge interface.
+
[source,json] [source,json]
---- ----
{ {
@@ -66,21 +64,20 @@ The following JSON example configures a localnet secondary network that is named
} }
---- ----
In the following example, the `localnet2` network interface is attached to the `ovs-br1` bridge. Through this attachment, the network interface is available to the OVN-Kubernetes network plugin as a secondary network. In the following multiple interfaces example, the `localnet2` network interface is attached to the `ovs-br1` bridge. Through this attachment, the network interface is available to the OVN-Kubernetes network plugin as a secondary network.
.Example mapping for nodes with multiple interfaces
[source,yaml] [source,yaml]
---- ----
apiVersion: nmstate.io/v1 apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy kind: NodeNetworkConfigurationPolicy
metadata: metadata:
name: ovs-br1-multiple-networks <1> name: ovs-br1-multiple-networks
spec: spec:
nodeSelector: nodeSelector:
node-role.kubernetes.io/worker: '' <2> node-role.kubernetes.io/worker: ''
desiredState: desiredState:
interfaces: interfaces:
- name: ovs-br1 <3> - name: ovs-br1
description: |- description: |-
A dedicated OVS bridge with eth1 as a port A dedicated OVS bridge with eth1 as a port
allowing all VLANs and untagged traffic allowing all VLANs and untagged traffic
@@ -90,26 +87,29 @@ spec:
allow-extra-patch-ports: true allow-extra-patch-ports: true
options: options:
stp: false stp: false
mcast-snooping-enable: true <4> mcast-snooping-enable: true
port: port:
- name: eth1 <5> - name: eth1
ovn: ovn:
bridge-mappings: bridge-mappings:
- localnet: localnet2 <6> - localnet: localnet2
bridge: ovs-br1 <7> bridge: ovs-br1
state: present <8> state: present
---- ----
<1> Specifies the name of the configuration object.
<2> Specifies a node selector that identifies the nodes to which the node network configuration policy applies. where:
<3> Specifies a new OVS bridge that operates separately from the default bridge used by OVN-Kubernetes for cluster traffic.
<4> Specifies whether to enable multicast snooping. When enabled, multicast snooping prevents network devices from flooding multicast traffic to all network members. By default, an OVS bridge does not enable multicast snooping. The default value is `false`. `name`:: Specifies the name of the configuration object.
<5> Specifies the network device on the host system to associate with the new OVS bridge. `node-role.kubernetes.io/worker`:: Specifies a node selector that identifies the nodes to which the node network configuration policy applies.
<6> Specifies the name of the secondary network that forwards traffic to the OVS bridge. This name must match the value of the `spec.config.name` field in the `NetworkAttachmentDefinition` CRD that defines the OVN-Kubernetes secondary network. `interfaces.name`:: Specifies a new OVS bridge that operates separately from the default bridge used by OVN-Kubernetes for cluster traffic.
<7> Specifies the name of the OVS bridge on the node. The value is required only when `state: present` is set. `mcast-snooping-enable`:: Specifies whether to enable multicast snooping. When enabled, multicast snooping prevents network devices from flooding multicast traffic to all network members. By default, an OVS bridge does not enable multicast snooping. The default value is `false`.
<8> Specifies the state of the mapping. Valid values are `present` to add the bridge or `absent` to remove the bridge. The default value is `present`. ``port.name`:: Specifies the network device on the host system to associate with the new OVS bridge.
+ `bridge-mappings.localnet`:: Specifies the name of the secondary network that forwards traffic to the OVS bridge. This name must match the value of the `spec.config.name` field in the `NetworkAttachmentDefinition` CRD that defines the OVN-Kubernetes secondary network.
`bridge-mappings.bridge`:: Specifies the name of the OVS bridge on the node. The value is required only when `state: present` is set.
`bridge-mappings.state`:: Specifies the state of the mapping. Valid values are `present` to add the bridge or `absent` to remove the bridge. The default value is `present`.
The following JSON example configures a localnet secondary network that is named `localnet2`. Note that the value for the `mtu` parameter must match the MTU value that was set for the `eth1` secondary network interface. The following JSON example configures a localnet secondary network that is named `localnet2`. Note that the value for the `mtu` parameter must match the MTU value that was set for the `eth1` secondary network interface.
+
[source,json] [source,json]
---- ----
{ {
@@ -125,4 +125,4 @@ The following JSON example configures a localnet secondary network that is named
"excludeSubnets": "10.100.200.0/29" "excludeSubnets": "10.100.200.0/29"
} }
---- ----
// end::localnet-content[]

1
modules/configuring-ovnk-additional-networks.adoc
View File

@@ -6,6 +6,7 @@
[id="configuration-ovnk-additional-networks_{context}"] [id="configuration-ovnk-additional-networks_{context}"]
= Configuration for an OVN-Kubernetes secondary network = Configuration for an OVN-Kubernetes secondary network
[role="_abstract"]
The {openshift-networking} OVN-Kubernetes network plugin allows the configuration of secondary network interfaces for pods. To configure secondary network interfaces, you must define the configurations in the `NetworkAttachmentDefinition` custom resource definition (CRD). The {openshift-networking} OVN-Kubernetes network plugin allows the configuration of secondary network interfaces for pods. To configure secondary network interfaces, you must define the configurations in the `NetworkAttachmentDefinition` custom resource definition (CRD).
[NOTE] [NOTE]

5
modules/configuring-pods-secondary-network.adoc
View File

@@ -6,9 +6,10 @@
[id="configuring-pods-secondary-network_{context}"] [id="configuring-pods-secondary-network_{context}"]
= Configuring pods for secondary networks = Configuring pods for secondary networks
[role="_abstract"]
You must specify the secondary network attachments through the `k8s.v1.cni.cncf.io/networks` annotation. You must specify the secondary network attachments through the `k8s.v1.cni.cncf.io/networks` annotation.
The following example provisions a pod with two secondary attachments, one for each of the attachment configurations presented in this guide. The following example provisions a pod with two secondary attachments, one for each of the attachment configurations presented in this guide:
[source,yaml] [source,yaml]
---- ----
@@ -26,4 +27,4 @@ spec:
image: k8s.gcr.io/e2e-test-images/agnhost:2.36 image: k8s.gcr.io/e2e-test-images/agnhost:2.36
imagePullPolicy: IfNotPresent imagePullPolicy: IfNotPresent
name: agnhost-container name: agnhost-container
---- ----

23
modules/configuring-pods-static-ip.adoc
View File

@@ -6,7 +6,8 @@
[id="configuring-pods-static-ip_{context}"] [id="configuring-pods-static-ip_{context}"]
= Configuring pods with a static IP address = Configuring pods with a static IP address
The following example provisions a pod with a static IP address. [role="_abstract"]
You can configure pods with a static IP address. The example in the procedure provisions a pod with a static IP address.
[NOTE] [NOTE]
==== ====
@@ -22,12 +23,12 @@ metadata:
annotations: annotations:
k8s.v1.cni.cncf.io/networks: '[ k8s.v1.cni.cncf.io/networks: '[
{ {
"name": "l2-network", <1> "name": "l2-network",
"mac": "02:03:04:05:06:07", <2> "mac": "02:03:04:05:06:07",
"interface": "myiface1", <3> "interface": "myiface1",
"ips": [ "ips": [
"192.0.2.20/24" "192.0.2.20/24"
] <4> ]
} }
]' ]'
name: tinypod name: tinypod
@@ -40,7 +41,11 @@ spec:
imagePullPolicy: IfNotPresent imagePullPolicy: IfNotPresent
name: agnhost-container name: agnhost-container
---- ----
<1> The name of the network. This value must be unique across all `NetworkAttachmentDefinition` CRDs.
<2> The MAC address to be assigned for the interface. where:
<3> The name of the network interface to be created for the pod.
<4> The IP addresses to be assigned to the network interface.
`k8s.v1.cni.cncf.io/networks.name`:: The name of the network. This value must be unique across all `NetworkAttachmentDefinition` CRDs.
`k8s.v1.cni.cncf.io/networks.mac`:: The MAC address to be assigned for the interface.
`k8s.v1.cni.cncf.io/networks.interface`:: The name of the network interface to be created for the pod.
`k8s.v1.cni.cncf.io/networks.ips`:: The IP addresses to be assigned to the network interface.

5
modules/microshift-install-multus-running-node.adoc
View File

@@ -6,6 +6,7 @@
[id="microshift-multus-installing-on-running-node_{context}"] [id="microshift-multus-installing-on-running-node_{context}"]
= Installing the Multus CNI plugin on a running node = Installing the Multus CNI plugin on a running node
[role="_abstract"]
If you want to attach additional networks to a pod for high-performance network configurations, you can install the {microshift-short} Multus RPM package. After installation, a host restart is required to re-create all the pods with the Multus annotation. If you want to attach additional networks to a pod for high-performance network configurations, you can install the {microshift-short} Multus RPM package. After installation, a host restart is required to re-create all the pods with the Multus annotation.
[IMPORTANT] [IMPORTANT]
@@ -15,7 +16,7 @@ Uninstalling the Multus CNI plugin is not supported.
.Prerequisites .Prerequisites
. You have root access to the host. * You have root access to the host.
.Procedure .Procedure
@@ -40,7 +41,7 @@ $ sudo systemctl restart
.Verification .Verification
. After restarting, ensure that the Multus CNI plugin components are created by running the following command: * After restarting, ensure that the Multus CNI plugin components are created by running the following command:
+ +
[source,terminal] [source,terminal]
---- ----

6
modules/microshift-multus-intro.adoc
View File

@@ -6,10 +6,14 @@
[id="microshift-multus-intro_{context}"] [id="microshift-multus-intro_{context}"]
= Secondary networks in {microshift-short} = Secondary networks in {microshift-short}
During node installation, the _default_ pod network is configured with default values unless you customize the configuration. The default network handles all ordinary network traffic for the node. Using the {microshift-short} Multus CNI plugin, you can add additional interfaces to pods from other networks. This gives you flexibility when you configure pods that deliver network functionality, such as switching or routing. [role="_abstract"]
Using the {microshift-short} Multus CNI plugin, you can add additional interfaces to pods from other networks. With this configuration, you have flexibility when you configure pods that deliver network functionality, such as switching or routing.
During node installation, the _default_ pod network is configured with default values unless you customize the configuration. The default network handles all ordinary network traffic for the node.
[id="microshift-supported-additional-networks_{context}"] [id="microshift-supported-additional-networks_{context}"]
== Supported secondary networks for network isolation == Supported secondary networks for network isolation
The following secondary networks are supported in {microshift-short} {product-version}: The following secondary networks are supported in {microshift-short} {product-version}:
* Bridge: Allows pods on the same host to communicate with each other and the host. * Bridge: Allows pods on the same host to communicate with each other and the host.

5
modules/nodes-control-plane-osp-migrating.adoc
View File

@@ -6,6 +6,7 @@
[id="nodes-control-plane-osp-migrating_{context}"] [id="nodes-control-plane-osp-migrating_{context}"]
= Migrating control plane nodes from one RHOSP host to another manually = Migrating control plane nodes from one RHOSP host to another manually
[role="_abstract"]
If control plane machine sets are not enabled on your cluster, you can run a script that moves a control plane node from one {rh-openstack-first} node to another. If control plane machine sets are not enabled on your cluster, you can run a script that moves a control plane node from one {rh-openstack-first} node to another.
[NOTE] [NOTE]
@@ -23,7 +24,7 @@ For information about control plane machine sets, see "Managing control plane ma
.Procedure .Procedure
* From a command line, run the following script: * From a command line, run the following script:
+
[source,bash] [source,bash]
---- ----
#!/usr/bin/env bash #!/usr/bin/env bash
@@ -79,5 +80,5 @@ oc adm uncordon "$node_name"
# Wait for cluster operators to stabilize # Wait for cluster operators to stabilize
until oc get co -o go-template='statuses: {{ range .items }}{{ range .status.conditions }}{{ if eq .type "Degraded" }}{{ if ne .status "False" }}DEGRADED{{ end }}{{ else if eq .type "Progressing"}}{{ if ne .status "False" }}PROGRESSING{{ end }}{{ else if eq .type "Available"}}{{ if ne .status "True" }}NOTAVAILABLE{{ end }}{{ end }}{{ end }}{{ end }}' | grep -qv '\(DEGRADED\|PROGRESSING\|NOTAVAILABLE\)'; do sleep 5; done until oc get co -o go-template='statuses: {{ range .items }}{{ range .status.conditions }}{{ if eq .type "Degraded" }}{{ if ne .status "False" }}DEGRADED{{ end }}{{ else if eq .type "Progressing"}}{{ if ne .status "False" }}PROGRESSING{{ end }}{{ else if eq .type "Available"}}{{ if ne .status "True" }}NOTAVAILABLE{{ end }}{{ end }}{{ end }}{{ end }}' | grep -qv '\(DEGRADED\|PROGRESSING\|NOTAVAILABLE\)'; do sleep 5; done
---- ----
+
If the script completes, the control plane machine is migrated to a new {rh-openstack} node. If the script completes, the control plane machine is migrated to a new {rh-openstack} node.

22
modules/nodes-nodes-kernel-arguments.adoc
View File

@@ -7,6 +7,7 @@
[id="nodes-nodes-kernel-arguments_{context}"] [id="nodes-nodes-kernel-arguments_{context}"]
= Adding kernel arguments to nodes = Adding kernel arguments to nodes
[role="_abstract"]
In some special cases, you might want to add kernel arguments to a set of nodes in your cluster. This should only be done with caution and clear understanding of the implications of the arguments you set. In some special cases, you might want to add kernel arguments to a set of nodes in your cluster. This should only be done with caution and clear understanding of the implications of the arguments you set.
[WARNING] [WARNING]
@@ -22,8 +23,7 @@ Examples of kernel arguments you could set include:
+ +
[WARNING] [WARNING]
==== ====
Disabling SELinux on {op-system} in production is not supported. Disabling SELinux on {op-system} in production is not supported. After SELinux has been disabled on a node, it must be re-provisioned before re-inclusion in a production cluster.
Once SELinux has been disabled on a node, it must be re-provisioned before re-inclusion in a production cluster.
==== ====
See link:https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt[Kernel.org kernel parameters] for a list and descriptions of kernel arguments. See link:https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt[Kernel.org kernel parameters] for a list and descriptions of kernel arguments.
@@ -35,7 +35,9 @@ In the following procedure, you create a `MachineConfig` object that identifies:
* A label that indicates where in the list of machine configs the change is applied. * A label that indicates where in the list of machine configs the change is applied.
.Prerequisites .Prerequisites
* Have administrative privilege to a working {product-title} cluster.
* You have `cluster-admin` privileges.
* Your cluster is running.
.Procedure .Procedure
@@ -73,17 +75,19 @@ apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig kind: MachineConfig
metadata: metadata:
labels: labels:
machineconfiguration.openshift.io/role: worker<1> machineconfiguration.openshift.io/role: worker
name: 05-worker-kernelarg-selinuxpermissive<2> name: 05-worker-kernelarg-selinuxpermissive
spec: spec:
kernelArguments: kernelArguments:
- enforcing=0<3> - enforcing=0<3>
---- ----
+ +
<1> Applies the new kernel argument only to worker nodes. where:
<2> Named to identify where it fits among the machine configs (05) and what it does (adds +
a kernel argument to configure SELinux permissive mode). `machineconfiguration.openshift.io/role`:: Applies the new kernel argument only to worker nodes.
<3> Identifies the exact kernel argument as `enforcing=0`. `name`:: Named to identify where it fits among the machine configs (05) and what it does (adds a kernel argument to configure SELinux permissive mode).
`kernelArguments`:: Identifies the exact kernel argument as `enforcing=0`.
. Create the new machine config: . Create the new machine config:
+ +
[source,terminal] [source,terminal]

28
modules/nodes-nodes-managing-about.adoc
View File

@@ -6,6 +6,7 @@
[id="nodes-nodes-managing-about_{context}"] [id="nodes-nodes-managing-about_{context}"]
= Modifying nodes = Modifying nodes
[role="_abstract"]
To make configuration changes to a cluster, or machine pool, you must create a custom resource definition (CRD), or `kubeletConfig` object. {product-title} uses the Machine Config Controller to watch for changes introduced through the CRD to apply the changes to the cluster. To make configuration changes to a cluster, or machine pool, you must create a custom resource definition (CRD), or `kubeletConfig` object. {product-title} uses the Machine Config Controller to watch for changes introduced through the CRD to apply the changes to the cluster.
[NOTE] [NOTE]
@@ -17,7 +18,7 @@ Because the fields in a `kubeletConfig` object are passed directly to the kubele
. Obtain the label associated with the static CRD, Machine Config Pool, for the type of node you want to configure. . Obtain the label associated with the static CRD, Machine Config Pool, for the type of node you want to configure.
Perform one of the following steps: Perform one of the following steps:
+
.. Check current labels of the desired machine config pool. .. Check current labels of the desired machine config pool.
+ +
For example: For example:
@@ -34,7 +35,7 @@ NAME CONFIG UPDATED UPDATING
master rendered-master-e05b81f5ca4db1d249a1bf32f9ec24fd True False False operator.machineconfiguration.openshift.io/required-for-upgrade= master rendered-master-e05b81f5ca4db1d249a1bf32f9ec24fd True False False operator.machineconfiguration.openshift.io/required-for-upgrade=
worker rendered-worker-f50e78e1bc06d8e82327763145bfcf62 True False False worker rendered-worker-f50e78e1bc06d8e82327763145bfcf62 True False False
---- ----
+
.. Add a custom label to the desired machine config pool. .. Add a custom label to the desired machine config pool.
+ +
For example: For example:
@@ -44,23 +45,19 @@ For example:
$ oc label machineconfigpool worker custom-kubelet=enabled $ oc label machineconfigpool worker custom-kubelet=enabled
---- ----
. Create a `kubeletconfig` custom resource (CR) for your configuration change, as demonstrated in the following sample configuration for a `custom-config` CR:
. Create a `kubeletconfig` custom resource (CR) for your configuration change.
+ +
For example:
+
.Sample configuration for a *custom-config* CR
[source,yaml] [source,yaml]
---- ----
apiVersion: machineconfiguration.openshift.io/v1 apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig kind: KubeletConfig
metadata: metadata:
name: custom-config <1> name: custom-config
spec: spec:
machineConfigPoolSelector: machineConfigPoolSelector:
matchLabels: matchLabels:
custom-kubelet: enabled <2> custom-kubelet: enabled
kubeletConfig: <3> kubeletConfig:
podsPerCore: 10 podsPerCore: 10
maxPods: 250 maxPods: 250
systemReserved: systemReserved:
@@ -68,11 +65,14 @@ spec:
memory: 1Gi memory: 1Gi
#... #...
---- ----
<1> Assign a name to CR. +
<2> Specify the label to apply the configuration change, this is the label you added to the machine config pool. where:
<3> Specify the new value(s) you want to change. +
`name`:: Assign a name to CR.
`custom-kubelet`:: Specify the label to apply the configuration change, this is the label you added to the machine config pool.
`kubeletConfig`:: Specify the new value(s) you want to change.
. Create the CR object. . Create the CR object:
+ +
[source,terminal] [source,terminal]
---- ----

1
modules/nodes-nodes-parallel-container-pulls-about.adoc
View File

@@ -6,6 +6,7 @@
[id="nodes-nodes-parallel-container-pulls-about_{context}"] [id="nodes-nodes-parallel-container-pulls-about_{context}"]
= About configuring parallel container image pulls = About configuring parallel container image pulls
[role="_abstract"]
To help control bandwidth issues, you can configure the number of workload images that can be pulled at the same time. To help control bandwidth issues, you can configure the number of workload images that can be pulled at the same time.
By default, the cluster pulls images in parallel, which allows multiple workloads to pull images at the same time. Pulling multiple images in parallel can improve workload start-up time because workloads can pull needed images without waiting for each other. However, pulling too many images at the same time can use excessive network bandwidth and cause latency issues throughout your cluster. By default, the cluster pulls images in parallel, which allows multiple workloads to pull images at the same time. Pulling multiple images in parallel can improve workload start-up time because workloads can pull needed images without waiting for each other. However, pulling too many images at the same time can use excessive network bandwidth and cause latency issues throughout your cluster.

36
modules/nodes-nodes-parallel-container-pulls-configure.adoc
View File

@@ -6,14 +6,12 @@
[id="nodes-nodes-parallel-container-pulls-configure_{context}"] [id="nodes-nodes-parallel-container-pulls-configure_{context}"]
= Configuring parallel container image pulls = Configuring parallel container image pulls
You can control the number of images that can be pulled by your workload simultaneously by using a kubelet configuration. [role="_abstract"]
You can control the number of images that can be pulled by your workload simultaneously by using a kubelet configuration. You can set a maximum number of images that can be pulled or force workloads to pull images one at a time.
You can set a maximum number of images that can be pulled or force workloads to pull images one at a time.
.Prerequisites .Prerequisites
* You have a running {product-title} cluster. * You have a running {product-title} cluster.
* You are logged in to the cluster as a user with administrative privileges. * You are logged in to the cluster as a user with administrative privileges.
.Procedure .Procedure
@@ -39,12 +37,15 @@ spec:
matchLabels: matchLabels:
parallel-pulls: set parallel-pulls: set
kubeletConfig: kubeletConfig:
serializeImagePulls: false <1> serializeImagePulls: false
maxParallelImagePulls: 3 <2> maxParallelImagePulls: 3
# ... # ...
---- ----
<1> Set to `false` to enable parallel image pulls. Set to `true` to force serial image pulling. The default is `false`. +
<2> Specify the maximum number of images that can be pulled in parallel. Enter a number or set to `nil` to specify no limit. This field cannot be set if `SerializeImagePulls` is `true`. The default is `nil`. where:
+
`serializeImagePulls`:: Set to `false` to enable parallel image pulls. Set to `true` to force serial image pulling. The default is `false`.
`maxParallelImagePulls`:: Specify the maximum number of images that can be pulled in parallel. Enter a number or set to `nil` to specify no limit. This field cannot be set if `SerializeImagePulls` is `true`. The default is `nil`.
. Create the new machine config by running a command similar to the following: . Create the new machine config by running a command similar to the following:
+ +
@@ -62,8 +63,6 @@ $ oc create -f <file_name>.yaml
$ oc get MachineConfig $ oc get MachineConfig
---- ----
+ +
.Example output
+
[source,terminal] [source,terminal]
---- ----
NAME GENERATEDBYCONTROLLER IGNITIONVERSION AGE NAME GENERATEDBYCONTROLLER IGNITIONVERSION AGE
@@ -74,8 +73,11 @@ NAME GENERATEDBYCONTROLLER
# ... # ...
rendered-parallel-c634a80f644740974ceb40c054c79e50 70025364a114fc3067b2e82ce47fdb0149630e4b 3.5.0 10s <2> rendered-parallel-c634a80f644740974ceb40c054c79e50 70025364a114fc3067b2e82ce47fdb0149630e4b 3.5.0 10s <2>
---- ----
<1> The new machine config. In this example, the machine config is for the `parallel` custom machine config pool. +
<2> The new rendered machine config. In this example, the machine config is for the `parallel` custom machine config pool. where:
+
`99-parallel-generated-kubelet`:: The new machine config. In this example, the machine config is for the `parallel` custom machine config pool.
`rendered-parallel-<sha_numnber>`:: The new rendered machine config. In this example, the machine config is for the `parallel` custom machine config pool.
. Check to see that the nodes in the `parallel` machine config pool are being updated by running the following command: . Check to see that the nodes in the `parallel` machine config pool are being updated by running the following command:
+ +
@@ -84,8 +86,6 @@ rendered-parallel-c634a80f644740974ceb40c054c79e50 70025364a114fc3067b2e82ce47f
$ oc get machineconfigpool $ oc get machineconfigpool
---- ----
+ +
.Example output
+
[source,terminal] [source,terminal]
---- ----
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE
@@ -95,21 +95,21 @@ worker rendered-worker-c634a80f644740974ceb40c054c79e50 True False
---- ----
. When the nodes are updated, verify that the parallel pull maximum was configured: . When the nodes are updated, verify that the parallel pull maximum was configured:
+
.. Open an `oc debug` session to a node by running a command similar to the following: .. Open an `oc debug` session to a node by running a command similar to the following:
+ +
[source,terminal] [source,terminal]
---- ----
$ oc debug node/<node_name> $ oc debug node/<node_name>
---- ----
+
.. Set `/host` as the root directory within the debug shell by running the following command: .. Set `/host` as the root directory within the debug shell by running the following command:
+ +
[source,terminal] [source,terminal]
---- ----
sh-5.1# chroot /host sh-5.1# chroot /host
---- ----
+
.. Examine the `kubelet.conf` file by running the following command: .. Examine the `kubelet.conf` file by running the following command:
+ +
[source,terminal] [source,terminal]
@@ -117,8 +117,6 @@ sh-5.1# chroot /host
sh-5.1# cat /etc/kubernetes/kubelet.conf | grep -i maxParallelImagePulls sh-5.1# cat /etc/kubernetes/kubelet.conf | grep -i maxParallelImagePulls
---- ----
+ +
.Example output
+
[source,terminal] [source,terminal]
---- ----
maxParallelImagePulls: 3 maxParallelImagePulls: 3

16
modules/nodes-nodes-swap-memory.adoc
View File

@@ -4,9 +4,9 @@
:_mod-docs-content-type: PROCEDURE :_mod-docs-content-type: PROCEDURE
[id="nodes-nodes-swap-memory_{context}"] [id="nodes-nodes-swap-memory_{context}"]
= Allowing swap memory use on nodes = Allowing swap memory use on nodes
[role="_abstract"]
You can allow workloads on the cluster nodes to use swap memory. You can allow workloads on the cluster nodes to use swap memory.
:FeatureName: Swap memory support on nodes :FeatureName: Swap memory support on nodes
@@ -36,11 +36,8 @@ Using swap memory can negatively impact workload performance and out-of-resource
.Prerequisites .Prerequisites
* You have a running {product-title} cluster that uses version 4.10 or later. * You have a running {product-title} cluster that uses version 4.10 or later.
* Your cluster is configured to use cgroup v2. Swap memory is not supported on nodes in clusters that use cgroup v1. * Your cluster is configured to use cgroup v2. Swap memory is not supported on nodes in clusters that use cgroup v1.
* You are logged in to the cluster as a user with administrative privileges. * You are logged in to the cluster as a user with administrative privileges.
* You have enabled the `TechPreviewNoUpgrade` feature set on the cluster (see _Nodes -> Working with clusters -> Enabling features using feature gates_). * You have enabled the `TechPreviewNoUpgrade` feature set on the cluster (see _Nodes -> Working with clusters -> Enabling features using feature gates_).
+ +
[NOTE] [NOTE]
@@ -70,13 +67,16 @@ spec:
matchLabels: matchLabels:
kubelet-swap: enabled kubelet-swap: enabled
kubeletConfig: kubeletConfig:
failSwapOn: false <1> failSwapOn: false
memorySwap: memorySwap:
swapBehavior: LimitedSwap <2> swapBehavior: LimitedSwap
#... #...
---- ----
<1> Set to `false` to enable swap memory use on the associated nodes. Set to `true` to disable swap memory use. +
<2> Optional: Specify the swap memory behavior for {product-title} pods. where:
+
`failSwapOn`:: Set to `false` to enable swap memory use on the associated nodes. Set to `true` to disable swap memory use.
`swapBehavior`:: Optional: Specify the swap memory behavior for {product-title} pods.
+ +
* `NoSwap`: {product-title} pods cannot use swap. This is the default. * `NoSwap`: {product-title} pods cannot use swap. This is the default.
* `LimitedSwap`: {product-title} pods of Burstable QoS class only are permitted to employ swap. * `LimitedSwap`: {product-title} pods of Burstable QoS class only are permitted to employ swap.

18
modules/nodes-nodes-working-master-schedulable.adoc
View File

@@ -6,21 +6,21 @@
[id="nodes-nodes-working-master-schedulable_{context}"] [id="nodes-nodes-working-master-schedulable_{context}"]
= Configuring control plane nodes as schedulable = Configuring control plane nodes as schedulable
You can configure control plane nodes to be schedulable, meaning that new pods are allowed for placement on the master nodes. By default, control plane nodes are not schedulable. [role="_abstract"]
You can configure control plane nodes to be schedulable, meaning that new pods are allowed for placement on the control plane nodes. By default, control plane nodes are not schedulable.
You can set the masters to be schedulable, but must retain the worker nodes. You can set the control plane nodes to be schedulable, but must retain the compute nodes.
[NOTE] [NOTE]
==== ====
You can deploy {product-title} with no worker nodes on a bare metal cluster. You can deploy {product-title} with no compute nodes on a bare-metal cluster. In this case, the control plane nodes are marked schedulable by default.
In this case, the control plane nodes are marked schedulable by default.
==== ====
You can allow or disallow control plane nodes to be schedulable by configuring the `mastersSchedulable` field. You can allow or disallow control plane nodes to be schedulable by configuring the `mastersSchedulable` field.
[IMPORTANT] [IMPORTANT]
==== ====
When you configure control plane nodes from the default unschedulable to schedulable, additional subscriptions are required. This is because control plane nodes then become worker nodes. When you configure control plane nodes from the default unschedulable to schedulable, additional subscriptions are required. This is because control plane nodes then become compute nodes.
==== ====
.Procedure .Procedure
@@ -46,11 +46,13 @@ metadata:
selfLink: /apis/config.openshift.io/v1/schedulers/cluster selfLink: /apis/config.openshift.io/v1/schedulers/cluster
uid: a636d30a-d377-11e9-88d4-0a60097bee62 uid: a636d30a-d377-11e9-88d4-0a60097bee62
spec: spec:
mastersSchedulable: false <1> mastersSchedulable: false
status: {} status: {}
#... #...
---- ----
<1> Set to `true` to allow control plane nodes to be schedulable, or `false` to +
disallow control plane nodes to be schedulable. where:
+
`mastersSchedulable`:: Set to `true` to allow control plane nodes to be schedulable, or `false` to disallow control plane nodes to be schedulable.
. Save the file to apply the changes. . Save the file to apply the changes.

8
modules/nodes-nodes-working-setting-booleans.adoc
View File

@@ -2,17 +2,16 @@
// //
// * nodes/nodes/nodes-nodes-managing.adoc // * nodes/nodes/nodes-nodes-managing.adoc
:_mod-docs-content-type: PROCEDURE :_mod-docs-content-type: PROCEDURE
[id="nodes-nodes-working-setting-booleans_{context}"] [id="nodes-nodes-working-setting-booleans_{context}"]
= Setting SELinux booleans = Setting SELinux booleans
[role="_abstract"]
{product-title} allows you to enable and disable an SELinux boolean on a {op-system-first} node. The following procedure explains how to modify SELinux booleans on nodes using the Machine Config Operator (MCO). This procedure uses `container_manage_cgroup` as the example boolean. You can modify this value to whichever boolean you need. {product-title} allows you to enable and disable an SELinux boolean on a {op-system-first} node. The following procedure explains how to modify SELinux booleans on nodes using the Machine Config Operator (MCO). This procedure uses `container_manage_cgroup` as the example boolean. You can modify this value to whichever boolean you need.
.Prerequisites .Prerequisites
* You have installed the OpenShift CLI (oc). * You have installed the {oc-first}.
.Procedure .Procedure
@@ -48,7 +47,6 @@ spec:
name: setsebool.service name: setsebool.service
#... #...
---- ----
+
. Create the new `MachineConfig` object by running the following command: . Create the new `MachineConfig` object by running the following command:
+ +
@@ -56,7 +54,7 @@ spec:
---- ----
$ oc create -f 99-worker-setsebool.yaml $ oc create -f 99-worker-setsebool.yaml
---- ----
+
[NOTE] [NOTE]
==== ====
Applying any changes to the `MachineConfig` object causes all affected nodes to gracefully reboot after the change is applied. Applying any changes to the `MachineConfig` object causes all affected nodes to gracefully reboot after the change is applied.

4
modules/nw-about-configuring-master-interface-container.adoc
View File

@@ -6,7 +6,7 @@
[id="nw-about-configuring-master-interface-container_{context}"] [id="nw-about-configuring-master-interface-container_{context}"]
= About configuring the master interface in the container network namespace = About configuring the master interface in the container network namespace
[role="_abstract"]
You can create a MAC-VLAN, an IP-VLAN, or a VLAN subinterface that is based on a `master` interface that exists in a container namespace. You can also create a `master` interface as part of the pod network configuration in a separate network attachment definition CRD. You can create a MAC-VLAN, an IP-VLAN, or a VLAN subinterface that is based on a `master` interface that exists in a container namespace. You can also create a `master` interface as part of the pod network configuration in a separate network attachment definition CRD.
To use a container namespace `master` interface, you must specify `true` for the To use a container namespace `master` interface, you must specify `true` for the `linkInContainer` parameter that exists in the subinterface configuration of the `NetworkAttachmentDefinition` CRD.
`linkInContainer` parameter that exists in the subinterface configuration of the `NetworkAttachmentDefinition` CRD.

15
modules/nw-multi-network-policy-differences.adoc
View File

@@ -6,21 +6,22 @@
[id="nw-multi-network-policy-differences_{context}"] [id="nw-multi-network-policy-differences_{context}"]
= Differences between multi-network policy and network policy = Differences between multi-network policy and network policy
Although the `MultiNetworkPolicy` API implements the `NetworkPolicy` API, there are several important differences: [role="_abstract"]
Although the `MultiNetworkPolicy` API implements the `NetworkPolicy` API, ensure that you understand the following key differences between the two policies:
* You must use the `MultiNetworkPolicy` API: * You must use the `MultiNetworkPolicy` API, as demonstrated in the following example configuration:
+ +
[source,yaml] [source,yaml]
---- ----
apiVersion: k8s.cni.cncf.io/v1beta1 apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy kind: MultiNetworkPolicy
# ...
---- ----
* You must use the `multi-networkpolicy` resource name when using the CLI to interact with multi-network policies. For example, you can view a multi-network policy object with the `oc get multi-networkpolicy <name>` command where `<name>` is the name of a multi-network policy. * You must use the `multi-networkpolicy` resource name when using the CLI to interact with multi-network policies. For example, you can view a multi-network policy object with the `oc get multi-networkpolicy <name>` command where `<name>` is the name of a multi-network policy.
* You can use the `k8s.v1.cni.cncf.io/policy-for` annotation on a `MultiNetworkPolicy` object to point to a `NetworkAttachmentDefinition` (NAD) custom resource (CR). The NAD CR defines the network to which the policy applies. * You can use the `k8s.v1.cni.cncf.io/policy-for` annotation on a `MultiNetworkPolicy` object to point to a `NetworkAttachmentDefinition` (NAD) custom resource (CR). The NAD CR defines the network to which the policy applies. The following example multi-network policy includes the `k8s.v1.cni.cncf.io/policy-for` annotation:
+ +
.Example multi-network policy that includes the `k8s.v1.cni.cncf.io/policy-for` annotation
[source,yaml] [source,yaml]
---- ----
apiVersion: k8s.cni.cncf.io/v1beta1 apiVersion: k8s.cni.cncf.io/v1beta1
@@ -28,11 +29,11 @@ kind: MultiNetworkPolicy
metadata: metadata:
annotations: annotations:
k8s.v1.cni.cncf.io/policy-for:<namespace_name>/<network_name> k8s.v1.cni.cncf.io/policy-for:<namespace_name>/<network_name>
# ...
---- ----
+ +
--
where: where:
+
`<namespace_name>`:: Specifies the namespace name. `<namespace_name>`:: Specifies the namespace name.
`<network_name>`:: Specifies the name of a network attachment definition. `<network_name>`:: Specifies the name of a network attachment definition.
--

4
modules/nw-multi-network-policy-enable.adoc
View File

@@ -6,11 +6,12 @@
[id="nw-multi-network-policy-enable_{context}"] [id="nw-multi-network-policy-enable_{context}"]
= Enabling multi-network policy for the cluster = Enabling multi-network policy for the cluster
[role="_abstract"]
As a cluster administrator, you can enable multi-network policy support on your cluster. As a cluster administrator, you can enable multi-network policy support on your cluster.
.Prerequisites .Prerequisites
* Install the OpenShift CLI (`oc`). * Install the {oc-first}.
* Log in to the cluster with a user with `cluster-admin` privileges. * Log in to the cluster with a user with `cluster-admin` privileges.
.Procedure .Procedure
@@ -25,6 +26,7 @@ metadata:
name: cluster name: cluster
spec: spec:
useMultiNetworkPolicy: true useMultiNetworkPolicy: true
# ...
---- ----
. Configure the cluster to enable multi-network policy. Successful output lists the name of the policy object and the `patched` status. . Configure the cluster to enable multi-network policy. Successful output lists the name of the policy object and the `patched` status.

19
modules/nw-multi-network-policy-ipv6-suppport.adoc
View File

@@ -6,13 +6,12 @@
[id="nw-multi-network-policy-ipv6-support_{context}"] [id="nw-multi-network-policy-ipv6-support_{context}"]
= Supporting multi-network policies in IPv6 networks = Supporting multi-network policies in IPv6 networks
[role="_abstract"]
The ICMPv6 Neighbor Discovery Protocol (NDP) is a set of messages and processes that enable devices to discover and maintain information about neighboring nodes. NDP plays a crucial role in IPv6 networks, facilitating the interaction between devices on the same link. The ICMPv6 Neighbor Discovery Protocol (NDP) is a set of messages and processes that enable devices to discover and maintain information about neighboring nodes. NDP plays a crucial role in IPv6 networks, facilitating the interaction between devices on the same link.
The Cluster Network Operator (CNO) deploys the iptables implementation of multi-network policy when the `useMultiNetworkPolicy` parameter is set to `true`. The Cluster Network Operator (CNO) deploys the iptables implementation of multi-network policy when the `useMultiNetworkPolicy` parameter is set to `true`.
To support multi-network policies in IPv6 networks the Cluster Network Operator deploys the following set of rules in every pod affected by a multi-network policy: To support multi-network policies in IPv6 networks the Cluster Network Operator deploys the following set of custom rules in every pod affected by a multi-network policy:
.Multi-network policy custom rules
[source,yaml] [source,yaml]
---- ----
@@ -32,14 +31,16 @@ data:
-p icmpv6 --icmpv6-type router-advertisement -j ACCEPT <4> -p icmpv6 --icmpv6-type router-advertisement -j ACCEPT <4>
---- ----
<1> This rule allows incoming ICMPv6 neighbor solicitation messages, which are part of the neighbor discovery protocol (NDP). These messages help determine the link-layer addresses of neighboring nodes. where:
<2> This rule allows incoming ICMPv6 neighbor advertisement messages, which are part of NDP and provide information about the link-layer address of the sender.
<3> This rule permits incoming ICMPv6 router solicitation messages. Hosts use these messages to request router configuration information. `icmpv6-type neighbor-solicitation`:: This rule allows incoming ICMPv6 neighbor solicitation messages, which are part of the neighbor discovery protocol (NDP). These messages help determine the link-layer addresses of neighboring nodes.
<4> This rule allows incoming ICMPv6 router advertisement messages, which give configuration information to hosts. `icmpv6-type neighbor-advertisement`:: This rule allows incoming ICMPv6 neighbor advertisement messages, which are part of NDP and provide information about the link-layer address of the sender.
`icmpv6-type router-solicitation`:: This rule permits incoming ICMPv6 router solicitation messages. Hosts use these messages to request router configuration information.
`icmpv6-type router-advertisement`:: This rule allows incoming ICMPv6 router advertisement messages, which give configuration information to hosts.
[NOTE] [NOTE]
==== ====
You cannot edit these predefined rules. You cannot edit the predefined rules.
==== ====
These rules collectively enable essential ICMPv6 traffic for correct network functioning, including address resolution and router communication in an IPv6 environment. With these rules in place and a multi-network policy denying traffic, applications are not expected to experience connectivity issues. The rules collectively enable essential ICMPv6 traffic for correct network functioning, including address resolution and router communication in an IPv6 environment. With these rules in place and a multi-network policy denying traffic, applications are not expected to experience connectivity issues.

32
modules/nw-multus-add-pod.adoc
View File

@@ -22,6 +22,7 @@ endif::[]
[id="nw-multus-add-pod_{context}"] [id="nw-multus-add-pod_{context}"]
= Adding a pod to a secondary network = Adding a pod to a secondary network
[role="_abstract"]
You can add a pod to a secondary network. The pod continues to send normal cluster-related network traffic over the default network. You can add a pod to a secondary network. The pod continues to send normal cluster-related network traffic over the default network.
When a pod is created, a secondary networks is attached to the pod. However, if a pod already exists, you cannot attach a secondary network to it. When a pod is created, a secondary networks is attached to the pod. However, if a pod already exists, you cannot attach a secondary network to it.
@@ -48,7 +49,7 @@ endif::sriov[]
.Prerequisites .Prerequisites
* Install the OpenShift CLI (`oc`). * Install the {oc-first}.
* Log in to the cluster. * Log in to the cluster.
ifdef::sriov[] ifdef::sriov[]
* Install the SR-IOV Operator. * Install the SR-IOV Operator.
@@ -65,9 +66,12 @@ endif::sriov[]
---- ----
metadata: metadata:
annotations: annotations:
k8s.v1.cni.cncf.io/networks: <network>[,<network>,...] <1> k8s.v1.cni.cncf.io/networks: <network>[,<network>,...]
---- ----
<1> To specify more than one secondary network, separate each network with a comma. Do not include whitespace between the comma. If you specify the same secondary network multiple times, that pod will have multiple network interfaces attached to that network. +
where:
+
`k8s.v1.cni.cncf.io/networks`:: To specify more than one secondary network, separate each network with a comma. Do not include whitespace between the comma. If you specify the same secondary network multiple times, that pod will have multiple network interfaces attached to that network.
+ +
.. To attach a secondary network with customizations, add an annotation with the following format: .. To attach a secondary network with customizations, add an annotation with the following format:
+ +
@@ -78,15 +82,18 @@ metadata:
k8s.v1.cni.cncf.io/networks: |- k8s.v1.cni.cncf.io/networks: |-
[ [
{ {
"name": "<network>", <1> "name": "<network>",
"namespace": "<namespace>", <2> "namespace": "<namespace>",
"default-route": ["<default_route>"] <3> "default-route": ["<default_route>"]
} }
] ]
---- ----
<1> Specify the name of the secondary network defined by a `NetworkAttachmentDefinition` object. +
<2> Specify the namespace where the `NetworkAttachmentDefinition` object is defined. where:
<3> Optional: Specify an override for the default route, such as `192.168.17.1`. +
`name`:: Specify the name of the secondary network defined by a `NetworkAttachmentDefinition` object.
`namespace`:: Specify the namespace where the `NetworkAttachmentDefinition` object is defined.
`default-route`:: Optional parameter. Specify an override for the default route, such as `192.168.17.1`.
. To create the pod, enter the following command. Replace `<name>` with the name of the pod. . To create the pod, enter the following command. Replace `<name>` with the name of the pod.
+ +
@@ -112,7 +119,7 @@ kind: Pod
metadata: metadata:
annotations: annotations:
k8s.v1.cni.cncf.io/networks: macvlan-bridge k8s.v1.cni.cncf.io/networks: macvlan-bridge
k8s.v1.cni.cncf.io/network-status: |- <1> k8s.v1.cni.cncf.io/network-status: |-
[{ [{
"name": "ovn-kubernetes", "name": "ovn-kubernetes",
"interface": "eth0", "interface": "eth0",
@@ -137,7 +144,10 @@ spec:
status: status:
... ...
---- ----
<1> The `k8s.v1.cni.cncf.io/network-status` parameter is a JSON array of +
where:
+
`k8s.v1.cni.cncf.io/network-status`:: The `k8s.v1.cni.cncf.io/network-status` parameter is a JSON array of
objects. Each object describes the status of a secondary network attached objects. Each object describes the status of a secondary network attached
to the pod. The annotation value is stored as a plain text value. to the pod. The annotation value is stored as a plain text value.

16
modules/nw-multus-bond-cni-object.adoc
View File

@@ -6,7 +6,8 @@
[id="nw-multus-bond-cni-object_{context}"] [id="nw-multus-bond-cni-object_{context}"]
= Configuration for a Bond CNI secondary network = Configuration for a Bond CNI secondary network
The Bond Container Network Interface (Bond CNI) enables the aggregation of multiple network interfaces into a single logical "bonded" interface within a container, enhancing network redundancy and fault tolerance. Only SR-IOV Virtual Functions (VFs) are supported for bonding with this plugin. [role="_abstract"]
The Bond Container Network Interface (Bond CNI) enables the aggregation of multiple network interfaces into a single logical bonded interface within a container, which enhanches network redundancy and fault tolerance. Only SR-IOV Virtual Functions (VFs) are supported for bonding with this plugin.
The following table describes the configuration parameters for the Bond CNI plugin: The following table describes the configuration parameters for the Bond CNI plugin:
@@ -15,7 +16,6 @@ The following table describes the configuration parameters for the Bond CNI plug
|==== |====
|Field|Type|Description |Field|Type|Description
|`name` |`name`
|`string` |`string`
|Specifies the name given to this CNI network attachment definition. This name is used to identify and reference the interface within the container. |Specifies the name given to this CNI network attachment definition. This name is used to identify and reference the interface within the container.
@@ -34,11 +34,11 @@ The following table describes the configuration parameters for the Bond CNI plug
|`mtu` |`mtu`
|`integer` |`integer`
|Optional: Specifies the maximum transmission unit (MTU) of the bond. The default is 1500. |Optional: Specifies the maximum transmission unit (MTU) of the bond. The default is `1500`.
|`failOverMac` |`failOverMac`
|`integer` |`integer`
|Optional: Specifies the `failOverMac` setting for the bond. Default is 0. |Optional: Specifies the `failOverMac` setting for the bond. Default is `0`.
|`mode` |`mode`
|`string` |`string`
@@ -50,7 +50,7 @@ The following table describes the configuration parameters for the Bond CNI plug
|`linksInContainer` |`linksInContainer`
|`boolean` |`boolean`
|Optional: Specifies whether the network interfaces intended for bonding are expected to be created and available directly within the container's network namespace when the bond starts. If `false` which is the default, the CNI plugin looks for these interfaces on the host system first before attempting to form the bond. |Optional: Specifies whether the network interfaces intended for bonding are expected to be created and available directly within the network namespace of the container when the bond starts. If `false` which is the default, the CNI plugin looks for these interfaces on the host system first before attempting to form the bond.
|`links` |`links`
|`object` |`object`
@@ -62,10 +62,8 @@ The following table describes the configuration parameters for the Bond CNI plug
|==== |====
--
:FeatureName: xmitHashPolicy :FeatureName: xmitHashPolicy
include::snippets/technology-preview.adoc[] include::snippets/technology-preview.adoc[]
--
[id="nw-multus-bond-cni-config-example_{context}"] [id="nw-multus-bond-cni-config-example_{context}"]
== Bond CNI plugin configuration example == Bond CNI plugin configuration example
@@ -127,4 +125,6 @@ The following example configures a secondary network named `bond-tlb-net` with t
} }
---- ----
<1> This parameter dictates how outgoing network traffic is distributed across the `net1` and `net2` active member interfaces within the bond. The hashing algorithm combines layer 2 information, specifically source and destination MAC addresses, with layer 3 information, which includes source and destination IP addresses. where
`xmitHashPolicy`:: This parameter dictates how outgoing network traffic is distributed across the `net1` and `net2` active member interfaces within the bond. The hashing algorithm combines layer 2 information, specifically source and destination MAC addresses, with layer 3 information, which includes source and destination IP addresses.

10
modules/nw-multus-bridge-object.adoc
View File

@@ -7,9 +7,9 @@
[id="nw-multus-bridge-object_{context}"] [id="nw-multus-bridge-object_{context}"]
= Configuration for a bridge secondary network = Configuration for a bridge secondary network
The following object describes the configuration parameters for the Bridge CNI plugin: [role="_abstract"]
The bridge CNI plugin JSON configuration object describes the configuration parameters for the Bridge CNI plugin. The following table details these parameters:
.Bridge CNI plugin JSON configuration object
[cols=".^2,.^2,.^6",options="header"] [cols=".^2,.^2,.^6",options="header"]
|==== |====
|Field|Type|Description |Field|Type|Description
@@ -40,7 +40,7 @@ endif::microshift[]
|`bridge` |`bridge`
|`string` |`string`
|Optional: Specify the name of the virtual bridge to use. If the bridge interface does not exist on the host, it is created. The default value is `cni0`. |Optional: Specify the name of the virtual bridge to use. If the bridge interface does not exist on the host, the bridge interface gets created. The default value is `cni0`.
|`ipMasq` |`ipMasq`
|`boolean` |`boolean`
@@ -73,7 +73,7 @@ ifndef::microshift[]
|`preserveDefaultVlan` |`preserveDefaultVlan`
|`string` |`string`
|Optional: Indicates whether the default vlan must be preserved on the `veth` end connected to the bridge. Defaults to true. |Optional: Indicates whether the default vlan must be preserved on the `veth` end connected to the bridge. Defaults to `true`.
|`vlanTrunk` |`vlanTrunk`
|`list` |`list`
@@ -135,7 +135,7 @@ ifdef::microshift[]
The following example configures a secondary network named `bridge-conf` for use with the {microshift-short} Multus CNI: The following example configures a secondary network named `bridge-conf` for use with the {microshift-short} Multus CNI:
[source,json] [source,json,subs="verbatim"]
---- ----
apiVersion: "k8s.cni.cncf.io/v1" apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition kind: NetworkAttachmentDefinition

17
modules/nw-multus-configure-dualstack-ip-address.adoc
View File

@@ -8,7 +8,10 @@
[id="nw-multus-configure-dualstack-ip-address_{context}"] [id="nw-multus-configure-dualstack-ip-address_{context}"]
= Creating a configuration for assignment of dual-stack IP addresses dynamically = Creating a configuration for assignment of dual-stack IP addresses dynamically
Dual-stack IP address assignment can be configured with the `ipRanges` parameter for: [role="_abstract"]
You can dynamically assign dual-stack IP addresses to a secondary network so that pods can communicate over both IPv4 and IPv6 addresses.
You can configure the following IP address assignment types in the `ipRanges` parameter:
* IPv4 addresses * IPv4 addresses
* IPv6 addresses * IPv6 addresses
@@ -47,13 +50,17 @@ spec:
---- ----
. Attach network to a pod. For more information, see "Adding a pod to a secondary network". . Attach the secondary network to a pod. For more information, see "Adding a pod to a secondary network".
. Verify that all IP addresses are assigned. .Verification
. Run the following command to ensure the IP addresses are assigned as metadata. * Verify that all IP addresses got assigned to the network interfaces within the network namespace of a pod by entering the following command:
+ +
[source,yaml] [source,yaml]
---- ----
$ oc exec -it mypod -- ip a $ oc exec -it <pod_name> -- ip a
---- ----
+
where:
+
`<podname>`:: The name of the pod.

12
modules/nw-multus-configuring-whereabouts-ip-reconciler-schedule.adoc
View File

@@ -6,12 +6,14 @@
[id="nw-multus-configuring-whereabouts-ip-reconciler-schedule_{context}"] [id="nw-multus-configuring-whereabouts-ip-reconciler-schedule_{context}"]
= Configuring the Whereabouts IP reconciler schedule = Configuring the Whereabouts IP reconciler schedule
The Whereabouts IPAM CNI plugin runs the IP reconciler daily. This process cleans up any stranded IP allocations that might result in exhausting IPs and therefore prevent new pods from getting an IP allocated to them. [role="_abstract"]
The Whereabouts IPAM CNI plugin runs the IP address reconciler daily. This process cleans up any stranded IP address allocations that might result in exhausting IP addresses and therefore prevent new pods from getting a stranded IP address allocated to them.
Use this procedure to change the frequency at which the IP reconciler runs. Use this procedure to change the frequency at which the IP reconciler runs.
.Prerequisites .Prerequisites
* You installed the OpenShift CLI (`oc`).
* You installed the {oc-first}.
* You have access to the cluster as a user with the `cluster-admin` role. * You have access to the cluster as a user with the `cluster-admin` role.
* You have deployed the `whereabouts-reconciler` daemon set, and the `whereabouts-reconciler` pods are up and running. * You have deployed the `whereabouts-reconciler` daemon set, and the `whereabouts-reconciler` pods are up and running.
@@ -28,7 +30,7 @@ This cron expression indicates the IP reconciler runs every 15 minutes. Adjust t
+ +
[NOTE] [NOTE]
==== ====
The `whereabouts-reconciler` daemon set can only consume a cron expression pattern that includes five asterisks. The sixth, which is used to denote seconds, is currently not supported. The `whereabouts-reconciler` daemon set can only consume a cron expression pattern that includes five asterisks. Red{nbsp} Hat does not support the sixth asterisk, which is used to denote seconds.
==== ====
. Retrieve information about resources related to the `whereabouts-reconciler` daemon set and pods within the `openshift-multus` namespace by running the following command: . Retrieve information about resources related to the `whereabouts-reconciler` daemon set and pods within the `openshift-multus` namespace by running the following command:
@@ -38,8 +40,6 @@ The `whereabouts-reconciler` daemon set can only consume a cron expression patte
$ oc get all -n openshift-multus | grep whereabouts-reconciler $ oc get all -n openshift-multus | grep whereabouts-reconciler
---- ----
+ +
.Example output
+
[source,terminal] [source,terminal]
---- ----
pod/whereabouts-reconciler-2p7hw 1/1 Running 0 4m14s pod/whereabouts-reconciler-2p7hw 1/1 Running 0 4m14s
@@ -54,8 +54,6 @@ daemonset.apps/whereabouts-reconciler 6 6 6 6
$ oc -n openshift-multus logs whereabouts-reconciler-2p7hw $ oc -n openshift-multus logs whereabouts-reconciler-2p7hw
---- ----
+ +
.Example output
[source,terminal] [source,terminal]
---- ----
2024-02-02T16:33:54Z [debug] event not relevant: "/cron-schedule/..2024_02_02_16_33_54.1375928161": CREATE 2024-02-02T16:33:54Z [debug] event not relevant: "/cron-schedule/..2024_02_02_16_33_54.1375928161": CREATE

30
modules/nw-multus-create-master-interface-bridge-cni.adoc
View File

@@ -6,10 +6,12 @@
[id="nw-multus-create-master-interface-bridge-cni_{context}"] [id="nw-multus-create-master-interface-bridge-cni_{context}"]
= Creating a subinterface based on a bridge master interface in a container namespace = Creating a subinterface based on a bridge master interface in a container namespace
[role="_abstract"]
You can create a subinterface based on a bridge `master` interface that exists in a container namespace. Creating a subinterface can be applied to other types of interfaces. You can create a subinterface based on a bridge `master` interface that exists in a container namespace. Creating a subinterface can be applied to other types of interfaces.
.Prerequisites .Prerequisites
* You have installed the OpenShift CLI (`oc`).
* You have installed the {oc-first}.
* You are logged in to the {product-title} cluster as a user with `cluster-admin` privileges. * You are logged in to the {product-title} cluster as a user with `cluster-admin` privileges.
.Procedure .Procedure
@@ -21,7 +23,7 @@ You can create a subinterface based on a bridge `master` interface that exists i
$ oc new-project test-namespace $ oc new-project test-namespace
---- ----
. Using the following YAML example, create a bridge `NetworkAttachmentDefinition` custom resource definition (CRD) file named `bridge-nad.yaml`: . Using the following YAML configuration example, create a bridge `NetworkAttachmentDefinition` custom resource definition (CRD) file named `bridge-nad.yaml`:
+ +
[source,yaml] [source,yaml]
---- ----
@@ -74,15 +76,17 @@ spec:
"cniVersion": "0.3.1", "cniVersion": "0.3.1",
"name": "ipvlan-net", "name": "ipvlan-net",
"type": "ipvlan", "type": "ipvlan",
"master": "net1", <1> "master": "net1",
"mode": "l3", "mode": "l3",
"linkInContainer": true, <2> "linkInContainer": true,
"ipam": {"type": "whereabouts", "ipRanges": [{"range": "10.0.0.0/24"}]} "ipam": {"type": "whereabouts", "ipRanges": [{"range": "10.0.0.0/24"}]}
}' }'
---- ----
+ +
<1> Specifies the ethernet interface to associate with the network attachment. This is subsequently configured in the pod networks annotation. where:
<2> Specifies that the `master` interface is in the container network namespace. +
`master`:: Specifies the ethernet interface to associate with the network attachment. The ethernet interface is subsequently configured in the pod networks annotation.
`linkInContainer`:: Specifies that the `master` interface exists in the container network namespace.
. Apply the YAML file by running the following command: . Apply the YAML file by running the following command:
+ +
@@ -98,7 +102,7 @@ $ oc apply -f ipvlan-additional-network-configuration.yaml
$ oc get network-attachment-definitions $ oc get network-attachment-definitions
---- ----
. Using the following YAML example, create a file named `pod-a.yaml` for the pod definition: . Using the following YAML configuration example, create a file named `pod-a.yaml` for the pod definition:
+ +
[source,yaml] [source,yaml]
---- ----
@@ -132,7 +136,9 @@ spec:
drop: [ALL] drop: [ALL]
---- ----
+ +
<1> Specifies the name to be used as the `master` for the IPVLAN interface. where:
+
`k8s.v1.cni.cncf.io/networks,interface`:: Specifies the name to be used as the `master` for the IPVLAN interface.
. Apply the YAML file by running the following command: . Apply the YAML file by running the following command:
+ +
@@ -141,6 +147,8 @@ spec:
$ oc apply -f pod-a.yaml $ oc apply -f pod-a.yaml
---- ----
.Verification
. Verify that the pod is running by using the following command: . Verify that the pod is running by using the following command:
+ +
[source,terminal] [source,terminal]
@@ -148,8 +156,6 @@ $ oc apply -f pod-a.yaml
$ oc get pod -n test-namespace $ oc get pod -n test-namespace
---- ----
+ +
.Example output
+
[source,terminal] [source,terminal]
---- ----
NAME READY STATUS RESTARTS AGE NAME READY STATUS RESTARTS AGE
@@ -163,8 +169,6 @@ pod-a 1/1 Running 0 2m36s
$ oc exec -n test-namespace pod-a -- ip a $ oc exec -n test-namespace pod-a -- ip a
---- ----
+ +
.Example output
+
[source,terminal] [source,terminal]
---- ----
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
@@ -193,4 +197,4 @@ $ oc exec -n test-namespace pod-a -- ip a
valid_lft forever preferred_lft forever valid_lft forever preferred_lft forever
---- ----
+ +
This output shows that the network interface `net2` is associated with the physical interface `net1`. This output shows that the network interface `net2` associates with the physical interface `net1`.

68
modules/nw-multus-create-multiple-vlans-sriov.adoc
View File

@@ -6,15 +6,16 @@
[id="nw-multus-create-multiple-vlans-sriov_{context}"] [id="nw-multus-create-multiple-vlans-sriov_{context}"]
= Creating multiple VLANs on SR-IOV VFs = Creating multiple VLANs on SR-IOV VFs
An example use case for utilizing this feature is to create multiple VLANs based on SR-IOV VFs. To do so, begin by creating an SR-IOV network and then define the network attachments for the VLAN interfaces. [role="_abstract"]
You can create multiple VLANs based on SR-IOV VFs. For this configuration, create an SR-IOV network and then define the network attachments for the VLAN interfaces.
The following example shows how to configure the setup illustrated in this diagram. The following diagram shows the setup process for creating multiple VLANs on SR-IOV VFs.
.Creating VLANs
image::345_OpenShift_config_additional_network_0823.png[Creating VLANs] image::345_OpenShift_config_additional_network_0823.png[Creating VLANs]
.Prerequisites .Prerequisites
* You installed the OpenShift CLI (`oc`).
* You installed the {oc-first}.
* You have access to the cluster as a user with the `cluster-admin` role. * You have access to the cluster as a user with the `cluster-admin` role.
* You have installed the SR-IOV Network Operator. * You have installed the SR-IOV Network Operator.
@@ -26,8 +27,9 @@ image::345_OpenShift_config_additional_network_0823.png[Creating VLANs]
---- ----
$ oc new-project test-namespace $ oc new-project test-namespace
---- ----
. Create an SR-IOV node policy:
. Create an SR-IOV node policy.
+
.. Create an `SriovNetworkNodePolicy` object, and then save the YAML in the `sriov-node-network-policy.yaml` file: .. Create an `SriovNetworkNodePolicy` object, and then save the YAML in the `sriov-node-network-policy.yaml` file:
+ +
[source,yaml] [source,yaml]
@@ -42,8 +44,8 @@ spec:
isRdma: false isRdma: false
needVhostNet: true needVhostNet: true
nicSelector: nicSelector:
vendor: "15b3" <1> vendor: "15b3"
deviceID: "101b" <2> deviceID: "101b"
rootDevices: ["00:05.0"] rootDevices: ["00:05.0"]
numVfs: 10 numVfs: 10
priority: 99 priority: 99
@@ -52,15 +54,17 @@ spec:
feature.node.kubernetes.io/network-sriov.capable: "true" feature.node.kubernetes.io/network-sriov.capable: "true"
---- ----
+ +
where:
+
`vendor`:: The vendor hexadecimal code of the SR-IOV network device. The value `15b3` associates with a Mellanox NIC.
`deviceID`:: The device hexadecimal code of the SR-IOV network device.
+
[NOTE] [NOTE]
==== ====
The SR-IOV network node policy configuration example, with the setting `deviceType: netdevice`, is tailored specifically for Mellanox Network Interface Cards (NICs). The SR-IOV network node policy configuration example, with the setting `deviceType: netdevice`, is tailored specifically for Mellanox Network Interface Cards (NICs).
==== ====
+ +
<1> The vendor hexadecimal code of the SR-IOV network device. The value `15b3` is associated with a Mellanox NIC. .. Apply the YAML configuration by running the following command:
<2> The device hexadecimal code of the SR-IOV network device.
.. Apply the YAML by running the following command:
+ +
[source,terminal] [source,terminal]
---- ----
@@ -69,12 +73,12 @@ $ oc apply -f sriov-node-network-policy.yaml
+ +
[NOTE] [NOTE]
==== ====
Applying this might take some time due to the node requiring a reboot. Applying the YAML configuration might take time because of a node reboot operation.
==== ====
. Create an SR-IOV network: . Create an SR-IOV network:
+
.. Create the `SriovNetwork` custom resource (CR) for the additional secondary SR-IOV network attachment as in the following example CR. Save the YAML as the file `sriov-network-attachment.yaml`: .. Create the `SriovNetwork` custom resource (CR) for the additional secondary SR-IOV network attachment as demonstrated in the following example CR. Save the YAML as a `sriov-network-attachment.yaml` file:
+ +
[source,yaml] [source,yaml]
---- ----
@@ -89,7 +93,7 @@ spec:
spoofChk: "off" spoofChk: "off"
trust: "on" trust: "on"
---- ----
+
.. Apply the YAML by running the following command: .. Apply the YAML by running the following command:
+ +
[source,terminal] [source,terminal]
@@ -97,8 +101,8 @@ spec:
$ oc apply -f sriov-network-attachment.yaml $ oc apply -f sriov-network-attachment.yaml
---- ----
. Create the VLAN secondary network: . Create the VLAN secondary network.
+
.. Using the following YAML example, create a file named `vlan100-additional-network-configuration.yaml`: .. Using the following YAML example, create a file named `vlan100-additional-network-configuration.yaml`:
+ +
[source,yaml] [source,yaml]
@@ -116,19 +120,21 @@ spec:
"plugins": [ "plugins": [
{ {
"type": "vlan", "type": "vlan",
"master": "ext0", <1> "master": "ext0",
"mtu": 1500, "mtu": 1500,
"vlanId": 100, "vlanId": 100,
"linkInContainer": true, <2> "linkInContainer": true,
"ipam": {"type": "whereabouts", "ipRanges": [{"range": "1.1.1.0/24"}]} "ipam": {"type": "whereabouts", "ipRanges": [{"range": "1.1.1.0/24"}]}
} }
] ]
} }
---- ----
+ +
<1> The VLAN configuration needs to specify the `master` name. This can be configured in the pod networks annotation. where:
<2> The `linkInContainer` parameter must be specified. +
`master`:: The VLAN configuration needs to specify the `master` name. You can specify the name in the networks annotation of a pod.
`linkInContainer`:: The `linkInContainer` parameter must be specified.
+
.. Apply the YAML file by running the following command: .. Apply the YAML file by running the following command:
+ +
[source,terminal] [source,terminal]
@@ -136,13 +142,13 @@ spec:
$ oc apply -f vlan100-additional-network-configuration.yaml $ oc apply -f vlan100-additional-network-configuration.yaml
---- ----
. Create a pod definition by using the earlier specified networks: . Create a pod definition by using the earlier specified networks.
+
.. Using the following YAML example, create a file named `pod-a.yaml` file: .. Using the following YAML configuration example, create a file named `pod-a.yaml` file:
+ +
[NOTE] [NOTE]
==== ====
The manifest below includes 2 resources: The manifest example includes the following resources:
* Namespace with security labels * Namespace with security labels
* Pod definition with appropriate network annotation * Pod definition with appropriate network annotation
@@ -170,7 +176,7 @@ metadata:
{ {
"name": "sriov-network", "name": "sriov-network",
"namespace": "test-namespace", "namespace": "test-namespace",
"interface": "ext0" <1> "interface": "ext0"
}, },
{ {
"name": "vlan-100", "name": "vlan-100",
@@ -194,8 +200,10 @@ spec:
type: "RuntimeDefault" type: "RuntimeDefault"
---- ----
+ +
<1> The name to be used as the `master` for the VLAN interface. where:
+
`interface`:: The name to be used as the `master` interface for the VLAN interface.
+
.. Apply the YAML file by running the following command: .. Apply the YAML file by running the following command:
+ +
[source,terminal] [source,terminal]
@@ -210,8 +218,6 @@ $ oc apply -f pod-a.yaml
$ oc describe pods nginx-pod -n test-namespace $ oc describe pods nginx-pod -n test-namespace
---- ----
+ +
.Example output
+
[source,terminal] [source,terminal]
---- ----
Name: nginx-pod Name: nginx-pod

13
modules/nw-multus-creating-whereabouts-reconciler-daemon-set.adoc
View File

@@ -6,29 +6,28 @@
[id="nw-multus-creating-whereabouts-reconciler-daemon-set_{context}"] [id="nw-multus-creating-whereabouts-reconciler-daemon-set_{context}"]
= Creating a whereabouts-reconciler daemon set = Creating a whereabouts-reconciler daemon set
The Whereabouts reconciler is responsible for managing dynamic IP address assignments for the pods within a cluster by using the Whereabouts IP Address Management (IPAM) solution. It ensures that each pod gets a unique IP address from the specified IP address range. It also handles IP address releases when pods are deleted or scaled down. [role="_abstract"]
The Whereabouts reconciler is responsible for managing dynamic IP address assignments for the pods within a cluster by using the Whereabouts IP Address Management (IPAM) solution. The Whereabouts reconciler ensures that each pod gets a unique IP address from the specified IP address range. The Whereabouts reconciler also handles IP address releases when pods are deleted or scaled down.
[NOTE] [NOTE]
==== ====
You can also use a `NetworkAttachmentDefinition` custom resource definition (CRD) for dynamic IP address assignment. You can also use a `NetworkAttachmentDefinition` custom resource definition (CRD) for dynamic IP address assignment.
==== ====
The `whereabouts-reconciler` daemon set is automatically created when you configure a secondary network through the Cluster Network Operator. It is not automatically created when you configure a secondary network from a YAML manifest. The `whereabouts-reconciler` daemon set is automatically created when you configure a secondary network through the Cluster Network Operator. The `whereabouts-reconciler` DaemonSet does not get automatically created when you configure a secondary network from a YAML manifest.
To trigger the deployment of the `whereabouts-reconciler` daemon set, you must manually create a `whereabouts-shim` network attachment by editing the Cluster Network Operator custom resource (CR) file. To trigger the deployment of the `whereabouts-reconciler` daemon set, you must manually create a `whereabouts-shim` network attachment by editing the Cluster Network Operator custom resource (CR) file.
Use the following procedure to deploy the `whereabouts-reconciler` daemon set.
.Procedure .Procedure
. Edit the `Network.operator.openshift.io` custom resource (CR) by running the following command: . Edit the `Network.operator.openshift.io` CR by running the following command:
+ +
[source,terminal] [source,terminal]
---- ----
$ oc edit network.operator.openshift.io cluster $ oc edit network.operator.openshift.io cluster
---- ----
. Include the `additionalNetworks` section shown in this example YAML extract within the `spec` definition of the custom resource (CR): . Include the `additionalNetworks` section shown in this example YAML extract within the `spec` definition of the CR:
+ +
[source,yaml] [source,yaml]
---- ----
@@ -63,8 +62,6 @@ spec:
$ oc get all -n openshift-multus | grep whereabouts-reconciler $ oc get all -n openshift-multus | grep whereabouts-reconciler
---- ----
+ +
.Example output
+
[source,terminal] [source,terminal]
---- ----
pod/whereabouts-reconciler-jnp6g 1/1 Running 0 6s pod/whereabouts-reconciler-jnp6g 1/1 Running 0 6s

4
modules/nw-multus-dummy-device-object.adoc
View File

@@ -6,11 +6,11 @@
[id="nw-multus-dummy-device-object_{context}"] [id="nw-multus-dummy-device-object_{context}"]
= Configuration for a dummy device additional network = Configuration for a dummy device additional network
[role="_abstract"]
The dummy CNI plugin functions like a loopback device. The plugin is a virtual interface, and you can use the plugin to route the packets to a designated IP address. Unlike a loopback device, the IP address is arbitrary and is not restricted to the `127.0.0.0/8` address range. The dummy CNI plugin functions like a loopback device. The plugin is a virtual interface, and you can use the plugin to route the packets to a designated IP address. Unlike a loopback device, the IP address is arbitrary and is not restricted to the `127.0.0.0/8` address range.
The following object describes the configuration parameters for the dummy CNI plugin: The dummy device CNI plugin JSON configuration object describes the configuration parameters for the dummy CNI plugin. The following table details these parameters:
.Dummy device CNI plugin JSON configuration object
[cols=".^2,.^2,.^6",options="header"] [cols=".^2,.^2,.^6",options="header"]
|==== |====
|Field|Type|Description |Field|Type|Description

9
modules/nw-multus-host-device-object.adoc
View File

@@ -6,15 +6,16 @@
[id="nw-multus-host-device-object_{context}"] [id="nw-multus-host-device-object_{context}"]
= Configuration for a host device secondary network = Configuration for a host device secondary network
[role="_abstract"]
The host device CNI plugin JSON configuration object describes the configuration parameters for the host-device CNI plugin.
[NOTE] [NOTE]
==== ====
Specify your network device by setting only one of the following parameters: `device`,`hwaddr`, `kernelpath`, or `pciBusID`. Specify your network device by setting only one of the following parameters: `device`,`hwaddr`, `kernelpath`, or `pciBusID`.
==== ====
The following object describes the configuration parameters for the host-device CNI plugin: The following table details the configuration parameters:
// containernetworking/plugins/.../host-device.go#L50
.Host device CNI plugin JSON configuration object
[cols=".^2,.^2,.^6",options="header"] [cols=".^2,.^2,.^6",options="header"]
|==== |====
|Field|Type|Description |Field|Type|Description
@@ -61,4 +62,4 @@ The following example configures a secondary network named `hostdev-net`:
"type": "host-device", "type": "host-device",
"device": "eth1" "device": "eth1"
} }
---- ----

29
modules/nw-multus-ipam-object.adoc
View File

@@ -13,20 +13,21 @@
[id="nw-multus-ipam-object_{context}"] [id="nw-multus-ipam-object_{context}"]
= Configuration of IP address assignment for a network attachment = Configuration of IP address assignment for a network attachment
[role="_abstract"]
For secondary networks, you can assign IP addresses by using an IP Address Management (IPAM) CNI plugin, which supports various assignment methods, including Dynamic Host Configuration Protocol (DHCP) and static assignment. For secondary networks, you can assign IP addresses by using an IP Address Management (IPAM) CNI plugin, which supports various assignment methods, including Dynamic Host Configuration Protocol (DHCP) and static assignment.
The DHCP IPAM CNI plugin responsible for dynamic assignment of IP addresses operates with two distinct components: The DHCP IPAM CNI plugin responsible for dynamic assignment of IP addresses operates with two distinct components:
* *CNI Plugin*: Responsible for integrating with the Kubernetes networking stack to request and release IP addresses. * CNI Plugin: Responsible for integrating with the Kubernetes networking stack to request and release IP addresses.
* *DHCP IPAM CNI Daemon*: A listener for DHCP events that coordinates with existing DHCP servers in the environment to handle IP address assignment requests. This daemon is _not_ a DHCP server itself. * DHCP IPAM CNI Daemon: A listener for DHCP events that coordinates with existing DHCP servers in the environment to handle IP address assignment requests. This daemon is not a DHCP server itself.
For networks requiring `type: dhcp` in their IPAM configuration, ensure the following: For networks requiring `type: dhcp` in their IPAM configuration, ensure the DHCP server meets the following conditions:
* A DHCP server is available and running in the environment. * A DHCP server is available and running in the environment.
* The DHCP server is external to the cluster and you expect the server to form part of the existing network infrastructure for the customer. * The DHCP server is external to the cluster and you expect the server to form part of the existing network infrastructure for the customer.
* The DHCP server is appropriately configured to serve IP addresses to the nodes. * The DHCP server is appropriately configured to serve IP addresses to the nodes.
In cases where a DHCP server is unavailable in the environment, consider using the Whereabouts IPAM CNI plugin instead. The Whereabouts CNI provides similar IP address management capabilities without the need for an external DHCP server. In cases where a DHCP server is unavailable in the environment, consider using the Whereabouts IPAM CNI plugin. The Whereabouts CNI provides similar IP address management capabilities without the need for an external DHCP server.
[NOTE] [NOTE]
==== ====
@@ -35,10 +36,6 @@ Use the Whereabouts CNI plugin when no external DHCP server exists or where stat
Ensure the periodic renewal of a DHCP lease throughout the lifetime of a container by including a separate daemon, the DHCP IPAM CNI Daemon. To deploy the DHCP IPAM CNI daemon, change the Cluster Network Operator (CNO) configuration to trigger the deployment of this daemon as part of the secondary network setup. Ensure the periodic renewal of a DHCP lease throughout the lifetime of a container by including a separate daemon, the DHCP IPAM CNI Daemon. To deploy the DHCP IPAM CNI daemon, change the Cluster Network Operator (CNO) configuration to trigger the deployment of this daemon as part of the secondary network setup.
////
IMPORTANT: If you set the `type` parameter to the `DHCP` value, you cannot set any other parameters.
////
[id="nw-multus-static_{context}"] [id="nw-multus-static_{context}"]
== Static IP address assignment configuration == Static IP address assignment configuration
@@ -110,14 +107,11 @@ The `addresses` array requires objects with the following fields:
|`domain` |`domain`
|`array` |`array`
|The default domain to append to a hostname. For example, if the |The default domain to append to a hostname. For example, if the domain is set to `example.com`, a DNS lookup query for `example-host` is rewritten as `example-host.example.com`.
domain is set to `example.com`, a DNS lookup query for `example-host` is
rewritten as `example-host.example.com`.
|`search` |`search`
|`array` |`array`
|An array of domain names to append to an unqualified hostname, |An array of domain names to append to an unqualified hostname, such as `example-host`, during a DNS lookup query.
such as `example-host`, during a DNS lookup query.
|==== |====
@@ -139,7 +133,7 @@ such as `example-host`, during a DNS lookup query.
[id="nw-multus-dhcp_{context}"] [id="nw-multus-dhcp_{context}"]
== Dynamic IP address (DHCP) assignment configuration == Dynamic IP address (DHCP) assignment configuration
A pod obtains its original DHCP lease when it is created. The lease must be periodically renewed by a minimal DHCP server deployment running on the cluster. A pod obtains its original DHCP lease when the pod gets created. The lease must be periodically renewed by a minimal DHCP server deployment running on the cluster.
[IMPORTANT] [IMPORTANT]
==== ====
@@ -166,10 +160,13 @@ spec:
"cniVersion": "0.3.1", "cniVersion": "0.3.1",
"type": "bridge", "type": "bridge",
"ipam": { "ipam": {
"type": "dhcp" <1> "type": "dhcp"
} }
} }
# ... # ...
---- ----
<1> Specifies dynamic IP address (DHCP) assignment for the cluster.
where:
`type`:: Specifies dynamic IP address assignment for the cluster.

6
modules/nw-multus-ipvlan-object.adoc
View File

@@ -10,9 +10,9 @@
[id="nw-multus-ipvlan-object_{context}"] [id="nw-multus-ipvlan-object_{context}"]
= Configuration for an IPVLAN secondary network = Configuration for an IPVLAN secondary network
The following object describes the configuration parameters for the IPVLAN, `ipvlan`, CNI plugin: [role="_abstract"]
The IPVLAN CNI plugin JSON configuration object describes the configuration parameters for the IPVLAN, `ipvlan`, CNI plugin. The following table details these parameters:
.IPVLAN CNI plugin JSON configuration object
[cols=".^2,.^2,.^6",options="header"] [cols=".^2,.^2,.^6",options="header"]
|==== |====
|Field|Type|Description |Field|Type|Description
@@ -81,4 +81,4 @@ The following example configures a secondary network named `ipvlan-net`:
] ]
} }
} }
---- ----

4
modules/nw-multus-macvlan-object.adoc
View File

@@ -7,9 +7,9 @@
[id="nw-multus-macvlan-object_{context}"] [id="nw-multus-macvlan-object_{context}"]
= Configuration for a MACVLAN secondary network = Configuration for a MACVLAN secondary network
The following object describes the configuration parameters for the MAC Virtual LAN (MACVLAN) Container Network Interface (CNI) plugin: [role="_abstract"]
The MACVLAN CNI plugin JSON configuration object describes the configuration parameters for the MAC Virtual LAN (MACVLAN) Container Network Interface (CNI) plugin. The following table describes these parameters:
.MACVLAN CNI plugin JSON configuration object
[cols=".^2,.^2,.^6",options="header"] [cols=".^2,.^2,.^6",options="header"]
|==== |====
|Field|Type|Description |Field|Type|Description

82
modules/nw-multus-tap-object.adoc
View File

@@ -6,10 +6,9 @@
[id="nw-multus-tap-object_{context}"] [id="nw-multus-tap-object_{context}"]
= Configuration for a TAP secondary network = Configuration for a TAP secondary network
The following object describes the configuration parameters for the TAP CNI [role="_abstract"]
plugin: The TAP CNI plugin JSON configuration object describes the configuration parameters for the TAP CNI plugin. The following table describes these parameters:
.TAP CNI plugin JSON configuration object
[cols=".^2,.^2,.^6",options="header"] [cols=".^2,.^2,.^6",options="header"]
|==== |====
|Field|Type|Description |Field|Type|Description
@@ -81,80 +80,3 @@ The following example configures a secondary network named `mynet`:
} }
---- ----
[id="nw-multus-enable-container_use_devices_{context}"]
== Setting SELinux boolean for the TAP CNI plugin
To create the tap device with the `container_t` SELinux context, enable the `container_use_devices` boolean on the host by using the Machine Config Operator (MCO).
.Prerequisites
* You have installed the OpenShift CLI (`oc`).
.Procedure
. Create a new YAML file named, such as `setsebool-container-use-devices.yaml`, with the following details:
+
[source, yaml]
----
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
labels:
machineconfiguration.openshift.io/role: worker
name: 99-worker-setsebool
spec:
config:
ignition:
version: 3.2.0
systemd:
units:
- enabled: true
name: setsebool.service
contents: |
[Unit]
Description=Set SELinux boolean for the TAP CNI plugin
Before=kubelet.service
[Service]
Type=oneshot
ExecStart=/usr/sbin/setsebool container_use_devices=on
RemainAfterExit=true
[Install]
WantedBy=multi-user.target graphical.target
----
+
. Create the new `MachineConfig` object by running the following command:
+
[source,terminal]
----
$ oc apply -f setsebool-container-use-devices.yaml
----
+
[NOTE]
====
Applying any changes to the `MachineConfig` object causes all affected nodes to gracefully reboot after the change is applied. This update can take some time to be applied.
====
+
. Verify the change is applied by running the following command:
+
[source,terminal]
----
$ oc get machineconfigpools
----
+
.Expected output
+
[source,terminal,options="nowrap",role="white-space-pre"]
----
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE
master rendered-master-e5e0c8e8be9194e7c5a882e047379cfa True False False 3 3 3 0 7d2h
worker rendered-worker-d6c9ca107fba6cd76cdcbfcedcafa0f2 True False False 3 3 3 0 7d
----
+
[NOTE]
====
All nodes should be in the updated and ready state.
====

82
modules/nw-multus-tap-setting-boolean.adoc Normal file
View File

@@ -0,0 +1,82 @@
// Module included in the following assemblies:
//
// * networking/multiple_networks/secondary_networks/creating-secondary-nwt-other-cni.adoc
:_mod-docs-content-type: PROCEDURE
[id="nw-multus-tap-setting-boolean.adoc_{context}"]
= Setting SELinux boolean for the TAP CNI plugin
[role="_abstract"]
To create the tap device with the `container_t` SELinux context, enable the `container_use_devices` boolean on the host by using the Machine Config Operator (MCO).
.Prerequisites
* You have installed the {oc-first}.
.Procedure
. Create a new YAML file with the following details:
+
.Example `setsebool-container-use-devices.yaml`
[source, yaml]
----
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
labels:
machineconfiguration.openshift.io/role: worker
name: 99-worker-setsebool
spec:
config:
ignition:
version: 3.2.0
systemd:
units:
- enabled: true
name: setsebool.service
contents: |
[Unit]
Description=Set SELinux boolean for the TAP CNI plugin
Before=kubelet.service
[Service]
Type=oneshot
ExecStart=/usr/sbin/setsebool container_use_devices=on
RemainAfterExit=true
[Install]
WantedBy=multi-user.target graphical.target
----
. Create the new `MachineConfig` object by running the following command:
+
[source,terminal]
----
$ oc apply -f setsebool-container-use-devices.yaml
----
+
[NOTE]
====
Applying any changes to the `MachineConfig` object causes all affected nodes to gracefully reboot after the change is applied. The MCO might take some time to apply the update.
====
.Verification
* Verify that the change is applied by running the following command:
+
[source,terminal]
----
$ oc get machineconfigpools
----
+
[source,terminal,options="nowrap",role="white-space-pre"]
----
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE
master rendered-master-e5e0c8e8be9194e7c5a882e047379cfa True False False 3 3 3 0 7d2h
worker rendered-worker-d6c9ca107fba6cd76cdcbfcedcafa0f2 True False False 3 3 3 0 7d
----
+
[NOTE]
====
All nodes should be in the `Updated` and `Ready` state.
====

6
modules/nw-multus-vlan-object.adoc
View File

@@ -8,9 +8,9 @@
[id="nw-multus-vlan-object_{context}"] [id="nw-multus-vlan-object_{context}"]
= Configuration for a VLAN secondary network = Configuration for a VLAN secondary network
The following object describes the configuration parameters for the VLAN, `vlan`, CNI plugin: [role="_abstract"]
The VLAN CNI plugin JSON configuration object describes the configuration parameters for the VLAN, `vlan`, CNI plugin. The following table details these parameters:
.VLAN CNI plugin JSON configuration object
[cols=".^2,.^2,.^6",options="header"] [cols=".^2,.^2,.^6",options="header"]
|==== |====
|Field|Type|Description |Field|Type|Description
@@ -81,4 +81,4 @@ The following example demonstrates a `vlan` configuration with a secondary netwo
"nameservers": [ "10.1.1.1", "8.8.8.8" ] "nameservers": [ "10.1.1.1", "8.8.8.8" ]
} }
} }
---- ----

67
modules/nw-multus-whereabouts-fast-ipam.adoc
View File

@@ -8,6 +8,7 @@
[id="nw-multus-whereabouts-fast-ipam_{context}"] [id="nw-multus-whereabouts-fast-ipam_{context}"]
= Fast IPAM configuration for the Whereabouts IPAM CNI plugin = Fast IPAM configuration for the Whereabouts IPAM CNI plugin
[role="_abstract"]
Wherabouts is an IP Address Management (IPAM) Container Network Interface (CNI) plugin that assigns IP addresses at a cluster-wide level. Whereabouts does not require a Dynamic Host Configuration Protocol (DHCP) server. Wherabouts is an IP Address Management (IPAM) Container Network Interface (CNI) plugin that assigns IP addresses at a cluster-wide level. Whereabouts does not require a Dynamic Host Configuration Protocol (DHCP) server.
A typical Wherabouts workflow is described as follows: A typical Wherabouts workflow is described as follows:
@@ -26,7 +27,7 @@ The Fast IPAM feature uses `nodeslicepools`, which are managed by the Whereabout
.Prerequisites .Prerequisites
* You added the `whereabouts-shim` configuration to the `Network.operator.openshift.io` custom resource (CR), so that the Cluster Network Operator (CNO) can deploy the Whereabouts Controller. See "Creating a Whereabouts reconciler daemon set". * You added the `whereabouts-shim` configuration to the `Network.operator.openshift.io` custom resource (CR), so that the Cluster Network Operator (CNO) can deploy the Whereabouts Controller. See "Creating a Whereabouts reconciler daemon set".
* For the Fast IPAM feature to work, ensure that the `NetworkAttachmentDefinition` (NAD) and the pod exist in the same `openshift-multus` namesapace. * For the Fast IPAM feature to work, ensure that the `NetworkAttachmentDefinition` (NAD) and the pod exist in the same `openshift-multus` namespace.
.Procedure .Procedure
@@ -37,7 +38,6 @@ The Fast IPAM feature uses `nodeslicepools`, which are managed by the Whereabout
$ oc get pods -n openshift-multus | grep controller $ oc get pods -n openshift-multus | grep controller
---- ----
+ +
.Example output
[source,terminal] [source,terminal]
---- ----
multus-admission-controller-d89bc96f-gbf7s 2/2 Running 0 6h3m multus-admission-controller-d89bc96f-gbf7s 2/2 Running 0 6h3m
@@ -49,35 +49,37 @@ multus-admission-controller-d89bc96f-gbf7s 2/2 Running 0 6h
If the Whereabouts Controller is not running, the Fast IPAM does not work. If the Whereabouts Controller is not running, the Fast IPAM does not work.
==== ====
. Create a NAD file for your cluster and add the Fast IPAM details to the file: . Create a NAD file for your cluster and add the Fast IPAM details to the file as demonstrated in the following example configuration:
+ +
.Example NAD file with a Fast IPAM configuration
[source,yaml,subs="attributes+,quotes"] [source,yaml,subs="attributes+,quotes"]
---- ----
apiVersion: "k8s.cni.cncf.io/v1" apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition kind: NetworkAttachmentDefinition
metadata: metadata:
name: wb-ipam name: wb-ipam
namespace: openshift-multus <1> namespace: openshift-multus
spec: spec:
config: { config: {
"cniVersion": "0.3.0", "cniVersion": "0.3.0",
"name": "wb-ipam-cni-name", <2> "name": "wb-ipam-cni-name",
"type": "bridge", "type": "bridge",
"bridge": "cni0", "bridge": "cni0",
"ipam": { "ipam": {
"type": "whereabouts", <3> "type": "whereabouts",
"range": "10.5.0.0/20", <4> "range": "10.5.0.0/20",
"node_slice_size": "/24" <5> "node_slice_size": "/24"
} }
} }
# ... # ...
---- ----
<1> The namespace where CNO deploys the NAD. +
<2> The name of the Whereabouts IPAM CNI plugin. where:
<3> The type of IPAM CNI plugin: `whereabouts`. +
<4> The IP address range for the IP pool that the Whereabouts IPAM CNI plugin uses for allocating IP addresses to pods. `namespace`:: The namespace where CNO deploys the NAD.
<5> Sets the slice size of IP addresses available to each node. `name`:: The name of the Whereabouts IPAM CNI plugin.
`type`:: The type of IPAM CNI plugin, such as `whereabouts`.
`range`:: The IP address range for the IP pool that the Whereabouts IPAM CNI plugin uses for allocating IP addresses to pods.
`node_slice_size`:: Sets the slice size of IP addresses available to each node.
. Add the Whereabouts IPAM CNI plugin annotation details to the YAML file for the pod: . Add the Whereabouts IPAM CNI plugin annotation details to the YAML file for the pod:
+ +
@@ -86,20 +88,23 @@ spec:
apiVersion: v1 apiVersion: v1
kind: Pod kind: Pod
metadata: metadata:
name: <pod_name> <1> name: <pod_name>
annotations: annotations:
k8s.v1.cni.cncf.io/networks: openshift-multus/wb-ipam <2> k8s.v1.cni.cncf.io/networks: openshift-multus/wb-ipam
spec: spec:
containers: containers:
- name: samplepod <3> - name: samplepod
command: ["/bin/ash", "-c", "trap : TERM INT; sleep infinity & wait"] <4> command: ["/bin/ash", "-c", "trap : TERM INT; sleep infinity & wait"] <4>
image: alpine image: alpine
# ... # ...
---- ----
<1> The name of the pod. +
<2> The annotation details that references the Whereabouts IPAM CNI plugin name that exists in the `openshift-multus` namespace. where:
<3> The name of the container for the pod. +
<4> Defines the entry point for the container and controls the behavior of the container in the Whereabouts IPAM CNI plugin. `name`:: The name of the pod.
`k8s.v1.cni.cncf.io/networks`:: The annotation details that references the Whereabouts IPAM CNI plugin name that exists in the `openshift-multus` namespace.
`- name`:: The name of the container for the pod.
`command`:: Defines the entry point for the container and controls the behavior of the container in the Whereabouts IPAM CNI plugin.
. Apply the NAD file configuration to pods that exist on nodes that run in your cluster: . Apply the NAD file configuration to pods that exist on nodes that run in your cluster:
+ +
@@ -117,8 +122,6 @@ $ oc create -f <NAD_file_name>.yaml
$ oc describe pod <pod_name> $ oc describe pod <pod_name>
---- ----
+ +
.Example output
+
[source,terminal] [source,terminal]
---- ----
... ...
@@ -140,30 +143,26 @@ Containers:
$ oc exec <pod_name> -- ip a $ oc exec <pod_name> -- ip a
---- ----
+ +
.Example output
[source,terminal] [source,terminal]
---- ----
... ...
3: net1@if23: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue 3: net1@if23: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue
link/ether 82:01:98:e5:0c:b7 brd ff:ff:ff:ff:ff:ff link/ether 82:01:98:e5:0c:b7 brd ff:ff:ff:ff:ff:ff
inet 192.168.2.0/24 brd 10.10.0.255 scope global net1 <1> inet 192.168.2.0/24 brd 10.10.0.255 scope global net1
valid_lft forever preferred_lft forever valid_lft forever preferred_lft forever
inet6 fe80::8001:98ff:fee5:cb7/64 scope link inet6 fe80::8001:98ff:fee5:cb7/64 scope link
valid_lft forever preferred_lft forever valid_lft forever preferred_lft forever
... ...
---- ----
<1> Pod is attached to the `192.168.2.1` IP address on the `net1` interface as expected. +
where:
+
`inet`: Pod is attached to the `192.168.2.1` IP address on the `net1` interface as expected.
. Check that the node selector pool exists in the `openshift-multus` namespace by entering the following command. The expected output shows the name of the node selector pool and the creation age in minutes. . Check that the node selector pool exists in the `openshift-multus` namespace by entering the following command. The expected output shows the name of the node selector pool, such as `nodeslicepool, and the creation age in minutes, such as `32m`.
+ +
[source,terminal] [source,terminal]
---- ----
$ oc get nodeslicepool -n openshift-multus $ oc get nodeslicepool -n openshift-multus
---- ----
+
.Example output
[source,terminal]
----
NAME AGE
nodeslicepool 32m
----

15
modules/nw-multus-whereabouts.adoc
View File

@@ -8,6 +8,7 @@
[id="nw-multus-whereabouts_{context}"] [id="nw-multus-whereabouts_{context}"]
= Dynamic IP address assignment configuration with Whereabouts = Dynamic IP address assignment configuration with Whereabouts
[role="_abstract"]
The Whereabouts CNI plugin helps the dynamic assignment of an IP address to a secondary network without the use of a DHCP server. The Whereabouts CNI plugin helps the dynamic assignment of an IP address to a secondary network without the use of a DHCP server.
The Whereabouts CNI plugin also supports overlapping IP address ranges and configuration of the same CIDR range multiple times within separate `NetworkAttachmentDefinition` CRDs. This provides greater flexibility and management capabilities in multitenant environments. The Whereabouts CNI plugin also supports overlapping IP address ranges and configuration of the same CIDR range multiple times within separate `NetworkAttachmentDefinition` CRDs. This provides greater flexibility and management capabilities in multitenant environments.
@@ -72,11 +73,14 @@ The following example shows a dynamic IP address assignment that uses overlappin
"ipam": { "ipam": {
"type": "whereabouts", "type": "whereabouts",
"range": "192.0.2.192/29", "range": "192.0.2.192/29",
"network_name": "example_net_common", <1> "network_name": "example_net_common",
} }
} }
---- ----
<1> Optional. If set, must match the `network_name` of `NetworkAttachmentDefinition 2`.
where:
`network_name`:: Optional parameter. If set, must match the `network_name` of `NetworkAttachmentDefinition 2`.
.NetworkAttachmentDefinition 2 .NetworkAttachmentDefinition 2
[source,json] [source,json]
@@ -85,8 +89,11 @@ The following example shows a dynamic IP address assignment that uses overlappin
"ipam": { "ipam": {
"type": "whereabouts", "type": "whereabouts",
"range": "192.0.2.192/24", "range": "192.0.2.192/24",
"network_name": "example_net_common", <1> "network_name": "example_net_common",
} }
} }
---- ----
<1> Optional. If set, must match the `network_name` of `NetworkAttachmentDefinition 1`.
where:
`network_name`:: Optional parameter. If set, must match the `network_name` of `NetworkAttachmentDefinition 1`.

37
modules/nw-networkpolicy-allow-application-all-namespaces.adoc
View File

@@ -16,6 +16,9 @@ endif::[]
[id="nw-networkpolicy-allow-traffic-from-all-applications_{context}"] [id="nw-networkpolicy-allow-traffic-from-all-applications_{context}"]
= Creating a {name} policy allowing traffic to an application from all namespaces = Creating a {name} policy allowing traffic to an application from all namespaces
[role="_abstract"]
You can configure a policy that allows traffic from all pods in all namespaces to a particular application.
ifndef::microshift[] ifndef::microshift[]
[NOTE] [NOTE]
==== ====
@@ -23,13 +26,11 @@ If you log in with a user with the `cluster-admin` role, then you can create a n
==== ====
endif::microshift[] endif::microshift[]
Follow this procedure to configure a policy that allows traffic from all pods in all namespaces to a particular application.
.Prerequisites .Prerequisites
ifndef::microshift[] ifndef::microshift[]
* Your cluster uses a network plugin that supports `NetworkPolicy` objects, such as the OVN-Kubernetes network plugin, with `mode: NetworkPolicy` set. * Your cluster uses a network plugin that supports `NetworkPolicy` objects, such as the OVN-Kubernetes network plugin, with `mode: NetworkPolicy` set.
endif::microshift[] endif::microshift[]
* You installed the OpenShift CLI (`oc`). * You installed the {oc-first}.
ifndef::microshift[] ifndef::microshift[]
* You logged in to the cluster with a user with `{role}` privileges. * You logged in to the cluster with a user with `{role}` privileges.
endif::microshift[] endif::microshift[]
@@ -39,35 +40,27 @@ endif::microshift[]
. Create a policy that allows traffic from all pods in all namespaces to a particular application. Save the YAML in the `web-allow-all-namespaces.yaml` file: . Create a policy that allows traffic from all pods in all namespaces to a particular application. Save the YAML in the `web-allow-all-namespaces.yaml` file:
+ +
ifndef::multi[]
[source,yaml] [source,yaml]
---- ----
ifndef::multi[]
kind: NetworkPolicy kind: NetworkPolicy
apiVersion: networking.k8s.io/v1 apiVersion: networking.k8s.io/v1
endif::multi[]
ifdef::multi[]
apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy
endif::multi[]
metadata:
name: web-allow-all-namespaces
namespace: default
ifdef::multi[]
annotations:
k8s.v1.cni.cncf.io/policy-for:<namespace_name>/<network_name>
endif::multi[]
spec: spec:
podSelector: podSelector:
matchLabels: matchLabels:
app: web <1> app: web
policyTypes: policyTypes:
- Ingress - Ingress
ingress: ingress:
- from: - from:
- namespaceSelector: {} <2> - namespaceSelector: {}
---- ----
<1> Applies the policy only to `app:web` pods in default namespace. endif::multi[]
<2> Selects all pods in all namespaces. +
where:
+
`app`:: Applies the policy only to `app:web` pods in default namespace.
`namespaceSelector`:: Selects all pods in all namespaces.
+ +
[NOTE] [NOTE]
==== ====
@@ -80,8 +73,6 @@ By default, if you do not specify a `namespaceSelector` parameter in the policy
---- ----
$ oc apply -f web-allow-all-namespaces.yaml $ oc apply -f web-allow-all-namespaces.yaml
---- ----
+
Successful output lists the name of the policy object and the `created` status.
.Verification .Verification
@@ -106,8 +97,6 @@ $ oc run test-$RANDOM --namespace=secondary --rm -i -t --image=alpine -- sh
# wget -qO- --timeout=2 http://web.default # wget -qO- --timeout=2 http://web.default
---- ----
+ +
.Expected output
+
[source,terminal] [source,terminal]
---- ----
<!DOCTYPE html> <!DOCTYPE html>

59
modules/nw-networkpolicy-allow-application-particular-namespace.adoc
View File

@@ -16,6 +16,12 @@ endif::[]
[id="nw-networkpolicy-allow-traffic-from-a-namespace_{context}"] [id="nw-networkpolicy-allow-traffic-from-a-namespace_{context}"]
= Creating a {name} policy allowing traffic to an application from a namespace = Creating a {name} policy allowing traffic to an application from a namespace
[role="_abstract"]
You can configure a policy that allows traffic to a pod with the label `app=web` from a particular namespace. This configuration is useful in the following use cases:
* Restrict traffic to a production database only to namespaces that have production workloads deployed.
* Enable monitoring tools deployed to a particular namespace to scrape metrics from the current namespace.
ifndef::microshift[] ifndef::microshift[]
[NOTE] [NOTE]
==== ====
@@ -23,16 +29,11 @@ If you log in with a user with the `cluster-admin` role, then you can create a n
==== ====
endif::microshift[] endif::microshift[]
Follow this procedure to configure a policy that allows traffic to a pod with the label `app=web` from a particular namespace. You might want to do this to:
* Restrict traffic to a production database only to namespaces that have production workloads deployed.
* Enable monitoring tools deployed to a particular namespace to scrape metrics from the current namespace.
.Prerequisites .Prerequisites
ifndef::microshift[] ifndef::microshift[]
* Your cluster uses a network plugin that supports `NetworkPolicy` objects, such as the OVN-Kubernetes network plugin, with `mode: NetworkPolicy` set. * Your cluster uses a network plugin that supports `NetworkPolicy` objects, such as the OVN-Kubernetes network plugin, with `mode: NetworkPolicy` set.
endif::microshift[] endif::microshift[]
* You installed the OpenShift CLI (`oc`). * You installed the {oc-first}.
ifndef::microshift[] ifndef::microshift[]
* You logged in to the cluster with a user with `{role}` privileges. * You logged in to the cluster with a user with `{role}` privileges.
endif::microshift[] endif::microshift[]
@@ -42,37 +43,55 @@ endif::microshift[]
. Create a policy that allows traffic from all pods in a particular namespaces with a label `purpose=production`. Save the YAML in the `web-allow-prod.yaml` file: . Create a policy that allows traffic from all pods in a particular namespaces with a label `purpose=production`. Save the YAML in the `web-allow-prod.yaml` file:
+ +
ifdef::multi[]
[source,yaml] [source,yaml]
---- ----
ifndef::multi[]
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
endif::multi[]
ifdef::multi[]
apiVersion: k8s.cni.cncf.io/v1beta1 apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy kind: MultiNetworkPolicy
endif::multi[]
metadata: metadata:
name: web-allow-prod name: web-allow-prod
namespace: default namespace: default
ifdef::multi[]
annotations: annotations:
k8s.v1.cni.cncf.io/policy-for:<namespace_name>/<network_name> k8s.v1.cni.cncf.io/policy-for:<namespace_name>/<network_name>
endif::multi[]
spec: spec:
podSelector: podSelector:
matchLabels: matchLabels:
app: web <1> app: web
policyTypes: policyTypes:
- Ingress - Ingress
ingress: ingress:
- from: - from:
- namespaceSelector: - namespaceSelector:
matchLabels: matchLabels:
purpose: production <2> purpose: production
---- ----
<1> Applies the policy only to `app:web` pods in the default namespace. endif::multi[]
<2> Restricts traffic to only pods in namespaces that have the label `purpose=production`. ifndef::multi[]
[source,yaml]
----
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: web-allow-prod
namespace: default
spec:
podSelector:
matchLabels:
app: web
policyTypes:
- Ingress
ingress:
- from:
- namespaceSelector:
matchLabels:
purpose: production
----
endif::multi[]
+
where:
+
`app`:: Applies the policy only to `app:web` pods in the default namespace.
`purpose`:: Restricts traffic to only pods in namespaces that have the label `purpose=production`.
. Apply the policy by entering the following command. Successful output lists the name of the policy object and the `created` status. . Apply the policy by entering the following command. Successful output lists the name of the policy object and the `created` status.
+ +
@@ -80,8 +99,6 @@ spec:
---- ----
$ oc apply -f web-allow-prod.yaml $ oc apply -f web-allow-prod.yaml
---- ----
+
Successful output lists the name of the policy object and the `created` status.
.Verification .Verification
@@ -148,8 +165,6 @@ $ oc run test-$RANDOM --namespace=prod --rm -i -t --image=alpine -- sh
# wget -qO- --timeout=2 http://web.default # wget -qO- --timeout=2 http://web.default
---- ----
+ +
.Expected output
+
[source,terminal] [source,terminal]
---- ----
<!DOCTYPE html> <!DOCTYPE html>

41
modules/nw-networkpolicy-allow-external-clients.adoc
View File

@@ -15,6 +15,7 @@ endif::[]
[id="nw-networkpolicy-allow-external-clients_{context}"] [id="nw-networkpolicy-allow-external-clients_{context}"]
= Creating a {name} policy to allow traffic from external clients = Creating a {name} policy to allow traffic from external clients
[role="_abstract"]
With the `deny-by-default` policy in place you can proceed to configure a policy that allows traffic from external clients to a pod with the label `app=web`. With the `deny-by-default` policy in place you can proceed to configure a policy that allows traffic from external clients to a pod with the label `app=web`.
ifndef::microshift[] ifndef::microshift[]
@@ -26,7 +27,7 @@ endif::microshift[]
ifdef::microshift[] ifdef::microshift[]
[NOTE] [NOTE]
==== ====
Firewalld rules run before any `NetworkPolicy` is enforced. Firewalled rules run before any `NetworkPolicy` is enforced.
==== ====
endif::microshift[] endif::microshift[]
@@ -36,7 +37,7 @@ Follow this procedure to configure a policy that allows external service from th
ifndef::microshift[] ifndef::microshift[]
* Your cluster uses a network plugin that supports `NetworkPolicy` objects, such as the OVN-Kubernetes network plugin, with `mode: NetworkPolicy` set. * Your cluster uses a network plugin that supports `NetworkPolicy` objects, such as the OVN-Kubernetes network plugin, with `mode: NetworkPolicy` set.
endif::microshift[] endif::microshift[]
* You installed the OpenShift CLI (`oc`). * You installed the {oc-first}.
ifndef::microshift[] ifndef::microshift[]
* You logged in to the cluster with a user with `{role}` privileges. * You logged in to the cluster with a user with `{role}` privileges.
endif::microshift[] endif::microshift[]
@@ -46,23 +47,11 @@ endif::microshift[]
. Create a policy that allows traffic from the public Internet directly or by using a load balancer to access the pod. Save the YAML in the `web-allow-external.yaml` file: . Create a policy that allows traffic from the public Internet directly or by using a load balancer to access the pod. Save the YAML in the `web-allow-external.yaml` file:
+ +
ifndef::multi[]
[source,yaml] [source,yaml]
---- ----
ifndef::multi[]
kind: NetworkPolicy kind: NetworkPolicy
apiVersion: networking.k8s.io/v1 apiVersion: networking.k8s.io/v1
endif::multi[]
ifdef::multi[]
apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy
endif::multi[]
metadata:
name: web-allow-external
namespace: default
ifdef::multi[]
annotations:
k8s.v1.cni.cncf.io/policy-for:<namespace_name>/<network_name>
endif::multi[]
spec: spec:
policyTypes: policyTypes:
- Ingress - Ingress
@@ -72,6 +61,27 @@ spec:
ingress: ingress:
- {} - {}
---- ----
endif::multi[]
ifdef::multi[]
[source,yaml]
----
apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy
metadata:
name: web-allow-external
namespace: default
annotations:
k8s.v1.cni.cncf.io/policy-for:<namespace_name>/<network_name>
spec:
policyTypes:
- Ingress
podSelector:
matchLabels:
app: web
ingress:
- {}
----
endif::multi[]
. Apply the policy by entering the following command. Successful output lists the name of the policy object and the `created` status. . Apply the policy by entering the following command. Successful output lists the name of the policy object and the `created` status.
+ +
@@ -80,7 +90,6 @@ spec:
$ oc apply -f web-allow-external.yaml $ oc apply -f web-allow-external.yaml
---- ----
+ +
Successful output lists the name of the policy object and the `created` status.
ifndef::microshift[] ifndef::microshift[]
This policy allows traffic from all resources, including external traffic as illustrated in the following diagram: This policy allows traffic from all resources, including external traffic as illustrated in the following diagram:

171
modules/nw-networkpolicy-create-cli.adoc
View File

@@ -17,6 +17,7 @@ endif::[]
[id="nw-networkpolicy-create-cli_{context}"] [id="nw-networkpolicy-create-cli_{context}"]
= Creating a {name} policy using the CLI = Creating a {name} policy using the CLI
[role="_abstract"]
To define granular rules describing ingress or egress network traffic allowed for namespaces in your cluster, you can create a {name} policy. To define granular rules describing ingress or egress network traffic allowed for namespaces in your cluster, you can create a {name} policy.
ifndef::multi,microshift[] ifndef::multi,microshift[]
@@ -30,7 +31,7 @@ endif::multi,microshift[]
ifndef::microshift[] ifndef::microshift[]
* Your cluster uses a network plugin that supports `NetworkPolicy` objects, such as the OVN-Kubernetes network plugin, with `mode: NetworkPolicy` set. * Your cluster uses a network plugin that supports `NetworkPolicy` objects, such as the OVN-Kubernetes network plugin, with `mode: NetworkPolicy` set.
endif::microshift[] endif::microshift[]
* You installed the OpenShift CLI (`oc`). * You installed the {oc-first}.
ifndef::microshift[] ifndef::microshift[]
* You logged in to the cluster with a user with `{role}` privileges. * You logged in to the cluster with a user with `{role}` privileges.
endif::microshift[] endif::microshift[]
@@ -38,7 +39,8 @@ endif::microshift[]
.Procedure .Procedure
. Create a policy rule: . Create a policy rule.
+
.. Create a `<policy_name>.yaml` file: .. Create a `<policy_name>.yaml` file:
+ +
[source,terminal] [source,terminal]
@@ -46,33 +48,34 @@ endif::microshift[]
$ touch <policy_name>.yaml $ touch <policy_name>.yaml
---- ----
+ +
--
where: where:
+
`<policy_name>`:: Specifies the {name} policy file name. `<policy_name>`:: Specifies the {name} policy file name.
--
.. Define a {name} policy in the file that you just created, such as in the following examples:
+ +
.Deny ingress from all pods in all namespaces .. Define a {name} policy in the created file. The following example denies ingress traffic from all pods in all namespaces. This is a fundamental policy, blocking all cross-pod networking other than cross-pod traffic allowed by the configuration of other Network Policies.
This is a fundamental policy, blocking all cross-pod networking other than cross-pod traffic allowed by the configuration of other Network Policies.
+ +
ifndef::multi[]
[source,yaml] [source,yaml]
---- ----
ifndef::multi[]
kind: NetworkPolicy kind: NetworkPolicy
apiVersion: networking.k8s.io/v1 apiVersion: networking.k8s.io/v1
spec:
podSelector: {}
policyTypes:
- Ingress
ingress: []
----
endif::multi[] endif::multi[]
ifdef::multi[] ifdef::multi[]
[source,yaml]
----
apiVersion: k8s.cni.cncf.io/v1beta1 apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy kind: MultiNetworkPolicy
endif::multi[] endif:: multi[]
metadata: metadata:
name: deny-by-default name: deny-by-default
ifdef::multi[]
annotations: annotations:
k8s.v1.cni.cncf.io/policy-for:<namespace_name>/<network_name> k8s.v1.cni.cncf.io/policy-for:<namespace_name>/<network_name>
endif::multi[]
spec: spec:
podSelector: {} podSelector: {}
policyTypes: policyTypes:
@@ -80,67 +83,59 @@ spec:
ingress: [] ingress: []
---- ----
+ +
ifdef::multi[]
--
where: where:
+
`<network_name>`:: Specifies the name of a network attachment definition. `<network_name>`:: Specifies the name of a network attachment definition.
--
endif::multi[] endif::multi[]
+ +
.Allow ingress from all pods in the same namespace The following example configuration allows ingress traffic from all pods in the same namespace:
+ +
ifndef::multi[]
[source,yaml] [source,yaml]
---- ----
ifndef::multi[]
kind: NetworkPolicy kind: NetworkPolicy
apiVersion: networking.k8s.io/v1 apiVersion: networking.k8s.io/v1
endif::multi[]
ifdef::multi[]
apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy
endif::multi[]
metadata: metadata:
name: allow-same-namespace name: allow-same-namespace
ifdef::multi[]
annotations:
k8s.v1.cni.cncf.io/policy-for:<namespace_name>/<network_name>
endif::multi[]
spec: spec:
podSelector: podSelector:
ingress: ingress:
- from: - from:
- podSelector: {} - podSelector: {}
# ...
---- ----
ifdef::multi[]
+
--
where:
`<network_name>`:: Specifies the name of a network attachment definition.
--
endif::multi[] endif::multi[]
+ ifdef::multi[]
.Allow ingress traffic to one pod from a particular namespace
+
This policy allows traffic to pods that have the `pod-a` label from pods running in `namespace-y`.
+
[source,yaml] [source,yaml]
---- ----
ifndef::multi[]
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
endif::multi[]
ifdef::multi[]
apiVersion: k8s.cni.cncf.io/v1beta1 apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy kind: MultiNetworkPolicy
endif::multi[]
metadata: metadata:
name: allow-traffic-pod name: allow-same-namespace
ifdef::multi[]
annotations: annotations:
k8s.v1.cni.cncf.io/policy-for:<namespace_name>/<network_name> k8s.v1.cni.cncf.io/policy-for:<namespace_name>/<network_name>
spec:
podSelector:
ingress:
- from:
- podSelector: {}
# ...
----
+
where:
+
`<network_name>`:: Specifies the name of a network attachment definition.
endif::multi[] endif::multi[]
+
The following example allows ingress traffic to one pod from a particular namespace. This policy allows traffic to pods that have the `pod-a` label from pods running in `namespace-y`.
+
ifndef::multi[]
[source,yaml]
----
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: allow-traffic-pod
spec: spec:
podSelector: podSelector:
matchLabels: matchLabels:
@@ -152,42 +147,51 @@ spec:
- namespaceSelector: - namespaceSelector:
matchLabels: matchLabels:
kubernetes.io/metadata.name: namespace-y kubernetes.io/metadata.name: namespace-y
# ...
---- ----
endif::multi[]
ifdef::multi[] ifdef::multi[]
[source,yaml]
----
apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy
metadata:
name: allow-traffic-pod
annotations:
k8s.v1.cni.cncf.io/policy-for:<namespace_name>/<network_name>
spec:
podSelector:
matchLabels:
pod: pod-a
policyTypes:
- Ingress
ingress:
- from:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: namespace-y
# ...
----
+ +
--
where: where:
+
`<network_name>`:: Specifies the name of a network attachment definition. `<network_name>`:: Specifies the name of a network attachment definition.
--
endif::multi[] endif::multi[]
+ +
ifdef::multi[] The following example configuration restricts traffic to a service. This policy when applied ensures every pod with both labels `app=bookstore` and `role=api` can only be accessed by pods with label `app=bookstore`. In this example the application could be a REST API server, marked with labels `app=bookstore` and `role=api`.
.Restrict traffic to a service
+ +
This policy when applied ensures every pod with both labels `app=bookstore` and `role=api` can only be accessed by pods with label `app=bookstore`. In this example the application could be a REST API server, marked with labels `app=bookstore` and `role=api`. This example configuration addresses the following use cases:
+ +
This example addresses the following use cases:
* Restricting the traffic to a service to only the other microservices that need to use it. * Restricting the traffic to a service to only the other microservices that need to use it.
* Restricting the connections to a database to only permit the application using it. * Restricting the connections to a database to only permit the application using it.
+ +
ifndef::multi[]
[source,yaml] [source,yaml]
---- ----
ifndef::multi[]
kind: NetworkPolicy kind: NetworkPolicy
apiVersion: networking.k8s.io/v1 apiVersion: networking.k8s.io/v1
endif::multi[]
ifdef::multi[]
apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy
endif::multi[]
metadata: metadata:
name: api-allow name: api-allow
ifdef::multi[]
annotations:
k8s.v1.cni.cncf.io/policy-for:<namespace_name>/<network_name>
endif::multi[]
spec: spec:
podSelector: podSelector:
matchLabels: matchLabels:
@@ -198,16 +202,34 @@ spec:
- podSelector: - podSelector:
matchLabels: matchLabels:
app: bookstore app: bookstore
# ...
---- ----
ifdef::multi[]
+
--
where:
`<network_name>`:: Specifies the name of a network attachment definition.
--
endif::multi[] endif::multi[]
ifdef::multi[]
[source,yaml]
----
apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy
metadata:
name: api-allow
annotations:
k8s.v1.cni.cncf.io/policy-for:<namespace_name>/<network_name>
spec:
podSelector:
matchLabels:
app: bookstore
role: api
ingress:
- from:
- podSelector:
matchLabels:
app: bookstore
# ...
----
+
where:
+
`<network_name>`:: Specifies the name of a network attachment definition.
endif::multi[] endif::multi[]
. To create the {name} policy object, enter the following command. Successful output lists the name of the policy object and the `created` status. . To create the {name} policy object, enter the following command. Successful output lists the name of the policy object and the `created` status.
@@ -227,6 +249,7 @@ where:
Successful output lists the name of the policy object and the `created` status. Successful output lists the name of the policy object and the `created` status.
ifndef::microshift[] ifndef::microshift[]
+
[NOTE] [NOTE]
==== ====
If you log in to the web console with `cluster-admin` privileges, you have a choice of creating a network policy in any namespace in the cluster directly in YAML or from a form in the web console. If you log in to the web console with `cluster-admin` privileges, you have a choice of creating a network policy in any namespace in the cluster directly in YAML or from a form in the web console.

7
modules/nw-networkpolicy-delete-cli.adoc
View File

@@ -16,6 +16,7 @@ endif::[]
[id="nw-networkpolicy-delete-cli_{context}"] [id="nw-networkpolicy-delete-cli_{context}"]
= Deleting a {name} policy using the CLI = Deleting a {name} policy using the CLI
[role="_abstract"]
You can delete a {name} policy in a namespace. You can delete a {name} policy in a namespace.
ifndef::multi,microshift[] ifndef::multi,microshift[]
@@ -44,14 +45,10 @@ endif::microshift[]
$ oc delete {name}policy <policy_name> -n <namespace> $ oc delete {name}policy <policy_name> -n <namespace>
---- ----
+ +
--
where: where:
+
`<policy_name>`:: Specifies the name of the {name} policy. `<policy_name>`:: Specifies the name of the {name} policy.
`<namespace>`:: Optional parameter. If you defined the object in a different namespace than the current namespace, the parameter specifices the namespace. `<namespace>`:: Optional parameter. If you defined the object in a different namespace than the current namespace, the parameter specifices the namespace.
--
+
Successful output lists the name of the policy object and the `deleted` status.
ifdef::multi[] ifdef::multi[]
:!multi: :!multi:

18
modules/nw-networkpolicy-delete-ocm.adoc
View File

@@ -7,6 +7,7 @@
[id="nw-networkpolicy-delete-ocm_{context}"] [id="nw-networkpolicy-delete-ocm_{context}"]
= Deleting a network policy using {cluster-manager} = Deleting a network policy using {cluster-manager}
[role="_abstract"]
You can delete a network policy in a namespace. You can delete a network policy in a namespace.
.Prerequisites .Prerequisites
@@ -26,10 +27,13 @@ endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
. From the *Administrator* perspective in the {cluster-manager} web console, under *Networking*, click *NetworkPolicies*. . From the *Administrator* perspective in the {cluster-manager} web console, under *Networking*, click *NetworkPolicies*.
. Use one of the following methods for deleting your network policy: . Use one of the following methods for deleting your network policy:
+
** Delete the policy from the *Network Policies* table: .. Delete the policy from the *Network Policies* table:
.. From the *Network Policies* table, select the stack menu on the row of the network policy you want to delete and then, click *Delete NetworkPolicy*. +
... From the *Network Policies* table, select the stack menu on the row of the network policy you want to delete and then, click *Delete NetworkPolicy*.
** Delete the policy using the *Actions* drop-down menu from the individual network policy details: +
.. Click on *Actions* drop-down menu for your network policy. .. Delete the policy using the *Actions* drop-down menu from the individual network policy details:
.. Select *Delete NetworkPolicy* from the menu. +
... Click on *Actions* drop-down menu for your network policy.
+
... Select *Delete NetworkPolicy* from the menu.

60
modules/nw-networkpolicy-deny-all-allowed.adoc
View File

@@ -16,7 +16,8 @@ endif::[]
[id="nw-networkpolicy-deny-all-multi-network-policy_{context}"] [id="nw-networkpolicy-deny-all-multi-network-policy_{context}"]
= Creating a default deny all {name} policy = Creating a default deny all {name} policy
This policy blocks all cross-pod networking other than network traffic allowed by the configuration of other deployed network policies and traffic between host-networked pods. This procedure enforces a strong deny policy by applying a `deny-by-default` policy in the `my-project` namespace. [role="_abstract"]
The default deny all {name} policy blocks all cross-pod networking other than network traffic allowed by the configuration of other deployed network policies and traffic between host-networked pods. This procedure enforces a strong deny policy by applying a `deny-by-default` policy in the `my-project` namespace.
[WARNING] [WARNING]
==== ====
@@ -27,7 +28,7 @@ Without configuring a `NetworkPolicy` custom resource (CR) that allows traffic c
ifndef::microshift[] ifndef::microshift[]
* Your cluster uses a network plugin that supports `NetworkPolicy` objects, such as the OVN-Kubernetes network plugin, with `mode: NetworkPolicy` set. * Your cluster uses a network plugin that supports `NetworkPolicy` objects, such as the OVN-Kubernetes network plugin, with `mode: NetworkPolicy` set.
endif::microshift[] endif::microshift[]
* You installed the OpenShift CLI (`oc`). * You installed the {oc-first}.
ifndef::microshift[] ifndef::microshift[]
* You logged in to the cluster with a user with `{role}` privileges. * You logged in to the cluster with a user with `{role}` privileges.
endif::microshift[] endif::microshift[]
@@ -37,55 +38,58 @@ endif::microshift[]
. Create the following YAML that defines a `deny-by-default` policy to deny ingress from all pods in all namespaces. Save the YAML in the `deny-by-default.yaml` file: . Create the following YAML that defines a `deny-by-default` policy to deny ingress from all pods in all namespaces. Save the YAML in the `deny-by-default.yaml` file:
+ +
ifdef::multi[]
[source,yaml] [source,yaml]
---- ----
ifdef::multi[]
apiVersion: k8s.cni.cncf.io/v1beta1 apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy kind: MultiNetworkPolicy
metadata: metadata:
name: deny-by-default name: deny-by-default
namespace: my-project <1> namespace: my-project
annotations: annotations:
k8s.v1.cni.cncf.io/policy-for:<namespace_name>/<network_name> <2> k8s.v1.cni.cncf.io/policy-for:<namespace_name>/<network_name>
spec: spec:
podSelector: {} <3> podSelector: {}
policyTypes: <4> policyTypes:
- Ingress <5> - Ingress
ingress: [] <6> ingress: []
----
+
where:
+
`namespace`:: Specifies the namespace in which to deploy the policy. For example, the `my-project` namespace.
`annotations`:: Specifies the name of namespace project followed by the network attachment definition name.
`podSelector`:: If this field is empty, the configuration matches all the pods. Therefore, the policy applies to all pods in the `my-project` namespace.
`policyTypes`:: Specifies a list of rule types that the `NetworkPolicy` relates to.
`- Ingress`:: Specifies `Ingress` only `policyTypes`.
`ingress`:: Specifies ingress rules. If not specified, all incoming traffic is dropped to all pods.
endif::multi[] endif::multi[]
ifndef::multi[] ifndef::multi[]
[source,yaml]
----
kind: NetworkPolicy kind: NetworkPolicy
apiVersion: networking.k8s.io/v1 apiVersion: networking.k8s.io/v1
metadata: metadata:
name: deny-by-default name: deny-by-default
namespace: my-project <1> namespace: my-project
spec: spec:
podSelector: {} <2> podSelector: {}
ingress: [] <3> ingress: []
endif::multi[]
---- ----
ifdef::multi[]
<1> Specifies the namespace in which to deploy the policy. For example, the `my-project` namespace.
<2> Specifies the name of namespace project followed by the network attachment definition name.
<3> If this field is empty, the configuration matches all the pods. Therefore, the policy applies to all pods in the `my-project` namespace.
<4> Specifies a list of rule types that the `NetworkPolicy` relates to.
<5> Specifies `Ingress` only `policyTypes`.
<6> Specifies `ingress` rules. If not specified, all incoming traffic is dropped to all pods.
endif::multi[]
ifndef::multi[]
<1> `Specifies the namespace in which to deploy the policy. For example, the `my-project` namespace.
<2> If this field is empty, the configuration matches all the pods. Therefore, the policy applies to all pods in the `my-project` namespace.
<3> There are no `ingress` rules specified. This causes incoming traffic to be dropped to all pods.
endif::multi[]
+ +
where:
+
`namespace`:: Specifies the namespace in which to deploy the policy. For example, the `my-project` namespace.
`podSelector`:: If this field is empty, the configuration matches all the pods. Therefore, the policy applies to all pods in the `my-project` namespace.
`ingress`:: Where `[]` indicates that no `ingress` rules are specified. This causes incoming traffic to be dropped to all pods.
endif::multi[]
. Apply the policy by entering the following command. Successful output lists the name of the policy object and the `created` status. . Apply the policy by entering the following command. Successful output lists the name of the policy object and the `created` status.
+ +
[source,terminal] [source,terminal]
---- ----
$ oc apply -f deny-by-default.yaml $ oc apply -f deny-by-default.yaml
---- ----
+
Successful output lists the name of the policy object and the `created` status.
ifdef::multi[] ifdef::multi[]
:!multi: :!multi:

33
modules/nw-networkpolicy-edit.adoc
View File

@@ -15,6 +15,7 @@ endif::[]
[id="nw-networkpolicy-edit_{context}"] [id="nw-networkpolicy-edit_{context}"]
= Editing a {name} policy = Editing a {name} policy
[role="_abstract"]
You can edit a {name} policy in a namespace. You can edit a {name} policy in a namespace.
ifndef::multi,microshift[] ifndef::multi,microshift[]
@@ -28,7 +29,7 @@ endif::multi,microshift[]
ifndef::microshift[] ifndef::microshift[]
* Your cluster uses a network plugin that supports `NetworkPolicy` objects, such as the OVN-Kubernetes network plugin, with `mode: NetworkPolicy` set. * Your cluster uses a network plugin that supports `NetworkPolicy` objects, such as the OVN-Kubernetes network plugin, with `mode: NetworkPolicy` set.
endif::microshift[] endif::microshift[]
* You installed the OpenShift CLI (`oc`). * You installed the {oc-first}.
ifndef::microshift[] ifndef::microshift[]
* You are logged in to the cluster with a user with `{role}` privileges. * You are logged in to the cluster with a user with `{role}` privileges.
endif::microshift[] endif::microshift[]
@@ -40,44 +41,38 @@ endif::microshift[]
+ +
[source,terminal,subs="attributes+"] [source,terminal,subs="attributes+"]
---- ----
$ oc get {name}policy $ oc get {name} policy -n <namespace>
---- ----
+ +
--
where: where:
+
`<namespace>`:: Optional: Specifies the namespace if the object is defined in a different namespace than the current namespace. `<namespace>`:: Optional: Specifies the namespace if the object is defined in a different namespace than the current namespace.
--
. Edit the {name} policy object. . Edit the {name} policy object.
+
** If you saved the {name} policy definition in a file, edit the file and make any necessary changes, and then enter the following command. .. If you saved the {name} policy definition in a file, edit the file and make any necessary changes, and then enter the following command.
+ +
[source,terminal] [source,terminal]
---- ----
$ oc apply -n <namespace> -f <policy_file>.yaml $ oc apply -n <namespace> -f <policy_file>.yaml
---- ----
+ +
--
where: where:
+
`<namespace>`:: Optional: Specifies the namespace if the object is defined in a different namespace than the current namespace. `<namespace>`:: Optional: Specifies the namespace if the object is defined in a different namespace than the current namespace.
`<policy_file>`:: Specifies the name of the file containing the network policy. `<policy_file>`:: Specifies the name of the file containing the network policy.
-- +
.. If you need to update the {name} policy object directly, enter the following command:
** If you need to update the {name} policy object directly, enter the following command:
+ +
[source,terminal,subs="attributes+"] [source,terminal,subs="attributes+"]
---- ----
$ oc edit {name}policy <policy_name> -n <namespace> $ oc edit {name} policy <policy_name> -n <namespace>
---- ----
+ +
--
where: where:
+
`<policy_name>`:: Specifies the name of the network policy. `<policy_name>`:: Specifies the name of the network policy.
`<namespace>`:: Optional: Specifies the namespace if the object is defined in a different namespace than the current namespace. `<namespace>`:: Optional: Specifies the namespace if the object is defined in a different namespace than the current namespace.
--
. Confirm that the {name} policy object is updated. . Confirm that the {name} policy object is updated.
+ +
@@ -86,12 +81,10 @@ where:
$ oc describe {name}policy <policy_name> -n <namespace> $ oc describe {name}policy <policy_name> -n <namespace>
---- ----
+ +
--
where: where:
+
`<policy_name>`:: Specifies the name of the {name} policy. `<policy_name>`:: Specifies the name of the {name} policy.
`<namespace>`:: Optional: Specifies the namespace if the object is defined in a different namespace than the current namespace. `<namespace>`:: Optional: Specifies the namespace if the object is defined in a different namespace than the current namespace.
--
ifdef::multi[] ifdef::multi[]
:!multi: :!multi:
@@ -104,4 +97,4 @@ ifndef::microshift[]
==== ====
If you log in to the web console with `cluster-admin` privileges, you have a choice of editing a network policy in any namespace in the cluster directly in YAML or from the policy in the web console through the *Actions* menu. If you log in to the web console with `cluster-admin` privileges, you have a choice of editing a network policy in any namespace in the cluster directly in YAML or from the policy in the web console through the *Actions* menu.
==== ====
endif::microshift[] endif::microshift[]

22
modules/nw-networkpolicy-object.adoc
View File

@@ -11,31 +11,35 @@
[id="nw-networkpolicy-object_{context}"] [id="nw-networkpolicy-object_{context}"]
= Example NetworkPolicy object = Example NetworkPolicy object
The following annotates an example NetworkPolicy object: [role="_abstract"]
The following configuration annotates an example NetworkPolicy object:
[source,yaml] [source,yaml]
---- ----
kind: NetworkPolicy kind: NetworkPolicy
apiVersion: networking.k8s.io/v1 apiVersion: networking.k8s.io/v1
metadata: metadata:
name: allow-27107 <1> name: allow-27107
spec: spec:
podSelector: <2> podSelector:
matchLabels: matchLabels:
app: mongodb app: mongodb
ingress: ingress:
- from: - from:
- podSelector: <3> - podSelector:
matchLabels: matchLabels:
app: app app: app
ports: <4> ports:
- protocol: TCP - protocol: TCP
port: 27017 port: 27017
---- ----
<1> The name of the NetworkPolicy object.
<2> A selector that describes the pods to which the policy applies. where:
`name`:: The name of the NetworkPolicy object.
`spec.podSelector`:: A selector that describes the pods to which the policy applies.
ifndef::microshift[] ifndef::microshift[]
The policy object can only select pods in the project that defines the NetworkPolicy object. The policy object can only select pods in the project that defines the NetworkPolicy object.
endif::microshift[] endif::microshift[]
<3> A selector that matches the pods from which the policy object allows ingress traffic. The selector matches pods in the same namespace as the NetworkPolicy. `ingress.from.podSelector`:: A selector that matches the pods from which the policy object allows ingress traffic. The selector matches pods in the same namespace as the NetworkPolicy.
<4> A list of one or more destination ports on which to accept traffic. `ingress.ports`:: A list of one or more destination ports on which to accept traffic.

24
modules/nw-networkpolicy-view-cli.adoc
View File

@@ -16,6 +16,7 @@ endif::[]
[id="nw-networkpolicy-view-cli_{context}"] [id="nw-networkpolicy-view-cli_{context}"]
= Viewing {name} policies using the CLI = Viewing {name} policies using the CLI
[role="_abstract"]
You can examine the {name} policies in a namespace. You can examine the {name} policies in a namespace.
ifndef::multi,microshift[] ifndef::multi,microshift[]
@@ -27,7 +28,7 @@ endif::multi,microshift[]
.Prerequisites .Prerequisites
* You installed the OpenShift CLI (`oc`). * You installed the {oc-first}.
ifndef::microshift[] ifndef::microshift[]
* You are logged in to the cluster with a user with `{role}` privileges. * You are logged in to the cluster with a user with `{role}` privileges.
endif::microshift[] endif::microshift[]
@@ -35,39 +36,34 @@ endif::microshift[]
.Procedure .Procedure
* List {name} policies in a namespace: . List {name} policies in a namespace.
+
** To view {name} policy objects defined in a namespace, enter the following .. To view {name} policy objects defined in a namespace enter the following
command: command:
+ +
[source,terminal,subs="attributes+"] [source,terminal,subs="attributes+"]
---- ----
$ oc get {name}policy $ oc get {name}policy
---- ----
+
** Optional: To examine a specific {name} policy, enter the following command: .. Optional: To examine a specific {name} policy enter the following command:
+ +
[source,terminal,subs="attributes+"] [source,terminal,subs="attributes+"]
---- ----
$ oc describe {name}policy <policy_name> -n <namespace> $ oc describe {name}policy <policy_name> -n <namespace>
---- ----
+ +
--
where: where:
`<policy_name>`:: Specifies the name of the {name} policy to inspect.
`<namespace>`:: Optional: Specifies the namespace if the object is defined in a different namespace than the current namespace.
--
ifndef::multi[]
+ +
For example: `<policy_name>`:: Specifies the name of the {name} policy to inspect.
`<namespace>`:: Optional: Specifies the namespace if the object is defined in a different namespace than the current namespace.
ifndef::multi[]
+ +
[source,terminal] [source,terminal]
---- ----
$ oc describe networkpolicy allow-same-namespace $ oc describe networkpolicy allow-same-namespace
---- ----
+ +
.Output for `oc describe` command
[source,text] [source,text]
---- ----
Name: allow-same-namespace Name: allow-same-namespace

4
modules/nw-networkpolicy-view-ocm.adoc
View File

@@ -7,6 +7,7 @@
[id="nw-networkpolicy-view-ocm_{context}"] [id="nw-networkpolicy-view-ocm_{context}"]
= Viewing network policies using {cluster-manager} = Viewing network policies using {cluster-manager}
[role="_abstract"]
You can view the configuration details of your network policy in {cluster-manager-first}. You can view the configuration details of your network policy in {cluster-manager-first}.
.Prerequisites .Prerequisites
@@ -25,8 +26,11 @@ endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
.Procedure .Procedure
. From the *Administrator* perspective in the {cluster-manager} web console, under *Networking*, click *NetworkPolicies*. . From the *Administrator* perspective in the {cluster-manager} web console, under *Networking*, click *NetworkPolicies*.
. Select the desired network policy to view. . Select the desired network policy to view.
. In the *Network Policy* details page, you can view all of the associated ingress and egress rules. . In the *Network Policy* details page, you can view all of the associated ingress and egress rules.
. Select *YAML* on the network policy details to view the policy configuration in YAML format. . Select *YAML* on the network policy details to view the policy configuration in YAML format.
ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[] ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
+ +

18
modules/nw-route-override-cni.adoc
View File

@@ -6,9 +6,9 @@
[id="nw-route-override-cni_{context}"] [id="nw-route-override-cni_{context}"]
= Configuring routes using the route-override plugin on a secondary network = Configuring routes using the route-override plugin on a secondary network
The following object describes the configuration parameters for the `route-override` CNI plugin: [role="_abstract"]
The Route override CNI plugin JSON configuration object describes the configuration parameters for the `route-override` CNI plugin. The following table details these parameters:
.Route override CNI plugin JSON configuration object
[cols=".^2,.^2,.^6",options="header"] [cols=".^2,.^2,.^6",options="header"]
|==== |====
|Field|Type|Description |Field|Type|Description
@@ -41,9 +41,9 @@ The following object describes the configuration parameters for the `route-overr
[id="nw-route-override-config-example_{context}"] [id="nw-route-override-config-example_{context}"]
== Route-override plugin configuration example == Route-override plugin configuration example
The `route-override` CNI is a type of CNI that it is designed to be used when chained with a parent CNI. It does not operate independently, but relies on the parent CNI to first create the network interface and assign IP addresses before it can modify the routing rules. The `route-override` CNI is a type of CNI that is designed to be used when chained with a parent CNI. The CNI type does not operate independently, but relies on the parent CNI to first create the network interface and assign IP addresses before the CNI type can modify the routing rules.
The following example configures a secondary network named `mymacvlan`. The parent CNI creates a network interface attached to `eth1` and assigns an IP address in the `192.168.1.0/24` range using `host-local` IPAM. The `route-override` CNI is then chained to the parent CNI and modifies the routing rules by flushing existing routes, deleting the route to `192.168.0.0/24`, and adding a new route for `192.168.0.0/24` with a custom gateway. The following example configures a secondary network named `mymacvlan`. The parent CNI creates a network interface attached to `eth1` and assigns an IP address in the `192.168.1.0/24` range by using `host-local` IPAM. The `route-override` CNI is then chained to the parent CNI and modifies the routing rules by flushing existing routes, deleting the route to `192.168.0.0/24`, and adding a new route for `192.168.0.0/24` with a custom gateway.
[source,json] [source,json]
---- ----
@@ -52,7 +52,7 @@ The following example configures a secondary network named `mymacvlan`. The pare
"name": "mymacvlan", "name": "mymacvlan",
"plugins": [ "plugins": [
{ {
"type": "macvlan", <1> "type": "macvlan",
"master": "eth1", "master": "eth1",
"mode": "bridge", "mode": "bridge",
"ipam": { "ipam": {
@@ -61,7 +61,7 @@ The following example configures a secondary network named `mymacvlan`. The pare
} }
}, },
{ {
"type": "route-override", <2> "type": "route-override",
"flushroutes": true, "flushroutes": true,
"delroutes": [ "delroutes": [
{ {
@@ -79,5 +79,7 @@ The following example configures a secondary network named `mymacvlan`. The pare
} }
---- ----
<1> The parent CNI creates a network interface attached to `eth1`. where:
<2> The chained `route-override` CNI modifies the routing rules.
`"type": "macvlan"`:: The parent CNI creates a network interface attached to `eth1`.
`"type": "route-override"`:: The chained `route-override` CNI modifies the routing rules.

25
modules/nw-sriov-configuring-multiple-nodes.adoc
View File

@@ -6,6 +6,7 @@
[id="configure-sr-iov-operator-parallel-nodes_{context}"] [id="configure-sr-iov-operator-parallel-nodes_{context}"]
= Configuring parallel node draining during SR-IOV network policy updates = Configuring parallel node draining during SR-IOV network policy updates
[role="_abstract"]
By default, the SR-IOV Network Operator drains workloads from a node before every policy change. The Operator performs this action, one node at a time, to ensure that the reconfiguration does not impact workloads. By default, the SR-IOV Network Operator drains workloads from a node before every policy change. The Operator performs this action, one node at a time, to ensure that the reconfiguration does not impact workloads.
In large clusters, draining nodes sequentially can be time-consuming, taking hours or even days. In time-sensitive environments, you can enable parallel node draining in an `SriovNetworkPoolConfig` custom resource (CR) for faster rollouts of SR-IOV network configurations. In large clusters, draining nodes sequentially can be time-consuming, taking hours or even days. In time-sensitive environments, you can enable parallel node draining in an `SriovNetworkPoolConfig` custom resource (CR) for faster rollouts of SR-IOV network configurations.
@@ -23,7 +24,7 @@ The procedure requires that you create SR-IOV resources and then parallel drain
.Prerequisites .Prerequisites
* Install the OpenShift CLI (`oc`). * Install the {oc-first}.
* Log in as a user with `cluster-admin` privileges. * Log in as a user with `cluster-admin` privileges.
* Install the SR-IOV Network Operator. * Install the SR-IOV Network Operator.
* Nodes have hardware that support SR-IOV. * Nodes have hardware that support SR-IOV.
@@ -38,18 +39,21 @@ The procedure requires that you create SR-IOV resources and then parallel drain
apiVersion: v1 apiVersion: v1
kind: SriovNetworkPoolConfig kind: SriovNetworkPoolConfig
metadata: metadata:
name: pool-1 <1> name: pool-1
namespace: openshift-sriov-network-operator <2> namespace: openshift-sriov-network-operator
spec: spec:
maxUnavailable: 2 <3> maxUnavailable: 2
nodeSelector: <4> nodeSelector:
matchLabels: matchLabels:
node-role.kubernetes.io/worker: "" node-role.kubernetes.io/worker: ""
---- ----
<1> Specify the name of the `SriovNetworkPoolConfig` object. +
<2> Specify namespace where the SR-IOV Network Operator is installed. where:
<3> Specify an integer number, or percentage value, for nodes that can be unavailable in the pool during an update. For example, if you have 10 nodes and you set the maximum unavailable to 2, then only 2 nodes can be drained in parallel at any time, leaving 8 nodes for handling workloads. +
<4> Specify the nodes to add the pool by using the node selector. This example adds all nodes with the `worker` role to the pool. `name`:: Specify the name of the `SriovNetworkPoolConfig` object.
`namespace`:: Specify namespace where the SR-IOV Network Operator is installed.
`maxUnavailable`:: Specify an integer number, or percentage value, for nodes that can be unavailable in the pool during an update. For example, if you have 10 nodes and you set the maximum unavailable to 2, then only 2 nodes can be drained in parallel at any time, leaving 8 nodes for handling workloads.
`nodeSelector`:: Specify the nodes to add the pool by using the node selector. This example adds all nodes with the `worker` role to the pool.
. Create the `SriovNetworkPoolConfig` resource by running the following command: . Create the `SriovNetworkPoolConfig` resource by running the following command:
+ +
@@ -65,9 +69,8 @@ $ oc create -f sriov-nw-pool.yaml
$ oc create namespace sriov-test $ oc create namespace sriov-test
---- ----
. Create a YAML file that defines the `SriovNetworkNodePolicy` resource: . Create a YAML file that defines the `SriovNetworkNodePolicy` resource, as demonstrated in the following example YAML file:
+ +
.Example `sriov-node-policy.yaml` file
[source,yaml] [source,yaml]
---- ----
apiVersion: sriovnetwork.openshift.io/v1 apiVersion: sriovnetwork.openshift.io/v1

3
modules/nw-sriov-expose-mtu.adoc
View File

@@ -7,6 +7,7 @@
[id="nw-sriov-expose-mtu_{context}"] [id="nw-sriov-expose-mtu_{context}"]
= Exposing MTU for vfio-pci SR-IOV devices to pod = Exposing MTU for vfio-pci SR-IOV devices to pod
[role="_abstract"]
After adding a pod to an additional network, you can check that the MTU is available for the SR-IOV network. After adding a pod to an additional network, you can check that the MTU is available for the SR-IOV network.
.Procedure .Procedure
@@ -17,6 +18,7 @@ After adding a pod to an additional network, you can check that the MTU is avail
---- ----
$ oc describe pod example-pod $ oc describe pod example-pod
---- ----
+
The following example shows the sample output: The following example shows the sample output:
+ +
[source,text] [source,text]
@@ -39,6 +41,7 @@ The following example shows the sample output:
---- ----
$ oc exec example-pod -n sriov-tests -- cat /etc/podnetinfo/annotations | grep mtu $ oc exec example-pod -n sriov-tests -- cat /etc/podnetinfo/annotations | grep mtu
---- ----
+
The following example shows the sample output: The following example shows the sample output:
+ +
[source,text] [source,text]

34
modules/nw-sriov-ibnetwork-object.adoc
View File

@@ -6,6 +6,7 @@
[id="nw-sriov-ibnetwork-object_{context}"] [id="nw-sriov-ibnetwork-object_{context}"]
= InfiniBand device configuration object = InfiniBand device configuration object
[role="_abstract"]
You can configure an InfiniBand (IB) network device by defining an `SriovIBNetwork` object. You can configure an InfiniBand (IB) network device by defining an `SriovIBNetwork` object.
The following YAML describes an `SriovIBNetwork` object: The following YAML describes an `SriovIBNetwork` object:
@@ -15,26 +16,23 @@ The following YAML describes an `SriovIBNetwork` object:
apiVersion: sriovnetwork.openshift.io/v1 apiVersion: sriovnetwork.openshift.io/v1
kind: SriovIBNetwork kind: SriovIBNetwork
metadata: metadata:
name: <name> <1> name: <name>
namespace: openshift-sriov-network-operator <2> namespace: openshift-sriov-network-operator
spec: spec:
resourceName: <sriov_resource_name> <3> resourceName: <sriov_resource_name>
networkNamespace: <target_namespace> <4> networkNamespace: <target_namespace>
ipam: |- <5> ipam: |-
{} {}
linkState: <link_state> <6> linkState: <link_state>
capabilities: <capabilities> <7> capabilities: <capabilities>
---- ----
<1> A name for the object. The SR-IOV Network Operator creates a `NetworkAttachmentDefinition` object with same name.
<2> The namespace where the SR-IOV Operator is installed. where:
<3> The value for the `spec.resourceName` parameter from the `SriovNetworkNodePolicy` object that defines the SR-IOV hardware for this additional network. `name`:: A name for the object. The SR-IOV Network Operator creates a `NetworkAttachmentDefinition` object with same name.
`namespace`:: The namespace where the SR-IOV Operator is installed.
<4> The target namespace for the `SriovIBNetwork` object. Only pods in the target namespace can attach to the network device. `resourceName`:: The value for the `spec.resourceName` parameter from the `SriovNetworkNodePolicy` object that defines the SR-IOV hardware for this additional network.
`networkNamespace`:: The target namespace for the `SriovIBNetwork` object. Only pods in the target namespace can attach to the network device.
<5> Optional: A configuration object for the IPAM CNI plugin as a YAML block scalar. The plugin manages IP address assignment for the attachment definition. `ipam`:: Optional parameter. A configuration object for the IPAM CNI plugin as a YAML block scalar. The plugin manages IP address assignment for the attachment definition.
`linkState`:: Optional parameter. The link state of virtual function (VF). Allowed values are `enable`, `disable` and `auto`.
<6> Optional: The link state of virtual function (VF). Allowed values are `enable`, `disable` and `auto`. `capabilities`:: Optional parameter. The capabilities to configure for this network. You can specify `'{ "ips": true }'` to enable IP address support or `'{ "infinibandGUID": true }'` to enable IB Global Unique Identifier (GUID) support.
<7> Optional: The capabilities to configure for this network. You can specify `'{ "ips": true }'` to enable IP address support or `'{ "infinibandGUID": true }'` to enable IB Global Unique Identifier (GUID) support.

16
modules/nw-sriov-runtime-config-ethernet.adoc
View File

@@ -6,6 +6,7 @@
[id="nw-sriov-runtime-config-ethernet_{context}"] [id="nw-sriov-runtime-config-ethernet_{context}"]
= Runtime configuration for an Ethernet-based SR-IOV attachment = Runtime configuration for an Ethernet-based SR-IOV attachment
[role="_abstract"]
When attaching a pod to an additional network, you can specify a runtime configuration to make specific customizations for the pod. For example, you can request a specific MAC hardware address. When attaching a pod to an additional network, you can specify a runtime configuration to make specific customizations for the pod. For example, you can request a specific MAC hardware address.
You specify the runtime configuration by setting an annotation in the pod specification. The annotation key is `k8s.v1.cni.cncf.io/networks`, and it accepts a JSON object that describes the runtime configuration. You specify the runtime configuration by setting an annotation in the pod specification. The annotation key is `k8s.v1.cni.cncf.io/networks`, and it accepts a JSON object that describes the runtime configuration.
@@ -21,9 +22,9 @@ metadata:
k8s.v1.cni.cncf.io/networks: |- k8s.v1.cni.cncf.io/networks: |-
[ [
{ {
"name": "<network_attachment>", <1> "name": "<network_attachment>",
"mac": "<mac_address>", <2> "mac": "<mac_address>",
"ips": ["<cidr_range>"] <3> "ips": ["<cidr_range>"]
} }
] ]
spec: spec:
@@ -33,6 +34,9 @@ spec:
imagePullPolicy: IfNotPresent imagePullPolicy: IfNotPresent
command: ["sleep", "infinity"] command: ["sleep", "infinity"]
---- ----
<1> The name of the SR-IOV network attachment definition CR. Example value is `ibl`.
<2> Optional: The MAC address for the SR-IOV device that is allocated from the resource type defined in the SR-IOV network attachment definition CR. To use this feature, you also must specify `{ "mac": true }` in the `SriovNetwork` object. Example value is `c2:11:22:33:44:55:66:77`. where:
<3> Optional: IP addresses for the SR-IOV device that is allocated from the resource type defined in the SR-IOV network attachment definition CR. Both IPv4 and IPv6 addresses are supported. To use this feature, you also must specify `{ "ips": true }` in the `SriovNetwork` object. Example value is `192.168.10.1/24", "2001::1/64`.
`k8s.v1.cni.cncf.io/networks.name`:: The name of the SR-IOV network attachment definition CR. Example value is `ibl`.
`k8s.v1.cni.cncf.io/networks.mac`:: Optional parameter. The MAC address for the SR-IOV device that is allocated from the resource type defined in the SR-IOV network attachment definition CR. To use this feature, you also must specify `{ "mac": true }` in the `SriovNetwork` object. Example value is `c2:11:22:33:44:55:66:77`.
`k8s.v1.cni.cncf.io/networks.ips`:: Optional parameter. IP addresses for the SR-IOV device that is allocated from the resource type defined in the SR-IOV network attachment definition CR. Both IPv4 and IPv6 addresses are supported. To use this feature, you also must specify `{ "ips": true }` in the `SriovNetwork` object. Example value is `192.168.10.1/24", "2001::1/64`.

16
modules/nw-sriov-runtime-config-sriov-ib.adoc
View File

@@ -16,17 +16,19 @@ The following JSON describes the runtime configuration options for an InfiniBand
---- ----
[ [
{ {
"name": "<network_attachment>", <1> "name": "<network_attachment>",
"infiniband-guid": "<guid>", <2> "infiniband-guid": "<guid>",
"ips": ["<cidr_range>"] <3> "ips": ["<cidr_range>"]
} }
] ]
---- ----
<1> The name of the SR-IOV network attachment definition CR.
<2> The InfiniBand GUID for the SR-IOV device. To use this feature, you also must specify `{ "infinibandGUID": true }` in the `SriovIBNetwork` object.
<3> The IP addresses for the SR-IOV device that is allocated from the resource type defined in the SR-IOV network attachment definition CR. Both IPv4 and IPv6 addresses are supported. To use this feature, you also must specify `{ "ips": true }` in the `SriovIBNetwork` object.
.Example runtime configuration where:
`name`:: The name of the SR-IOV network attachment definition CR.
`infiniband-guid`:: The InfiniBand GUID for the SR-IOV device. To use this feature, you also must specify `{ "infinibandGUID": true }` in the `SriovIBNetwork` object.
`ips`:: The IP addresses for the SR-IOV device that is allocated from the resource type defined in the SR-IOV network attachment definition CR. Both IPv4 and IPv6 addresses are supported. To use this feature, you also must specify `{ "ips": true }` in the `SriovIBNetwork` object.
[source,yaml] [source,yaml]
---- ----
apiVersion: v1 apiVersion: v1

30
modules/virt-configuring-secondary-network-vm-live-migration.adoc
View File

@@ -8,11 +8,11 @@
= Configuring a dedicated secondary network for live migration = Configuring a dedicated secondary network for live migration
[role="_abstract"] [role="_abstract"]
To configure a dedicated secondary network for live migration, you must first create a bridge network attachment definition (NAD) by using the CLI. Then, you add the name of the `NetworkAttachmentDefinition` object to the `HyperConverged` custom resource (CR). To configure a dedicated secondary network for live migration, you must first create a bridge network attachment definition (NAD) by using the CLI. You can then add the name of the `NetworkAttachmentDefinition` object to the `HyperConverged` custom resource (CR).
.Prerequisites .Prerequisites
* You installed the OpenShift CLI (`oc`). * You installed the {oc-first}.
* You logged in to the cluster as a user with the `cluster-admin` role. * You logged in to the cluster as a user with the `cluster-admin` role.
* Each node has at least two Network Interface Cards (NICs). * Each node has at least two Network Interface Cards (NICs).
* The NICs for live migration are connected to the same VLAN. * The NICs for live migration are connected to the same VLAN.
@@ -26,25 +26,28 @@ To configure a dedicated secondary network for live migration, you must first cr
apiVersion: "k8s.cni.cncf.io/v1" apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition kind: NetworkAttachmentDefinition
metadata: metadata:
name: my-secondary-network <1> name: my-secondary-network
namespace: {CNVNamespace} namespace: {CNVNamespace}
spec: spec:
config: '{ config: '{
"cniVersion": "0.3.1", "cniVersion": "0.3.1",
"name": "migration-bridge", "name": "migration-bridge",
"type": "macvlan", "type": "macvlan",
"master": "eth1", <2> "master": "eth1",
"mode": "bridge", "mode": "bridge",
"ipam": { "ipam": {
"type": "whereabouts", <3> "type": "whereabouts",
"range": "10.200.5.0/24" <4> "range": "10.200.5.0/24"
} }
}' }'
---- ----
<1> Specify the name of the `NetworkAttachmentDefinition` object. +
<2> Specify the name of the NIC to be used for live migration. where:
<3> Specify the name of the CNI plugin that provides the network for the NAD. +
<4> Specify an IP address range for the secondary network. This range must not overlap the IP addresses of the main network. `metadata.name`:: Specify the name of the `NetworkAttachmentDefinition` object.
`config.master`:: Specify the name of the NIC to be used for live migration.
`config.type`:: Specify the name of the CNI plugin that provides the network for the NAD.
`config.range`:: Specify an IP address range for the secondary network. This range must not overlap the IP addresses of the main network.
. Open the `HyperConverged` CR in your default editor by running the following command: . Open the `HyperConverged` CR in your default editor by running the following command:
+ +
@@ -67,13 +70,16 @@ metadata:
spec: spec:
liveMigrationConfig: liveMigrationConfig:
completionTimeoutPerGiB: 800 completionTimeoutPerGiB: 800
network: <network> <1> network: <network>
parallelMigrationsPerCluster: 5 parallelMigrationsPerCluster: 5
parallelOutboundMigrationsPerNode: 2 parallelOutboundMigrationsPerNode: 2
progressTimeout: 150 progressTimeout: 150
# ... # ...
---- ----
<1> Specify the name of the Multus `NetworkAttachmentDefinition` object to be used for live migrations. +
where:
+
`network`:: Specify the name of the Multus `NetworkAttachmentDefinition` object to be used for live migrations.
. Save your changes and exit the editor. The `virt-handler` pods restart and connect to the secondary network. . Save your changes and exit the editor. The `virt-handler` pods restart and connect to the secondary network.

9
networking/hardware_networks/configuring-sriov-ib-attach.adoc
View File

@@ -6,32 +6,25 @@ include::_attributes/common-attributes.adoc[]
toc::[] toc::[]
[role="_abstract"]
You can configure an InfiniBand (IB) network attachment for an Single Root I/O Virtualization (SR-IOV) device in the cluster. You can configure an InfiniBand (IB) network attachment for an Single Root I/O Virtualization (SR-IOV) device in the cluster.
Before you perform any tasks in the following documentation, ensure that you xref:../../networking/networking_operators/sr-iov-operator/installing-sriov-operator.adoc#installing-sriov-operator[installed the SR-IOV Network Operator]. Before you perform any tasks in the following documentation, ensure that you xref:../../networking/networking_operators/sr-iov-operator/installing-sriov-operator.adoc#installing-sriov-operator[installed the SR-IOV Network Operator].
// InfiniBand device configuration object
include::modules/nw-sriov-ibnetwork-object.adoc[leveloffset=+1] include::modules/nw-sriov-ibnetwork-object.adoc[leveloffset=+1]
// Creating a configuration for assignment of dual-stack IP addresses dynamically
include::modules/nw-multus-configure-dualstack-ip-address.adoc[leveloffset=+2] include::modules/nw-multus-configure-dualstack-ip-address.adoc[leveloffset=+2]
// Configuration of IP address assignment for a network attachment
include::modules/nw-multus-ipam-object.adoc[leveloffset=+2] include::modules/nw-multus-ipam-object.adoc[leveloffset=+2]
// Dynamic IP address assignment configuration with Whereabouts
include::modules/nw-multus-whereabouts.adoc[leveloffset=+2] include::modules/nw-multus-whereabouts.adoc[leveloffset=+2]
// Configuring SR-IOV additional network
include::modules/nw-sriov-network-attachment.adoc[leveloffset=+1] include::modules/nw-sriov-network-attachment.adoc[leveloffset=+1]
// Runtime configuration for an InfiniBand-based SR-IOV attachment
include::modules/nw-sriov-runtime-config-sriov-ib.adoc[leveloffset=+1] include::modules/nw-sriov-runtime-config-sriov-ib.adoc[leveloffset=+1]
// Adding a pod to an additional network
include::modules/nw-multus-add-pod.adoc[leveloffset=+1] include::modules/nw-multus-add-pod.adoc[leveloffset=+1]
// Exposing MTU for vfio-pci SR-IOV devices to pod
include::modules/nw-sriov-expose-mtu.adoc[leveloffset=+2] include::modules/nw-sriov-expose-mtu.adoc[leveloffset=+2]
[role="_additional-resources"] [role="_additional-resources"]

24
networking/hardware_networks/configuring-sriov-net-attach.adoc
View File

@@ -6,48 +6,40 @@ include::_attributes/common-attributes.adoc[]
toc::[] toc::[]
[role="_abstract"]
You can configure an Ethernet network attachment for an Single Root I/O Virtualization (SR-IOV) device in the cluster. You can configure an Ethernet network attachment for an Single Root I/O Virtualization (SR-IOV) device in the cluster.
Before you perform any tasks in the following documentation, ensure that you xref:../../networking/networking_operators/sr-iov-operator/installing-sriov-operator.adoc#installing-sriov-operator[installed the SR-IOV Network Operator]. Before you perform any tasks in the following documentation, ensure that you installed the SR-IOV Network Operator.
// Ethernet device configuration object
include::modules/nw-sriov-network-object.adoc[leveloffset=+1] include::modules/nw-sriov-network-object.adoc[leveloffset=+1]
[role="_additional-resources"] [role="_additional-resources"]
.Additional resources == Additional resources
xref:../../networking/hardware_networks/configuring-namespaced-sriov-resources.adoc#introduction-to-namespaced-sriovnetwork-resources_configuring-namespaced-sriov-resources[Configuring namespaced SR-IOV resources]
* xref:../../networking/networking_operators/sr-iov-operator/installing-sriov-operator.adoc#installing-sriov-operator[Installing the SR-IOV Network Operator]
* xref:../../networking/hardware_networks/configuring-namespaced-sriov-resources.adoc#introduction-to-namespaced-sriovnetwork-resources_configuring-namespaced-sriov-resources[Configuring namespaced SR-IOV resources]
// Creating a configuration for assignment of dual-stack IP addresses dynamically
include::modules/nw-multus-configure-dualstack-ip-address.adoc[leveloffset=+2] include::modules/nw-multus-configure-dualstack-ip-address.adoc[leveloffset=+2]
// Configuration of IP address assignment for a network attachment
include::modules/nw-multus-ipam-object.adoc[leveloffset=+2] include::modules/nw-multus-ipam-object.adoc[leveloffset=+2]
// Dynamic IP address assignment configuration with Whereabouts include::modules/nw-multus-whereabouts.adoc[leveloffset=+2]
include::modules/nw-multus-whereabouts.adoc[leveloffset=+3]
// Configuring SR-IOV additional network
include::modules/nw-sriov-network-attachment.adoc[leveloffset=+1] include::modules/nw-sriov-network-attachment.adoc[leveloffset=+1]
// Assigning an SR-IOV network to a VRF
include::modules/cnf-assigning-a-sriov-network-to-a-vrf.adoc[leveloffset=+1] include::modules/cnf-assigning-a-sriov-network-to-a-vrf.adoc[leveloffset=+1]
// Creating an additional SR-IOV network attachment with the CNI VRF plugin
include::modules/cnf-creating-an-additional-sriov-network-with-vrf-plug-in.adoc[leveloffset=+2] include::modules/cnf-creating-an-additional-sriov-network-with-vrf-plug-in.adoc[leveloffset=+2]
// Runtime configuration for an Ethernet-based SR-IOV attachment
include::modules/nw-sriov-runtime-config-ethernet.adoc[leveloffset=+1] include::modules/nw-sriov-runtime-config-ethernet.adoc[leveloffset=+1]
// Adding a pod to an additional network
include::modules/nw-multus-add-pod.adoc[leveloffset=+1] include::modules/nw-multus-add-pod.adoc[leveloffset=+1]
// Exposing MTU for vfio-pci SR-IOV devices to pod
include::modules/nw-sriov-expose-mtu.adoc[leveloffset=+2] include::modules/nw-sriov-expose-mtu.adoc[leveloffset=+2]
// Configuring parallel node draining during SR-IOV network policy updates
include::modules/nw-sriov-configuring-multiple-nodes.adoc[leveloffset=+1] include::modules/nw-sriov-configuring-multiple-nodes.adoc[leveloffset=+1]
// Excluding the SR-IOV network topology for NUMA-aware scheduling
include::modules/nw-sriov-configure-exclude-topology-manager.adoc[leveloffset=+1] include::modules/nw-sriov-configure-exclude-topology-manager.adoc[leveloffset=+1]
[role="_additional-resources"] [role="_additional-resources"]

1
networking/multiple_networks/assigning-a-secondary-network-to-a-vrf.adoc
View File

@@ -6,6 +6,7 @@ include::_attributes/common-attributes.adoc[]
toc::[] toc::[]
[role="_abstract"]
As a cluster administrator, you can configure a secondary network for a virtual routing and forwarding (VRF) domain by using the CNI VRF plugin. The virtual network that this plugin creates is associated with the physical interface that you specify. As a cluster administrator, you can configure a secondary network for a virtual routing and forwarding (VRF) domain by using the CNI VRF plugin. The virtual network that this plugin creates is associated with the physical interface that you specify.
Using a secondary network with a VRF instance has the following advantages: Using a secondary network with a VRF instance has the following advantages:

7
networking/multiple_networks/secondary_networks/configuring-ip-secondary-nwt.adoc
View File

@@ -6,20 +6,17 @@ include::_attributes/common-attributes.adoc[]
toc::[] toc::[]
The following sections give instructions and information for how to configure IP address assignments for secondary networks. [role="_abstract"]
You can configure IP address assignments for secondary networks so that pods can connect to the secondary networks.
include::modules/nw-multus-ipam-object.adoc[leveloffset=+1] include::modules/nw-multus-ipam-object.adoc[leveloffset=+1]
// Dynamic IP address assignment configuration with Whereabouts
include::modules/nw-multus-whereabouts.adoc[leveloffset=+2] include::modules/nw-multus-whereabouts.adoc[leveloffset=+2]
// Creating a whereabouts-reconciler daemon set
include::modules/nw-multus-creating-whereabouts-reconciler-daemon-set.adoc[leveloffset=+2] include::modules/nw-multus-creating-whereabouts-reconciler-daemon-set.adoc[leveloffset=+2]
// Configuring the Whereabouts IP reconciler schedule
include::modules/nw-multus-configuring-whereabouts-ip-reconciler-schedule.adoc[leveloffset=+2] include::modules/nw-multus-configuring-whereabouts-ip-reconciler-schedule.adoc[leveloffset=+2]
// Fast IPAM configuration for the Whereabouts IPAM CNI plugins
include::modules/nw-multus-whereabouts-fast-ipam.adoc[leveloffset=+2] include::modules/nw-multus-whereabouts-fast-ipam.adoc[leveloffset=+2]
include::modules/nw-multus-configure-dualstack-ip-address.adoc[leveloffset=+2] include::modules/nw-multus-configure-dualstack-ip-address.adoc[leveloffset=+2]

3
networking/multiple_networks/secondary_networks/configuring-master-interface.adoc
View File

@@ -6,7 +6,8 @@ include::_attributes/common-attributes.adoc[]
toc::[] toc::[]
The following section provides instructions and information for how to create and manage a MAC-VLAN, IP-VLAN, and VLAN subinterface based on a master interface. [role="_abstract"]
You can create and manage a MAC-VLAN, IP-VLAN, and VLAN subinterface based on a `master` interface.
include::modules/nw-about-configuring-master-interface-container.adoc[leveloffset=+1] include::modules/nw-about-configuring-master-interface-container.adoc[leveloffset=+1]

10
networking/multiple_networks/secondary_networks/configuring-multi-network-policy.adoc
View File

@@ -6,7 +6,8 @@ include::_attributes/common-attributes.adoc[]
toc::[] toc::[]
Administrators can use the `MultiNetworkPolicy` API to create multiple network policies that manage traffic for pods attached to secondary networks. For example, you can create policies that allow or deny traffic based on specific ports, IPs/ranges, or labels. [role="_abstract"]
As an administrator, you can use the `MultiNetworkPolicy` API to create multiple network policies that manage traffic for pods that are attached to secondary networks. For example, you can create policies that allow or deny traffic based on specific ports, IPs and ranges, or labels.
Multi-network policies can be used to manage traffic on secondary networks in the cluster. These policies cannot manage the default cluster network or primary network of user-defined networks. Multi-network policies can be used to manage traffic on secondary networks in the cluster. These policies cannot manage the default cluster network or primary network of user-defined networks.
@@ -32,12 +33,7 @@ include::modules/nw-multi-network-policy-ipv6-suppport.adoc[leveloffset=+1]
[id="{context}_working-with-multi-network-policy"] [id="{context}_working-with-multi-network-policy"]
== Working with multi-network policy == Working with multi-network policy
As a cluster administrator, you can create, edit, view, and delete multi-network policies. As a cluster administrator, you can create, edit, view, and delete multi-network policies. Before you do any of these tasks, you must have enabled multi-network policy support for your cluster.
[id="{context}_prerequisites"]
=== Prerequisites
* You have enabled multi-network policy support for your cluster.
include::modules/nw-networkpolicy-create-cli.adoc[leveloffset=+2] include::modules/nw-networkpolicy-create-cli.adoc[leveloffset=+2]

14
networking/multiple_networks/secondary_networks/creating-secondary-nwt-other-cni.adoc
View File

@@ -6,40 +6,34 @@ include::_attributes/common-attributes.adoc[]
toc::[] toc::[]
[role="_abstract"]
The specific configuration fields for secondary networks are described in the following sections. The specific configuration fields for secondary networks are described in the following sections.
// Configuration for a bridge secondary network
include::modules/nw-multus-bridge-object.adoc[leveloffset=+1] include::modules/nw-multus-bridge-object.adoc[leveloffset=+1]
// Configuration for a bond-cni secondary network
include::modules/nw-multus-bond-cni-object.adoc[leveloffset=+1] include::modules/nw-multus-bond-cni-object.adoc[leveloffset=+1]
[role="_additional-resources"] [role="_additional-resources"]
.Additional resources .Additional resources
* xref:../../../networking/hardware_networks/using-pod-level-bonding.adoc#nw-sriov-cfg-bond-interface-with-virtual-functions_using-pod-level-bonding[Configuring a bond interface from two SR-IOV interfaces] * xref:../../../networking/hardware_networks/using-pod-level-bonding.adoc#nw-sriov-cfg-bond-interface-with-virtual-functions_using-pod-level-bonding[Configuring a bond interface from two SR-IOV interfaces]
// Configuration for a host device secondary network
include::modules/nw-multus-host-device-object.adoc[leveloffset=+1] include::modules/nw-multus-host-device-object.adoc[leveloffset=+1]
// Configure for a dummy additional network
include::modules/nw-multus-dummy-device-object.adoc[leveloffset=+1] include::modules/nw-multus-dummy-device-object.adoc[leveloffset=+1]
// Configuration for an VLAN secondary network
include::modules/nw-multus-vlan-object.adoc[leveloffset=+1] include::modules/nw-multus-vlan-object.adoc[leveloffset=+1]
// Configuration for an ipvlan secondary network
include::modules/nw-multus-ipvlan-object.adoc[leveloffset=+1] include::modules/nw-multus-ipvlan-object.adoc[leveloffset=+1]
// Configuration for a macvlan secondary network
include::modules/nw-multus-macvlan-object.adoc[leveloffset=+1] include::modules/nw-multus-macvlan-object.adoc[leveloffset=+1]
// Configuration for a TAP secondary network
include::modules/nw-multus-tap-object.adoc[leveloffset=+1] include::modules/nw-multus-tap-object.adoc[leveloffset=+1]
// Configuration for a route-override secondary network include::modules/nw-multus-tap-setting-boolean.adoc[leveloffset=+1]
include::modules/nw-route-override-cni.adoc[leveloffset=+1] include::modules/nw-route-override-cni.adoc[leveloffset=+1]
[role="_additional-resources"] [role="_additional-resources"]
.Additional resources .Additional resources
* For more information about enabling an SELinux boolean on a node, see xref:../../../nodes/nodes/nodes-nodes-managing.adoc#nodes-nodes-working-setting-booleans_nodes-nodes-managing[Setting SELinux booleans]. * xref:../../../nodes/nodes/nodes-nodes-managing.adoc#nodes-nodes-working-setting-booleans_nodes-nodes-managing[Setting SELinux booleans]

12
networking/multiple_networks/secondary_networks/creating-secondary-nwt-ovnk.adoc
View File

@@ -6,14 +6,8 @@ include::_attributes/common-attributes.adoc[]
toc::[] toc::[]
As a cluster administrator, you can configure a secondary network for your cluster using the `NetworkAttachmentDefinition` (NAD) resource. [role="_abstract"]
As a cluster administrator, you can configure a secondary network for your cluster by using the `NetworkAttachmentDefinition` (NAD) resource.
[NOTE]
====
Support for user-defined networks as a secondary network will be added in a future version of {product-title}.
====
//For more information, see the xr3f:../networking/multiple_networks/secondary_networks/understanding-user-defined-network.adoc#understanding-user-defined-network[Understanding user defined networks]
include::modules/configuring-ovnk-additional-networks.adoc[leveloffset=+1] include::modules/configuring-ovnk-additional-networks.adoc[leveloffset=+1]
@@ -25,8 +19,6 @@ include::modules/configuring-localnet-switched-topology.adoc[leveloffset=+2]
include::modules/configuring-layer-two-switched-topology.adoc[leveloffset=+3] include::modules/configuring-layer-two-switched-topology.adoc[leveloffset=+3]
//include::modules/configuring-layer-three-routed-topology.adoc[leveloffset=+2]
include::modules/configuring-pods-secondary-network.adoc[leveloffset=+2] include::modules/configuring-pods-secondary-network.adoc[leveloffset=+2]
include::modules/configuring-pods-static-ip.adoc[leveloffset=+2] include::modules/configuring-pods-static-ip.adoc[leveloffset=+2]

2
networking/network_security/network_policy/creating-network-policy.adoc
View File

@@ -9,7 +9,7 @@ endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
toc::[] toc::[]
//TODO OSDOCS-11830 Or namespace owner/admin?? [role="_abstract"]
As a cluster administrator, you can create a network policy for a namespace. As a cluster administrator, you can create a network policy for a namespace.
include::modules/nw-networkpolicy-object.adoc[leveloffset=+1] include::modules/nw-networkpolicy-object.adoc[leveloffset=+1]

1
networking/network_security/network_policy/deleting-network-policy.adoc
View File

@@ -9,6 +9,7 @@ endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
toc::[] toc::[]
[role="_abstract"]
As a cluster administrator, you can delete a network policy from a namespace. As a cluster administrator, you can delete a network policy from a namespace.
include::modules/nw-networkpolicy-delete-cli.adoc[leveloffset=+1] include::modules/nw-networkpolicy-delete-cli.adoc[leveloffset=+1]

1
networking/network_security/network_policy/editing-network-policy.adoc
View File

@@ -6,6 +6,7 @@ include::_attributes/common-attributes.adoc[]
toc::[] toc::[]
[role="_abstract"]
As a cluster administrator, you can edit an existing network policy for a namespace. As a cluster administrator, you can edit an existing network policy for a namespace.
include::modules/nw-networkpolicy-edit.adoc[leveloffset=+1] include::modules/nw-networkpolicy-edit.adoc[leveloffset=+1]

1
networking/network_security/network_policy/viewing-network-policy.adoc
View File

@@ -9,6 +9,7 @@ endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
toc::[] toc::[]
[role="_abstract"]
As a cluster administrator, you can view a network policy for a namespace. As a cluster administrator, you can view a network policy for a namespace.
include::modules/nw-networkpolicy-object.adoc[leveloffset=+1] include::modules/nw-networkpolicy-object.adoc[leveloffset=+1]

14
nodes/nodes/nodes-nodes-managing.adoc
View File

@@ -7,20 +7,14 @@ include::_attributes/common-attributes.adoc[]
toc::[] toc::[]
[role="_abstract"]
{product-title} uses a KubeletConfig custom resource (CR) to manage the {product-title} uses a KubeletConfig custom resource (CR) to manage the configuration of nodes. By creating an instance of a `KubeletConfig` object, a managed machine config is created to override setting on the node.
configuration of nodes. By creating an instance of a `KubeletConfig` object, a managed machine config is created to override setting on the node.
[NOTE] [NOTE]
==== ====
*Logging in to remote machines for the purpose of changing their configuration is not supported.* Logging in to remote machines for the purpose of changing their configuration is not supported.
==== ====
// The following include statements pull in the module files that comprise
// the assembly. Include any combination of concept, procedure, or reference
// modules required to cover the user story. You can also include other
// assemblies.
include::modules/nodes-nodes-managing-about.adoc[leveloffset=+1] include::modules/nodes-nodes-managing-about.adoc[leveloffset=+1]
include::modules/nodes-nodes-working-master-schedulable.adoc[leveloffset=+1] include::modules/nodes-nodes-working-master-schedulable.adoc[leveloffset=+1]
@@ -43,7 +37,7 @@ include::modules/nodes-nodes-parallel-container-pulls-configure.adoc[leveloffset
include::modules/nodes-control-plane-osp-migrating.adoc[leveloffset=+1] include::modules/nodes-control-plane-osp-migrating.adoc[leveloffset=+1]
[role="_additional-resources"] [role="_additional-resources"]
.Additional resources == Additional resources
* xref:../../machine_management/control_plane_machine_management/cpmso-managing-machines.adoc#cpmso-managing-machines[Managing control plane machines with control plane machine sets] * xref:../../machine_management/control_plane_machine_management/cpmso-managing-machines.adoc#cpmso-managing-machines[Managing control plane machines with control plane machine sets]

1
virt/live_migration/virt-configuring-cross-cluster-live-migration-network.adoc
View File

@@ -7,6 +7,7 @@ include::_attributes/attributes-openshift-dedicated.adoc[]
toc::[] toc::[]
[role="_abstract"]
Cross-cluster live migration requires that the clusters be connected in the same network. Specifically, `virt-handler` pods must be able to communicate. Cross-cluster live migration requires that the clusters be connected in the same network. Specifically, `virt-handler` pods must be able to communicate.
:FeatureName: Cross-cluster live migration :FeatureName: Cross-cluster live migration