3. Setting Up Your Robin Cluster

Before your cluster becomes fully operational, there are additional steps that need to be performed in order to configure Robin correctly.

Note

If your Robin cluster was created by GoROBIN, many of these steps will not apply.

3.1. Robin license activation

After installing Robin software on any platform, whenever you run a command a notice will appear stating that the Robin license is not currently activated. This is an indication that no license has currently been applied to the cluster and thus certain commands will not be usable. In order to utilize the cluster to its full capability a license must be applied to it. Described below are the types of licenses that can be activated in order to enable your cluster to function completely and how to acquire/activate each one.

Note

You must renew your license within 15 days after it expires. If you do not renew it, your cluster is locked after 15 days from the license expiry.

3.1.1. Types of License

Robin offers the following types of license for the Robin CNP:

• Robin Enterprise trial license - This license is an evaluation license with unlimited capacity, 24x7 enterprise support, and a 30-day free trial.

• Robin Express license - This license is a community license, free for a lifetime with limited capacity (only five nodes with five TB of storage within a cluster) and community support.

• Robin Production license - This license is a custom production license for built specifically for customers that have a paid contract with Robin.io.

3.1.2. Activate Robin Enterprise trial license

The Robin Enterprise trial license is an evaluation license that offers unlimited capacity, 24x7 enterprise support, and a 30-day free trial. It allows full access to all the features of the Robin platform and enables users to experience the product fully.

After the successful installation of a Robin cluster, the Robin Enterprise trial license can be activated in the following two ways:

• Using an auto-generated User ID

• Using a license key

3.1.2.1. Method 1: Using a User ID

Complete the following steps to activate the Robin Enterprise trial license using a User ID:

1. Sign into the get.robin.io website by following the appropriate instructions.

2. After logging in, hover over the user icon in the upper righthand corner and copy the displayed User ID.

3. Login to your Robin CNP cluster and run the robin license activate command with copied User ID as shown in the example below:

# robin license activate --userid 3D87AHGE
License has been applied successfully

3.1.2.2. Method 2: Using a License Key

The Robin Enterprise trial license can also be activated using a license key. In order to generate a license key on get.robin.io the cluster license ID must be provided. The complete steps are outlined below:

1. Login to your Robin CNP cluster and save the output of the following command:

   # robin license id
   

2. Sign into the get.robin.io website by following the appropriate instructions.

3. After logging in, click the ACTIVATE tab and navigate to the Activate entering your license ID section.

4. In the ROBIN LICENSE ID field, enter the license ID from step 1 and select Robin Enterprise trial for the license type.

5. Click Activate in order to generate a license key and copy it.

6. Login to your Robin CNP cluster and run the robin license apply command with copied license key as shown in the example below:

# robin license apply lg48ugNqMOnHTelEE7KrnaY1IlGFeFlowPkXt6MQkoK3zJ4ULZvNZEKsq34gS5x6B7CrCEPP8t78xkya2xfj6XlVWHGo5/zFt6gEKGeugHef0r3RbJC4zMuGdiucREHMCbAFyZ/dYHGPSnod2I8pG5/adxdOtEFUwReYBIPgNBJ3Sh7WCt8d3xW/jLPVUUPfyqToAv2m6C8SZwlI1QDhp0/NQD8cJ5CJoI4bCJpOM6pNgfbMhY9nTjORLNERujdrYhrWojs/kasySwH4uOnIFzF9GVLD/HgYR8viZOrUs1yq72V0MP7CLAsxtjnMiNeIKxgnXSrHzJIgLZvqEm80Q5ZImTREtJU53KHv5xJ7EvflFzWa8JBzXhrOXywuI/CJpbFCPA+s7BbWEneG/7aw0M6zxFR6s7ItYAmXryEW3cXnyM19o5oHswrHY9WX/67sMXBmdhzUa/zVugJmDUSvtuKV6X8aXpp/hPFzMOTzkOfk/4/ACMNZB2wWPl9Wg9hyFfx1+JitUeKhuUmqMt7grLrCY2SP9wHAUXOwPUnrpmk88sJHWDpBKeVrSApaTHuH5lJFIMw7iatxQT7nw8hsJ5sz4sRoq0iyV/EFA1k+UjVyvP+oLRgUJur6VqalpoEo0oTlJ4pZX1g7iM5dhLn5lLn7RMpzylqs2/Lo2j8dQexE7kbFV34vSlL0/oqg6YjsjpC1SVd/L3X72PXydBM9eCv6P82Zj8nARVEMq0yGGUTkjPervGcNg0VAFyeL1mA3K0KeduzRKuM5cyixrfB3M7BdxJyJ3Ob0YHoHwKzGRCY0w9yhtUhR/mGMklXomjgjFdc+L92qi2QA/fZz4qbhSFTUxY/fzOdPZKZvEXYXR9oSOAOqDjfuOk8GPDAE2H6RDN5AJk3nn3ViNI8JGW3Tf+dLiFWHxfieIVMlpT45Fy5/24K1QfoSv4HQ/p5qaOdq8Ygw5kXmoQw8fujXdqRA8dnIEcxk9fgXoAVOjSSGe9tllqy1mzMGEpQxMC4REH4qNwQMJDk6TOjEKijwpHHLDvsirJoyx6wm65geBTUxJVjmQrh568fou2BuCJhkKLfKiRd0Pj+yjkDqtCjw21v8yh1H+gkIJIshBrAz3jQJ2O6DV0g3ka/akaVvmBhk8vUxyDFC2d6ixurmdGz44Cz3cDA1JHG3D4iciiErA+K+/Iz1RavVmwp/FGrI2W2QMOSzMRqJKTsq2zoGOYWWEdIIvYRaISAEmsKa4eSHnl5vjlf/4lhTLP/Il12nV1cG3zUXUlMiadEww4//NWhet91LInGr+R1Pjb1yYFPmx2
License has been applied successfully

3.1.3. Activate Robin Express license

The Robin Express license is a free-for-life license that offers a maximum of 5 nodes and a total of 5 TB of storage within a Robin cluster with community support. It allows users to have a small Robin cluster running for an unlimited period of time.

After the successful installation of a Robin cluster, the Robin Express license can be activated using a license key by completing the following steps:

1. Login to your Robin CNP cluster and save the output of the following command:

   # robin license id
   

2. Sign into the get.robin.io website by following the appropriate instructions.

3. After logging in, click the ACTIVATE tab and navigate to the Activate entering your license ID section.

4. In the ROBIN LICENSE ID field, enter the license ID from step 1 and select Robin Express for the license type.

5. Click Activate in order to generate a license key and copy it.

6. Login to your Robin CNP cluster and run the robin license apply command with copied license key as shown in the example below:

# robin license apply lg48ugNqMOnHTelEE7KrnaY1IlGFeFlowPkXt6MQkoK3zJ4ULZvNZEKsq34gS5x6B7CrCEPP8t78xkya2xfj6XlVWHGo5/zFt6gEKGeugHef0r3RbJC4zMuGdiucREHMCbAFyZ/dYHGPSnod2I8pG5/adxdOtEFUwReYBIPgNBJ3Sh7WCt8d3xW/jLPVUUPfyqToAv2m6C8SZwlI1QDhp0/NQD8cJ5CJoI4bCJpOM6pNgfbMhY9nTjORLNERujdrYhrWojs/kasySwH4uOnIFzF9GVLD/HgYR8viZOrUs1yq72V0MP7CLAsxtjnMiNeIKxgnXSrHzJIgLZvqEm80Q5ZImTREtJU53KHv5xJ7EvflFzWa8JBzXhrOXywuI/CJpbFCPA+s7BbWEneG/7aw0M6zxFR6s7ItYAmXryEW3cXnyM19o5oHswrHY9WX/67sMXBmdhzUa/zVugJmDUSvtuKV6X8aXpp/hPFzMOTzkOfk/4/ACMNZB2wWPl9Wg9hyFfx1+JitUeKhuUmqMt7grLrCY2SP9wHAUXOwPUnrpmk88sJHWDpBKeVrSApaTHuH5lJFIMw7iatxQT7nw8hsJ5sz4sRoq0iyV/EFA1k+UjVyvP+oLRgUJur6VqalpoEo0oTlJ4pZX1g7iM5dhLn5lLn7RMpzylqs2/Lo2j8dQexE7kbFV34vSlL0/oqg6YjsjpC1SVd/L3X72PXydBM9eCv6P82Zj8nARVEMq0yGGUTkjPervGcNg0VAFyeL1mA3K0KeduzRKuM5cyixrfB3M7BdxJyJ3Ob0YHoHwKzGRCY0w9yhtUhR/mGMklXomjgjFdc+L92qi2QA/fZz4qbhSFTUxY/fzOdPZKZvEXYXR9oSOAOqDjfuOk8GPDAE2H6RDN5AJk3nn3ViNI8JGW3Tf+dLiFWHxfieIVMlpT45Fy5/24K1QfoSv4HQ/p5qaOdq8Ygw5kXmoQw8fujXdqRA8dnIEcxk9fgXoAVOjSSGe9tllqy1mzMGEpQxMC4REH4qNwQMJDk6TOjEKijwpHHLDvsirJoyx6wm65geBTUxJVjmQrh568fou2BuCJhkKLfKiRd0Pj+yjkDqtCjw21v8yh1H+gkIJIshBrAz3jQJ2O6DV0g3ka/akaVvmBhk8vUxyDFC2d6ixurmdGz44Cz3cDA1JHG3D4iciiErA+K+/Iz1RavVmwp/FGrI2W2QMOSzMRqJKTsq2zoGOYWWEdIIvYRaISAEmsKa4eSHnl5vjlf/4lhTLP/Il12nV1cG3zUXUlMiadEww4//NWhet91LInGr+R1Pjb1yYFPmx2
License has been applied successfully

3.1.4. Activate Robin Production license

When you purchase the production license for Robin CNP from Robin.io, a custom license contract is created based on the sales agreement made. This contract acts a template from which production licenses are generated. It contains the following details:

• Authorized users

• Owners

• Contract end date

• Maximum number of nodes

• Renewal period, and so on.

Each contract is saved on get.robin.io which in turn is where all production licenses are created. Once the production license is generated, it can be activated in the following ways:

• License proxy server - As the name suggests this option entails the usage of a stateful proxy server that contacts the get.robin.io website on behalf of Robin clusters that are otherwise on isolated networks. It can be setup on a low resource machine with Kuberentes installed and can be connected to multiple Robin clusters through the usage of a config variable. It enables the intial license activation of the aforementioned Robin clusters whilst also introducing the possibility of automatic renewal. Details on how to setup the proxy server are given below.

• Manually - A production license can also be applied manually after it is generated on get.robin.io. Details on how to do so are described below. Note the same process can be utilized when the license needs to be renewed.

3.1.4.1. Method 1: Using a License Proxy server

A License Proxy server enables you to automatically activate and renew the licenses of the linked Robin CNP clusters, without any manual intervention.

Points to consider for License Proxy server

• Each License Proxy server can handle multiple Robin CNP clusters but it can associate with only one license contract.

• The License Proxy server is made known to each Robin CNP cluster through the config variables.

• There must be constant connectivity between each respective Robin CNP cluster and the License Proxy server. If there is a drop in connectivity, alerts will be generated on the Robin CNP cluster until the issue is resolved.

• Make sure that there is a constant connectivity between the License Proxy server and the get.robin.io website to activate and renew the licenses of all associated Robin CNP clusters automatically.

• Although It is not mandatory but it is highly recommended that the License Proxy server should deploy on a machine that is not part of any of the Robin CNP clusters to be associated with it.

Prerequisites

• Kubernetes v1.8 or above must be deployed on the machine where the proxy server will be deployed.

• A request must be submitted to the Robin.io Customer Success team for access to the license_proxy.tar and license_deployment.yaml files which contain the image and object spec for the proxy server.

• The contract to be associated with the proxy server must already be created. This can be confirmed with the Robin.io Customer Success team.

Deploy and activate License Proxy server

You can deploy and activate a License Proxy server either before installing Robin CNP or after installing Robin CNP.

The following are the steps to deploy, activate a License Proxy server and link it to the relevant Robin clusters:

1. Create server certificate for License Proxy server:

   ./license-proxy-cert.bin initialize-certs /root/license-proxy-certs --namespace default --ip-addrs 192.2.11.141
   CA cert files created at the following locations: /etc/ssl/license_proxy_ca_ssl.key, /etc/ssl/license_proxy_ca_ssl.crt
   Successfully created file: /root/license-proxy-certs/license-proxy-server.cert
   Successfully created file: /root/license-proxy-certs/license-proxy-server.config
   Successfully created file: /root/license-proxy-certs/license-proxy-server.key
   Successfully created file: /root/license-proxy-certs/license-proxy-server.request
   Successfully created license-proxy-server secret in default
   

2. Create Client certificate and its key:

   ./license-proxy-cert.bin create-client-cert lak-test /root/license-proxy-certs --force
   Client key/cert files created at the following locations: /root/license-proxy-certs/lak-test.key, /root/license-proxy-certs/lak-test.crt
   

3. Using the license_proxy.tar file, load the docker image for the proxy server by running the following command:

   # docker load -i license-proxy.tar
   

4. To deploy the Kubernetes objects needed for the proxy server, including the Pod, PVC etc. run the following command:

   # kubectl apply -f license-deployment.yaml
   

5. Ensure the License Proxy Pod is in a running state by issuing the following command:

   # kubectl describe pod -n default license-proxy
   

6. After confirming the License Proxy is in a healthy state, execute into the main container and fetch the ID associated with it as shown in the example below. This will be used to activate the License Proxy server thus allowing it to serve activation and renewal requests.

   # kubectl exec -ti -n default license-proxy -- robin proxy id
   

7. Sign into the get.robin.io website by following the appropriate instructions.

8. On the Activate page, click the ACTIVATE PROXY tab, and navigate to the Link a proxy to a contract section.

9. Select the contract to associate with the proxy, enter a name to help easily identify the proxy and input the proxy ID from Step 4.

10. To generate a proxy key, click Activate and copy it.

11. Activate the proxy with the generated key:

    # kubectl exec -ti -n default license-proxy -- bash
    # robin proxy activate U7oF1y9WMpPRubRvFRDThbqIrel1TrflAkqsXqrRNmn3l6PH5BMQoNC2CyO1dwQqh8HpdWeAEeY3Wl8a0b6inU6nSEzya7KiTYftcfyryCX1vLEz9Eg20AJNMICOurbrQuENhMYxnAXfDotKhg6yAM8BZ51HpiVZq3P6WyHz00JnlzcPR+DAB4JN9rTkttn64CBApT6tUCpTzCqODfZqk55o3RnXCTMnuC4clRKJw6Ro1obQEpQiOMWTx0IC8RI1m1sik+ANESG4ap6Sn0xN9wFZZGgK6xqlI+GW8Ftr9Z5VFa+cD0L7tuVMSCNQihFV3jVk9KF77Ok7meCT1cbeAY1SHxW/l9ArcT4crieFzIXi1VeU8vjejFpPYO/6znmEPIKjlYgUDQFYojFvJXBoW2uTyNoPZIFgFCq3EWxs9jxM5o9KXCiFGZvDZpBrWJ9FWAUV6E+FeunEAcmPASqKYn2X0RCq5Y7MumgL+3OHdD5BL//koUWl/yS+ioi04IjXt+p/wbpYoqRF4tWgONLJhnvg9xQi/mCqGRhioL4DHuuvWSjCCb9T8F50ZszLTF15qMQMArSRhvAh3N/t3r56DnjBZbgc+ebKsnvlJT5SSE0+lrnfTPhl8tqQMhw3GaNTASjON4PuYVBD=
    Successfully activated Robin Proxy
    

Activate license using License Proxy server

After deploying and activating License Proxy server, you can activate license of a Robin CNP cluster.

Complete the following steps to activate license of a Robin CNP cluster:

1. Login to Robin CNP cluster using your username and password.

2. Update the license_server_url config variable with the License Proxy server URL to link the Robin CNP cluster with the License Proxy server to automatically activate or renew its license:

   # robin config update cluster license_server_url http://192.0.2.55:31123
   The 'cluster' attribute 'license_server_url' has been updated
   

   If you have already specified the License Proxy server URL in the --license-server-url option as part of Robin CNP installation command, follow the step 3.

   Note

   If the standard deployment YAMLs are used for the License Proxy server, the URL through which it can be contacted is: <host_ipaddress>:<svc_node_port>. The default NodePort used is 31123.

3. Copy the following certificates and key from the machine where you have setup License Proxy server to the cluster created during the deploy and activate License Proxy server:

   • CA certificate

   • Client certificate

   • Client key

4. Create certificate group for license proxy server:

   # robin cert-group create license-proxy robin-server /etc/robin/rcm/ssl/license-proxy robin-master "ca.cert:/etc/ssl/license_proxy_ca_ssl.crt,client.cert:/root/license-proxy-certs/lak-test.crt,client.key:/root/license-proxy-certs/lak-test.key"
   {"response":"Cert Group 'license-proxy' created"}
   
   # robin cert-group list
   NAME          | APP          | DIRECTORY                        | PODS         | NUM_FILES | VERSION
   --------------+--------------+----------------------------------+--------------+-----------+---------
   license-proxy | robin-server | /etc/robin/rcm/ssl/license-proxy | robin-server | 3
   

5. Bounce Robin Master Pod. Once Robin master Pod is bounced, License will be activated automatically.

Note

To activate or renew the license of a Robin CNP cluster on demand which is already linked to a License Proxy server, run the robin license renew command inside the Robin master Pod.

Important

Further details on the config variables, namely the license_server_url and license_renew_period attributes, that control the behavior of the License Proxy server from the perspective of the Robin cluster can be found Cluster wide Attributes.

3.1.4.2. Method 2: Apply a Production license manaully

If a license proxy server cannot be setup in the given environment, the Production license can also be generated and applied manually with the use of an authorization token. In order to generate a token on get.robin.io a contract must be available for use by the given user. The complete steps are outlined below:

1. Sign into the get.robin.io website by following the appropriate instructions.

2. After logging in, hover over the user icon in the upper right corner and click the Generate Token link.

3. Within the presented section, select the contract to associate with the token, and enter the number of days the token should be valid for.

4. Click Generate Token in order to generate a token and copy it.

5. Login to your Robin CNP cluster and run the robin license renew command with copied token as shown in the example below:

# robin license renew --token vF6KtruI1mdDhm6ASbAMhMiuhHaR9J/iMUR/FtyMnXbDmkOyZr+Zu4Fb6BdnRLNyPtliHteH/I1+s51h/AWeQ==
License has been renewed successfully

3.2. License management

3.2.1. View License ID

CLI

API

Each Robin cluster has a unique, auto-generated identification number associated with it that enables license keys to be created specifically for the given cluster. In order to view the license ID of a cluster run the following command:

# robin license id --json

--json

Output in JSON

Example:

# robin license id
License Id: YGVkYWBjYGFiZWkhZ00lZk0gX1NcYWkDQDM5P0wENjNHNjNcQzAyOi75QF0ERyRcND0GREU1Q0z8QDQxPWjg.S_

Returns the unique, auto-generated identification number associated with a cluster that enables license keys to be created specifically for the given cluster.

End Point: /api/v3/robin_server/license

Method: GET

URL Parameters:

• id=true : This mandatory parameter specifies that the License ID of the cluster should be returned.

Data Parameters: None

Port: RCM Port (default value is 29442)

Headers:

• Authorization: <auth_token> : 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), 401 (Unauthorized Error), 400 (Invalid API Usage Error)

Example Response:

Output

{
    "license_id": "YGVkZ1BjZlFlX1khZ00lZk0gX1NcYWkDQDM5P0wENjNHNjNcQzAyOi75QF0ERyRcND0GREU1Q0z8\r\nQDQxPWjg.SFoI1kjXWNcYFwiZWk3"
}

3.2.2. View license information

CLI

API

To view additional details about the current applied license, run the following command:

# robin license info --usage

--usage

View cluster usage with regard to license restrictions

Example:

# robin license info

ROBIN License Information:

ID ......................... YGVkYWBjYGFiZWkhZ00lZk0gX1NcYWkDQDM5P0wENjNHNjNcQzAyOi75QF0ERyRcND0GREU1Q0z8\r\nQDQxPWjg.S_
Type ....................... Evaluation
Created on ................. 2022-09-14T10:38:30 UTC
ROBIN Type ................. Platform
Host Type .................. PHYSICAL
Version .................... 5.4.1-4998
K8S Provider ............... ROBIN
Deployment Source .......... Installer
Expires on ................. 2022-10-14T10:38:30 UTC (18 day(s) remaining)
Status ..................... OK

Returns additional details about the license currently applied on a cluster.

End Point: /api/v3/robin_server/license

Method: GET

URL Parameters: None

Data Parameters: None

Port: RCM Port (default value is 29442)

Headers:

• Authorization: <auth_token> : 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), 401 (Unauthorized Error), 400 (Invalid API Usage Error)

Example Response:

Output

{
    "license_info": {
        "license": {
            "sku": "platform",
            "features": {
                "snapshot": true,
                "clone": true,
                "backup": true
            },
            "expireson": "2022-12-11T09:06:15",
            "creator": "Robin",
            "issuedto": {
                "name": "",
                "email": "internal_robin@robin.io"
            },
            "pernode": {
                "disks": 72,
                "storage": 1266637395197952,
                "cpu_cores": 96,
                "containers": 128,
                "memory": 2199023255552
            },
            "percluster": {
                "gpu_cores": 120000,
                "users": 1000,
                "apps": 10000,
                "disks": 360000,
                "storage": 6333186975989760000,
                "snapshots": 2560000,
                "cpu_cores": 480000,
                "memory": 10995116277760000,
                "clones": 10000,
                "nodes": 5000,
                "tenants": 1000,
                "containers": 50000
            },
            "activated": true,
            "createtime": "2022-11-11T09:06:15",
            "version": "5.4.1-46",
            "installkey": "385e43c7-bf16-4768-9b77-0e09ddb7263c",
            "host_type": "physical",
            "k8s_provider": "robin",
            "type": "Evaluation",
            "id": "YGVkZ1BjZlFlX1khZ00lZk0gX1NcYWkDQDM5P0wENjNHNjNcQzAyOi75QF0ERyRcND0GREU1Q0z8\r\nQDQxPWjg.SFoI1kjXWNcYFwiZWk3",
            "deployment_source": "installer",
            "robin_type": "platform",
            "num_days_expire": 12,
            "num_days_lockdown": 27
        },
        "profile": {
            "apps": 0,
            "snapshots": 0,
            "clones": 0,
            "containers": 0,
            "users": 3,
            "tenants": 1,
            "disks": 3,
            "nodes": 3,
            "node_def": {
                "3": {
                    "primary_hostname": "vnode-109-179.robinsystems.com",
                    "disks": 1,
                    "storage": 85899345920,
                    "cpu_cores": 8,
                    "memory": 16655675392
                },
                "1": {
                    "primary_hostname": "vnode-109-177.robinsystems.com",
                    "disks": 1,
                    "storage": 85899345920,
                    "cpu_cores": 8,
                    "memory": 16655675392
                },
                "2": {
                    "primary_hostname": "vnode-109-178.robinsystems.com",
                    "disks": 1,
                    "storage": 85899345920,
                    "cpu_cores": 8,
                    "memory": 16655675392
                }
            },
            "cpu_cores": 24,
            "gpu_cores": 0,
            "memory": 49967026176,
            "storage": 257698037760
        },
        "status": "OK",
        "status_message": "License is in a good state."
    }
}

3.2.3. Activate a license

CLI

API

In order to activate a license and thus allow a cluster to be fully operational, run the following command:

# robin license activate --userid <userid>

--userid <userid>

Custom User ID generated after logging into the get.robin.io website. Note this parameter is mandatory whenn the license_server_url parameter is not set to the URL for a Robin License Proxy server

Example:

# robin license activate --userid 3D87AHGE
License has been applied successfully

Returns a URL which can be used to activate a license in order to allow the cluster to become fully operational.

End Point: /api/v3/robin_server/license

Method: GET

URL Parameters:

• url=activate : This mandatory parameter specifies that the URL for activation should be returned.

• userid=<userid> : Utilizing this parameter results in the URL returned pointing directly to get.robin.io. It is mandatory when the license_server_url parameter is not set to the URL for a Robin License Proxy server.

Data Parameters: None

Port: RCM Port (default value is 29442)

Headers:

• Authorization: <auth_token> : 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), 401 (Unauthorized Error), 400 (Invalid API Usage Error)

Example Response:

Output

3.2.4. Apply a license key

CLI

API

In order to apply a generated license key manually, run the following command:

# robin license apply <license_key> --desc <desc>
                                    --force

license_key	Raw license key to be used or path to file containing license key
--desc <desc>	Description to associate with license being applied
--force	Override inferior license check

Example:

# robin license apply lg48ugNqMOnHTelEE7KrnaY1IlGFeFlowPkXt6MQkoK3zJ4ULZvNZEKsq34gS5x6B7CrCEPP8t78xkya2xfj6XlVWHGo5/zFt6gEKGeugHef0r3RbJC4zMuGdiucREHMCbAFyZ/dYHGPSnod2I8pG5/adxdOtEFUwReYBIPgNBJ3Sh7WCt8d3xW/jLPVUUPfyqToAv2m6C8SZwlI1QDhp0/NQD8cJ5CJoI4bCJpOM6pNgfbMhY9nTjORLNERujdrYhrWojs/kasySwH4uOnIFzF9GVLD/HgYR8viZOrUs1yq72V0MP7CLAsxtjnMiNeIKxgnXSrHzJIgLZvqEm80Q5ZImTREtJU53KHv5xJ7EvflFzWa8JBzXhrOXywuI/CJpbFCPA+s7BbWEneG/7aw0M6zxFR6s7ItYAmXryEW3cXnyM19o5oHswrHY9WX/67sMXBmdhzUa/zVugJmDUSvtuKV6X8aXpp/hPFzMOTzkOfk/4/ACMNZB2wWPl9Wg9hyFfx1+JitUeKhuUmqMt7grLrCY2SP9wHAUXOwPUnrpmk88sJHWDpBKeVrSApaTHuH5lJFIMw7iatxQT7nw8hsJ5sz4sRoq0iyV/EFA1k+UjVyvP+oLRgUJur6VqalpoEo0oTlJ4pZX1g7iM5dhLn5lLn7RMpzylqs2/Lo2j8dQexE7kbFV34vSlL0/oqg6YjsjpC1SVd/L3X72PXydBM9eCv6P82Zj8nARVEMq0yGGUTkjPervGcNg0VAFyeL1mA3K0KeduzRKuM5cyixrfB3M7BdxJyJ3Ob0YHoHwKzGRCY0w9yhtUhR/mGMklXomjgjFdc+L92qi2QA/fZz4qbhSFTUxY/fzOdPZKZvEXYXR9oSOAOqDjfuOk8GPDAE2H6RDN5AJk3nn3ViNI8JGW3Tf+dLiFWHxfieIVMlpT45Fy5/24K1QfoSv4HQ/p5qaOdq8Ygw5kXmoQw8fujXdqRA8dnIEcxk9fgXoAVOjSSGe9tllqy1mzMGEpQxMC4REH4qNwQMJDk6TOjEKijwpHHLDvsirJoyx6wm65geBTUxJVjmQrh568fou2BuCJhkKLfKiRd0Pj+yjkDqtCjw21v8yh1H+gkIJIshBrAz3jQJ2O6DV0g3ka/akaVvmBhk8vUxyDFC2d6ixurmdGz44Cz3cDA1JHG3D4iciiErA+K+/Iz1RavVmwp/FGrI2W2QMOSzMRqJKTsq2zoGOYWWEdIIvYRaISAEmsKa4eSHnl5vjlf/4lhTLP/Il12nV1cG3zUXUlMiadEww4//NWhet91LInGr+R1Pjb1yYFPmx2
License has been applied successfully

Applies a specified license key to the cluster.

End Point: /api/v3/robin_server/license

Method: PUT

URL Parameters: None

Data Parameters:

• license: <license_key> - This mandatory field within the payload specifies the license key to apply.

• desc: <desc> - Utilizing this parameter within the payload, by specifying by specifying a string, results in the description for the applied license being set to the string given.

• force: [true|false] - Utilizing this parameter within the payload, by specifying a boolean value, determines whether or not the inferior license check is overriden.

Port: RCM Port (default value is 29442)

Headers:

• Authorization: <auth_token> : 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), 401 (Unauthorized Error), 400 (Invalid API Usage Error)

Example Response:

Output

3.2.5. Renew a license

CLI

API

In order to renew a license such that its expiration date is extended, run the following command:

# robin license renew --token <token>

--token <token>

Authorization token generated on the get.robin.io website. Note this parameter is mandatory whenn the license_server_url parameter is not set to the URL for a Robin License Proxy server

Example:

# robin license renew
License has been renewed successfully

Returns a URL which can be used to renew a license in order to extend the expiration date for a license.

End Point: /api/v3/robin_server/license

Method: GET

URL Parameters:

• url=renew : This mandatory parameter specifies that the URL for renewal should be returned.

• token=<token> : Utilizing this parameter results in the URL returned utilizing the specified authorization token and its associated contract. It is mandatory when the license_server_url parameter is not set to the URL for a Robin License Proxy server.

Data Parameters: None

Port: RCM Port (default value is 29442)

Headers:

• Authorization: <auth_token> : 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), 401 (Unauthorized Error), 400 (Invalid API Usage Error)

Example Response:

Output

3.3. Resource pool assignment

Resource pools are a construct in Robin which allow you to group nodes in the cluster together for allocation purposes. Pools provide resource isolation. More details on resource pools and commands to manage them can be found here.

Upon installation, a resource pool named default is created. If you wish to create a custom resource pool run this command:

# robin rpool add <name>

Example:

# robin rpool add demo
Added resource pool demo.

In order to add nodes to a resource pool run this command:

# robin host assign-rpool <hostnames> <rpool_name> --wait

Example:

# robin host assign-rpool centos-60-212,centos-60-214 demo --wait
Job: 11  Name: HostAddResourcePoolMulti     State: VALIDATED       Error: 0
Job: 11  Name: HostAddResourcePoolMulti     State: WAITING         Error: 0
Job: 11  Name: HostAddResourcePoolMulti     State: COMPLETED       Error: 0

Note

The default resource pool is not assigned to any nodes upon installation. Thus, if you want to utilize the precreated resource pool you still have to explicitly assign it.

3.4. Role assignment

There are three Robin roles that can be assigned to hosts: Manager, Compute and Storage. Depending on the resources present on a node you can initialize it to have one or more of these roles. This allows for a more granular control over what resources a node can provide for allocation. More details on the specific roles, what they entail, and how to manage them can be found here.

Note

Upon installation, nodes which that installed as masters will have the Manager role already assigned to them.

To add a role, run this command:

# robin host add-role <hostnames> <roles> --wait

Example:

# robin host add-role centos-60-212,centos-60-214 Compute,Storage --wait
Job: 18  Name: HostAddRoles     State: VALIDATED       Error: 0
Job: 18  Name: HostAddRoles     State: WAITING         Error: 0
Job: 18  Name: HostAddRoles     State: COMPLETED       Error: 0

To verify the roles were appropriately added, run this command:

# robin host list
Id           | Hostname                         | Version   | Status | State  | Resource Pool | Roles  | Cores | GPUs | Memory            | HDD(Alloc/Total) | SSD(Alloc/Total) | Instances | Joined Time
-------------+----------------------------------+-----------+--------+--------+---------------+--------+-------+------+-------------------+------------------+------------------+-----------+----------------------
1539379146:1 | centos-60-212.robinsystems.com   | 5.0.5-548 | Ready  | ONLINE | demo          | M*,S,C | 1/6   | 0/0  | 7.76 GB/15.5 GB   | 396 GB/43.66 TB  | 0 GB/111.79 GB   | 0         | 12 Oct 2019 14:19:32
1539379146:2 | centos-60-214.robinsystems.com   | 5.0.5-548 | Ready  | ONLINE | demo          | C,S    | 1/24  | 0/0  | 22.81 GB/94.25 GB | 0 GB/0  B        | 50 GB/894.25 GB  | 0         | 12 Oct 2019 14:27:07

3.5. IP-Pool addition

An IP-Pool is a construct in Robin that groups together a set of IP addresses. Given that these IP addresses are then allocated by Robin during the application creation process, an IP-Pool allows you to have some control over what IP addresses are assigned to application containers. More details on IP-pools and commands to manage them can be found here.

Upon installation, an IP-Pool named default is created. If you wish to create a custom IP-Pool run this command:

# robin ip-pool add <name> --driver=<driver> --ranges <ip_range> --netmask <netmask>

Example:

# robin ip-pool add ovs-p1 --driver=ovs 10.10.1.82-128 255.255.255.0
Registered IP pool ovs-p1.

Note

The subnet for the IP-Pool is required to be present on at least one of the nodes with the compute role.

3.6. File collection addition

A file collection is an NFS like server that is backed by a volume allocated from Robin managed storage. Bundles and images used to create applications will be stored on File Collections, in addition to any logs that are collected. More details on File Collections and commands to manage them can be found here.

3.6.1. Considerations for file collection creation

Here are some factors that should be taken into account when creating a new File Collection:

• The size of the collection. This will vary per use case and will be dependent on the number and size of the images that will be used for application creation.

• The replication factor of the volumes backing the collection. This is vital as it helps ensure the collection is recoverable after failovers.

• The collection type, which can be either log or file. This depends on the use case.

• The resource pool from which to draw storage for the allocated volume.

• The media type for the volume which will provide storage for the collection (either HDD or SSD). This will depend on the cluster.

• File Collections will only be created on Robin nodes with the Manager role.

Moreover additional planning is required to ensure that there is sufficient capacity should a Master node fail. Operators should either:

• Ensure that the replication factor on the File Collection is N-1 where N is the number of Master nodes

• Ensure that there is sufficient space available on the Master nodes to allow the creation of a temporary File Collection should one of the master nodes fail in such a way that

  • The entire server has to be replaced

  • The operating system has to be reinstalled.

Note

The considerations regarding node failures also apply to Robin volumes in a situation where the number of replicas is equal to the number of hard drives available for Storage. For example a situation where they apply is a three node cluster, wherein which there is one hard drive available for storage on each node.

3.6.2. File collection creation

To create a file collection run this command:

# robin collection create <media_type> <rpool_name> --collection_type <type> --replicas <count> --size <size>

Example:

# robin collection create HDD demo --collection_type FILE_COLLECTION --replicas 3 --size 50G
Job:  189 Name: CollectionAdd        State: VALIDATED       Error: 0
Job:  189 Name: CollectionAdd        State: PROCESSED       Error: 0
Job:  189 Name: CollectionAdd        State: WAITING         Error: 0
Job:  189 Name: CollectionAdd        State: FINALIZED       Error: 0
Job:  189 Name: CollectionAdd        State: COMPLETED       Error: 0

3.7. Enabling Metrics

Robin provides metrics collection for both nodes and applications via Prometheus. Statistics such as CPU usage, disk utilization, memory etc. are collected for these entities. Robin uses Prometheus for three main reasons:

• Given its affinity for recording numeric time series, it is an excellent tool for machine-centric monitoring as all the data that is exposed is numeric.

• Prometheus supports multidimensional data collection for microservices making it very easy to leverage for Robin application monitoring.

• Resilience: each Prometheus server can be run completely independent of network storage or remote services.

The data collected is stored on disk in Prometheus’s local time series database. The time series data is stored in a custom format and is retained for a variable number of days. The amount of storage needed for the created PVC is dependent on the retention policy. More details on how the scraped data is stored are available here.

3.7.1. Considerations for setting up metrics

Here are some factors that should be taken into account when enabling metrics collection:

• The retention time period. This will depend on the amount of historical data you wish to keep. The default is 7 days.

• The size of the storage volume. This will be automatically calculated by multiplying the retention period by 1.5Gi but can be overridden. It is important to create a volume large enough to cover the whole retention period.

• The replication factor of the volumes backing the collection. We recommend 3 to ensure the data previously collected is always available even after failure.

• The fault domain for replicas. This will be cluster dependent and can be disk, host, or rack.

• The resource pool from which to draw storage for the allocated volume.

• The media type for the volume that will provide storage for the collection (either HDD or SSD). This will be cluster dependent.

3.7.2. Starting Metrics

Robin brings up the Prometheus server and node exporter alongisde Grafana via Helm. In order to deploy the Prometheus Helm chart, run the following command:

# robin metrics start --media <media_type> --resource-pool <rpool_name> --faultdomain <fault_domain> --replicas <count> --retention-period <period>

Example:

# robin metrics start --media HDD --resource-pool demo --faultdomain disk --replicas 3 --retention-period 2
Job:  192 Name: MetricsStartCollect  State: PREPARED        Error: 0
Job:  192 Name: MetricsStartCollect  State: DONE            Error: 0
Job:  192 Name: MetricsStartCollect  State: AGENT_WAIT      Error: 0
Job:  192 Name: MetricsStartCollect  State: NOTIFIED        Error: 0
Job:  192 Name: MetricsStartCollect  State: COMPLETED       Error: 0

Note

The default username and password needed to access the Grafana dashboard is admin/admin.

3.7.3. Viewing Metrics Status

You can view the status of metrics collection by Robin CNP for Prometheus and Grafana. If you want to view cAdvisor status, you can run the robin metrics cadvisor-status command.

To view the status of metrics collection, run the following command:

# robin metrics status

Example

[root@hypervvm-63-114 ~]# robin metrics status
 Prometheus:
 -- Status........ Running
 -- URL........... http://[fd74:ca9b:3a09:868c:0010:0009:0063:0114]:31266

 Grafana:
 -- Status........ Running
 -- URL........... https://[fd74:ca9b:3a09:868c:0010:0009:0063:0114]:31412

3.7.4. Stopping Metrics

You can stop metrics collection if you do need metrics from Robin CNP. When you stop metric collection, Robin CNP stops metric collection for all parameters. It stops the Prometheus, Grafana, and cAdvisor monitoring systems. If you do not want to disable cAdvisor, you must use the --skip-cadvisor option. And, if you need to delete previously collected data, you can use the --delete option while stopping the metrics collection.

To stop metrics, run the following command:

# robin metrics stop --wait

Example

[root@hypervvm-63-114 ~]# robin metrics stop --wait
Job:  202 Name: MetricsStopCollect   State: PREPARED        Error: 0
Job:  202 Name: MetricsStopCollect   State: COMPLETED       Error: 0

3.7.5. cAdvisor as a DaemonSet

Robin CNP v5.4.3 HF5 contains the cAdvisor as a standalone DaemonSet. By default, cAdvisor (Container Advisor) is enabled when you enable Robin Metrics on your Robin Cluster. However, if you do not want to use Robin Metrics but still need cAdvisor for gathering node-level metrics, you can enable it and manage cAdvisor independently. You can start, stop, and view the status of the cAdvisor services without enabling Robin Metrics. This allows you to view metrics on any observability framework (OBF) of your choice.

Note

When disabling metrics in Robin CNP using the robin metrics stop command, CNP also disables the CAdvisor. If you want to continue to use CAdvisor without using the complete metrics feature, you can use the --skip -cadvisor option with the robin metrics stop command

3.7.5.1. Starting cAdvisor Metrics

You can enable cAdvisor for viewing node-level metrics. You can enable this without enabling Robin Metrics.

Note

You do not need to enable cAdvisor separately if Robin Metrics is already enabled.

To start cAdvisor, run the following command:

# robin metrics start-cadvisor

Example

[root@hypervvm-63-114 ~]#  robin metrics start-cadvisor --wait
Job:  179 Name: MetricsStartCadvisor State: PREPARED        Error: 0
Job:  179 Name: MetricsStartCadvisor State: AGENT_WAIT      Error: 0
Job:  179 Name: MetricsStartCadvisor State: FINALIZED       Error: 0
Job:  179 Name: MetricsStartCadvisor State: COMPLETED       Error: 0

3.7.5.2. Viewing cAdvisor Metrics Status

You can check the status of the cAdvisor after enabling it. The status displays as Running or Stopped.

To view the status of the cAdvisor, run the following command:

# robin metrics status --cadvisor

Example

[root@hypervvm-63-114 ~]# robin metrics status --cadvisor
Cadvisor Status........ Running/Total Pods - 3/3

3.7.5.3. Stopping cAdvisor

You can stop the cAdvisor when you do not need node level metrics.

To stop cAdvisor, run the following command:

# robin metrics stop-cadvisor

Example

[root@hypervvm-63-114 ~]# robin metrics stop-cadvisor --wait
Job:  198 Name: MetricsStopCadvisor  State: PREPARED        Error: 0
Job:  198 Name: MetricsStopCadvisor  State: COMPLETED       Error: 0

3.8. Robin client

You can download the Robin client on your Linux or macOS machine to access your Robin cluster remotely. To retrieve the client binary, issue the following command:

# curl -k 'https://<master_ip>:<port>/api/v3/robin_server/download?file=robincli&os=<os>' -o robin

Note

The possiible values for the os URL parameter include: linux and mac. Please select the appropriate value for your desired operating system when retrieving the client.

Example:

# curl -k 'https://vnode42:29442/api/v3/robin_server/download?file=robincli&os=linux' -o robin
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                Dload  Upload   Total   Spent    Left  Speed
100 10.1M  100 10.1M    0     0  1421k      0  0:00:07  0:00:07 --:--:-- 1483k

# ls -lart
-rw-r--r--    1 demo  staff    10655536 Mar 26 14:12 robin

After running the curl command a file should have been downloaded to your current working directory. Make it an executable and setup the appropriate context based on the type of installation:

3.8.1. Non-HA Deployments

# chmod +x robin

# robin client add-context <master_ip> --set-current

3.8.2. HA deployments

Before setting up the context for highly available clusters make sure the robincp_mode config attribute is enabled by logging into the appropriate node and issuing the following command:

# robin config list | grep "robincp_mode"
manager          | robincp_mode                                  | False

If the aformentioned attribute is not enabled, issue the following command:

# robin config update manager robincp_mode True --wait
Job:  163 Name: HostConfigUpdateMulti State: VALIDATED       Error: 0
Job:  163 Name: HostConfigUpdateMulti State: COMPLETED       Error: 0

# robin config list | grep "robincp_mode"
manager          | robincp_mode                                  | True

Once this step is complete, finish setting up the client by issuing the following commands:

# chmod +x robin

# ./robin client add-context <cluster_vip> --port 29465 --file-port 29465 --event-port 29465 --set-current

Note

The examples above for client context configurations assume default port usage. For custom port deployments please set the custom port for each respective service explicitly. More information about client contexts please refer to the documentation here.

3.8.3. Access using Whitelisted IP address

You can access your Robin CNP cluster remotely by adding the IP address of the machine from which you want to access your cluster as whitelisted IP address.

3.8.3.1. Prerequisites

• You must install your Robin CNP cluster with the zero-trust=true option.

Perform the following steps to access your Robin CNP cluster using the whitelisted IP address:

1. Login to your Robin CNP cluster using your username and password.

2. Add the whitelisted IP address to the robin-iptables-cfg in the /bin directory.

   # cd bin/
   # vi robin-iptables-cfg
   ZEROTRUST=1
   #Robin Control Ports
   CONTROLPORTS="6443,29442,29443,29445,29449"
   #Application Ports
   APPPORTS=""
   IP_VERSION=4
   HAINSTALL=0
   #Comma separated list of IPs or subnets that are whitelisted
   WHITELIST_IPS="<IP addresses of machines>"
   

3. Run the robin-k8s-iptables script:

   # ./robin-k8s-iptables
   

4. Create a network policy yaml with the whitelisted IP addresses.

   apiVersion: crd.projectcalico.org/v1
   kind: NetworkPolicy
   metadata:
     name: allow-ingress-external
     namespace: robinio
   spec:
     selector:
       app == 'robin-master'
     types:
       - Ingress
       - Egress
     ingress:
       action: Allow
       protocol: TCP
       source:
         nets:
           - <K8S cluster CIDR>
           - <Whitelisted IP address>
     egress:
       action: Allow
   

5. Run the following command to apply the network policy yaml to your Robin CNP cluster:

   # kubectl apply -f <network policy>.yaml
   

6. Run the robin-k8s-iptables script again:

   # ./robin-k8s-iptables
   

7. Access the machine where you have already downloaded the Robin client’s binary.

8. Run the following command to make the Robin client executable:

   # chmod +x robin
   

9. Run the following command to add context to the Robin client:

   # robin client add-context <IP address of node where Robin master Pod is running> --set-current
   

   Example

   # ./robincli-5.4.3-83 client add-context 192:0:2:24 --set-current
   Context robin-cluster-192:0:2:24 updated successfully and set as the current context
   

   Note

   • To know the IP address of node where Robin master Pod is running, run the kubectl get pod -n robinio -o wide | grep robin-master command.

   • When the Robin master Pod moves from one node to another node, robin client add-context must be added with the new node again.

Before you can use the CLI you will have to login with the username and password (by default it is admin/Robin123):

# ./robin login <username>

Enter the password when prompted.

3.9. Robin Auth Utility

Before downloading and configuring the Kubernetes client (see below), you first must download the robin-auth utility. The robin-auth utility returns the credentials of the currently logged in Robin user. The credentials are passed to the Kubernetes API server when sending requests using the Kubernetes client. You can download the robin-auth utility on your Linux or macOS machine by issuing the following command:

# curl -k 'https://<master_ip>:<port>/api/v3/robin_server/download?file=robinauth&os=<os>' -o robin-auth

Note

The possiible values for the os URL parameter include: linux and mac. Please select the appropriate value for your desired operating system when retrieving the client.

Example:

# curl -k 'https://vnode42:29442/api/v3/robin_server/download?file=robinauth&os=linux' -o robin-auth
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                         Dload  Upload   Total   Spent    Left  Speed
100 46.8M  100 46.8M    0     0  36.1M      0  0:00:01  0:00:01 --:--:-- 36.1M

# ls -lart robin-auth
-rw-r--r-- 1 root root 6145568 Sep  1 14:58 robin-auth

After running the curl command a file should have been downloaded to your current working directory. Make it an executable and move it to a directory that is in your current PATH.

# chmod +x robin-auth

  Check if a bin directory is present by running the ls command. If the directory is not present, create the bin directory.

# mkdir ~/bin

# mv robin-auth ~/bin

# robin login user1
Password:
User user1 is logged into t1 tenant

# robin-auth
{"kind": "ExecCredential", "status": {"token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ0ZW5hbnRfaWQiOjIsImV4cCI6MTU5OTA4NjI1MiwidXNlcl9pZCI6NX0._fN7JSEdRvNqHtdHJiMog5USAiTEnD4xiAMRdOy_NLw"}, "apiVersion": "client.authentication.k8s.io/v1beta1"}

Note

• The robin-auth utility works in conjunction with the Robin client (see above).

• The robin-auth utility must be located in your current PATH.

3.10. Kubernetes client

You can download the Kubernetes client on your Linux or macOS machine and setup the configuration via Robin in order to access the Kubernetes cluster externally. To retrieve the Kubernetes client, issue the following command:

# curl -k 'https://<master_ip>:<port>/api/v3/robin_server/download?file=kubectl&os=<os>' -o kubectl

Example:

# curl -k 'https://vnode31:29442/api/v3/robin_server/download?file=kubectl&os=linux' -o kubectl
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                Dload  Upload   Total   Spent    Left  Speed
100 44.5M  100 44.5M    0     0  28.9M      0  0:00:01  0:00:01 --:--:-- 28.9M

# ls -lart kubectl
-rw-r--r--    1 demo  staff    46682408 Apr 18 23:43 kubectl

After running the curl command a file should have been downloaded to your current working directory. Make it an executable and configure the client by issuing the following commands:

# chmod +x kubectl

# mkdir ~/.kube

# ./robin k8s get-kube-config --save-as-file --dest-dir ~/.kube

# kubectl get nodes
NAME                       STATUS   ROLES    AGE   VERSION
vnode31.robinsystems.com   Ready    master   9d    v1.16.3
vnode35.robinsystems.com   Ready    <none>   9d    v1.16.3
vnode52.robinsystems.com   Ready    <none>   9d    v1.16.3

Note

• The above steps assume that the Robin client and robin-auth utility have already been downloaded and setup correctly on the remote machine. More details on how to setup your Robin client can be found in the above section.

• The downloaded kubeconfig file contains an entry for the currently logged in Robin user, which is set as the default. The credentials for the currently logged in Robin user will be used when accessing the Kubernetes API server.

3.11. Helm client

You can download the Helm client on your Linux or macOS machine by issuing the following command:

# curl -k 'https://<master_ip>:<port>/api/v3/robin_server/download?file=helm&os=<os>' -o helm

Example:

# curl -k 'https://vnode31:29442/api/v3/robin_server/download?file=helm&os=linux' -o helm
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                Dload  Upload   Total   Spent    Left  Speed
100 38.5M  100 38.5M    0     0  29.3M      0  0:00:01  0:00:01 --:--:-- 29.4M

# ls -lart
-rw-r--r--    1 demo  staff    40460288 Apr 18 23:48 helm

After running the curl command, a file should have been downloaded to your current working directory. Make the file an executable by issuing the following commands:

# chmod +x helm

3.12. Helm 2 client

Note

Support for Helm 2 and Tiller is deprecated and will be removed in the next release.

You can download the Helm 2 client on your Linux or macOS machine and configure the necessary Helm/Tiller objects via Robin in order to utilize Helm to deploy charts to be managed by the platform. To retrieve the Helm 2 client, issue the following comman:

# curl -k 'https://<master_ip>:<port>/api/v3/robin_server/download?file=helm2&os=<os>' -o helm2

Example:

# curl -k 'https://vnode31:29442/api/v3/robin_server/download?file=helm2&os=linux' -o helm2
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                Dload  Upload   Total   Spent    Left  Speed
100 38.5M  100 38.5M    0     0  29.3M      0  0:00:01  0:00:01 --:--:-- 29.4M

# ls -lart
-rw-r--r--    1 demo  staff    40460288 Apr 18 23:48 helm2

After running the curl command a file should have been downloaded to your current working directory. Make it an executable, configure the necessary files and deploy the appropriate Tiller objects by issuing the following commands:

# chmod +x helm2

# ./robin whoami
       username: robin
         tenant: Administrators
        tenants: ['Administrators']
      namespace: t001-u000003
session_expires: 2020-04-19T23:13:10

# ./robin k8s deploy-tiller t001-u000003
Tiller objects were successfully deployed for namespace 't001-u000003'

# robin k8s helm-setup t001-u000003
Helm initialized successfully

Note

The above steps assume that the Robin client has already been setup correctly on the remote machine. More details on how to setup your Robin client can be found in the above section. In addition when running the final two commands ensure the Robin namespace displayed in the output of the whoami command is passed as parameter.

3.13. Robin Certificate Management

Robin certificate management feature allows you to manage all certificates in your cluster without manual intervention. Robin CNP leverages cert-manager to achieve this.

cert-manager is a native Kubernetes certificate management controller. It automates the issuance, renewal, and management of certificates from both external Certificate Authorities (CA) such as Let’s Encrypt, DigiCert, HashiCorp Vault and local Certificate Authorities (self-signed certificates).

cert-manager adds Certificate and Issuer resources to Kubernetes clusters, simplifies the process of obtaining, generating, and renewing certificates for the cluster. For more information, see, cert-manager.

Robin certificate management feature manages certificates only for Robin internal services deployed in the robinio namespace. It ensures that all certificates are valid and up-to-date by automatically renewing them before they expire.

Certificate Authorities in Robin CNP Cluster

A Robin CNP cluster has the following certificate authorities (CAs):

• Cluster CA – It signs all certificates for internal communication within the cluster.

• Identity CA – It signs the Cluster Identity certificate for all external-facing services such as Kubernetes API Server, Robin client, GUI, etc.

Certificate Issuers in Robin Certificate Management

Robin certificate management feature contains the following certificate issuers:

• cluster-issuer - It issues and renews all certificates used internally by the various control plane services.

• ident-issuer - It issues and renews the Cluster Identity certificate used for all external-facing services such as Kubernetes API Server, Robin client, GUI, etc.

These two certificate issuers are configured and managed independently. Therefore, you can reset the Identity CA certificate without affecting certificates issued by the cluster-issuer, which are used by the control plane services.

Certificate Issuer Operation and Control Modes

A certificate issuer has the following operation and control modes for managing certificates:

• Local control - Certificates and keys are generated by internal functions of the control planes.

• External control - Certificates and keys are generated by an external CA and manually deployed in the cluster.

  Note

  Robin CNP supports external control only for the ident-issuer certificate issuer type. If you use external control, you are responsible for renewing the certificate.

• cert-manager control - Certificates and keys are generated and automatically renewed by cert-manager.

  Note

  Currently, the cert-manager supports only self-signed cluster CA.

Points to consider for Robin certificate management

• When you install or upgrade to the latest Robin CNP version, cert-manager is deployed by default. A new service called robin-cert-monitor is also deployed to monitor the state of all certificates required by various Pods and containers in the Robin CNP cluster, ensuring that all required certificates exist and are valid.

• During install or upgrade, only the cert-manager option is supported. If you want to manage certificates using the local control mode, use the robin cert reset-cluster-certs to enable it.

• After upgrading to the latest Robin CNP version, if your cluster is already installed with a Cluster Identity certificate signed by an external CA, you must reconfigure it using the robin cert reset-cluster-identity command.

• If you want to use a Cluster Identity certificate signed by an external CA after installing Robin CNP, use the robin cert reset-cluster-identity command to configure it.

• To install Robin CNP with both (Cluster Identity certificate signed by an external CA and cert-manager), you need to pass the following options in the config.json file for one of the master nodes.

  • ident-ca-path

  • ident-cert-path

  • ident-key-path

  For more information, see Installation with custom Cluster Identity certificate.

• Only one cert-manager instance can be deployed in a cluster.

• You cannot install your own cert-manager on a Robin CNP cluster. If you want to use cert-manager functionality, use the cert-manager instance deployed as part of the Robin certificate management feature to create Issuers and Certificates in other namespaces.

The following commands are described in this section:

robin cert list	List all certificates for a cluster
robin cert renewal-check	Check the status of all certificates for a cluster
robin cert reset-cluster-identity	Reset Cluster Identity CA and its key
robin cert reset-cluster-certs	Reset Cluster CA and its key

3.13.1. List all cluster certificates

You can view all certificates in a cluster issued by both the cluster-issuer and ident-issuer certificate issuers.

It provides the following additional information about certificates:

• Certificate authority (CA)

• Issuer type

• Certificate’s name

• Certificate’s expiry

CLI

Run the following command to view all certifictes for a cluster:

# robin cert list
                --json

--json

Output in JSON format.

Example

# robin cert list
CERTIFICATE AUTHORITY | EXPIRES              | ISSUER_TYPE
----------------------+----------------------+--------------
cluster-ca            | 2035-03-26T04:33:07Z | cert-manager
robin-ssl             | 2035-03-26T04:33:07Z | cert-manager

CERTIFICATE                                   | EXPIRES              | CERTIFICATE AUTHORITY | ISSUER_TYPE
----------------------------------------------+----------------------+-----------------------+--------------
cluster-tls                                   | 2028-03-27T04:33:08Z | cluster-ca            | cert-manager
file-server-tls                               | 2028-03-27T04:33:12Z | robin-ssl             | cert-manager
iomgr-client-hypervvm-63-34.robinsystems.com  | 2028-03-27T04:33:21Z | robin-ssl             | cert-manager
iomgr-client-hypervvm-63-35.robinsystems.com  | 2028-03-27T04:33:25Z | robin-ssl             | cert-manager
iomgr-client-hypervvm-63-36.robinsystems.com  | 2028-03-27T04:33:30Z | robin-ssl             | cert-manager
iomgr-server-hypervvm-63-34.robinsystems.com  | 2028-03-27T04:33:19Z | robin-ssl             | cert-manager
iomgr-server-hypervvm-63-35.robinsystems.com  | 2028-03-27T04:33:23Z | robin-ssl             | cert-manager
iomgr-server-hypervvm-63-36.robinsystems.com  | 2028-03-27T04:33:28Z | robin-ssl             | cert-manager
log-server-tls                                | 2028-03-27T04:33:13Z | robin-ssl             | cert-manager
master-tls                                    | 2028-03-27T04:33:10Z | robin-ssl             | cert-manager
node-tls-hypervvm-63-34.robinsystems.com      | 2028-03-27T04:33:18Z | robin-ssl             | cert-manager
node-tls-hypervvm-63-35.robinsystems.com      | 2028-03-27T04:33:22Z | robin-ssl             | cert-manager
node-tls-hypervvm-63-36.robinsystems.com      | 2028-03-27T04:33:26Z | robin-ssl             | cert-manager
robin-auth                                    | 2035-03-26T04:33:14Z | robin-ssl             | cert-manager
stormgr-client-tls                            | 2028-03-27T04:33:16Z | robin-ssl             | cert-manager
stormgr-server-tls                            | 2028-03-27T04:33:14Z | robin-ssl             | cert-manager

3.13.2. Status of Cluster Certificates

You can check the current state of all certificates in a cluster using the robin cert renewal-check command. This command also helps you to start, stop, and update the CertRenewalCheck CronJob.

The robin cert renewal-check command launches a robin-certs-check Kubernetes job, which runs inside its own Pod. The robin-certs-check job runs a script that checks the status of all cluster certificates. If the certificates of Pods or containers are about to expire, the robin-cert-monitor service renews these certificates. The robin cert renewal-check command also restarts all Pods or containers impacted by recently renewed certificates for new certificates to take effect, which results in the reloading of all certificates used by Pods or containers. The HAProxy and Keepalived containers, deployed on each master node in the cluster, are containers that utilize Robin CNP-managed certificates.

The Kubernetes API server Pods are configured with Robin CNP cluster certificates and may be restarted during a certificate renewal check.

Note

Restarting control plane Pods may cause temporary disruption to the cluster. Execute this command with caution.

CLI

Run the following command to check the current state of all certificates for a cluster:

# robin cert renewal-check
                      --ttl-after-finished <ttl_after_finished>
                      --start-cronjob
                      --stop-cronjob
                      --update-cronjob
                      --schedule <schedule>
                      --force
                      --dry-run

--ttl-after-finished <ttl_after_finished>	Number of seconds the CertRenewalCheck job stays active after its completion. If you set its value to 0, the CertRenewalCheck job will never be deleted.
--start-cronjob	Start a CronJob that launches a CertRenewalCheck job on a periodic basis.
--stop-cronjob	Stop the CronJob that stops the CertRenewalCheck job, if running.
--update-cronjob	Update the currently running CronJob to change the time period of CertRenewalCheck job.
--schedule <schedule>	String to schedule a CronJob. For information, see Crontab.
--force	It is a mandatory option to check cluster certificates for renewal.
--dry-run	Perform a dry run without actually triggering Pod or container restarts. You cannot use this option with the --start-cronjob, --stop-cronjob, or --update-cronjob options.

Example

# robin cert renewal-check --force
Cluster Certificate Check: Started (jobid=764)

# robin job info 764
ID  | Type                      | Desc                          | State              | Start           | End      | Duration | Dependson | Error | Message
----+---------------------------+-------------------------------+--------------------+-----------------+----------+----------+-----------+-------+----------------------------------------
764 | CertRenewalCheck          | Checking cluster certificates | COMPLETED          | 15 May 02:45:03 | 02:45:04 | 0:00:01  | []        | 0     | K8s job 'robin-certs-check' started...

3.13.3. Reset Cluster Identity CA and its certificate

You can reset the Cluster Identity CA and its certificate for a cluster using the robin cert reset-cluster-identity command. Once you reset the Cluster Identity CA certificate, it generates a new Cluster Identity certificate and its key for external facing services such as Kubernetes API Server, Robin client, GUI, etc.

You can use this command to configure or update the Cluster Identity certificate signed by an external CA for a cluster in the following scenarios:

• A Cluster Identity certificate was not provided during Robin CNP installation, and you want to configure it post installation.

• The existing Cluster Identity CA certificate is expired.

• The existing Cluster Identity CA is changed.

To configure or reset a Cluster Identity certificate signed by an external CA, specify the following options as part of the robin cert reset-cluster-identity command:

• –ident-ca-path

• –ident-cert-path

• –ident-key-path

Note

To apply new certificates, you must run the robin cert renewal-check command to restart the affected Pods and containers for new certificates to take effect.

CLI

Run the following command to reset the Cluster Identity CA and its certificate for a cluster:

# robin cert reset-cluster-identity [{cert-manager,local,external}]
                                  --ident-ca-path <ident_ca_path>
                                  --ident-cert-path <ident_cert_path>
                                  --ident-key-path <ident_key_path>
                                  --force

{cert-manager,local,external}	Type of certificate Issuer. Valid values are cert-manager, local, and external. The default value is cert-manager.
--ident-ca-path <ident_ca_path>	Path to the external CA certificate that signs the Cluster Identity certificate. This is required when the certificate issuer type is external.
--ident-cert-path <ident_cert_path>	Path to the Cluster Identity certificate. This is required when the certificate issuer type is external.
--ident-key-path <ident_key_path>	Path to the Cluster Identity certificate’s private key. This is required when the certificate issuer type is external.
--force	Forcibly reset the cluster identity CA and its certificate. This option is mandatory to reset the cluster identity CA and its certificate.

Example

# robin cert reset-cluster-identity --force
Cluster identity CA and certificate have been reset

3.13.4. Reset Cluster CA and its certificates

You can reset the Cluster CA and its certificate for a cluster using the robin cert reset-cluster-certs command. It generates a new Cluster CA certificate and its key. The robin-cert-monitor service then generates new certificates and keys for all currently issued certificates in a cluster.

Note

To apply new certificates, you must run the robin cert renewal-check command to restart the affected Pods and containers for new certificates to take effect.

CLI

Run the following command to reset the Cluster CA and its certificate for a cluster:

# robin cert reset-cluster-certs [{cert-manager, local}]
                                 --force

{cert-manager,local}	Type of certificate Issuer. Valid values are cert-manager, and local. The default value is cert-manager.
--force	Forcibly reset the cluster identity CA and its certificate. This option is mandatory to reset the cluster CA and its certificate.

Example

# robin cert reset-cluster-certs local --force
Cluster CA and certificates have been reset

3.14. Secure communication between kubelet and kube-apiserver

In a Kubernetes cluster, the kubelet and kube-apiserver communicate with each other securely using TLS certificates. The kubelet, running on each node, authenticates with the kube-apiserver to register itself and manage containers. This communication is secured through mutual TLS, meaning both the kubelet and kube-apiserver present their certificates to verify each other’s identity. This ensures that only authorized kubelets connect to the kube-apiserver and communication between them is secure.

The kubelet presents its server certificate to clients that connect to it. By default, kubelet’s server certificate is self-signed meaning it is signed by a temporary Certificate Authority (CA) that is created on the fly and then discarded.

To enable secure communication between the kubelet and kube-apiserver, you must configure the kubelet to obtain its server certificate by issuing a Certificate Signing Request (CSR), rather than using a server certificate signed by a self-signed CA. After configuring the kubelet, you must also configure the kube-apiserver to process and approve the CSR.

Complete the following steps to configure secure communication between kubelet and kube-apiserver:

1. Configure kubelet on all nodes of a cluster, starting with the master nodes and then followed by the worker nodes:

   # ./k8s-script-el8-5.5.0-1529.sh config-kubelet-ca
   

   The above k8s-script configures the kubelet on each node to request its server certificate. The kubelet sends a Certificate Signing Request (CSR) to thekube-apiserver when requesting or renewing its server certificate. After submitting the CSR. the kubelet waits for CSR approval.

2. Configure the kube-apiserver:

   # ./k8s-script-el8-5.5.0-1529.sh config-kubelet-apiserver
   

   The robin-cert-monitor service, which runs automatically in the cluster, monitors for CSRs issued by the kubelets, and approves them if any CSRs are available. When the kubelet issues a CSR, it waits for CSR approval. Once it is approved, kubelet is restarted to reload its new server certificate.