Networking

Procedure

1. Log in as a user with cluster-admin privileges.

2. Generate the default project template:

   $ oc adm create-bootstrap-project-template -o yaml > template.yaml

3. Use a text editor to modify the generated template.yaml file by adding objects or modifying existing objects.

4. The project template must be created in the openshift-config namespace. Load your modified template:

   $ oc create -f template.yaml -n openshift-config

5. Edit the project configuration resource using the web console or CLI.

   • Using the web console:

     1. Navigate to the Administration → Cluster Settings page.
     2. Click Global Configuration to view all configuration resources.
     3. Find the entry for Project and click Edit YAML.

   • Using the CLI:

     1. Edit the project.config.openshift.io/cluster resource:

        $ oc edit project.config.openshift.io/cluster

6. Update the spec section to include the projectRequestTemplate and name parameters, and set the name of your uploaded project template. The default name is project-request.

   Project configuration resource with custom project template

   apiVersion: config.openshift.io/v1
   kind: Project
   metadata:
     ...
   spec:
     projectRequestTemplate:
       name: <template_name>

7. After you save your changes, create a new project to verify that your changes were successfully applied.

Procedure

1. Edit the default template for a new project by running the following command:

   $ oc edit template <project_template> -n openshift-config

   Replace <project_template> with the name of the default template that you configured for your cluster. The default template name is project-request.

2. In the template, add each NetworkPolicy object as an element to the objects parameter. The objects parameter accepts a collection of one or more objects.

   In the following example, the objects parameter collection includes several NetworkPolicy objects:

   objects:
   - apiVersion: networking.k8s.io/v1
     kind: NetworkPolicy
     metadata:
       name: allow-from-same-namespace
     spec:
       podSelector:
       ingress:
       - from:
         - podSelector: {}
   - apiVersion: networking.k8s.io/v1
     kind: NetworkPolicy
     metadata:
       name: allow-from-openshift-ingress
     spec:
       ingress:
       - from:
         - namespaceSelector:
             matchLabels:
               network.openshift.io/policy-group: ingress
       podSelector: {}
       policyTypes:
       - Ingress
   ...

3. Optional: Create a new project to confirm that your network policy objects are created successfully by running the following commands:

   1. Create a new project:

      $ oc new-project <project> 1

      1

      Replace <project> with the name for the project you are creating.

   2. Confirm that the network policy objects in the new project template exist in the new project:

      $ oc get networkpolicy
      NAME                           POD-SELECTOR   AGE
      allow-from-openshift-ingress   <none>         7s
      allow-from-same-namespace      <none>         7s

1. Create the Pod resource definition and add the k8s.v1.cni.cncf.io/networks parameter to the Pod metadata mapping. The k8s.v1.cni.cncf.io/networks accepts a comma separated string of one or more NetworkAttachmentDefinition Custom Resource (CR) names:

   metadata:
     annotations:
       k8s.v1.cni.cncf.io/networks: <network>[,<network>,...] 1

   1

   Replace <network> with the name of the additional network to associate with the Pod. To specify more than one additional network, separate each network with a comma. Do not include whitespace between the comma. If you specify the same additional network multiple times, that Pod will have multiple network interfaces attached to that network.

   In the following example, two additional networks are attached to the Pod:

   apiVersion: v1
   kind: Pod
   metadata:
     name: example-pod
     annotations:
       k8s.v1.cni.cncf.io/networks: net1,net2
   spec:
     containers:
     - name: example-pod
       command: ["/bin/bash", "-c", "sleep 2000000000000"]
       image: centos/tools

2. Create the Pod by running the following command:

   $ oc create -f pod.yaml

3. Optional: Confirm that the annotation exists in the Pod CR by running the following command. Replace <name> with the name of the Pod.

   $ oc get pod <name> -o yaml

   In the following example, the example-pod Pod is attached to the net1 additional network:

   $ oc get pod example-pod -o yaml
   apiVersion: v1
   kind: Pod
   metadata:
     annotations:
       k8s.v1.cni.cncf.io/networks: macvlan-bridge
       k8s.v1.cni.cncf.io/networks-status: |- 1
         [{
             "name": "openshift-sdn",
             "interface": "eth0",
             "ips": [
                 "10.128.2.14"
             ],
             "default": true,
             "dns": {}
         },{
             "name": "macvlan-bridge",
             "interface": "net1",
             "ips": [
                 "20.2.2.100"
             ],
             "mac": "22:2f:60:a5:f8:00",
             "dns": {}
         }]
     name: example-pod
     namespace: default
   spec:
     ...
   status:
     ...

   1

   The k8s.v1.cni.cncf.io/networks-status parameter is a JSON array of objects. Each object describes the status of an additional network attached to the Pod. The annotation value is stored as a plain text value.

1. Edit the Pod resource definition by running the following command. Replace <name> with the name of the Pod to edit.

   $ oc edit pod <name>

2. Update the annotations mapping to remove the additional network from the Pod by performing one of the following actions:

   • To remove all additional networks from a Pod, remove the k8s.v1.cni.cncf.io/networks parameter from the Pod resource definition as in the following example:

     apiVersion: v1
     kind: Pod
     metadata:
       name: example-pod
       annotations: {}
     spec:
       containers:
       - name: example-pod
         command: ["/bin/bash", "-c", "sleep 2000000000000"]
         image: centos/tools

   • To remove a specific additional network from a Pod, update the k8s.v1.cni.cncf.io/networks parameter by removing the name of the NetworkAttachmentDefinition for the additional network.

3. Optional: Confirm that the Pod is no longer attached to the additional network by running the following command. Replace <name> with the name of the Pod.

   $ oc describe pod <name>

   In the following example, the example-pod Pod is attached only to the default cluster network.

   $ oc describe pod example-pod
   
   Name:               example-pod
   ...
   Annotations:        k8s.v1.cni.cncf.io/networks-status:
                         [{
                             "name": "openshift-sdn",
                             "interface": "eth0",
                             "ips": [
                                 "10.131.0.13"
                             ],
                             "default": true, 1
                             "dns": {}
                         }]
   Status:             Running
   ...

   1

   Only the default cluster network is attached to the Pod.

1. Edit the CNO CR by running the following command:

   $ oc edit networks.operator.openshift.io cluster

2. Modify the CR that you are creating by adding the configuration for the additional network you are creating, as in the following example CR.

   The following YAML configures the bridge CNI plug-in:

   apiVersion: operator.openshift.io/v1
   kind: Network
   metadata:
     name: cluster
   spec:
     additionalNetworks: 1
     - name: test-network-1
       namespace: test-1
       type: Raw
       rawCNIConfig: '{
         "cniVersion": "0.3.1",
         "name": "test-network-1",
         "type": "bridge",
         "ipam": {
           "type": "static",
           "addresses": [
             {
               "address": "191.168.1.1/24"
             }
           ]
         }
       }'

   1

   Specify the configuration for the additional network attachment definition.

3. Save your changes and quit the text editor to commit your changes.

4. Optional: Confirm that the CNO created the NetworkAttachmentDefinition CR by running the following command. There might be a delay before the CNO creates the CR.

   $ oc get network-attachment-definitions -n <namespace>
   NAME                 AGE
   test-network-1       14m

1. Edit the CNO CR by running the following command:

   $ oc edit networks.operator.openshift.io cluster

2. Modify the CR that you are creating by adding the configuration for the additional network you are creating, as in the following example CR.

   The following YAML configures the macvlan CNI plug-in:

   apiVersion: operator.openshift.io/v1
   kind: Network
   metadata:
     name: cluster
   spec:
     additionalNetworks: 1
     - name: test-network-1
       namespace: test-1
       type: SimpleMacvlan
       simpleMacvlanConfig:
         ipamConfig:
           type: static
           staticIPAMConfig:
             addresses:
             - address: 10.1.1.0/24

   1

   Specify the configuration for the additional network attachment definition.

3. Save your changes and quit the text editor to commit your changes.

4. Optional: Confirm that the CNO created the NetworkAttachmentDefinition CR by running the following command. There might be a delay before the CNO creates the CR.

   $ oc get network-attachment-definitions -n <namespace>
   NAME                 AGE
   test-network-1       14m

1. Edit the CNO CR by running the following command:

   $ oc edit networks.operator.openshift.io cluster

2. Modify the CR that you are creating by adding the configuration for the additional network you are creating, as in the following example CR.

   The following YAML configures the ipvlan CNI plug-in:

   apiVersion: operator.openshift.io/v1
   kind: Network
   metadata:
     name: cluster
   spec:
     additionalNetworks: 1
     - name: test-network-1
       namespace: test-1
       type: Raw
       rawCNIConfig: '{
         "cniVersion": "0.3.1",
         "name": "test-network-1",
         "type": "ipvlan",
         "master": "eth1",
         "mode": "l2",
         "ipam": {
           "type": "static",
           "addresses": [
             {
               "address": "191.168.1.1/24"
             }
           ]
         }
       }'

   1

   Specify the configuration for the additional network attachment definition.

3. Save your changes and quit the text editor to commit your changes.

4. Optional: Confirm that the CNO created the NetworkAttachmentDefinition CR by running the following command. There might be a delay before the CNO creates the CR.

   $ oc get network-attachment-definitions -n <namespace>
   NAME                 AGE
   test-network-1       14m

1. Edit the CNO CR by running the following command:

   $ oc edit networks.operator.openshift.io cluster

2. Modify the CR that you are creating by adding the configuration for the additional network you are creating, as in the following example CR.

   The following YAML configures the host-device CNI plug-in:

   apiVersion: operator.openshift.io/v1
   kind: Network
   metadata:
     name: cluster
   spec:
     additionalNetworks: 1
     - name: test-network-1
       namespace: test-1
       type: Raw
       rawCNIConfig: '{
         "cniVersion": "0.3.1",
         "name": "test-network-1",
         "type": "host-device",
         "device": "eth1"
       }'

   1

   Specify the configuration for the additional network attachment definition.

3. Save your changes and quit the text editor to commit your changes.

4. Optional: Confirm that the CNO created the NetworkAttachmentDefinition CR by running the following command. There might be a delay before the CNO creates the CR.

   $ oc get network-attachment-definitions -n <namespace>
   NAME                 AGE
   test-network-1       14m

Procedure

1. Create the following SriovNetworkNodePolicy CR, and then save the YAML in the <name>-sriov-node-network.yaml file. Replace <name> with the name for this configuration.

   apiVersion: sriovnetwork.openshift.io/v1
   kind: SriovNetworkNodePolicy
   metadata:
     name: <name> 1
     namespace: sriov-network-operator 2
   spec:
     resourceName: <sriov_resource_name> 3
     nodeSelector:
       feature.node.kubernetes.io/network-sriov.capable: "true" 4
     priority: <priority> 5
     mtu: <mtu> 6
     numVfs: <num> 7
     nicSelector: 8
       vendor: "<vendor_code>" 9
       deviceID: "<device_id>" 10
       pfNames: ["<pf_name>", ...] 11
       rootDevices: ["<pci_bus_id>", "..."] 12
     deviceType: <device_type> 13
     isRdma: false 14

   1

   Specify a name for the CR.

   2

   Specify the namespace where the SR-IOV Operator is installed.

   3

   Specify the resource name of the SR-IOV device plug-in. The prefix openshift.io/ will be added when it’s referred in Pod spec. You can create multiple SriovNetworkNodePolicy CRs for a resource name.

   4

   Specify the node selector to select which node to be configured. User can choose to label the nodes manually or with tools like Kubernetes Node Feature Discovery. Only SR-IOV network devices on selected nodes will be configured. The SR-IOV CNI plug-in and device plug-in will be only deployed on selected nodes.

   5

   Specify an integer value between 0 and 99. A larger number gets lower priority, so a priority of 99 is lower than a priority of 10.

   6

   Specify a value for the maximum transmission unit (MTU) of the virtual function. The value for MTU must be in the range from 1 to 9000. If you do not need to specify the MTU, specify a value of ''.

   7

   Specify the number of the virtual functions (VF) to create for the SR-IOV physical network device. For an Intel Network Interface Card (NIC), the number of VFs cannot be larger than the total VFs supported by the device. For a Mellanox NIC, the number of VFs cannot be larger than 128.

   8

   The nicSelector mapping selects the Ethernet device for the Operator to configure. You do not need to specify values for all the parameters. It is recommended to identify the Ethernet adapter with enough precision to minimize the possibility of selecting an Ethernet device unintentionally. If you specify rootDevices, you must also specify a value for vendor, deviceID, or pfNames. If you specify both pfNames and rootDevices at the same time, ensure that they point to an identical device.

   9

   Specify the vendor hex code of the SR-IOV network device. The only allowed values are either 8086 or 15b3.

   10

   Specify the device hex code of SR-IOV network device. The only allowed values are 158b, 1015, 1017.

   11

   The parameter accepts an array of one or more physical function (PF) names for the Ethernet device.

   12

   The parameter accepts an array of one or more PCI bus addresses for the physical function of the Ethernet device. Provide the address in the following format: 0000:02:00.1.

   13

   Specify the driver type for the virtual functions. You can specify one of the following values: netdevice or vfio-pci. The default value is netdevice.

   14

   Specify whether to enable RDMA mode. The default value is false. Only RDMA over Converged Ethernet (RoCE) mode is supported on Mellanox Ethernet adapters.

   Note

   If RDMA flag is set to true, you can continue to use the RDMA enabled VF as a normal network device. A device can be used in either mode.

2. Create the CR by running the following command:

   $ oc create -f <filename> 1

   1

   Replace <filename> with the name of the file you created in the previous step.

Procedure

1. Create the following SriovNetwork CR, and then save the YAML in the <name>-sriov-network.yaml file. Replace <name> with a name for this additional network.

   apiVersion: sriovnetwork.openshift.io/v1
   kind: SriovNetwork
   metadata:
     name: <name> 1
     namespace: sriov-network-operator 2
   spec:
     networkNamespace: <target_namespace> 3
     ipam: |- 4
       ...
     vlan: <vlan> 5
     resourceName: <sriov_resource_name> 6

   1

   Replace <name> with a name for the CR. The Operator will create a NetworkAttachmentDefinition CR with same name.

   2

   Specify the namespace where the SR-IOV Operator is installed.

   3

   Replace <target_namespace> with the namespace where the NetworkAttachmentDefinition CR will be created.

   4

   Specify a configuration object for the ipam CNI plug-in as a YAML block scalar. The plug-in manages IP address assignment for the attachment definition.

   5

   Replace <vlan> with a Virtual LAN (VLAN) ID for the additional network. The integer value must be from 0 to 4095. The default value is 0.

   6

   Replace <sriov_resource_name> with the value for the .spec.resourceName parameter from the SriovNetworkNodePolicy CR that defines the SR-IOV hardware for this additional network.

2. Create the CR by running the following command:

   $ oc create -f <filename> 1

   1

   Replace <filename> with the name of the file you created in the previous step.

3. Optional: Confirm that the NetworkAttachmentDefinition CR associated with the SriovNetwork CR that you created in the previous step exists by running the following command. Replace <namespace> with the namespace you specified in the SriovNetwork CR.

   oc get net-attach-def -n <namespace>

1. Create the Pod resource definition and add the k8s.v1.cni.cncf.io/networks parameter to the Pod metadata mapping. The k8s.v1.cni.cncf.io/networks accepts a comma separated string of one or more NetworkAttachmentDefinition Custom Resource (CR) names:

   metadata:
     annotations:
       k8s.v1.cni.cncf.io/networks: <network>[,<network>,...] 1

   1

   Replace <network> with the name of the additional network to associate with the Pod. To specify more than one additional network, separate each network with a comma. Do not include whitespace between the comma. If you specify the same additional network multiple times, that Pod will have multiple network interfaces attached to that network.

   In the following example, two additional networks are attached to the Pod:

   apiVersion: v1
   kind: Pod
   metadata:
     name: example-pod
     annotations:
       k8s.v1.cni.cncf.io/networks: net1,net2
   spec:
     containers:
     - name: example-pod
       command: ["/bin/bash", "-c", "sleep 2000000000000"]
       image: centos/tools

2. Create the Pod by running the following command:

   $ oc create -f pod.yaml

3. Optional: Confirm that the annotation exists in the Pod CR by running the following command. Replace <name> with the name of the Pod.

   $ oc get pod <name> -o yaml

   In the following example, the example-pod Pod is attached to the net1 additional network:

   $ oc get pod example-pod -o yaml
   apiVersion: v1
   kind: Pod
   metadata:
     annotations:
       k8s.v1.cni.cncf.io/networks: macvlan-bridge
       k8s.v1.cni.cncf.io/networks-status: |- 1
         [{
             "name": "openshift-sdn",
             "interface": "eth0",
             "ips": [
                 "10.128.2.14"
             ],
             "default": true,
             "dns": {}
         },{
             "name": "macvlan-bridge",
             "interface": "net1",
             "ips": [
                 "20.2.2.100"
             ],
             "mac": "22:2f:60:a5:f8:00",
             "dns": {}
         }]
     name: example-pod
     namespace: default
   spec:
     ...
   status:
     ...

   1

   The k8s.v1.cni.cncf.io/networks-status parameter is a JSON array of objects. Each object describes the status of an additional network attached to the Pod. The annotation value is stored as a plain text value.

1. Run the following command to edit the Cluster Network Operator (CNO) CR in your default text editor:

   $ oc edit networks.operator.openshift.io cluster

2. In the additionalNetworks collection, update the additional network with your changes.
3. Save your changes and quit the text editor to commit your changes.

4. Optional: Confirm that the CNO updated the NetworkAttachmentDefinition CR by running the following command. Replace <network-name> with the name of the additional network to display. There might be a delay before the CNO updates the NetworkAttachmentDefinition CR to reflect your changes.

   $ oc get network-attachment-definitions <network-name> -o yaml

   For example, the following console output displays a NetworkAttachmentDefinition that is named net1:

   $ oc get network-attachment-definitions net1 -o go-template='{{printf "%s\n" .spec.config}}'
   { "cniVersion": "0.3.1", "type": "macvlan",
   "master": "ens5",
   "mode": "bridge",
   "ipam":       {"type":"static","routes":[{"dst":"0.0.0.0/0","gw":"10.128.2.1"}],"addresses":[{"address":"10.128.2.100/23","gateway":"10.128.2.1"}],"dns":{"nameservers":["172.30.0.10"],"domain":"us-west-2.compute.internal","search":["us-west-2.compute.internal"]}} }

1. Edit the Cluster Network Operator (CNO) in your default text editor by running the following command:

   $ oc edit networks.operator.openshift.io cluster

2. Modify the CR by removing the configuration from the additionalNetworks collection for the network attachment definition you are removing.

   apiVersion: operator.openshift.io/v1
   kind: Network
   metadata:
     name: cluster
   spec:
     additionalNetworks: [] 1

   1

   If you are removing the configuration mapping for the only additional network attachment definition in the additionalNetworks collection, you must specify an empty collection.

3. Save your changes and quit the text editor to commit your changes.

4. Delete the NetworkAttachmentDefinition CR for the additional network by running the following command. Replace <name> with the name of the additional network to remove.

   $ oc delete network-attachment-definition <name>

5. Optional: Confirm that the additional network CR was deleted by running the following command:

   $ oc get network-attachment-definition --all-namespaces

Procedure

1. Update the NetNamespace resource with the egress IP address using the following JSON:

    $ oc patch netnamespace <project_name> --type=merge -p \ 1
     '{
       "egressIPs": [
         "<ip_address>" 2
       ]
     }'

   1

   Specify the name of the project.

   2

   Specify a single egress IP address. Using multiple IP addresses is not supported.

   For example, to assign project1 to an IP address of 192.168.1.100 and project2 to an IP address of 192.168.1.101:

   $ oc patch netnamespace project1 --type=merge -p \
     '{"egressIPs": ["192.168.1.100"]}'
   $ oc patch netnamespace project2 --type=merge -p \
     '{"egressIPs": ["192.168.1.101"]}'

2. Indicate which nodes can host egress IP addresses by setting the egressCIDRs parameter for each host using the following JSON:

   $ oc patch hostsubnet <node_name> --type=merge -p \ 1
     '{
       "egressCIDRs": [
         "<ip_address_range_1>", "<ip_address_range_2>" 2
       ]
     }'

   1

   Specify a node name.

   2

   Specify one or more IP address ranges in CIDR format.

   For example, to set node1 and node2 to host egress IP addresses in the range 192.168.1.0 to 192.168.1.255:

   $ oc patch hostsubnet node1 --type=merge -p \
     '{"egressCIDRs": ["192.168.1.0/24"]}'
   $ oc patch hostsubnet node2 --type=merge -p \
     '{"egressCIDRs": ["192.168.1.0/24"]}'

   OpenShift Container Platform automatically assigns specific egress IP addresses to available nodes in a balanced way. In this case, it assigns the egress IP address 192.168.1.100 to node1 and the egress IP address 192.168.1.101 to node2 or vice versa.

Procedure

1. Update the NetNamespace resource by specifying the following JSON object with the desired IP addresses:

   $ oc patch netnamespace <project> --type=merge -p \ 1
     '{
       "egressIPs": [ 2
         "<ip_address>"
         ]
     }'

   1

   Specify the name of the project.

   2

   Specify one or more egress IP addresses. The egressIPs parameter is an array.

   For example, to assign the project1 project to an IP address of 192.168.1.100:

   $ oc patch netnamespace project1 --type=merge \
     -p '{"egressIPs": ["192.168.1.100"]}'

   You can set egressIPs to two or more IP addresses on different nodes to provide high availability. If multiple egress IP addresses are set, pods use the first IP in the list for egress, but if the node hosting that IP address fails, pods switch to using the next IP in the list after a short delay.

2. Manually assign the egress IP to the node hosts. Set the egressIPs parameter on the HostSubnet object on the node host. Using the following JSON, include as many IPs as you want to assign to that node host:

   $ oc patch hostsubnet <node_name> --type=merge -p \ 1
     '{
       "egressIPs": [ 2
         "<ip_address_1>",
         "<ip_address_N>"
         ]
     }'

   1

   Specify the name of the project.

   2

   Specify one or more egress IP addresses. The egressIPs field is an array.

   For example, to specify that node1 should have the egress IPs 192.168.1.100, 192.168.1.101, and 192.168.1.102:

   $ oc patch hostsubnet node1 --type=merge -p \
     '{"egressIPs": ["192.168.1.100", "192.168.1.101", "192.168.1.102"]}'

   In the previous example, all egress traffic for project1 will be routed to the node hosting the specified egress IP, and then connected (using NAT) to that IP address.

Procedure

1. Create a policy rule:

   1. Create a <policy-name>.yaml file where <policy-name> describes the egress policy rules.
   2. In the file you created, define an egress policy object.

2. Enter the following command to create the policy object:

   $ oc create -f <policy-name>.yaml -n <project>

   In the following example, a new EgressNetworkPolicy object is created in a project named project1:

   $ oc create -f default-rules.yaml -n project1
   egressnetworkpolicy.network.openshift.io/default-rules created

3. Optional: Save the <policy-name>.yaml so that you can make changes later.

1. Find the name of the EgressNetworkPolicy object for the project. Replace <project> with the name of the project.

   $ oc get -n <project> egressnetworkpolicy

2. Optional: If you did not save a copy of the EgressNetworkPolicy object when you created the egress network firewall, enter the following command to create a copy.

   $ oc get -n <project> \ 1
     egressnetworkpolicy <name> \ 2
     -o yaml > <filename>.yaml 3

   1

   Replace <project> with the name of the project

   2

   Replace <name> with the name of the object.

   3

   Replace <filename> with the name of the file to save the YAML.

3. Enter the following command to replace the EgressNetworkPolicy object. Replace <filename> with the name of the file containing the updated EgressNetworkPolicy object.

   $ oc replace -f <filename>.yaml

1. Find the name of the EgressNetworkPolicy object for the project. Replace <project> with the name of the project.

   $ oc get -n <project> egressnetworkpolicy

2. Enter the following command to delete the EgressNetworkPolicy object. Replace <project> with the name of the project and <name> with the name of the object.

   $ oc delete -n <project> egressnetworkpolicy <name>

Procedure

1. Use the following command to join projects to an existing project network:

   $ oc adm pod-network join-projects --to=<project1> <project2> <project3>

   Alternatively, instead of specifying specific project names, you can use the --selector=<project_selector> option to specify projects based upon an associated label.

2. Optional: Run the following command to view the pod networks that you have joined together:

   $ oc get netnamespaces

   Projects in the same pod-network have the same network ID in the NETID column.

Procedure

1. Edit the Network.operator.openshift.io Custom Resource (CR) by running the following command:

   $ oc edit network.operator.openshift.io cluster

2. Modify the kubeProxyConfig parameter in the CR with your changes to the kube-proxy configuration, such as in the following example CR:

   apiVersion: operator.openshift.io/v1
   kind: Network
   metadata:
     name: cluster
   spec:
     kubeProxyConfig:
       iptablesSyncPeriod: 30s
       proxyArguments:
         iptables-min-sync-period: ["30s"]

3. Save the file and exit the text editor.

   The syntax is validated by the oc command when you save the file and exit the editor. If your modifications contain a syntax error, the editor opens the file and displays an error message.

4. Run the following command to confirm the configuration update:

   $ oc get networks.operator.openshift.io -o yaml

   The command returns output similar to the following example:

   apiVersion: v1
   items:
   - apiVersion: operator.openshift.io/v1
     kind: Network
     metadata:
       name: cluster
     spec:
       clusterNetwork:
       - cidr: 10.128.0.0/14
         hostPrefix: 23
       defaultNetwork:
         type: OpenShiftSDN
       kubeProxyConfig:
         iptablesSyncPeriod: 30s
         proxyArguments:
           iptables-min-sync-period:
           - 30s
       serviceNetwork:
       - 172.30.0.0/16
     status: {}
   kind: List

5. Optional: Run the following command to confirm that the Cluster Network Operator accepted the configuration change:

   $ oc get clusteroperator network
   NAME      VERSION     AVAILABLE   PROGRESSING   DEGRADED   SINCE
   network   4.1.0-0.9   True        False         False      1m

   The AVAILABLE field is True when the configuration update is applied successfully.

Procedure

1. Using the oc annotate command, add the timeout to the route:

   $ oc annotate route <route_name> \
       --overwrite haproxy.router.openshift.io/timeout=<timeout><time_unit> 1

   1

   Supported time units are microseconds (us), milliseconds (ms), seconds (s), minutes (m), hours (h), or days (d).

   The following example sets a timeout of two seconds on a route named myroute:

   $ oc annotate route myroute --overwrite haproxy.router.openshift.io/timeout=2s

Procedure

1. Create a new project for your service:

   $ oc new-project <project_name>

   For example:

   $ oc new-project myproject

2. Use the oc new-app command to create a service. For example:

   $ oc new-app \
       -e MYSQL_USER=admin \
       -e MYSQL_PASSWORD=redhat \
       -e MYSQL_DATABASE=mysqldb \
       registry.redhat.io/rhscl/mysql-80-rhel7

3. Run the following command to see that the new service is created:

   $ oc get svc -n myproject
   NAME             TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
   mysql-80-rhel7   ClusterIP   172.30.63.31   <none>        3306/TCP   4m55s

   By default, the new service does not have an external IP address.

1. Log in to OpenShift Container Platform.

2. Log in to the project where the service you want to expose is located:

   $ oc project project1

3. Run the following command to expose the route:

   $ oc expose service <service_name>

   For example:

   $ oc expose service mysql-80-rhel7
   route "mysql-80-rhel7" exposed

4. Use a tool, such as cURL, to make sure you can reach the service using the cluster IP address for the service:

   $ curl <pod_ip>:<port>

   For example:

   $ curl 172.30.131.89:3306

   The examples in this section use a MySQL service, which requires a client application. If you get a string of characters with the Got packets out of order message, you are connected to the service.

   If you have a MySQL client, log in with the standard CLI command:

   $ mysql -h 172.30.131.89 -u admin -p
   Enter password:
   Welcome to the MariaDB monitor.  Commands end with ; or \g.
   
   MySQL [(none)]>

Procedure

1. Edit the router-internal.yaml file:

   # cat router-internal.yaml
   apiVersion: v1
   items:
   - apiVersion: operator.openshift.io/v1
     kind: IngressController
     metadata:
       name: sharded
       namespace: openshift-ingress-operator
     spec:
       domain: <apps-sharded.basedomain.example.net>
       nodePlacement:
         nodeSelector:
           matchLabels:
             node-role.kubernetes.io/worker: ""
       routeSelector:
         matchLabels:
           type: sharded
     status: {}
   kind: List
   metadata:
     resourceVersion: ""
     selfLink: ""

2. Apply the Ingress Controller router-internal.yaml file:

   # oc apply -f router-internal.yaml

   The Ingress Controller selects routes in any namespace that have the label type: sharded.

Procedure

1. Edit the router-internal.yaml file:

   # cat router-internal.yaml
   apiVersion: v1
   items:
   - apiVersion: operator.openshift.io/v1
     kind: IngressController
     metadata:
       name: sharded
       namespace: openshift-ingress-operator
     spec:
       domain: <apps-sharded.basedomain.example.net>
       nodePlacement:
         nodeSelector:
           matchLabels:
             node-role.kubernetes.io/worker: ""
       namespaceSelector:
         matchLabels:
           type: sharded
     status: {}
   kind: List
   metadata:
     resourceVersion: ""
     selfLink: ""

2. Apply the Ingress Controller router-internal.yaml file:

   # oc apply -f router-internal.yaml

   The Ingress Controller selects routes in any namespace that is selected by the namespace selector that have the label type: sharded.

Procedure

1. Create a new project for your service:

   $ oc new-project <project_name>

   For example:

   $ oc new-project myproject

2. Use the oc new-app command to create a service. For example:

   $ oc new-app \
       -e MYSQL_USER=admin \
       -e MYSQL_PASSWORD=redhat \
       -e MYSQL_DATABASE=mysqldb \
       registry.redhat.io/rhscl/mysql-80-rhel7

3. Run the following command to see that the new service is created:

   $ oc get svc -n myproject
   NAME             TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
   mysql-80-rhel7   ClusterIP   172.30.63.31   <none>        3306/TCP   4m55s

   By default, the new service does not have an external IP address.

1. Log in to OpenShift Container Platform.

2. Log in to the project where the service you want to expose is located:

   $ oc project project1

3. Run the following command to expose the route:

   $ oc expose service <service_name>

   For example:

   $ oc expose service mysql-80-rhel7
   route "mysql-80-rhel7" exposed

4. Use a tool, such as cURL, to make sure you can reach the service using the cluster IP address for the service:

   $ curl <pod_ip>:<port>

   For example:

   $ curl 172.30.131.89:3306

   The examples in this section use a MySQL service, which requires a client application. If you get a string of characters with the Got packets out of order message, you are connected to the service.

   If you have a MySQL client, log in with the standard CLI command:

   $ mysql -h 172.30.131.89 -u admin -p
   Enter password:
   Welcome to the MariaDB monitor.  Commands end with ; or \g.
   
   MySQL [(none)]>

1. Log in to OpenShift Container Platform.

2. Load the project where the service you want to expose is located.

   $ oc project project1

3. Open a text file on the master node and paste the following text, editing the file as needed:

   Sample load balancer configuration file

   apiVersion: v1
   kind: Service
   metadata:
     name: egress-2 1
   spec:
     ports:
     - name: db
       port: 3306 2
     loadBalancerIP:
     type: LoadBalancer 3
     selector:
       name: mysql 4

   1

   Enter a descriptive name for the load balancer service.

   2

   Enter the same port that the service you want to expose is listening on.

   3

   Enter loadbalancer as the type.

   4

   Enter the name of the service.

4. Save and exit the file.

5. Run the following command to create the service:

   oc create -f <file-name>

   For example:

   oc create -f mysql-lb.yaml

6. Execute the following command to view the new service:

   $ oc get svc
   NAME       TYPE           CLUSTER-IP      EXTERNAL-IP                             PORT(S)          AGE
   egress-2   LoadBalancer   172.30.22.226   ad42f5d8b303045-487804948.example.com   3306:30357/TCP   15m

   The service has an external IP address automatically assigned if there is a cloud provider enabled.

7. On the master, use a tool, such as cURL, to make sure you can reach the service using the public IP address:

   $ curl <public-ip>:<port>

   For example:

   $ curl 172.29.121.74:3306

   The examples in this section use a MySQL service, which requires a client application. If you get a string of characters with the Got packets out of order message, you are connecting with the service:

   If you have a MySQL client, log in with the standard CLI command:

   $ mysql -h 172.30.131.89 -u admin -p
   Enter password:
   Welcome to the MariaDB monitor.  Commands end with ; or \g.
   
   MySQL [(none)]>

Procedure

1. Create a new project for your service:

   $ oc new-project <project_name>

   For example:

   $ oc new-project myproject

2. Use the oc new-app command to create a service. For example:

   $ oc new-app \
       -e MYSQL_USER=admin \
       -e MYSQL_PASSWORD=redhat \
       -e MYSQL_DATABASE=mysqldb \
       registry.redhat.io/rhscl/mysql-80-rhel7

3. Run the following command to see that the new service is created:

   $ oc get svc -n myproject
   NAME             TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
   mysql-80-rhel7   ClusterIP   172.30.63.31   <none>        3306/TCP   4m55s

   By default, the new service does not have an external IP address.

1. Log in to OpenShift Container Platform.

2. Log in to the project where the service you want to expose is located:

   $ oc project project1

3. Run the following command to expose the route:

   $ oc expose service <service_name>

   For example:

   $ oc expose service mysql-80-rhel7
   route "mysql-80-rhel7" exposed

4. Use a tool, such as cURL, to make sure you can reach the service using the cluster IP address for the service:

   $ curl <pod_ip>:<port>

   For example:

   $ curl 172.30.131.89:3306

   The examples in this section use a MySQL service, which requires a client application. If you get a string of characters with the Got packets out of order message, you are connected to the service.

   If you have a MySQL client, log in with the standard CLI command:

   $ mysql -h 172.30.131.89 -u admin -p
   Enter password:
   Welcome to the MariaDB monitor.  Commands end with ; or \g.
   
   MySQL [(none)]>

Procedure

1. Create a new project for your service:

   $ oc new-project <project_name>

   For example:

   $ oc new-project myproject

2. Use the oc new-app command to create a service. For example:

   $ oc new-app \
       -e MYSQL_USER=admin \
       -e MYSQL_PASSWORD=redhat \
       -e MYSQL_DATABASE=mysqldb \
       registry.redhat.io/rhscl/mysql-80-rhel7

3. Run the following command to see that the new service is created:

   $ oc get svc -n myproject
   NAME             TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
   mysql-80-rhel7   ClusterIP   172.30.63.31   <none>        3306/TCP   4m55s

   By default, the new service does not have an external IP address.

1. Log in to OpenShift Container Platform.

2. Log in to the project where the service you want to expose is located:

   $ oc project project1

3. To expose a node port for the application, enter the following command. OpenShift Container Platform automatically selects an available port in the 30000-32767 range.

   $ oc expose dc mysql-80-rhel7 --type=NodePort --name=mysql-ingress

4. Optional: To confirm the service is available with a node port exposed, enter the following command:

   $ oc get svc -n myproject
   NAME             TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
   mysql-80-rhel7   ClusterIP   172.30.217.127   <none>        3306/TCP         9m44s
   mysql-ingress    NodePort    172.30.107.72    <none>        3306:31345/TCP   39s

5. Optional: To remove the service created automatically by the oc new-app command, enter the following command:

   $ oc delete svc mysql-80-rhel7