1
0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 12:46:18 +01:00
Files
openshift-docs/modules/nw-multus-create-master-interface-bridge-cni.adoc

200 lines
6.0 KiB
Plaintext

// Module included in the following assemblies:
//
// * networking/multiple_networks/secondary_networks/configuring-master-interface.adoc
:_mod-docs-content-type: PROCEDURE
[id="nw-multus-create-master-interface-bridge-cni_{context}"]
= 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.
.Prerequisites
* You have installed the {oc-first}.
* You are logged in to the {product-title} cluster as a user with `cluster-admin` privileges.
.Procedure
. Create a dedicated container namespace where you want to deploy your pod by entering the following command:
+
[source,terminal]
----
$ oc new-project test-namespace
----
. Using the following YAML configuration example, create a bridge `NetworkAttachmentDefinition` custom resource definition (CRD) file named `bridge-nad.yaml`:
+
[source,yaml]
----
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: bridge-network
spec:
config: '{
"cniVersion": "0.4.0",
"name": "bridge-network",
"type": "bridge",
"bridge": "br-001",
"isGateway": true,
"ipMasq": true,
"hairpinMode": true,
"ipam": {
"type": "host-local",
"subnet": "10.0.0.0/24",
"routes": [{"dst": "0.0.0.0/0"}]
}
}'
----
. Run the following command to apply the `NetworkAttachmentDefinition` CRD to your {product-title} cluster:
+
[source,terminal]
----
$ oc apply -f bridge-nad.yaml
----
. Verify that you successfully created a `NetworkAttachmentDefinition` CRD by entering the following command. The expected output shows the name of the NAD CRD and the creation age in minutes.
+
[source,terminal]
----
$ oc get network-attachment-definitions
----
. Using the following YAML example, create a file named `ipvlan-additional-network-configuration.yaml` for the IPVLAN secondary network configuration:
+
[source,yaml]
----
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
name: ipvlan-net
namespace: test-namespace
spec:
config: '{
"cniVersion": "0.3.1",
"name": "ipvlan-net",
"type": "ipvlan",
"master": "net1",
"mode": "l3",
"linkInContainer": true,
"ipam": {"type": "whereabouts", "ipRanges": [{"range": "10.0.0.0/24"}]}
}'
----
+
where:
+
`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:
+
[source,terminal]
----
$ oc apply -f ipvlan-additional-network-configuration.yaml
----
. Verify that the `NetworkAttachmentDefinition` CRD has been created successfully by running the following command. The expected output shows the name of the NAD CRD and the creation age in minutes.
+
[source,terminal]
----
$ oc get network-attachment-definitions
----
. Using the following YAML configuration example, create a file named `pod-a.yaml` for the pod definition:
+
[source,yaml]
----
apiVersion: v1
kind: Pod
metadata:
name: pod-a
namespace: test-namespace
annotations:
k8s.v1.cni.cncf.io/networks: '[
{
"name": "bridge-network",
"interface": "net1" <1>
},
{
"name": "ipvlan-net",
"interface": "net2"
}
]'
spec:
securityContext:
runAsNonRoot: true
seccompProfile:
type: RuntimeDefault
containers:
- name: test-pod
image: quay.io/openshifttest/hello-sdn@sha256:c89445416459e7adea9a5a416b3365ed3d74f2491beb904d61dc8d1eb89a72a4
securityContext:
allowPrivilegeEscalation: false
capabilities:
drop: [ALL]
----
+
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:
+
[source,terminal]
----
$ oc apply -f pod-a.yaml
----
.Verification
. Verify that the pod is running by using the following command:
+
[source,terminal]
----
$ oc get pod -n test-namespace
----
+
[source,terminal]
----
NAME READY STATUS RESTARTS AGE
pod-a 1/1 Running 0 2m36s
----
. Show network interface information about the `pod-a` resource within the `test-namespace` by running the following command:
+
[source,terminal]
----
$ oc exec -n test-namespace pod-a -- ip a
----
+
[source,terminal]
----
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: eth0@if105: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue state UP group default
link/ether 0a:58:0a:d9:00:5d brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 10.217.0.93/23 brd 10.217.1.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::488b:91ff:fe84:a94b/64 scope link
valid_lft forever preferred_lft forever
4: net1@if107: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether be:da:bd:7e:f4:37 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 10.0.0.2/24 brd 10.0.0.255 scope global net1
valid_lft forever preferred_lft forever
inet6 fe80::bcda:bdff:fe7e:f437/64 scope link
valid_lft forever preferred_lft forever
5: net2@net1: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
link/ether be:da:bd:7e:f4:37 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.1/24 brd 10.0.0.255 scope global net2
valid_lft forever preferred_lft forever
inet6 fe80::beda:bd00:17e:f437/64 scope link
valid_lft forever preferred_lft forever
----
+
This output shows that the network interface `net2` associates with the physical interface `net1`.