********************* Managing Networking ********************* The Robin platform extends Kubernetes networking via both Calico and SRIOV/Open vSwitch-based CNI (Container Network Interface) drivers. This dual support offers flexibility in using either overlay networks to create non-rigid L3 subnets that span multiple data centers/cloud environments, or bridged networking to get wire-speed network access for high-performance applications. In either mode, Robin enhances the CNI driver to retain the IP address of the Pod when it is restarted or relocated. This provides additional flexibility during the application lifecycle management process for operations such as scaling and migration, as well as ensuring high availability. IP-Pool Management =================== An IP-Pool is a construct in Robin that groups together a set of IP addresses. The main properties of an IP-Pool is the aforementioned range of addresses specified, the netmask and the backing network driver. The netmask assigned indicates the number of IP addresses that can be used from the specified range. In addition Robin supports a multitude of network drivers through which the container networking is orchestrated and enabled. The supported drivers include: Calico, OVS, and SR-IOV. For more information on considerations when selecting a driver please review the below section on CNI plugins. As part of the installation process, Robin creates two Calico backed IP-Pools named ``robin-default`` and ``nonrobin-default`` respectively for the users convenience. The former uses the range 172.21.0-15.0-255 whilst the later is assigned the range 172.21.16-31.0-255. As the name suggests the ``nonrobin-default`` is used by Kubernetes when the applications are deployed using native Kubernetes tools. Its counter-part can be used for the applications deployed via Robin Bundles. .. note:: The ``nonrobin-default`` IP-Pool is hidden by default as Robin does not utilize it directly. When creating an application, one can specify an IP-Pool to be used at the Vnode level. As a result, the IP Address assigned to a container can be easily controlled and managed by the user. Moreover, in situations where a container needs multiple IP addresses, one can specify a set of IP-Pools and the number IP Addresses that need to be assigned from each of them in order to satisfy the requirement. However in the aforementioned situation if there are multiple IP-Pools containing default gateways, all of the gateways will programmed as source based routes except for the first. Along with additional details, the following commands are described in this section: =============================== ================================================================================= ``robin ip-pool add`` Add an IP-Pool ``robin ip-pool add-certs`` Add certificates to an existing IP-Pool ``robin ip-pool add-ranges`` Add additional IP ranges to an existing IP-Pool ``robin ip-pool list`` List IP-Pools ``robin ip-pool info`` Display detailed information about an IP-Pool ``robin ip-pool remove`` Remove an IP-Pool ``robin ip-pool remove-ranges`` Remove a range of IP addresses from an existing IP-Pool ``robin ip-pool rename`` Rename an existing IP-Pool =============================== ================================================================================= ================== Adding an IP-Pool ================== .. tabs:: .. tab:: CLI To add an IP-Pool for Robin to utilize during application deployment, issue the following command: .. code-block:: text # robin ip-pool add --ranges --network --netmask --prefix --zone --tenant --vlan --driver --gateway --nameserver --dns-search --nictags --ifcount --routes --vfdriver ============================== ============================================================================================== ``name`` IP-Pool Name ``--ranges `` Comma separated list of IP ranges to assign to IP-Pool. Each range can also be specified in CIDR format ``--network `` IP network without ranges to be used for static IP allocations ``--netmask `` Mask indicating number of IP addresses that can be used from given range ``--prefix `` CIDR prefix to be used with the IP Pool ``--zone `` Name of zone in which to create this IP-Pool ``--tenant `` Name of Tenant to which this IP-Pool belongs to ``--vlan `` VLAN to be associated with this IP-Pool. Note this option is only valid for OVS and SRIOV driver backed IP-Pools ``--driver `` Driver to back this IP-Pool. Valid choices include: OVS, Calico, Secondary, Isolated and SR-IOV ``--gateway `` Default gateway to be used for this IP-Pool ``--nameserver `` Comma separated list of DNS name servers to be used for Pods deployed using this IP-Pool ``--dns-search `` Comma separated list of DNS search strings to be used for Pods deployed using this IP-Pool ``--nictags `` Comma separated NIC tags to select when assigning interfaces from this network. Each tag must be specified as key/value pair. Only keys "name" and "pci_address" are supported ``--ifcount `` Preset the interface count when using this network. Applicable only for the SR-IOV driver ``--routes `` Comma separated list of routes to associated with this network ``--vfdriver `` Kernel driver to bind to when attaching an SR-IOV virtual function. Applicable only for the SR-IOV driver ============================== ============================================================================================== .. Note:: At least one of the ``--network`` or ``--ranges`` options must be given when creating an IP-Pool however both cannot be used. Similarly either one of the ``--prefix`` or ``--netmask`` parameters must be utilized but both cannot be specified. If an IP-Pool is created without ranges, it can only be used for static IP Address allocations. **Example 1 (Creating a basic OVS IP-Pool):** .. code-block:: text # robin ip-pool add demo --ranges 10.9.106.1-255 --netmask 255.255.0.0 --driver ovs Registered IP pool demo. **Example 2 (Creating an SR-IOV IP-Pool with VLAN):** .. code-block:: text # robin ip-pool add demo --ranges 10.9.106.1-255 --netmask 255.255.0.0 --driver sriov --vlan 500 Registered IP pool demo. With the above IP-Pool Robin will select VF's based on the VLANs allowed for a particular NIC. **Example 3 (Creating an SR-IOV IP-Pool with NIC tags using the pci_address parameter):** .. code-block:: text # robin ip-pool add demo --ranges 10.9.106.1-255 --netmask 255.255.0.0 --driver sriov --vlan 500 --nictags pci_addr=0000:3b:00.0 Registered IP pool demo. With the above IP-Pool Robin will select VF's only from NICs with the pci address "0000:3b:00.0". **Example 5 (Creating an SR-IOV IP-Pool with NIC tags using the name parameter):** .. code-block:: text # robin ip-pool add demo --ranges 10.9.106.1-255 --netmask 255.255.0.0 --driver sriov --vlan 500 --nictags name=sriov0 Registered IP pool demo. With the above IP-Pool Robin will select VF's only from NICs with the name "sriov0". **Example 6 (Creating an SR-IOV IP-Pool with Bonded VFs):** .. code-block:: text # robin ip-pool add demo --ranges 192.168.1.101-110 --netmask 255.255.255.0 --driver sriov --vlan 500 --ifcount 2 --nictags name=sriov0,name=sriov2 Registered IP pool demo. With the above IP-Pool Robin will select one VF from a NIC named sriov0, one VF from a NIC named sriov2 and bond them together. **Example 7 (Creating an SR-IOV IP-Pool with Bonded VFs based on VLAN):** .. code-block:: text # robin ip-pool add demo --ranges 192.168.1.101-110 --netmask 255.255.255.0 --driver sriov --vlan 500 --ifcount 2 Registered IP pool demo. With the above IP-Pool Robin will select two VFs from two NICs (one from each) where VLAN 500 is allowed and bond them together. **Example 8 (Creating an SR-IOV IP-Pool with Bonded VFs from the same NIC):** .. code-block:: text # robin ip-pool add demo --ranges 192.168.1.101-110 --netmask 255.255.255.0 --driver sriov --vlan 500 --ifcount 2 --nictags name=sriov0,name=sriov0 Registered IP pool demo. With the above IP-Pool Robin will select two VFs from a NIC named sriov0 and bond them together. **Example 9 (Creating an SR-IOV IP-Pool with VF Driver):** .. code-block:: text # robin ip-pool add demo --ranges 192.168.1.101-110 --netmask 255.255.255.0 --driver sriov --vlan 500 --nictags name=sriov0 --vfdriver igb_uio Registered IP pool demo. With the above IP-Pool Robin will select one VF from a NIC named sriov0 and bind it with the specified driver. **Example 10 (Creating an IP-Pool by specifying IP ranges in network/CIDR format):** .. code-block:: text # robin ip-pool add demo --ranges 192.10.88.0/24 --netmask 255.255.0.0 --driver ovs Registered IP pool demo. With the above IP-Pool Robin will configure its ranges utilizing the CIDR format i.e (/24, /16, /26 etc) with which the ranges were represented. .. Note:: In all the above examples for SR-IOV backed IP-Pools, when the ``--vlan`` option is specified independently of any other parameters it acts as a constraining factor whilst also tagging outgoing packets. In every other scenario only the latter holds true. As a result when options such as the ``--nictags`` option is passed alongside the ``--vlan`` option, the latter stops becoming a constraining factor. .. tab:: API Adds an IP-Pool for Robin to utilize during application deployment. **End Point:** /api/v3/robin_server/ip-pools **Method:** POST **URL Parameters:** None **Data Parameters:** - ``ip_pool: `` -- - ``name: `` - This mandatory field within the payload specifies the name of the IP-Pool to be created. - ``driver: `` - This mandatory field within the payload specifies the network driver to be associated with the IP-Pool. Valid options include: 'ovs', 'sriov', 'secondary', 'isolated' and 'calico'. - ``zoneid: `` - This mandatory field within the payload specifies the name of the zone in which the IP-Pool should be created. - ``ranges: `` - Utilizing this parameter within the payload, by specifying a list containing dictionaries in the form ``{'range': }`` for each range, results in the specified ranges being assigned to this IP-Pool. - ``network: `` - Utilizing this parameter within the payload, by specifying an IP network without ranges, results in the specified network being used for IP allocations when utilizing this network. - ``netmask: `` - Utilizing this parameter within the payload, by specifying an appropriate mask, results in aforementioned mask being applied to the specified ranges and thus indicating the number of IP addresses that can be used. - ``prefix: `` - Utilizing this parameter within the payload, by specifying a CIDR prefix, results in the aforementioned prefix being associated with the IP-Pool. - ``tenant: `` - Utilizing this parameter within the payload, by specifying a tenant name, results in the IP-Pool being associated with the aforementioned tenant. - ``vlan_number: `` - Utilizing this parameter within the payload, by specifying a VLAN number, results in the IP-Pool being associated with the aforementioned VLAN number. Note this option is only valid for OVS and SRIOV driver backed IP-Pools. - ``gateway: `` - Utilizing this parameter within the payload, by specifying a gateway, results aforementioned gateway being set as the default gateway for the IP-Pool. - ``nameserver: `` - Utilizing this parameter within the payload, by specifying a string of DNS name servers which are comma seperated, results in the aforementioned name servers being used for Pods deployed using this IP-Pool. - ``dns_search: `` - Utilizing this parameter within the payload, by specifying a string of DNS search strings which are comma seperated, results in the aforementioned search strings being used for Pods deployed using this IP-Pool. - ``nictags: `` - Utilizing this parameter within the payload, by specifying a list containing dictionaries in the form ``{: }`` for each NIC tag, results in only interfaces associated with the aforementioned tags being utilized when using this IP-Pool. Note only keys "name" and "pci_address" are supported. - ``ifcount: `` - Utilizing this parameter within the payload presets the interface count for allocations to the integer specified when using this network. Valid values include 1 and 2. Note this option is only valid for SRIOV driver backed IP-Pools. - ``routes: `` - Utilizing this parameter within the payload, by specifying a list containing dictionaries in the form ``{'dest': , 'gateway': }`` for each route, results in the specified routes being associated with this IP-Pool. - ``vfdriver: `` - Utilizing this parameter within the payload, by specifying the name of a kernel driver, results in the aforementioned driver being bound to when attaching an SR-IOV virtual function. Valid options include: 'igb_uio', 'vfio-pci', and 'uio_pci_generic'. Note this option is only valid for SRIOV driver backed IP-Pools. .. Note:: At least one of the ``network`` or ``ranges`` properties must be given when creating an IP-Pool however both cannot be used. Similarly either one of the ``prefix`` or ``netmask`` properties must be utilized but both cannot be specified. If an IP-Pool is created without ranges, it can only be used for static IP Address allocations. **Port:** RCM Port (default value is 29442) **Headers:** - ``Authorization: `` : Authorization token to identify which user is sending the request. The token can be acquired from the login API. **Success Response Code:** 200 **Error Response Code:** 500 (Internal Server Error), 404 (Not Found Error), 401 (Unauthorized Error), 400 (Invalid API Usage Error), 409 (Duplicate Resource Error) **Example Response:** .. raw:: html
Output .. code-block:: text { "message":"Registered IP pool demo. \n" } .. raw:: html
================================== Adding certificates to an IP-Pool ================================== .. tabs:: .. tab:: CLI To add certificates to an IP-Pool in order to make certain addresses accessible in a secure manner, issue the following command: .. code-block:: text # robin ip-pool add-certs --keypass --is_hostnames --no_multinode ======================== ============================================================================================================================ ``name`` IP-Pool Name ``certificates`` Path to SSL certificates file ``--keypass `` Passphrase of the key ``--is_hostnames`` Indicates that the filename specified contains the hostname and its format is . ``--no_multinode`` Indicates that the certificate can be used for multiple hosts ======================== ============================================================================================================================ **Example:** .. code-block:: text # robin ip-pool add-cert demo ~/ssl/demo-cert Added certificates. .. tab:: API Adds certificates to an IP-Pool in order to make certain addresses accessible in a secure manner. **End Point:** /api/v3/robin_server/ip-pools/ **Method:** PUT **URL Parameters:** None **Data Parameters:** - ``action: add_certs`` - This mandatory field within the payload specifies that the add certificates operation is to be performed. - ``cert_info: `` -- - ``filename: `` - This mandatory field within the payload specifies the base file name of the certificate file. - ``certificate: `` - This mandatory field within the payload specifies the base64 decoded details within the specified file. - ``multinode: [true|false]`` - Utilizing this parameter within the payload indicates whether or not this certificate can be used for multiple hosts. - ``is_hostnames: [true|false]`` - Utilizing this parameter within the payload indicates whether or not the specified certificate filename contains the hostname and is in the format .. **Port:** RCM Port (default value is 29442) **Headers:** - ``Authorization: `` : Authorization token to identify which user is sending the request. The token can be acquired from the login API. **Success Response Code:** 200 **Error Response Code:** 500 (Internal Server Error), 404 (Not Found Error), 401 (Unauthorized Error), 400 (Invalid API Usage Error) **Example Response:** .. raw:: html
Output .. code-block:: text { "message":"Added certificates.\n" } .. raw:: html
================================== Adding ranges to an IP-Pool ================================== .. tabs:: .. tab:: CLI To add additional ranges to an IP-Pool in order to expand the number of IP Addresses available, issue the following command: .. code-block:: text # robin ip-pool add-ranges ====================== ============================================================================================================================ ``name`` IP-Pool Name ``ranges`` Comma separated list of additional IP ranges to assign to IP-Pool ====================== ============================================================================================================================ **Example:** .. code-block:: text # robin ip-pool add-ranges demo 10.9.107.1-255 Added range. .. tab:: API Adds IP ranges that are currently assigned to an IP-Pool in order to expand the number of available IP ranges. **End Point:** /api/v3/robin_server/ip-pools/ **Method:** PUT **URL Parameters:** None **Data Parameters:** - ``action: add_ranges`` - This mandatory field within the payload specifies that the add ranges operation is to be performed. - ``ranges: `` - This mandatory field within the payload specifies a list of comma seperated ranges to be added from the given IP-Pool. **Port:** RCM Port (default value is 29442) **Headers:** - ``Authorization: `` : Authorization token to identify which user is sending the request. The token can be acquired from the login API. **Success Response Code:** 200 **Error Response Code:** 500 (Internal Server Error), 404 (Not Found Error), 401 (Unauthorized Error), 400 (Invalid API Usage Error) **Example Response:** .. raw:: html
Output .. code-block:: text { "message":"Added range.\n" } .. raw:: html
================================== Listing registered IP-Pools ================================== .. tabs:: .. tab:: CLI To list registered IP-Pools alongside details such as the associated driver and network ranges contained within each pool, issue the following command: .. code-block:: text # robin ip-pool list --all --full --json ====================== ============================================================================================================================ ``--all`` Display all registered IP-Pools including hidden ones ``--full`` Display additional information for listed IP-Pools ``--json`` Output in JSON ====================== ============================================================================================================================ **Example:** .. code-block:: text # robin ip-pool list --all Name | Driver | Network | VLAN | Total | Used | Free -----------------+--------+---------------+------+-------+------+------ nonrobin-default | calico | 172.21.0.0/16 | - | 4096 | 2 | 4094 robin-default | calico | 172.21.0.0/16 | - | 4096 | 0 | 4096 demo | ovs | 10.9.0.0/16 | - | 255 | 0 | 255 .. tab:: API Returns all registered IP-Pools alongside details such as the associated driver and network ranges contained within each pool. **End Point:** /api/v3/robin_server/ip-pools/ **Method:** GET **URL Parameters:** None **Data Parameters:** - ``all: true`` - Utilizing this parameter within the payload results in details of hidden IP-Pools being returned as well. **Port:** RCM Port (default value is 29442) **Headers:** - ``Authorization: `` : Authorization token to identify which user is sending the request. The token can be acquired from the login API. **Success Response Code:** 200 **Error Response Code:** 500 (Internal Server Error) **Example Response:** .. raw:: html
Output .. code-block:: text { "items":[ { "available":"4092", "description":null, "zone":"default", "tenants":[ ], "subnet":"172.21.0.0", "vfdriver":null, "ranges":[ { "range":"172.21.0-15.0-255" } ], "gateway":null, "name":"nonrobin-default", "netmask":"255.255.0.0", "used":"4", "total":"4096", "nictags":null, "dns_search":null, "zone_id":1, "driver":"calico", "routes":[ ], "ifcount":1, "nameserver":null }, { "available":"4094", "description":null, "zone":"default", "tenants":[ "Administrators" ], "subnet":"172.21.0.0", "vfdriver":null, "ranges":[ { "range":"172.21.16-31.0-255" } ], "gateway":null, "name":"robin-default", "netmask":"255.255.0.0", "used":"2", "total":"4096", "nictags":null, "dns_search":null, "zone_id":1, "driver":"calico", "routes":[ ], "ifcount":1, "nameserver":null }, { "available":"255", "description":null, "zone":"default", "tenants":[ "Administrators" ], "subnet":"10.9.0.0", "vfdriver":null, "ranges":[ { "range":"10.9.106.1-255" } ], "gateway":null, "name":"demo", "netmask":"255.255.0.0", "used":"0", "total":"255", "nictags":null, "dns_search":null, "zone_id":1, "driver":"ovs", "routes":[ ], "ifcount":1, "nameserver":null } ] } .. raw:: html
.. tab:: Kubernetes To list registered IP-Pools via the ``robinippool`` custom resource alongside details such as the associated driver, network ranges, VLANs and bonded NICs contained within each pool, issue the following command: .. code-block:: text # kubectl get robinippool **Example:** .. code-block:: text [root@qct-05 ~]# kubectl get robinippool NAME NETMASK NETWORK IPPREFIX SUBNET GATEWAY NAMESERVER DRIVER VFDRIVER RANGE(S) VLAN BONDED TRUST SPOOFCHK robin-default 255.255.0.0 172.21.0.0 calico ["172.21.16-31.0-255"] 1 sec-1 255.255.255.0 24 192.168.1.0 secondary ["192.168.1.11-20"] 1 sec-2 255.255.255.0 24 192.168.2.0 secondary ["192.168.2.11-20"] 1 sriov-b1 255.255.255.0 192.168.110.0 sriov ["192.168.110.165-170"] 20 2 off on sriov-b2 255.255.255.0 192.168.111.0 sriov ["192.168.111.165-170"] 20 2 off on sriov1 255.255.255.0 192.168.10.0 sriov igb_uio ["192.168.10.101-164"] 20 1 off on sriov10 255.255.255.0 192.168.100.0 sriov native ["192.168.100.101-164"] 20 1 off on sriov2 255.255.255.0 192.168.20.0 sriov igb_uio ["192.168.20.101-164"] 20 1 off on sriov3 255.255.255.0 192.168.30.0 sriov igb_uio ["192.168.30.101-164"] 20 1 off on sriov4 255.255.255.0 192.168.40.0 sriov igb_uio ["192.168.40.101-164"] 20 1 off on sriov5 255.255.255.0 192.168.50.0 sriov native ["192.168.50.101-164"] 20 2 off on sriov6 255.255.255.0 192.168.60.0 sriov native ["192.168.60.101-164"] 20 2 off on sriov7 255.255.255.0 192.168.70.0 sriov native ["192.168.70.101-164"] 20 1 off on sriov8 255.255.255.0 192.168.80.0 sriov native ["192.168.80.101-164"] 20 1 off on sriov9 255.255.255.0 192.168.90.0 sriov native ["192.168.90.101-164"] 20 1 off on sriov98 255.255.255.0 192.168.98.0 sriov igb_uio ["192.168.98.101-164"] 20 1 off on sriov99 255.255.255.0 192.168.99.0 sriov igb_uio ["192.168.99.101-164"] ============================================= Show information about a specific IP-Pool ============================================= .. tabs:: .. tab:: CLI To view details about a particular IP-Pool including its utilization, associated driver, and the network range(s) it covers, issue the following command: .. code-block:: text # robin ip-pool info --json ====================== ============================================================================================================================ ``name`` Name of IP-Pool ``--json`` Output in JSON ====================== ============================================================================================================================ **Example:** .. code-block:: text # robin ip-pool info demo IPPool: demo Driver: ovs Subnet: 10.10.2.0 Netmask: 255.255.255.0 Range: 10.10.2.102-130 Pool Utilization: 0/29/29 (Used/Available/Total) .. tab:: API Returns details about a particular IP-Pool including its utilization, associated driver, and the network range(s) it covers. **End Point:** /api/v3/robin_server/ip-pools/ **Method:** GET **URL Parameters:** None **Data Parameters:** - ``name: `` - This mandatory parameter within the payload specifies which IP-Pool actually needs to be queried. **Port:** RCM Port (default value is 29442) **Headers:** - ``Authorization: `` : Authorization token to identify which user is sending the request. The token can be acquired from the login API. **Success Response Code:** 200 **Error Response Code:** 500 (Internal Server Error), 404 (Not Found Error), 401 (Unauthorized Error) **Example Response:** .. raw:: html
Output .. code-block:: text { "items":[ { "available":"255", "description":null, "zone":"default", "tenants":[ "Administrators" ], "subnet":"10.9.0.0", "vfdriver":null, "ranges":[ { "range":"10.9.106.1-255" } ], "gateway":null, "name":"demo", "netmask":"255.255.0.0", "used":"0", "total":"255", "nictags":null, "dns_search":null, "zone_id":1, "driver":"ovs", "routes":[ ], "ifcount":1, "nameserver":null } ] } .. raw:: html
===================== Removing an IP-Pool ===================== .. tabs:: .. tab:: CLI To remove an IP-Pool from Robin, issue the following command: .. code-block:: text # robin ip-pool remove --yes ====================== ============================================================================================== ``name`` IP-Pool Name ``--yes`` Do not prompt the user for confirmation of deletion ====================== ============================================================================================== **Example:** .. code-block:: text # robin ip-pool remove demo --yes Unregistered IP-Pool 'demo'. .. tab:: API Removes an IP-Pool from Robin. **End Point:** /api/v3/robin_server/ip-pools/ **Method:** DELETE **URL Parameters:** None **Data Parameters:** None **Port:** RCM Port (default value is 29442) **Headers:** - ``Authorization: `` : Authorization token to identify which user is sending the request. The token can be acquired from the login API. **Success Response Code:** 200 **Error Response Code:** 500 (Internal Server Error), 404 (Not Found Error), 401 (Unauthorized Error) **Example Response:** .. raw:: html
Output .. code-block:: text { "message":"Unregistered IP pool demo.\n" } .. raw:: html
================================ Removing ranges from an IP-Pool ================================ .. tabs:: .. tab:: CLI To remove IP ranges that are currently assigned to an IP-Pool in order to reduce the number of available IP ranges, issue the following command: .. code-block:: text # robin ip-pool remove-ranges --yes ====================== ============================================================================================== ``name`` IP-Pool Name ``ranges`` Comma separated list of IP ranges to remove from an IP-Pool ``--yes`` Do not prompt the user for confirmation of removal ====================== ============================================================================================== **Example:** .. code-block:: text # robin ip-pool remove-ranges demo 10.9.107.1-255 --yes Removed range. .. tab:: API Removes IP ranges that are currently assigned to an IP-Pool in order to reduce the number of available IP ranges. **End Point:** /api/v3/robin_server/ip-pools/ **Method:** PUT **URL Parameters:** None **Data Parameters:** - ``action: remove_ranges`` - This mandatory field within the payload specifies that the remove ranges operation is to be performed. - ``ranges: `` - This mandatory field within the payload specifies a list of comma seperated ranges to be removed from the given IP-Pool. **Port:** RCM Port (default value is 29442) **Headers:** - ``Authorization: `` : Authorization token to identify which user is sending the request. The token can be acquired from the login API. **Success Response Code:** 200 **Error Response Code:** 500 (Internal Server Error), 404 (Not Found Error), 401 (Unauthorized Error), 400 (Invalid API Usage Error) **Example Response:** .. raw:: html
Output .. code-block:: text { "message":"Removed range.\n" } .. raw:: html
================================ Renaming an IP-Pool ================================ .. tabs:: .. tab:: CLI To rename an IP-Pool, issue the following command: .. code-block:: text # robin ip-pool rename ====================== ============================================================================================== ``name`` IP-Pool Name ``new_name`` New name of the specified IP-Pool ====================== ============================================================================================== **Example:** .. code-block:: text # robin ip-pool rename demo demo_change IP-Pool 'demo' renamed to 'demo_change'. .. tab:: API Renames an existing IP-Pool. **End Point:** /api/v3/robin_server/ip-pools/ **Method:** PUT **URL Parameters:** None **Data Parameters:** - ``action: rename`` - This mandatory field within the payload specifies that the rename operation is to be performed. - ``new_name: `` - This mandatory field within the payload specifies the new name for the specified IP-Pool. **Port:** RCM Port (default value is 29442) **Headers:** - ``Authorization: `` : Authorization token to identify which user is sending the request. The token can be acquired from the login API. **Success Response Code:** 200 **Error Response Code:** 500 (Internal Server Error), 404 (Not Found Error), 401 (Unauthorized Error), 400 (Invalid API Usage Error) **Example Response:** .. raw:: html
Output .. code-block:: text { "message":"IP-Pool 'demo' renamed to 'demo_change'.\n" } .. raw:: html
VLAN Support =================== The VLAN (Virtual LAN) feature allows one to logically group a set of devices in the same L2 domain irrespective of how they are physically connected. Additionally one can carve out logical groups even if the devices are connected to the same L2 switch. Listed below are some of the advantages of using VLANs: - Performance - Broadcast traffic is sent to all the nodes in an L2 domain. VLANs allow creating groups or virtual L2 domains, thus containing the broadcast traffic to the created logical groups. - Isolation and Security - VLANs allow one to control the broadcast domain and enforce which logical groups can talk to one another - Flexibility - A device can be easily added/removed from a VLAN logical group without actually changing the physical connectivity - Cost Reduction - VLANs can be used to create broadcast domains without the need for expensive routers Along with additional details, the following commands are described in this section: =============================== ================================================================================= ``robin vlan add`` Register a VLAN ``robin vlan list`` List VLANs ``robin vlan remove`` Unregister a VLAN ``robin host add-vlan`` Configure a VLAN for an interface on a host ``robin host remove-vlan`` Remove a VLAN from an interface on a host =============================== ================================================================================= =================== Registering a VLAN =================== .. tabs:: .. tab:: CLI To register a VLAN with Robin so it can be configured for an interface, issue the following command: .. code-block:: text # robin vlan add --skip-vlan-interface --add-vlan-interface .. Note:: The Robin server might need to access pods deployed in a particular VLAN. As a result a VLAN interface needs to be created on the current Robin Master. This VLAN interface is created, when ``--add-vlan-interface`` is enabled, on the aforementioned node when an IP-Pool is created and has an associated VLAN. The IP address linked to the VLAN interface is picked from the addresses provided in the IP Pool. In some deployments, VLAN routing could be provided in a different manner and thus a VLAN interface might not be needed on the Robin Master. If this is the case, you can create VLAN with ``--skip-vlan-interface`` option (this is the default behavior). ========================= ============================================================================================== ``vlan_number`` VLAN number/identifier ``--skip-vlan-interface`` Skips VLAN interface configuration on the Robin Master node ``--add-vlan-interface`` Configures the VLAN interface on the Robin Master node ========================= ============================================================================================== **Example:** .. code-block:: text # robin vlan add 9 --wait Job: 180 Name: VLANAdd State: PROCESSED Error: 0 Job: 180 Name: VLANAdd State: COMPLETED Error: 0 .. tab:: API Registers a VLAN with Robin so it can be configured for an interface. **End Point:** /api/v3/robin_server/vlans **Method:** POST **URL Parameters:** None **Data Parameters:** - ``vlan: `` - This mandatory field within the payload specifies the VLAN number for the VLAN to be registered. - ``skip_vlan_interface: [true|false]`` - This mandatory field within the payload is a boolean value that specifies whether or not the VLAN interface should be configured on the Robin Master node. **Port:** RCM Port (default value is 29442) **Headers:** - ``Authorization: `` : Authorization token to identify which user is sending the request. The token can be acquired from the login API. **Success Response Code:** 202 **Error Response Code:** 500 (Internal Server Error), 404 (Not Found Error), 401 (Unauthorized Error), 400 (Invalid API Usage Error), 409 (Duplicate Resource Error) **Example Response:** .. raw:: html
Output .. code-block:: text { "jobid":209 } .. raw:: html
====================== Listing all VLANs ====================== .. tabs:: .. tab:: CLI To list registered VLANs alongside details such as the IP-Pools it is assigned to and the number of NICs associated with it, issue the following command: .. code-block:: text # robin vlan list --json ====================== ============================================================================================================================ ``--json`` Output in JSON ====================== ============================================================================================================================ **Example:** .. code-block:: text # robin vlan list VLAN | IP Pools | Instance Count | Interface Count -----+----------+----------------+----------------- 9 | None | 0 | 0 .. tab:: API Returns all registered VLANs alongside details such as the IP-Pools it is assigned to and the number of NICs associated with it. **End Point:** /api/v3/robin_server/vlans/ **Method:** GET **URL Parameters:** None **Data Parameters:** None **Port:** RCM Port (default value is 29442) **Headers:** - ``Authorization: `` : Authorization token to identify which user is sending the request. The token can be acquired from the login API. **Success Response Code:** 200 **Error Response Code:** 500 (Internal Server Error) **Example Response:** .. raw:: html
Output .. code-block:: text { "items":[ { "skip_vlan_interface":true, "ip_pools":[ ], "instance_cnt":0, "number":9, "nic_cnt":0 } ] } .. raw:: html
============================= Configuring a VLAN on a host ============================= .. tabs:: .. tab:: CLI Before installing Robin on a VLAN based setup, it is expected that an administrator would have planned which VLANs are to be used for deploying applications and thus configured the installation appropriately. However in order to configure a VLAN post installation, issue the following command: .. code-block:: text # robin host add-vlan [] --vlans --interface --all --untagged =========================== ==================================================================================================== ``hosts`` A comma separated list of hosts to add VLANs to. If this isn't provided, then --all must be used ``--vlans `` Range of VLANs to be added (Use 'ALL' to enable all vlans) ``--interface `` Interface on host on which VLANs should be added ``--all`` VLANs will be added to every host in the cluster ``--untagged`` Network traffic will not be tagged with the VLAN number =========================== ==================================================================================================== **Example:** .. code-block:: text # robin host add-vlan vnode89.robinsystems.com --vlans 9 --interface br0 --untagged Job: 180 Name: HostVLANAdd State: PROCESSED Error: 0 Job: 180 Name: HostVLANAdd State: COMPLETED Error: 0 .. tab:: API Configures a VLAN on a host after Robin installation. **End Point:** /api/v3/robin_server/hosts/ **Method:** PUT **URL Parameters:** None **Data Parameters:** - ``action: add_vlans`` - This mandatory field within the payload specifies that the add VLAN operation is to be performed. - ``vlans: `` - Utilizing this parameter in the payload, by specifying a range of VLANs, results in the aforementioned VLANs being configured on the host. - ``all_vlans: true`` - Utilizing this parameter in the payload results in all possible VLANs being configured on this host. The default value is False. - ``interface: `` - Utilizing this parameter in the payload, by specifying an interface name, results in the given VLANs being configured on the aforementioned interface. - ``untagged: true`` - Utilizing this parameter in the payload results in the VLAN being configured on SRIOV interfaces as untagged. The default value is False. .. note:: Either the ``vlans`` or ``all_vlans`` parameter must be present in the request body. **Port:** RCM Port (default value is 29442) **Headers:** - ``Authorization: `` : Authorization token to identify which user is sending the request. The token can be acquired from the login API. **Success Response Code:** 202 **Error Response Code:** 500 (Internal Server Error), 404 (Not Found Error), 401 (Unauthorized Error), 400 (Invalid API Usage Error) **Example Response:** .. raw:: html
Output .. code-block:: text { "jobid":217 } .. raw:: html
============================= Removing a VLAN from a host ============================= .. tabs:: .. tab:: CLI In order to remove a VLAN that is configured on an interface which is present on a host, issue the following command: .. code-block:: text # robin host remove-vlan [] --vlans --interface --all ============================ ======================================================================================================== ``hosts`` A comma separated list of hosts to remove VLANs from. If this isn't provided, then --all must be used ``--vlans `` Range of VLANs to be removed (Use 'ALL' to indicate all vlans) ``--interface `` Interface on host from which VLANs should be removed ``--all`` VLANs will be removed on every host in the cluster ============================ ======================================================================================================== **Example:** .. code-block:: text # robin host remove-vlan vnode89.robinsystems.com --vlans 9 --interface br0 Job: 180 Name: HostVLANRemove State: PROCESSED Error: 0 Job: 180 Name: HostVLANRemove State: COMPLETED Error: 0 .. tab:: API Removes a VLAN that is configured on an interface which is present on a host. **End Point:** /api/v3/robin_server/hosts/ **Method:** PUT **URL Parameters:** None **Data Parameters:** - ``action: remove_vlans`` - This mandatory field within the payload specifies that the remove VLAN operation is to be performed. - ``vlans: `` - This mandatory field within the payload specifies the range of VLANs to be removed. - ``interface: `` - Utilizing this parameter in the payload indicates the interface on the specified host from which the VLAN(s) should be removed. **Port:** RCM Port (default value is 29442) **Headers:** - ``Authorization: `` : Authorization token to identify which user is sending the request. The token can be acquired from the login API. **Success Response Code:** 202 **Error Response Code:** 500 (Internal Server Error), 404 (Not Found Error), 401 (Unauthorized Error), 400 (Invalid API Usage Error) **Example Response:** .. raw:: html
Output .. code-block:: text { "jobid":213 } .. raw:: html
====================== Unregistering a VLAN ====================== .. tabs:: .. tab:: CLI To unregister a VLAN from Robin, issue the following command: .. code-block:: text # robin vlan remove --yes .. Note:: The VLAN must be removed from all hosts it was configured on before it can be unregistered. ========================= ============================================================================================== ``vlan_number`` VLAN number/identifier ``--yes`` Do not prompt the user for confirmation of removal ========================= ============================================================================================== **Example:** .. code-block:: text # robin vlan remove 9 --wait --yes Job: 182 Name: VLANRemove State: PROCESSED Error: 0 Job: 182 Name: VLANRemove State: COMPLETED Error: 0 .. tab:: API Unregisters a VLAN from robin. **End Point:** /api/v3/robin_server/vlans/ **Method:** DELETE **URL Parameters:** None **Data Parameters:** None **Port:** RCM Port (default value is 29442) **Headers:** - ``Authorization: `` : Authorization token to identify which user is sending the request. The token can be acquired from the login API. **Success Response Code:** 202 **Error Response Code:** 500 (Internal Server Error), 404 (Not Found Error), 401 (Unauthorized Error) **Example Response:** .. raw:: html
Output .. code-block:: text { "jobid":83 } .. raw:: html
========================================== Assumptions made about VLAN Configurations ========================================== Below are a list of assumptions and/or rules that made with regards to VLAN integration with Robin: - Upstream ports are configured as trunk ports and the right VLANs are allowed on these ports. - On a single host with multiple ports, then same VLAN is not configured on different ports (an exception to this rule is SR-IOV ports). - Multiple IP subnets can be configured to be carried using the same VLAN. - The same IP subnet cannot be configured for two different VLANs. Advanced Compute and Networking Support ======================================= =================================================================================================== Supported and Unsupported Functionalities When Using Kubernetes YAML or Helm Chart for Deployment =================================================================================================== The following are the supported functionalities: - Multiple interfaces support - OVS support - SR-IOV device allocation - FPGA device allocation - Dedicated CPU support The following is the unsupported functionality: - VNF deployment .. note::Robin has no plans to support hard-coded CPU IDs in any form of deployment. ================================ Specifying Dedicated CPU Request ================================ If your Pod needs dedicated CPUs, then the Pod must be in guaranteed QoS class (requests = limits) and should ask for integer CPU requests. Also, Pods need to have CPU and memory specified in requests and limits. .. code-block:: text spec: containers: -name: nginx image: nginx resources: limits: memory: "200Mi" cpu: "2" requests: memory: "200Mi" cpu: "2 Check Pod’s QoS Class after deploying by following the example mentioned below: .. code-block:: text kubectl describe Pod Pod-l2fwd-78554948b7-zrfvj | grep -i qos QoS Class: Guaranteed =========================================== Prerequisites for Using Network Annotations =========================================== To use network annotations, you must meet the following prerequisites: - The namespace in which Helm Charts or YAML based objects are planned to be deployed in should be registered with Robin. Details on the command by which to achieve this can be found `here `_. - All Kubernetes objects including controllers, DaemonSets, Pods etc. that request network resources must meet one of the following conditions in order to have the appropriate network resources allocated to them by the Robin orchestrator: - Both ``app`` and ``release`` labels need to be present within the object definition. This is considered the old style of naming. - Both ``app.kubernetes.io/name`` and ``app.kubernetes.io/instance`` labels need to be present within the object definition. This is considered the new style of naming. For more information on updated naming conventions, see `Recommended Labels `_. .. note:: - This is also applicable for other Kubernetes resources as per the Helm best practices. For more information, see `Labels and Annotations - Best Practices `_ - Each controller including all StatefulSets, Deployments, and Daemonsets within a Kubernetes cluster must have a unique combination ``app`` and ``release`` labels. ================================================ Robin Annotation for Multiple Interfaces Support ================================================ Robin platform supports configuring multiple IPV4/IPV6 addresses on a single pod interface. With this support, you should be able to configure multiple IPV4, multiple IPV6, or both IPV4 and IPV6 addresses on a single pod interface. Robin provides a new annotation for adding multiple network interfaces for Deployments, Pods, Statefulsets, or DaemonSets. After you add these annotations, Robin takes care of the remaining tasks, such as planning, creating network attachment definitions, defining objects, etc. To get the Robin interface list, you use Robin’s custom resource: robinippool. For more information, review the section detailed `here `_. The following is the annotation for multiple interfaces. .. code-block:: text robin.io/networks: '[{"ippool": "ovs1"}, {"ippool": "sriovigb"}]' .. note:: A Pod that needs only a Calico interface does not require Robin annotation. ========================== New Driver Type: secondary ========================== To support multiple IPV4 and IPV6 or a combination of both IP addresses, Robin provides a new driver type by name *secondary*. Just like OVS, SR-IOV, and Calico, *secondary* is a new driver type for Robin IP pools. If you need to use multiple IP address configurations on a single interface, you must create IP pools using the new *secondary* driver type. You can create multiple IP pools using the secondary driver type for assigning an IP address from each pool. Each IP pool that is created using the secondary driver should have a primary(not a driver type) IP pool associated with it. The primary IP pool can be one of these: OVS or SR-IOV driver type IP pool. ======================================== Multiple Interfaces Annotations Examples ======================================== The following are the annotations examples: **IP Pools for this Example:** .. code-block:: text robin ip-pool add sriov1 --driver sriov --ranges 192.168.1.1-25 --netmask 255.255.0.0 robin ip-pool add ovs1 --driver ovs --ranges 192.168.1.1-100 --netmask 255.255.0.0 robin ip-pool add sriovigb --driver sriov --ranges 192.168.1.101-150 --netmask 255.255.0.0 --vfdriver igb_uio robin ip-pool add sriov-bond --ranges 192.168.112.0-200 --netmask 255.255.255.0 --driver sriov --ifcount 2 **Pod with calico and OVS interface** .. code-block:: text annotations: robin.io/networks: '[{"ippool": "ovs1"}]' **Pod with calico and SRIOV (iavf)** .. code-block:: text annotations: robin.io/networks: '[{"ippool": "sriov1"}]' **Pod with calico, OVS and SRIOV (iavf)** .. code-block:: text annotations: robin.io/networks: '[{"ippool": "ovs1"}, {"ippool": "sriov1"}]' **Pod with SRIOV, FPGA and calico** .. code-block:: text annotations: robin.io/networks: '[{"ippool": "sriov1"}]' robin.io/devices: '[{"type": "fpga", "devid": "0x0d90", "vendor": "0x8086", "driver": "igbuio", "count": 1, "name": "random"}]' FPGA without the name key annotations: robin.io/networks: '[{"ippool": "sriov1"}]' robin.io/devices: '[{"type": "fpga", "devid": "0x0d90", "vendor": "0x8086", "driver": "igbuio", "count": 1}]'' **Pod with SRIOV ibg_uio and calico** .. code-block:: text annotations: robin.io/networks: '[{"ippool": "sriovigb"}]' **Pod with only OVS (no calico)** .. code-block:: text annotations: robin.io/default-network: '{"ippool": "ovs1"}' **Pod with OVS and SRIOV(no calico)** .. code-block:: text annotations: robin.io/default-network: '{"ippool": "ovs1"}' robin.io/networks: '[{"ippool": "sriov1"}] **Bonded SRIOV and calico** .. code-block:: text annotations: robin.io/networks: '[{"ippool": "sriov-bond"}]' **Static IP** .. code-block:: text annotations: robin.io/networks: '[{"ippool": "sriov1", "static_ips": ["192.168.96.10-15", "192.168.96.17"]}]' robin.io/networks: '[{"ippool": "sriov121", "static_ips": ["192.168.121.105"]}, {"ippool": "sriov120", "static_ips": ["192.168.120.105"]}]'' **Static IP with policy pool/range** .. code-block:: text annotations: # Use IPs only from the range provided robin.io/networks: '[{"ippool": "sriov1", "static_ip_policy": "range", "static_ips": ["192.168.96.10-15", "192.168.96.17"]}]' annotations: # Use IPs from range provided and if all used, pick any available IP from the IPPool robin.io/networks: '[{"ippool": "sriov1", "static_ip_policy": "ippool", "static_ips": ["192.168.96.10-15", "192.168.96.17"]}] .. Note:: The difference between ``statick_ip_policy: range`` and ``ip-pool``. The ``range`` option is used when IPs should be given only from IPs specified in the annotations. The ``range`` option is the default option. The ``ip-pool`` is used when the IPs in the annotations are exhausted or already used. Pick any available IP from a specified IP pool. Dual Stack Allot Example ^^^^^^^^^^^^^^^^^^^^^^^^ **IP pools used** .. code-block:: text robin ip-pool add sriov7 --ranges fd74:ca9b:3a09:8687:c0:a8:1:65-a4 --prefix 64 --driver sriov --nictags name=enp175s0f0 --ifcount 1 --vlan 20 robin ip-pool add sec-1 --driver secondary --ranges fd74:ca9b:3a09:868b:c0:a8:b:65-a4 --prefix 64 robin ip-pool add sec-2 --driver secondary --ranges fd74:ca9b:3a09:868c:c0:a8:c:65-a4 --prefix 64 robin ip-pool add sec-4 --driver secondary --ranges 192.0.2.25-30 --prefix 24 **Annotation used** .. code-block:: text annotations: robin.io/networks: '[{"ippool": "sriov7"}, {"ippool": "sec-2", "primary": "sriov7"}, {"ippool": "sec-1", "primary": "sriov7"}, {"ippool": "sec-4", "primary": "sriov7"}] **Resulting Interface in the Pod** .. code-block:: text eth1: flags=4163 mtu 1500 inet 192.0.2.25 netmask 255.255.255.0 broadcast 192.0.2.255 inet6 fd74:ca9b:3a09:868c:c0:a8:c:89 prefixlen 64 scopeid 0x0 inet6 fd74:ca9b:3a09:8687:c0:a8:1:6c prefixlen 64 scopeid 0x0 inet6 fd74:ca9b:3a09:868b:c0:a8:b:7c prefixlen 64 scopeid 0x0 inet6 fe80::548f:f6ff:feb8:545 prefixlen 64 scopeid 0x20 ether 56:8f:f6:b8:05:45 txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 ========================== Robin Isolated CNI Plugin ========================== Robin Cloud Native Platform(CNP) provides a new CNI plugin called robin-isolated. You can use the plugin to configure an IP address on the lo interface of a Pod. To use the robin-isolated CNI plugin, you must create an IP pool with driver type **isolated**. **Example:** 1. Create IP pool .. code-block:: text robin ip-pool add isolated-pool --ranges 88.10.20.100-150 --netmask 255.255.255.0 --driver isolated 2. Provide IP pool in network annotation. .. code-block:: text annotations: robin.io/networks: '[{"ippool": "isolated-pool"}]' =========================================== Secondary IP Pool and IP Addressing Support =========================================== Create a primary IP pool (OVS/SR-IOV only. No Calico pool can be used as primary) as shown below: .. code-block:: text robin ip-pool add ovs-1 --ranges 10.9.10.151-200 --netmask 255.255.255.0 --driver ovs Now create multiple secondary IP pools as follows. .. code-block:: text robin ip-pool add sec-1 --ranges 192.168.10.151-200 --netmask 255.255.255.0 --driver secondary robin ip-pool add sec-2 --ranges 192.168.30.151-200 --netmask 255.255.255.0 --driver secondary Lastly create Pod using the appropriate annotations. The example below will configure 3 IP addresses on a single Pod interface i.e :literal:`eth0`. .. code-block:: text annotations: robin.io/networks: '[{"ippool": "ovs-1"}, {"ippool": "sec-1", "primary": "ovs-1"}, {"ippool": "sec-2", "primary": "ovs-1"}]}]' ====================== Custom Interface Names ====================== The custom interface name feature allows users to provide a custom name for a network interface for easy identification. In addition this feature allows users to implement custom interface names inside a Pod based on the requirements of a network function. If you do not provide a custom name for a network interface, Robin uses the default interface naming scheme. **Points to consider:** - You cannot set the interface name to be `eth0` or `lo` as the Pod will remain in ContainerCreating state. - You can set interface name to be `net` if available. .. code-block:: text annotations: robin.io/networks: '[{"ippool": "sriov100", "interface_name": "sr1"}] ========================== Network Annotation options ========================== You can use the following options to customize the interface allocated. The following six options are supported in both in the input_yaml and network annotations: #. ``trust`` #. ``bond_mode`` #. ``mtu`` #. ``nw_type`` #. ``container`` #. ``spoofchk`` .. Note:: The ``trust`` and ``spoofchk`` are L2 options for Virtual Functions. **trust and spoofchk** **Example:** By using input.yaml for Bundles: .. code-block:: yaml By input.yaml for Bundles: 1 appname: "centos-app" 2 ippools: ["robin-default"] 3 media: HDD 4 roles: 5 - name: pktgen 6 ippools: 7 - ippool: sriov103 8 "trust": "on" 9 "spoofchk": "on" 10 - ippool: sriov104 11 "trust": "on" 12 "spoofchk": "on" .. code-block:: yaml By Pod yaml using annotations 12 robin.io/networks: '[{"ippool": "sriov99", "trust": "on", "spoofchk": "on"}]' **Bond_mode** The ``bond_mode`` option is for bond CNI. Robin supports only active-backup mode and it is the default mode. .. code-block:: yaml Anyway it can be specified like below using input.yaml 1 appname: "centos-app" 2 ippools: ["robin-default"] 3 media: HDD 4 roles: 5 - name: pktgen 6 ippools: 7 - ippool: sriov103 8 bond_mode: active-backup By Pod yaml using annotations 12 robin.io/networks: '[{"ippool": "sriov99", "bond_mode": "active-backup"}] **Allocate Device or Interface to a Specific Container in a Pod** When a Pod has multiple containers and if you want to allocate a device or interface to a specific container, you can specify container name in the annotation. .. code-block:: yaml annotations: robin.io/networks: {"ippool": "sriov1", "container": "container1"} robin.io/devices: '[{"container": "container2", type": "fpga", "devid": "0x0d90", "vendor": "0x8086", "driver": "igbuio", "count": 1}] **mtu** The ``mtu`` option is to set the mtu for VF (backend switch port and PF mtu set has to be taken care by net-admin) .. code-block:: yaml With input.yaml 1 appname: "centos-app" 2 ippools: ["robin-default"] 3 media: HDD 4 roles: 5 - name: pktgen 6 ippools: 7 - ippool: sriov103 9 "mtu": "9000" With Pod yaml robin.io/networks: '[{"ippool": "sriov103", "name": "FRONTHAUL", "trust": "on", "spoofchk": "on", "mtu": "9000"}, {"ippool": "sriov104", "name": "FRONTHAUL", "trust": "on", "spoofchk": "on", "mtu": "9000"}]' **name** You can use the parameter ''name'' in the YAML file so that the environment variables related to the interface have a name as a prefix. With input YAML it has to be bundle-net params and with the Pod YAML, that tie-up is not available. .. code-block:: yaml 1 appname: "centos-app" 2 ippools: ["robin-default"] 3 media: HDD 4 roles: 5 - name: pktgen 6 ippools: 7 - ippool: sriov103 8 name: mynet1 With Pod yaml robin.io/networks: '[{"ippool": "sriov103", "name": "FRONTHAUL", "trust": "on", "spoofchk": "on", "mtu": "9000"}, {"ippool": "sriov104", "name": "FRONTHAUL", "trust": "on", "spoofchk": "on", "mtu": "9000"}] =========================================== Kubernetes Annotations for Device Requests =========================================== Similar to multiple interfaces, Robin provides a new annotation for devices to add in Deployments, Pods, Statefulsets, or DaemonSets. The following is the annotation for device requests: .. code-block:: text robin.io/devices: '[{"type": "fpga", "devid": "0x0d90", "vendor": "0x8086", "driver": "vfiopci", "count": 1, "name": "fec"}]’ ============================ Getting CPU IDs Inside a Pod ============================ If you need allocating CPU IDs inside containers requesting guaranteed CPUs, you can access them in the :file:`/robinenv` file. **Example:** .. code-block:: text [root@Pod-l2fwd l2fwd]# cat /robinenv ROBIN_CPUSET=5,6,29,30 ROBIN_CPUSET_ORDERED=5:29,6:30 ROBIN_CPUSET_RANGE=5-6,29-30 ============================================= Environment Variables to use with Annotations ============================================= Robin exposes a set of environment variables prefixed with the phrase "ROBIN" within Pods deployed via YAML files. A subset of the aforementioned variables are displayed below and can be accessed via the ``env`` command from within the Pod. **Example:** .. code-block:: text [root@Pod-pktgen-5-668b9d6d5c-58822 pktgen]# env | grep ROBIN ROBIN_SRIOV5_SUBNET=fd74:ca9b:3a09:8685:0000:0000:0000:0000 ROBIN_NONROBIN_DEFAULT_IP_ADDRESS=fd74:ca9b:3a09:868c:0172:0018:0000:42af ROBIN_NONROBIN_DEFAULT_DRIVER=calico ROBIN_SRIOV5_VFIDS=9,7 ROBIN_SRIOV5_DRIVER=sriov ROBIN_NONROBIN_DEFAULT_NETMASK=ffff:ffff:ffff:ffff:ffff:ffff:ffff:c000 ROBIN_SRIOV5_IP_ADDRESS=fd74:ca9b:3a09:8685:00c0:00a8:0001:006f ROBIN_SRIOV5_PFNAMES=enp175s0f1,enp175s0f0 ROBIN_SRIOV5_PCI_ADDR=0000:af:0b.1,0000:af:02.7 ROBIN_NONROBIN_DEFAULT_SUBNET=fd74:ca9b:3a09:868c:0172:0018:0000:4000 ROBIN_SRIOV5_MTU=1500 ROBIN_SRIOV5_VFDRIVER=iavf ROBIN_MEMORY=209715200 ROBIN_SRIOV5_INTF_NAMES=eth1,eth2 ROBIN_SRIOV5_VLAN=20 ROBIN_SRIOV5_NETMASK=ffff:ffff:ffff:ffff:0000:0000:0000:0000 ========================================== Change in CPU Reservation in Robin Bundles ========================================== Starting with Robin v5.3.5, if you need dedicated CPUs, you need to mention the reserve CPU=true or false in your bundle. If you set: - reserve = true, Robin provides a reserved CPU - reserve = false, Robin provides a shared CPU **Example** .. code-block:: text compute: memory: 1G hugepages_1gi: 3G cpu: reserve: true cores: 5 .. note:: With Robin supporting the Topology Manager, the CPU pools feature in Robin bundles is deprecated. So, the isol key inside the cpu section in the manifest is also deprecated. The following are deprecated: - Isolated shared - Isolated dedicated - Non-isolated