Configuring an SR-IOV Ethernet network attachment
You can configure an Ethernet network attachment for an Single Root I/O Virtualization (SR-IOV) device in the cluster.
Ethernet device configuration object
You can configure an Ethernet network device by defining an SriovNetwork
object.
The following YAML describes an SriovNetwork
object:
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
name: <name> (1)
namespace: openshift-sriov-network-operator (2)
spec:
resourceName: <sriov_resource_name> (3)
networkNamespace: <target_namespace> (4)
vlan: <vlan> (5)
spoofChk: "<spoof_check>" (6)
ipam: |- (7)
{}
linkState: <link_state> (8)
maxTxRate: <max_tx_rate> (9)
minTxRate: <min_tx_rate> (10)
vlanQoS: <vlan_qos> (11)
trust: "<trust_vf>" (12)
capabilities: <capabilities> (13)
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 Network Operator is installed. | ||
3 | The value for the spec.resourceName parameter from the SriovNetworkNodePolicy object that defines the SR-IOV hardware for this additional network. | ||
4 | The target namespace for the SriovNetwork object. Only pods in the target namespace can attach to the additional network. | ||
5 | Optional: A Virtual LAN (VLAN) ID for the additional network. The integer value must be from 0 to 4095 . The default value is 0 . | ||
6 | Optional: The spoof check mode of the VF. The allowed values are the strings “on” and “off” .
| ||
7 | A configuration object for the IPAM CNI plugin as a YAML block scalar. The plugin manages IP address assignment for the attachment definition. | ||
8 | Optional: The link state of virtual function (VF). Allowed value are enable , disable and auto . | ||
9 | Optional: A maximum transmission rate, in Mbps, for the VF. | ||
10 | Optional: A minimum transmission rate, in Mbps, for the VF. This value must be less than or equal to the maximum transmission rate.
| ||
11 | Optional: An IEEE 802.1p priority level for the VF. The default value is 0 . | ||
12 | Optional: The trust mode of the VF. The allowed values are the strings “on” and “off” .
| ||
13 | Optional: The capabilities to configure for this additional network. You can specify “{ “ips”: true }” to enable IP address support or “{ “mac”: true }” to enable MAC address support. |
Configuration of IP address assignment for an additional network
The IP address management (IPAM) Container Network Interface (CNI) plugin provides IP addresses for other CNI plugins.
You can use the following IP address assignment types:
Static assignment.
Dynamic assignment through a DHCP server. The DHCP server you specify must be reachable from the additional network.
Dynamic assignment through the Whereabouts IPAM CNI plugin.
Static IP address assignment configuration
The following table describes the configuration for static IP address assignment:
Field | Type | Description |
---|---|---|
|
| The IPAM address type. The value |
|
| An array of objects specifying IP addresses to assign to the virtual interface. Both IPv4 and IPv6 IP addresses are supported. |
|
| An array of objects specifying routes to configure inside the pod. |
|
| Optional: An array of objects specifying the DNS configuration. |
The addresses
array requires objects with the following fields:
Field | Type | Description |
---|---|---|
|
| An IP address and network prefix that you specify. For example, if you specify |
|
| The default gateway to route egress network traffic to. |
Field | Type | Description |
---|---|---|
|
| The IP address range in CIDR format, such as |
|
| The gateway where network traffic is routed. |
Field | Type | Description |
---|---|---|
|
| An array of one or more IP addresses for to send DNS queries to. |
|
| The default domain to append to a hostname. For example, if the domain is set to |
|
| An array of domain names to append to an unqualified hostname, such as |
Static IP address assignment configuration example
{
"ipam": {
"type": "static",
"addresses": [
{
"address": "191.168.1.7/24"
}
]
}
}
Dynamic IP address (DHCP) assignment configuration
The following JSON describes the configuration for dynamic IP address address assignment with DHCP.
Renewal of DHCP leases 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. The SR-IOV Network Operator does not create a DHCP server deployment; The Cluster Network Operator is responsible for creating the minimal DHCP server deployment. To trigger the deployment of the DHCP server, you must create a shim network attachment by editing the Cluster Network Operator configuration, as in the following example: Example shim network attachment definition
|
Field | Type | Description |
---|---|---|
|
| The IPAM address type. The value |
Dynamic IP address (DHCP) assignment configuration example
{
"ipam": {
"type": "dhcp"
}
}
Dynamic IP address assignment configuration with Whereabouts
The Whereabouts CNI plugin allows the dynamic assignment of an IP address to an additional network without the use of a DHCP server.
The following table describes the configuration for dynamic IP address assignment with Whereabouts:
Field | Type | Description |
---|---|---|
|
| The IPAM address type. The value |
|
| An IP address and range in CIDR notation. IP addresses are assigned from within this range of addresses. |
|
| Optional: A list of zero or more IP addresses and ranges in CIDR notation. IP addresses within an excluded address range are not assigned. |
Dynamic IP address assignment configuration example that uses Whereabouts
{
"ipam": {
"type": "whereabouts",
"range": "192.0.2.192/27",
"exclude": [
"192.0.2.192/30",
"192.0.2.196/32"
]
}
}
Creating a Whereabouts reconciler daemon set
The Whereabouts reconciler is responsible for managing dynamic IP address assignments for the pods within a cluster using the Whereabouts IP Address Management (IPAM) solution. It ensures that each pods gets a unique IP address from the specified IP address range. It also handles IP address releases when pods are deleted or scaled down.
You can also use a |
The Whereabouts reconciler daemon set is automatically created when you configure an additional network through the Cluster Network Operator. It is not automatically created when you configure an additional network from a YAML manifest.
To trigger the deployment of the Whereabouts reconciler daemonset, you must manually create a whereabouts-shim
network attachment by editing the Cluster Network Operator custom resource file.
Use the following procedure to deploy the Whereabouts reconciler daemonset.
Procedure
Edit the
Network.operator.openshift.io
custom resource (CR) by running the following command:$ oc edit network.operator.openshift.io cluster
Modify the
additionalNetworks
parameter in the CR to add thewhereabouts-shim
network attachment definition. For example:apiVersion: operator.openshift.io/v1
kind: Network
metadata:
name: cluster
spec:
additionalNetworks:
- name: whereabouts-shim
namespace: default
rawCNIConfig: |-
{
"name": "whereabouts-shim",
"cniVersion": "0.3.1",
"type": "bridge",
"ipam": {
"type": "whereabouts"
}
}
type: Raw
Save the file and exit the text editor.
Verify that the
whereabouts-reconciler
daemon set deployed successfully by running the following command:$ oc get all -n openshift-multus | grep whereabouts-reconciler
Example output
pod/whereabouts-reconciler-jnp6g 1/1 Running 0 6s
pod/whereabouts-reconciler-k76gg 1/1 Running 0 6s
pod/whereabouts-reconciler-k86t9 1/1 Running 0 6s
pod/whereabouts-reconciler-p4sxw 1/1 Running 0 6s
pod/whereabouts-reconciler-rvfdv 1/1 Running 0 6s
pod/whereabouts-reconciler-svzw9 1/1 Running 0 6s
daemonset.apps/whereabouts-reconciler 6 6 6 6 6 kubernetes.io/os=linux 6s
Creating a configuration for assignment of dual-stack IP addresses dynamically
Dual-stack IP address assignment can be configured with the ipRanges
parameter for:
IPv4 addresses
IPv6 addresses
multiple IP address assignment
Procedure
Set
type
towhereabouts
.Use
ipRanges
to allocate IP addresses as shown in the following example:cniVersion: operator.openshift.io/v1
kind: Network
=metadata:
name: cluster
spec:
additionalNetworks:
- name: whereabouts-shim
namespace: default
type: Raw
rawCNIConfig: |-
{
"name": "whereabouts-dual-stack",
"cniVersion": "0.3.1,
"type": "bridge",
"ipam": {
"type": "whereabouts",
"ipRanges": [
{"range": "192.168.10.0/24"},
{"range": "2001:db8::/64"}
]
}
}
Attach network to a pod. For more information, see “Adding a pod to an additional network”.
Verify that all IP addresses are assigned.
Run the following command to ensure the IP addresses are assigned as metadata.
$ oc exec -it mypod -- ip a
Additional resources
Configuring SR-IOV additional network
You can configure an additional network that uses SR-IOV hardware by creating an SriovNetwork
object. When you create an SriovNetwork
object, the SR-IOV Network Operator automatically creates a NetworkAttachmentDefinition
object.
Do not modify or delete an |
Prerequisites
Install the OpenShift CLI (
oc
).Log in as a user with
cluster-admin
privileges.
Procedure
Create a
SriovNetwork
object, and then save the YAML in the<name>.yaml
file, where<name>
is a name for this additional network. The object specification might resemble the following example:apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
name: attach1
namespace: openshift-sriov-network-operator
spec:
resourceName: net1
networkNamespace: project2
ipam: |-
{
"type": "host-local",
"subnet": "10.56.217.0/24",
"rangeStart": "10.56.217.171",
"rangeEnd": "10.56.217.181",
"gateway": "10.56.217.1"
}
To create the object, enter the following command:
$ oc create -f <name>.yaml
where
<name>
specifies the name of the additional network.Optional: To confirm that the
NetworkAttachmentDefinition
object that is associated with theSriovNetwork
object that you created in the previous step exists, enter the following command. Replace<namespace>
with the networkNamespace you specified in theSriovNetwork
object.$ oc get net-attach-def -n <namespace>