2. Installing Robin CNP Using GoRobin

Robin.io provides the GoRobin utility for quick and simple installation of Robin CNP. The utility simplifies the install, uninstall, and upgrade procedures.

The GoRobin utility performs all the pre-install checks, copies the required installation files to all nodes, and runs the post-installation checks automatically.

You can install Robin CNP in the following two modes:

  • High availability (HA) - This mode must be utilized for all business requirements.

  • Non-HA

Note

Currently, Robin CNP 5.4.1 can only be installed on non-cloud based setups using the GoRobin utility.

2.1. Supported Operating Systems

The following are the supported operating systems and Kernel versions for installing Robin CNP:

OS Version

Kernel Version

CentOS 7.9

3.10.0-1160.71.1.el7.x86_64 and lower

Red Hat Enterprise Linux 8.3

4.18.0-240.el8.x86_64

Rocky Linux 8.6

4.18.0-372.9.1.el8.x86_64 and lower

You can run the uname -r command to know the kernel version and if required, use the yum update kernel command for CentOS and dnf update kernel command for Rocky Linux and Red Hat Enterprise Linux to update the kernel version. Reboot the nodes after updating the kernel version.

Note

Nodes within a Robin cluster do not need to be homogenous with regard to the OS installed them. This means all nodes with different operating systems can be part of the same Robin cluster and be installed at the same time.

2.2. Prerequisites

The following are the hardware, networking, and license prerequisites:

2.2.1. General Prerequisites

  • Robin CNP installation files, namely the GoRobin utility and the GoRobin tarfile. The aforementioned files will use the following naming convention gorobin_<version> and gorobintar-<version>.tar respectively.

  • Login credentials for hosts on which Robin CNP will be installed.

Note

Contact the Robin Support team or Account Manager for installation files. These installation files cannot be edited in anyway including a renaming of the files.

2.2.2. Hardware and Networking Prerequisites

The following are the hardware and networking prerequisites:

  • All nodes in the cluster must be DNS resolvable for the Internet connectivity among the nodes.

  • A minimum of 16 GB memory for all nodes.

  • A minimum of 8 cores.

  • A minimum of three nodes for HA mode and one node for non-HA mode. Robin recommends at least five nodes when installing Robin CNP in HA mode.

  • Credentials of the nodes (IP addresses, username, and password).

  • A 10G network bandwidth for the interconnect network among hosts.

  • A virtual IP address for HA mode and the IP address must be in the same subnet as that of the hosts on which you are going to install Robin CNP.

  • A VRID of your network. It must be a unique integer per cluster between 1 to 255.

2.2.3. License Proxy (Optional)

If you want to activate the license as part of Robin CNP installation and use License Proxy, you must first set up License Proxy and use its URL as part of the config.json file. For more information, see License Proxy.

2.3. Host Login JSON File

You can use the host login JSON file when installing CNP instead of the --hosts option if the hosts within the Robin cluster have different SSH passwords and port configurations.

Note

If you have different SSH passwords and port configurations for hosts, keep this host JSON file ready before your start the installation steps.

Sample hosts login credentials JSON file.

{
      "hyper6-6.robin.com": {
            "password": "admin12",
            "role": "master",
            "user": "root",
            "port": "22"
      },
      "hyper6-7.robin.com": {
            "password": "admin34",
            "role": "master",
            "user": "root",
            "port": "22"
      },
      "hyper6-8.robin.com": {
            "password": "admin56",
            "role": "master",
            "user": "root",
            "port": "22"
      },
      "hyper6-9.robin.com": {
            "password": "admin78",
            "user": "root",
            "port": "22"
      }
}

2.4. Config JSON File

The Config JSON file enables you to provide the install options. You can use Config JSON file when installing Robin CNP to pass configuration details for hosts. You need to provide the config.json file when installing Robin CNP using --config-json command option.

The following are the sample format of config.json file. .

You can use the following format to include any configuration in the config.json file .

Sample Format

{'<host1>:{<parameter>:< parameter value'},

<host2>:{<parameter>:< parameter value'}}

Sample config.json file

{
 "vm-2-61.robinsystems.com":{
       "robin-install-dir":"/home/custom_robininstall",
       "robin-backup-dir":"/home/custom_robinbackup",
       "robindsdir":"/home/custom_robinds",
       "ip-protocol":"ipv6",
       "disablerepo":"*",
       "enablerepo":"robin-repo",
       "ca-cert-path":"/root/certs/abhi/abhi-inter-ca.crt",
       "ca-key-path":"/root/certs/abhi/abhi-inter-ca.key",
       "update-coredns":"True",
       "topology-manager-policy":"best-effort",
       "setup-gpu-operator":"True",
       "nics":"eth1",
       "reserved-cpus":"0-3",
       "loadbalancer-iprange"="<range_of_IPs>"
 },
 "vm-2-62.robinsystems.com":{
       "robin-install-dir":"/home/custom_robininstall",
       "robin-backup-dir":"/home/custom_robinbackup",
       "robindsdir":"/home/custom_robinds",
       "ip-protocol":"ipv6",
       "disablerepo":"*",
       "enablerepo":"robin-repo",
       "nics":"eth1",
       "reserved-cpus":"0-3"
 },
 "vm-2-63.robinsystems.com":{
       "robin-install-dir":"/home/custom_robininstall",
       "robin-backup-dir":"/home/custom_robinbackup",
       "robindsdir":"/home/custom_robinds",
       "ip-protocol":"ipv6",
       "disablerepo":"*",
       "enablerepo":"robin-repo",
       "reserved-cpus":"0-3"
 },
 "vm-2-64.robinsystems.com":{
       "robin-install-dir":"/home/custom_robininstall",
       "robin-backup-dir":"/home/custom_robinbackup",
       "robindsdir":"/home/custom_robinds",
       "ip-protocol":"ipv6",
       "disablerepo":"*",
       "enablerepo":"robin-repo",
       "nics":"eth1",
       "reserved-cpus":"0-3"
 }
 }

Important:

You must provide the following parameters only using the config.json file instead of using the respective options currently present on the commandline:

  • ca-key-path - Provide only in the first node

  • ca-cert-path - Provide only in the first node

  • update-coredns - Provide only in the first node

  • topology-manager-policy - Provide only in the first node. Valid values= none, best-effort, restricted or single-numa-node

2.5. Installing Robin CNP in an On-Premises Setup

2.5.1. Step 1 - Pre-installation Checks

The GoRobin utility takes care of the pre-install checks. However, it is recommended that you manually check the following before installing:

  • All required prerequisites are met. For more information, see Prerequisites.

  • Disable the network firewall if it is enabled.

  • Disable SELinux only during installation.

  • Network Time Protocol (NTP) Server is up and running.

  • Disable Swap on your hosts.

  • The root user needs to be present in the sudoers file located at /etc/sudoers.

  • Remove conflicting packages such as, podman and buildah packages on CentOS 8 hosts.

    Note

    The CNP Installer might prompt you to remove more conflicting packages during installation. You must rerun the installation after removing the conflicting packages.

  • When installing Robin CNP on Rocky Linux host systems, if runc package is installed, you must uninstall it before installing Robin CNP.

  • If the directory /var/lib/docker is present, it must be on an XFS filesystem.

  • The locations /, /var, and /var/crash should be on separate partitions.

  • Robin supports GPU allocations only via the NVIDIA GPU operator that works on CentOS Kernel version 3.10.0-1160 and above.

  • Automatic detection of isolated CPUs only occurs when the respective hosts have been configured to have isolated cores via tuned and/or tuna settings. The cores which are not part of this isolated set will be set as the reserved CPUs for Kubelet. If the isolated cores are configured in an alternative manner they will have to be passed to the installer explicitly. If isolated CPUs are not configured, you can configure using config.json parameter. Example: "reserved-cpus": "0-3".

2.5.2. Step 2 - Prepare hosts and Config JSON files (Optional)

When installing Robin CNP, optionally, you can use the hosts.json file instead of the --hosts option and the config.json file to provide all required installation options instead of providing each option individually as part of the install command.

  • Prepare your hosts JSON file if you have non-homogenous SSH password and port configurations. For more information, see JSON File.

  • Prepare Config JSON file for passing configuration options. For more information, see Config JSON File.

2.5.3. Step 3 - Storage Configuration

You need to create the following storage before installing Robin CNP for automatic storage configuration.

  1. Create /var directory of size 60 GB.

  2. Create /home directory of size 240 GB.

The Robin installer uses the folders and creates the required subfolders.

Note

If you prefer to manually configure storage, create separate volumes as per the following requirements:

/var/lib/docker

Directory in which the Docker images and metadata will be stored. Minimum 50 GB in size, but can be sized according to the application spread.

/home/robinds

Directory in which Robin config and Consul data will be stored. Minimum 20 GB in size.

/home/robinds/var/log

Directory in which all the Robin log files will be stored. Minimum 60 GB in size. Robin log files are capped at ~55G on master nodes and 30G on worker nodes.

/ home/robinds/var/crash

Directory in which Robin core dump files will be stored. Minimum 100GB in size. This is sufficient to store data for at least 4 crashes.

/home /robinds/var/lib/pgsql

Directory in which the Robin database will be stored. Minimum 80GB in size. Needs to have sufficient space to hold the contents of the database, as well as a backup to support failover.

Note

Robin CNP discovers and initializes only the unpartitioned drives for Pod deployments. You should not tag or label these drives.

2.5.4. Step 4 - Download GoRobin Utility and Robin CNP Software

To download Robin CNP installation files, you should contact the Robin Support Team or your Robin Account Manager.

2.5.5. Step 5 - Installing Robin CNP in HA Mode

Before installing Robin CNP, your cluster nodes must meet all the listed prerequisites and pre-install checks are complete.

  • Install Options for VLAN Support

    The following options you can use for VLAN support with possible physical interface configurations in the config.json file. For example, "nics":"eth1:9:untagged". For more information, see VLAN-based installation.

    • Interface without VLANs: --nics=<nic>:<vlanNo>:untagged

    • Interface with an IP Address and VLAN: --nics=<nic>:<vlanNo>:untagged.

    • Interface with only VLANs: --nics=<nic>:<vlanNo>.

  • Custom root CA certificate and key

    To use custom root CA certificate and key, specify the following key pair values in the config.json file for one of the master nodes. For more information, see Custom root CA certificate and key.

    • "ca-cert-path": "<path_to_CA_certificate>"

    • "ca-key-path" : "<path_to_key>"

  • Best-Effort Quality of Service (QoS)

    To enable the Best-Effort QoS feature, specify the following key pair value in the config.json file for one of the master nodes. For more information, see Best-Effort QoS.

    • “best-effort-qos": "True"

  • custom name for Robin default Calico IP-Pool

    To use the custom name for Robin default Calico IP-Pool, specify the following key pair value in the config.json file for one of the master nodes:

    • “robin-default-ippool-name": "<custom_name>"

    Note

    If you do not specify the custom name, Robin CNP uses the robin-default name for the Robin default Calico IP-Pool.

To install Robin CNP in an on-premises environment, run the following command:

# ./gorobin_<version> onprem install-ha --hosts <hostnames> --gorobintar <path-to-gorobin-tarball> --pemfile <pemfile-path> --vip <virtual-ip> --vrid <virtual-router-id>

Note

These are the required parameters for HA installation --hosts, --gorobintar, --vip, --vrid along with the positional arguments. In addition, you can also optionally use the hosts and config JSON file. For more information, see Host Login JSON File and Config JSON File.

The following are the important parameters for installing Robin CNP in the HA mode:

--hosts

A comma-separated list of fully qualified hostnames to deploy Robin software.

--hosts-json

Path to JSON file containing hosts. JSON file format.

{<host>:{"user":<root>,"password":<pem_path or sshpassword>,"port":<22>} ,..}

Note

You must provide one of these two options: --hosts or --hosts-json.

--dir DIR

Directory to extract installation files to, at least 10 GB required.Default is /tmp

--gorobintar

Path to GoRobin tarball containing installation files.

--vip

Virtual IP address of the Kubernetes control plane (must be an IP address).

--vrid

Cluster-unique virtual router ID used by Keepalived (must be an integer from 1 to 255)

--ignore-warnings

Ignore precheck warnings and go forward with the installation.

--config-json

Path to JSON file containing extra configuration parameters for each host.

Format:

{'<host1>:{<parameter>:< parameter value'},

  <host2>:{<parameter>:< parameter value'}}

--license-id

License ID, obtained from get.robin.io, to activate cluster with.

--pemfile

Hosts PEM Key File

Important:

You must provide the following parameters only using the config.json file.

  • --ca-key-path

  • --ca-cert-path

  • --update-coredns

  • --topology-manager-policy

Note

If your setup has GPUs and does not get detected during installation, run this command: robin host probe <hostname> --rediscover.

Example

# ./gorobin_5.4.1-35 onprem install-ha --hosts 192.0.2.61,192.0.2.62,192.0.2.63 --gorobintar gorobintar-5.4.1-35.tar --ignore-warnings --vrid 218 --vip 192.0.2.202
Please Enter the sshpassword for hosts in your Robin cluster. GoRobin will use this sshpassword to access all hosts in your cluster
Password:
- Checking network connectivity to host vm-2-61.robinsystems.com ... DONE (0 secs)
- Checking network connectivity to host vm-2-62.robinsystems.com ... DONE (0 secs)
- Checking network connectivity to host vm-2-63.robinsystems.com ... DONE (0 secs)
- Running GoRobin Precheck on host vm-2-61.robinsystems.com ... DONE (0 s ecs)
- Running GoRobin Precheck on host vm-2-62.robinsystems.com ... DONE (0 s ecs)
- Running GoRobin Precheck on host vm-2-63.robinsystems.com ... DONE (0 s ecs)
This step will remove any existing Robin tars and re-copy new Robin tars from /root/ folder on all nodes. Are you sure you want to proceed (y/n) ? y
- Removing ROBIN tarball from '3' node(s) in the cluster ... DONE (0 secs)
-
Copying ROBIN tarball to '3' node(s) at /root/ in the cluster ... File upload to DONE (636 secs)all hosts: 100% -- (8151232149|8151232149)
- Running Precheck on host vm-2-61.robinsystems.com ... WARNING (20 secs)
  - Precheck on this host had warnings. Please check /root//vm-2-61.robinsystems.com_precheck_20220829-085140 for details.
- Running Precheck on host vm-2-62.robinsystems.com ... WARNING (21 secs)
  - Precheck on this host had warnings. Please check /root//vm-2-62.robinsystems.com_precheck_20220829-085201 for details.
- Running Precheck on host vm-2-63.robinsystems.com ... WARNING (20 secs)
  - Precheck on this host had warnings. Please check /root//vm-2-63.robinsystems.com_precheck_20220829-085222 for details.
- Executing hostname ping checks for all nodes in the cluster ... DONE (0 secs)
- Checking time drift between all the nodes ... DONE (0 secs)
- Installing host packages on '3' node(s) in the cluster. You may check /var/log/robin-host-script.log on each host to track progress ... DONE (512 secs)
- Configuring 'vm-2-61' as Master Node of cluster. You may check /var/log/robin-k8s-script.log on vm-2-61.robinsystems.com ... DONE (84 secs)
- Copying kubeconfig file to all nodes ... DONE (6 secs)
- Adding '2' additional master node(s) 'vm-2-62.robinsystems.com, vm-2-63.robinsystems.com' to cluster. You may check /var/log/robin-k8s-script.log on the host. ... DONE (120 secs)
- Configuring additional Kubernetes plugins. You may check /root/robin-k8splus-script.log on vm-2-61.robinsystems.com ... DONE (6 secs)
- Installing Robin on cluster. You may check /root/robin-script.log on vm-2-61 ... DONE (361 secs)
- Validating Installation ... DONE (0 secs)
- Initializing Compute and Storage services on 3 node(s) ... DONE (55 secs)

-----------------------------------------------------------------
 Cluster with 3 node(s) is ready for use
   1. vm-2-61.robinsystems.com
   2. vm-2-62.robinsystems.com
   3. vm-2-63.robinsystems.com
Robin Cluster Name ..... cluster-Bp1254
Robin Admin Username ... admin
Robin Admin Password ... admin1
Robin Admin Access ..... https://192.0.2.202


Note: Since a license was not provided at runtime, the cluster is not fully activated.

-----------------------------------------------------------------
ROBIN was installed on the following hosts which had precheck warnings: vm-2-61.robinsystems.com, vm-2-62.robinsystems.com, vm-2-63.robinsystems.com. This is due to the '--ignore-warnings' flag being passed during the installation. This might lead to erroneous behavior and hence an unsupported installation.
- Removing ROBIN tarball from '3' node(s) at /root/ in the cluster ... DONE (0 secs)
- Pulling ROBIN Install logs from '3' node(s) at /root/ ... DONE (0 secs)

2.5.6. Step 6 - Verify Installation

You can log in to Robin CNP and verify installation by running the following commands:

# robin login admin --password Robin123
User robin is logged in

# robin host list
Id           | Hostname                        | Version  | Status | RPool   | Avail. Zone | LastOpr | Roles | Cores  | GPUs  | Mem         | HDD(#/Alloc/Total) | SSD(#/Alloc/Total) | Pod Usage | Joined Time
-------------+---------------------------------+----------+--------+---------+-------------+---------+-------+--------+-------+-------------+--------------------+--------------------+-----------+----------------------
1665460022:1 | vm-2-61.robinsystems.com        | 5.4.1-35 | Ready  | default | N/A         | ONLINE  | C,S   | 7/5/12 | 0/0/0 | 20G/10G/31G | 2/-/200G           | -/-/-              | 75/25/100 | 10 Oct 2022 13:48:58

* Note: all values indicated above in the format XX/XX/XX represent the Free/Allocated/Total values of the respective resource unless otherwise specified. In addition allocated values for compute resource such as cpu, memory and pod usage includes reserved values for the corresponding resource.

2.6. Installing Robin CNP in non-HA Mode

You can install Robin CNP in a non-HA mode using the GoRobin utility.

All the prerequisites applicable for HA mode installation are also applicable for non-HA mode.

To install Robin CNP in a non-HA mode, run the following command:

# ./gorobin_<version> onprem install-nonha --hosts <hostnames> --gorobintar <path-to-gorobin-tarball>

Example

# ./gorobin_5.4.1-23 onprem install-nonha --hosts 192.0.2.61 --gorobintar gorobintar-5.4.1-23-bin.tar --ignore-warnings
Please Enter the sshpassword for hosts in your Robin cluster. GoRobin will use this sshpassword to access all hosts in your cluster
Password:
- Checking network connectivity to host vm-2-61.robinsystems.com ... DONE (0 secs)
- Running GoRobin Precheck on host vm-2-61.robinsystems.com ... DONE (0 secs)
This step will remove any existing Robin tars and re-copy new Robin tars from /root/ folder on all nodes. Are you sure you want to proceed (y/n) ? n
- Running Precheck on host vm-2-61.robinsystems.com ... WARNING (23 secs)
  - Precheck on this host had warnings. Please check /root//vm-2-61.robinsystems.com_precheck_20221010-124813 for details.
- Executing hostname ping checks for all nodes in the cluster ... DONE (0 secs)
- Checking time drift between all the nodes  ... DONE (0 secs)
- Installing host packages on '1' node(s) in the cluster. You may check /var/log/robin-host-script.log on each host to track progress ... DONE (571 secs)
- Configuring 'vm-2-61' as Master Node of cluster. You may check /var/log/robin-k8s-script.log on vm-2-61.robinsystems.com ... DONE (80 secs)
- Copying kubeconfig file to all nodes ... DONE (2 secs)
- Configuring additional Kubernetes plugins. You may check /root/robin-k8splus-script.log on vm-2-61.robinsystems.com ... DONE (6 secs)
- Installing Robin on cluster. You may check /root/robin-script.log on hypervvm-61-61 ... DONE (243 secs)
- Validating Installation ... DONE (0 secs)
- Initializing Compute and Storage services on 1 node(s) ... DONE (40 secs)

-----------------------------------------------------------------
Cluster with 1 node(s) is ready for use
  1. vm-2-61.robinsystems.com
Robin Cluster Name ..... cluster-q54g
Robin Admin Username ... admin
Robin Admin Password ... admin2
Robin Admin Access ..... https://vm-2-61.robinsystems.com


Note: Since a license was not provided at runtime, the cluster is not fully activated.

-----------------------------------------------------------------
ROBIN was installed on the following hosts which had precheck warnings: vm-2-61.robinsystems.com. This is due to the '--ignore-warnings' flag being passed during the installation. This might lead to erroneous behavior and hence an unsupported installation.
- Removing ROBIN tarball from '1' node(s) at /root/ in the cluster ... DONE (0 secs)
- Pulling ROBIN Install logs from '1' node(s) at /root/ ... DONE (0 secs)

2.7. Post Installation Steps

  1. License Activation.

2.8. Uninstalling Robin CNP

You can uninstall Robin CNP using the GoRobin utility when required.

Prerequisite:

  • You must delete and clean up all Pods (including file collection and metrics) and mounts before uninstalling Robin CNP.

To uninstall Robin CNP, run the following command:

./gorobin_<version> onprem teardown --hosts <host-names> --gorobintar <path-to-gorobin-tarball>

--hosts

Comma-separated list of fully qualified hostnames to remove ROBIN software from.

--tar-url

URL for GoRobin tarball file.

--gorobintar

Path to the GoROBIN tarball containing installation files.

2.9. VLAN-based installation

VLANs allow a user to logically group a set of devices in the same L2 domain irrespective of how they are physically connected. Consequently this provides a variety of benefits from a networking prespective including isolation, security and flexibility. More details on VLANs can be found here.

A Robin cluster can be configured during the installation process so that VLAN support is natively enabled. This is done by providing the --nics option to installer. Here’s a list of all possible types of physical interface configurations and the corresponding options that need to be passed:

You can configure VLAN support on the Robin cluster during installation by using the --nics option.

The following options you can use for VLAN support with possible physical interface configurations in the config.json file. For example, "nics":"eth1:9:untagged"

  • Interface without VLANs: --nics=<nic>:<vlanNo>:untagged

    Note

    The VLAN number specified here should be based on what is configured on the upstream switch.

  • Interface with an IP Address and VLAN: --nics=<nic>:<vlanNo>:untagged.

    Note

    Use this option for the interface without a VLAN configured. Its counterparts tagged with the VLANs will be automatically detected and registered.

  • Interface with only VLANs: --nics=<nic>:<vlanNo>.

    Note

    In this scenario, all traffic leaving the interface is tagged with a VLAN number. Here the untagged option need not be specified, as the upstream switch expects only tagged traffic.

2.10. Custom root CA certificate and key

Robin allows you to use a custom root certificate authority (CA) certificate and key when installing a Robin CNP cluster. A digital certificate is an electronic file that proves the authenticity of a device, server, or user. Digital certificate authentication helps organizations to ensure that only trusted devices and users can connect to their networks. It also provides assurance to the client applications that they are connecting to the right server.

A certificate authority (CA) is an entity that stores, signs, and issues digital certificates. When a CA signs a certificate, it certifies the ownership of the domain name specified in the subject of the certificate.

The following are the types of certificates:

  • Root CA Certificate: A Root CA certificate forms the basis for a trust chain. The root CA certificates issued by private trusted CAs or commercial entities that sell certificates are considered trustworthy. When the root CA certificate is trustworthy, any certificate signed and issued by it is also trustworthy.

  • Intermediate Root CA Certificate: Intermediate root CA certificates have the same signing capabilities as root CA certificates with a limited scope. The intermediate root CA certificates are not self-signed, however, they are signed by the root CA certificate or another intermediate root CA certificate. There can be multiple intermediate root CA certificates in a trust chain.

  • Domain Certificate: A domain certificate is issued for a specific domain that needs validation. The following are the types of domain certificates:

    • Server certificate: When a client application sends a request to a server, the server returns its domain certificate. If the certificate’s subject does not match the domain name in the URL, the request is rejected.

    • Node certificate: A node certificate is the same as a domain certificate for a server, except that its domain is a physical or virtual host. All valid hostnames and IP addresses that map to the node are included in the certificate as alternative names. Binding the certificate to the node rather than to the domain name allows all services running on the node to use the same certificate for authentication.

  • User Certificate: A user certificate is used to validate the identity of a user. When a user sends a request to a server, a copy of its user certificate also gets passed in. If the certificate is validated, then the request will be handled, otherwise, the request is rejected.

Robin uses certificates to secure access to API endpoints and the Robin UI. When you install the first master node of a Robin cluster, Robin generates a self-signed root CA certificate and private key. Robin uses the root CA certificate’s private key to sign all other certificates issued by the cluster, such as node certificates for every node and user certificates.

2.10.1. How CA certificate works

When a client application sends a request to the Robin API, it is presented with the node certificate where the service is running. The node certificate contains alternative names that include the hostnames and IP addresses of the nodes. If the hostname or IP address mentioned in the URL does not match the details available in the alternative names of the node certificate, the certificate is deemed untrustworthy, and the request is rejected.

A client application also rejects the node certificate if it is not signed by a certificate stored in the client’s Trusted Root CA Certificate store. It can be the case for any certificate signed by the root CA of the Robin CNP cluster.

You have the following three options to avoid the rejection of the node certificate:

  • Configure the client in such a way that the client does not perform a validation check on the certificate. For example, ignore certificate validation errors.

  • Add the cluster’s root CA certificate to the client’s Trusted Root CA Certificate store.

  • Provide an intermediate root CA certificate signed by a known and trusted CA when installing the first master node of the Robin CNP cluster.

Note

Robin recommends the third option when installing a Robin CNP cluster in the production environment.

2.10.2. Custom root CA certificate and key

Robin allows you to use a custom root CA certificate and key when installing a Robin CNP cluster. You can obtain the custom root CA certificate and key from an external trusted CA or from a private trusted CA (public key infrastructure service).

After obtaining the root CA certificate, make sure that it is configured as an intermediate root CA certificate. The intermediate root CA certificate is used as a signing certificate to sign other certificates issued by the cluster.

Note

The intermediate root CA certificate must have a pathlen greater than or equal to the number of intermediate CA certificates in the chain of certificates used to authenticate an entity, including itself. For example, if the signing certificate is a root CA certificate, then the intermediate root CA certificate must have at least one pathlen.

When installing Robin CNP, you need to specify the following key pair values in the config.json file for one of the master nodes:

  • "ca-cert-path": "<path_to_CA_certificate>"

  • "ca-key-path" : "<path_to_key>"

Note

Make sure that the custom root CA certificate and key must be present on the node where Robin CNP installation will be initiated.

2.11. Best-Effort Quality of Service for isolated CPU setups

To increase the performance of the applications, you can assign the isolated CPU cores to the application Pods. Robin allows you to reserve and allocate the isolated CPU cores to the application Pods. When you deploy the application Pods using the isolated CPU cores, the performance of your application is increased.

In isolated CPU setups, the non-application Pods or the control plane Pods use some isolated CPU cores along with non-isolated CPU cores. When these Pods use the isolated CPU cores, the purpose of using the isolated CPU cores in the isolated CPU setups is not achieved. When you enable the Best-Effort Quality of Service (QoS) feature, all isolated CPU cores are available for applications.

2.11.1. How it works

You can stop the non-application Pods or the control plane Pods from using the isolated CPU cores. To stop these Pods from using the isolated CPU cores, you must enable the Best-Effort QoS feature. Once you enable this feature, the CPU requests for these Pods are automatically set to zero.

After setting the CPU requests for the non-application Pods to zero, these Pods do not use the isolated CPU cores and all isolated CPU cores are available for the application Pods.

To enable the Best-Effort QoS feature, you must specify the following key pair value in the config.json file for one of the master nodes:

  • “best-effort-qos": "True"

2.11.2. Points to consider for the Best-Effort QoS feature

  • You can enable this feature during the Robin CNP installation only.

  • You cannot enable or disable this feature post-installation because this is a non-configurable feature.

  • You cannot use this feature after upgrading to Robin CNP v5.4.1 from Robin CNP v5.3.X

2.12. Load Balancer Support via MetalLB

Robin utilizes the layer 2 mode of MetalLB to provide support for network load balancing on bare metal clusters. It allows users to deploy and effectively use Kubernetes services of type LoadBalancer in a production bare metal environment. The IP range specified for the load balancer is separate from Robin IP Pool ranges and must be in the expanded format (eg: 192.0.2.20-192.0.2.30).

Note

You can set up MetalLB during the Robin CNP installation by specifying the IP address range in the loadbalancer-iprange parameter in the config.json for one of the master nodes.

However, You can set up MetalLB post Robin CNP installation using the setup script. You can also remove it from an existing Robin Cluster using the cleanup script.

2.12.1. Setup MetalLB Post Robin Installation

You can set up MetalLB post Robin CNP installation.

Perform the following steps to set up MetalLB post Robin CNP installation:

  1. Run the following command to extract the GoRobin tar file:

    # tar -xvf <gorobintar_file>

  2. Run the following command to change your current working directory to gorobintar:

    # cd gorobintar

  3. Run the following command to set up MetalLB:

    # ./k8splus-script.sh setup-metallb --loadbalancer-iprange=<range_of_ips>

    Example:

    # ./k8splus-script.sh setup-metallb --loadbalancer-iprange=192.0.2.20-192.0.2.30
                    Robin K8s Plugins Setup-metallb
Extracting Payload                                : DONE
Setting up Metallb                                : DONE
Successfully setup Metallb

# kubectl get pods -n metallb-system
NAME                          READY   STATUS    RESTARTS   AGE
controller-6f47b9bf54-t2qrj   1/1     Running   0          4d
speaker-kvmpg                 1/1     Running   0          4d

2.12.2. Cleanup MetalLB

If MetalLB is set up on your Robin cluster, you can remove it.

Run the following command to remove MetalLB from the Robin cluster:

# cd gorobintar
# ./k8splus-script.sh cleanup-metallb

Example:

# cd gorobintar
# ./k8splus-script.sh cleanup-metallb
                  Robin K8s Plugins Cleanup-metallb
Are you sure you want to cleanup metallb configuration [y/n] ?: y
Extracting Payload                                : DONE
Cleaning up Metallb                               : DONE
Successfully cleaned up Metallb

2.13. High availability of Robin services

Robin manages the high availability of all management services that are deployed as part of a Robin installation. Robin pods are deployed as part of a daemonset. Some pods are designated to run master services. Robin configures 3 of these pods as manager pods which can host these master services.

  • If one of the Kubernetes nodes goes down, Robin seamlessly starts master services on other manager pods.

  • If a pod hosting Robin master services is removed from the Kuberenetes cluster, Robin will automatically designate another pod as manager pod, so that it always has 3 master pods.

2.14. Data Integrity

Checksum is a simple mathematical operation performed on a set of data to generate a fixed-size value that represents the integrity of the data. The generated checksum is often compared with a reference checksum to detect errors or inconsistencies that might have occurred during data transmission, storage, or processing. Robin calculates the checksum of every data block persisted on a storage device and stores it along with the metadata for the data block.