*********************************** 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. 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. Prerequisites ============= The following are the hardware, networking, and license prerequisites: General Prerequisites --------------------- - Robin CNP installation files, namely the GoRobin utility and the GoRobin tarfile. The aforementioned files will use the following naming convention ``gorobin_`` and ``gorobintar-.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. 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. 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 `_. 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.** .. code-block:: json { "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" } } 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** .. code-block:: text {':{:< parameter value'}, :{:< parameter value'}} **Sample config.json file** .. code-block:: json { "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"="" }, "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`` Installing Robin CNP in an On-Premises Setup ============================================ 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".`` 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 `__. 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. | +------------------------+---------------------------------------------+ | / | Directory in which Robin core dump files | | home/robinds/var/crash | will be stored. Minimum 100GB in size. This | | | is sufficient to store data for at least 4 | | | crashes. | +------------------------+---------------------------------------------+ | /home | Directory in which the Robin database will | | /robinds/var/lib/pgsql | 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. 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. 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=::untagged`` - Interface with an IP Address and VLAN: ``--nics=::untagged``. - Interface with only VLANs: ``--nics=:``. * **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": ""`` * ``"ca-key-path" : ""`` * **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": ""`` .. 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: .. code-block:: text # ./gorobin_ onprem install-ha --hosts --gorobintar --pemfile --vip --vrid .. 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. ``{:{"user":,"password":,"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:** .. code-block:: text {':{:< parameter value'}, :{:< 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 --rediscover``. **Example** .. code-block:: text # ./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) Step 6 - Verify Installation ----------------------------- You can log in to Robin CNP and verify installation by running the following commands: .. code-block:: text # 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. 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: .. code-block:: text # ./gorobin_ onprem install-nonha --hosts --gorobintar **Example** .. code-block:: text # ./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) Post Installation Steps ======================= 1. `License Activation `__. 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: .. code-block:: text ./gorobin_ onprem teardown --hosts --gorobintar ================== =================================================================================================== ``--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. ================== =================================================================================================== 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=::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=::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=:``. .. 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. 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. 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. 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": ""`` * ``"ca-key-path" : ""`` .. Note:: Make sure that the custom root CA certificate and key must be present on the node where Robin CNP installation will be initiated. 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. 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"`` 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 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. 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: .. code-block:: text # tar -xvf 2. Run the following command to change your current working directory to gorobintar: .. code-block:: text # cd gorobintar 3. Run the following command to set up MetalLB: .. code-block:: text # ./k8splus-script.sh setup-metallb --loadbalancer-iprange= **Example**: .. code-block:: text # ./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 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: .. code-block:: text # cd gorobintar # ./k8splus-script.sh cleanup-metallb **Example**: .. code-block:: text # 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 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. 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.