****************************** Managing Stateful Applications ****************************** .. role:: raw-html(raw) :format: html Kubernetes is a framework for managing complex applications in a containerized environment. It provides various facilities for managing container placement, resource allocation, service discovery, load balancing, scaling, etc. Kubernetes does not, however, have a notion of what an application actually is, nor is there a Kubernetes resource called 'application'. On a Kubernetes cluster, the pod is the basic operational unit. Containers are grouped into pods and deployed as individual units, or they are deployed under the control of various resource controllers such as ReplicaSet, StatefulSet, Deployment, etc. How to define a set of related Kubernetes resources as a single unit is left for users to decide. Fortunately, a number of solutions that address this problem have evolved in recent times: ========================= =================== **Helm Release** Helm is a tool that streamlines the installation and management of Kubernetes applications. A Helm chart is a collection of specifications describing a related set of Kubernetes resources. A Helm release is a specific instance of a Helm chart which has been deployed to a Kubernetes cluster. **Custom Operator** Custom Operators are specialized controllers that automate complex tasks beyond the scope of what Kubernetes itself provides. They provide a way to extend the cluster's behavior without making modifications to Kubernetes itself. Many ISVs have developed Operators that deploy their software on Kubernetes. ========================= =================== **Topics covered in this chapter:** =============================== ================================================================================= ``robin app create`` Create an application ``robin app register`` Register a stateful application ``robin app unregister`` Unregister a stateful application ``robin app delete`` Delete an application ``robin app list`` List applications ``robin app info`` Display detailed information about an app ``robin app status`` Display the status of the objects associated with an app ``robin app attach-repo`` Attach an external storage repo to an app ``robin app detach-repo`` Detaches a previously attached repo from an app ``robin app snapshot-schedule`` Configures a snapshot schedule for an app ``robin app backup-schedule`` Configures a backup schedule for an app ``robin app start`` Start an application instance ``robin app stop`` Stop an application instance ``robin app restart`` Restart an application instance ``robin app restore`` Revert an app to the point-in-time of specified snapshot or backup ``robin app update`` Configure application parameters ``robin app upgrade`` Upgrade an application ``robin app config`` Configure various attributes/schedules of an app ``robin app share`` Share an app with one or more tenant users ``robin app unshare`` Stop sharing an app with one or more tenant users ``robin app list-shares`` List application shares ``robin app change-owner`` Reassign ownership of an app ``robin app expandvol`` Expand the size of a volume associated with an app =============================== ================================================================================= Application life cycle management ================================= The lack of a proper Application construct in Kubernetes poses a problem when it comes to managing the life cycle of a complex application made up of various Kubernetes resources. For example, how would one snapshot or clone an entire Helm release that spans PersistVolumeClaims, Secrets, ConfigMaps, SatefulSet, Pods, Services etc? Or how about snapshotting a web tier, app tier and database tier each deployed separately using three different kubectl manifest files? Robin Applications ================== Robin provides a framework for managing stateful applications deployed on a Kubernetes cluster. All resources that together deliver a service to the end user are collected together into a single unit, which Robin calls an **Application**. Robin maintains metadata on each of the application’s associated resources in its configuration database. This allows Robin to perform life cycle management operations, such as snapshot, backup, restore, etc., that encompass all of an application's data and metadata (state of each Kubernetes resource). Three types of applications can be managed by Robin: ROBIN ------- Robin Platform provides the ability to deploy applications to a Kubernetes cluster using custom Application Bundles containing all specifications and resources necessary for application deployment. When Robin Platform deploys the application, it takes responsibility for creating all relevant Kubernetes resources, such as StatefulSets, PersistentVolumeClaims, etc. Robin Applications are automatically handled by the Robin Platform framework. Helm ----- Helm provides the ability to deploy applications to a Kubernetes cluster using Helm charts containing all specifications and resources necessary for application deployment. When Helm deploys an application, it takes responsibility for creating all relevant Kubernetes resources. Helm Applications are not automatically known to Robin Platform. But they can be registered with the Robin Platform cluster. In order for this to work, all storage for the application must be from the Robin Platform. The application also needs to be registered with Robin Platform. FlexApp --------- Robin Platform also provides a very flexible mechanism for registering any set of Kubernetes resources as a Robin Application. The **FlexApp** construct uses label selector rules to group the resources together. For example, ``--select app=apache --select app=mysql`` would select Pods and PVCs for a web and database tier together into a single FlexApp object. The command to create/register a FlexApp, is detailed in the sections below. Limits on Non-bundle Applications for Tenants and Users ======================================================== Robin CNP allows you to set limits on non-bundle applications for tenant and tenant users at Resource pools and application levels. For more information, see `here `__. By default, the following configurations are enabled for setting limits for non-bundle applications: - ``robin config update cluster k8s_check_rpool_limits true|false`` .. NOte:: If you disable this configuration, the set limits will not be applicable. - ``robin config update cluster k8s_auto_registration true|false`` .. Note:: If this configuration is disabled manually before the upgrade to Robin CNP 5.4.1, you must enable it manually for limits to be applicable for non-bundle applications. The set limits will be applicable, and application registration on Robin CNP will succeed only if Kubernetes objects (Pods, Deployment, DaemonSet, Statefulset, and PVCs) have any one of the following labels: - ``app, release`` - ``app.kubernetes.io/instance, app.kubernetes.io/name`` Robin Application Bundles ========================= Robin Platform offers a new type of application deployment framework called "Application Bundles", which is ideally suited for complex workloads such as Cloudera, Oracle RAC, Splunk, SAP HANA, etc. An Application Bundle contains all resources necessary to deploy an application to a Kubernetes cluster, such as: * The list of services offered by the application. For example, services offered by MongoDB include ConfigServer, QueryRouter, Shards, ReplicaSets. * Which image to pull for each service. Note that images can be vendor published images, or they can be custom images hosted on a local registry. * Optionally, application specific placement constraints can also be specified. For example, anti/affinity policies for services. All application configuration information is contained in a YAML file, called the 'manifest' file. The manifest file, icon file, and any application-specific life cycle hook scripts are packaged into a single tar file and uploaded to the Robin Platform as an *Application Bundle*. Robin Platform's Application Bundles enable an App Store-like experience for deploying any Application, with a special focus on the needs of complex distributed data-heavy Big Data, NoSQL and Databases. Once a bundle has been uploaded, a user can use it when deploying an application with a single click from the UI, a single command from the CLI, or a single REST call programmatically. The highly flexible and customizable Robin Application Bundle framework offers application developers freedom from the underlying infrastructure. You define the application once and deploy it anywhere, on-prem or public clouds like AWS, Azure and Google Cloud. Robin Platform comes pre-packaged with ready-to-use Application Bundles for several applications including: * Big Data: HortonWorks, Cloudera, Spark, ElasticSearch, ELK, Splunk * NoSQL: MongoDB, Cassandra, CouchDB * Databases: Oracle, Oracle RAC, SAP HANA, Microsoft SQL Server, IBM DB2, Postgres, MySQL, MariaDB * AI / machine learning: TensorFlow, Caffe, Theano, R, Jupyter Users can onboard any application or database that runs on Linux very quickly. Refer to the `Robin Application Bundle Guide `__ for instructions. Upload a Robin Application Bundle ---------------------------------- Add a bundle to the Robin cluster with the following command: .. code-block:: text # robin bundle add An example of its usage is shown below: .. code-block:: text # robin bundle add mysql docker-8.0 docker-mysql-8.0-416_master.tar.gz File upload: 100% -- (79763/79763) Job: 118 Name: BundleAdd State: VALIDATED Error: 0 Job: 118 Name: BundleAdd State: COMPLETED Error: 0 .. Note:: For more details on the above command refer to the documentation provided `here `__. Listing Application Bundles ---------------------------- List all the bundles currently present on the Robin cluster with the following command: .. code-block:: text # robin bundle list An example of its usage is shown below: .. code-block:: text # robin bundle list Bundle Id | Type | Owner/Tenant | Name | Version | Zone Id | Content Id | Description | Group Id | #Templates | #Apps ----------+-------+----------------------+----------+------------+------------+----------------------------------+-------------+----------+------------+------- 1 | ROBIN | admin1/t1 | mysql2 | docker-8.0 | 1580884960 | f428eeefd6d08ddb7ea91f38e4755771 | - | 4 | 0 | 0 2 | ROBIN | robin/Administrators | postgres | docker-9.5 | 1580884960 | 91120e615901bab8947b9d8380b186a1 | - | 2 | 1 | 1 3 | HELM | admin1/t1 | mysql | helm-1.6.2 | 1580884960 | 00f4243a24cc74624d7272a6217d425f | - | 3 | 0 | 0 .. Note:: For more details on the above command refer to the documentation provided `here `__. Create an Application from a Robin Application Bundle ----------------------------------------------------- Create a Robin bundle based application with the following command: .. code-block:: text # robin app create from-bundle --rpool An example of its usage is shown below: .. code-block:: text # robin app create from-bundle pgsql 2 postgres_template.json --rpool default --wait Job: 115 Name: ApplicationCreate State: VALIDATED Error: 0 Job: 115 Name: ApplicationCreate State: WAITING Error: 0 Job: 115 Name: ApplicationCreate State: COMPLETED Error: 0 .. Note:: For more details on the above command refer to the documentation provided `here `__. Advanced placement policies for Robin Application Bundles ---------------------------------------------------------- One advantage of using Robin Application Bundles is that the Robin Platform, as the orchestrator, can enforce multiple placement policies. This is not a feature available in native Kubernetes deployers, such as Helm. This gives users additional control over the placement of pods, affinity rules, etc. for their deployment. Also, these placement policies can be applied independently on each service or role within the application. This fine-grained control helps optimize application performance, cluster utilization, and allows the user to easily customize their deployment based on their cluster configuration. The placement policies that Robin Platform offers are: * Round-robin placement of pods within different nodes, racks, and datacenters. This rule makes sure that every deployed pod is placed on an a different instance within the specified infrastructure component, depending on available resources. This will spread the compute aspect of an application as much as possible. * Prevent placing more than one pod on the same node, rack, or datacenter. This rule makes sure that every deployed pod is strictly placed on an a different instance within the specified infrastructure. If that is not possible, the application creation will fail. This ensures that the compute aspect of the application is not piled up on one infrastructure piece alone. * Enforce Storage and Compute for all pods to be on same node, rack, or datacenter. This rule makes sure that every deployed pod has storage and compute affinity. As a consequence, each container and its associated volume(s) will be associated with the same infrastructure piece. Performance will obviously benefit. * Restrict the placement of pods to nodes tagged with specific tags ([key:value, ...]). This rule makes sure that every deployed pod is placed only on hosts tagged with the specified key-value pairs (either via Kubernetes or Robin Platform). This allows a user to control exactly where a set of pods are spawned and thus optimize cluster utilization. * Do not place pods for service on a node, rack, or datacenter which is also running service . This rule makes sure that every pod deployed for a particular role will never be hosted by an infrastructure piece that is hosting any pods from a different, specified service. For example, the compute aspect of two different roles of an application could always be placed on separate pieces of infrastructure. * Always place pods for service on a node, rack, or datacenter which is also running service . This rule makes sure that every pod deployed for a particular role will always be hosted by an infrastructure piece that is hosting any pods from a different, specified service. For example, the compute aspect of two different roles of an application could always be co-located. Helm Releases ============= A Helm chart is a collection of specifications describing a related set of Kubernetes resources. A Helm release is a specific instance of a Helm chart deployed to a Kubernetes cluster. Robin Platform supports the registration of a Helm release as a HELM Application, which allows the application to be managed using Robin Platform's life cycle management facilities. In order for this to work, all storage for the application must be from the Robin Platform. The application also needs to be deployed to the user's assigned Kubernetes namespace. Moreover Robin allows for the auto-registration of Helm releases when the config attribute ``k8s_auto_registration`` is set to true. This results in any newly created instances of Helm charts being exposed to the lifecycle management features Robin provides without any user intervention. However there are certain caveats to utilizing this feature: - In order for an application to be auto registered there has to exist an underlying file collection with free space as a generic bundle for the release will be created and added. - Only Helm releases deployed in namespaces which are imported into Robin will be automatically registered. - One of the following combinations of labels must be present within the objects deployed by the release. Either both the ``app`` and ``release`` labels must be present within the aforementioned objects or both the ``app.kubernetes.io/name`` and ``app.kubernetes.io/instance`` labels must be present. - Releases that were created previously in namespaces that have since been imported into Robin will not be picked up immediately. As a result there will be an initial delay before the application is made visible to Robin users. Of course, one is always able to manually register the pre-existing application to hasten this process. - If two Helm releases with the same name are deployed in different imported namespaces, Robin CNP does not auto-register the second app with the same name. Instead it must be registered manually using the ``robin app register`` command as shown below. .. Note:: If you want to use storage-compute-affinity and network-planning features using Robin annotations, do not use the **nodeName** field in the spec. Register a Helm3 Release ------------------------- As Helm3 is configured on all hosts within the Robin cluster as part of the Robin Platform installation, there is no need for any additional setup. Thus the following example showcases **user1**, who is a member of Tenant **t1** with namespace **t003-u000004**, registering a deployed Helm3 release. **Log in as user1:** .. code-block:: text # robin login user1 Password: User user1 is logged into t1 tenant **Get the current user context for user1:** The ``robin whoami`` command returns useful information about the current Robin Platform user. It includes a list of tenants the user is a member of (user1 is only a member of one tenant) and which tenant they are currently logged into. Additionally, the whoami output includes the Kubernetes namespace that has been assigned to the user for their current tenant. This is the namespace the Helm chart needs to be installed into. .. code-block:: text # robin whoami username: user1 tenant: t1 tenants: ['t1'] namespace: t003-u000004 session_expires: 2020-01-24T11:53:02 **Add the bitnami Helm repo for the current user:** .. code-block:: text # helm repo add bitnami https://charts.bitnami.com/bitnami "bitnami" has been added to your repositories **Install the bitnami/mysql Helm chart:** With respect to the helm command line below, note that ``persistence.storageClass`` is set equal to 'robin'. Using Robin Storage is a requirement for Helm release registration with Robin. Also note the inclusion of the current user's assigned namespace in the Helm command line. The ``--namespace`` parameter specifies which Kubernetes namespace the application resources will be bound to. .. code-block:: text # helm install demo bitnami/mysql --set global.storageClass=robin --namespace t003-u000004 NAME: demo LAST DEPLOYED: Thu Aug 19 22:23:54 2021 NAMESPACE: t003-u000004 STATUS: deployed REVISION: 1 NOTES: MySQL can be accessed via port 3306 on the following DNS name from within your cluster: mysqldb.t003-u000004.svc.cluster.local To get your root password run: MYSQL_ROOT_PASSWORD=$(kubectl get secret --namespace t003-u000004 mysqldb -o jsonpath="{.data.mysql-root-password}" | base64 --decode; echo) To connect to your database: 1. Run an Ubuntu pod that you can use as a client: kubectl run -i --tty ubuntu --image=ubuntu:16.04 --restart=Never -- bash -il 2. Install the mysql client: $ apt-get update && apt-get install mysql-client -y 3. Connect using the mysql cli, then provide your password: $ mysql -h mysqldb -p To connect to your database directly from outside the K8s cluster: MYSQL_HOST=127.0.0.1 MYSQL_PORT=3306 # Execute the following command to route the connection: kubectl port-forward svc/mysqldb 3306 mysql -h ${MYSQL_HOST} -P${MYSQL_PORT} -u root -p${MYSQL_ROOT_PASSWORD} **Get the Helm3 release name:** .. code-block:: text # helm list --namespace t003-u000004 NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION mysqldb t003-u000004 1 2020-10-06 03:37:21.126307438 +0000 UTC deployed mysql-1.6.7 5.7.30 **Manually register Helm3 release as a HELM Application:** .. code-block:: text # robin app register mysqldb --app helm/mysqldb -n t003-u000004 Job: 114 Name: K8SAppRegister State: PREPARED Error: 0 Job: 114 Name: K8SAppRegister State: COMPLETED Error: 0 .. Note:: If the ``k8s_auto_registration`` config attribute is enabled and all of the aforementioned necessary conditions are met this step need not be performed. **Verify that the app is registered with Robin:** .. code-block:: text # robin app list Helm/Flex Apps: +----------+------+--------+----------------------+--------------+-----------+---------+ | Name | Type | State | Owner/Tenant | Namespace | Snapshots | Backups | +----------+------+--------+----------------------+--------------+-----------+---------+ | mysqldb | helm | ONLINE | user1/t1 | t003-u000004 | 0 | 0 | +----------+------+--------+----------------------+--------------+-----------+---------+ **Get detailed information about the resulting application:** .. code-block:: text # robin app info mysqldb Name : mysqldb Kind : helm State : ONLINE Number of repos : 0 Number of snapshots : 0 Number of usable backups : 0 Number of archived/failed backups : 0 Query: ------- {'apps': ['helm/mysqldb@t003-u000004'], 'namespace': 't003-u000004', 'selectors': [], 'resources': []} Register a Helm2 Release ------------------------- .. note:: Support for Helm 2 and Tiller is deprecated. As a result no native Robin commands are provided to facilitate the deployment of Helm 2 and the onus is on the user to ensure Helm 2/Tiller are deployed appropriately. However charts deployed via Helm 2 can still be registered with Robin. Following is a step-by-step walkthrough, detailing how the Helm environment needs to configured for a Robin user, how to install a Helm chart that generates a Helm release suitable for registration with Robin Platform, and how to perform a Helm release registration. Note that the initial steps must be performed by a superadmin user. The remaining steps are to be performed by the Robin Platform user. The following example assumes superadmin user **admin** is setting up the Helm environment for Robin Platform user **user1** who is a member of Tenant **t1**. **Log in as the superadmin user:** .. code-block:: text # robin login admin Password: User admin is logged into Administrators tenant **Generate a list of Robin Platform users:** .. code-block:: text # robin user list ID | Username | Full Name | Email | Tenants | Current Tenant | Current Role | Current Namespace | Authentication ---+----------+---------------+-------+----------------+----------------+--------------+-------------------+---------------- 3 | admin | Robin Systems | | Administrators | Administrators | superadmin | t001-u000003 | local 4 | user1 | | | t1 | t1 | user | t003-u000004 | local Note the Current Namespace for user1: **t003-u000004**. The Kubernetes resources associated with Tiller (ServiceAccount and RoleBinding) need to be deployed within this namespace. **Log in as user1:** .. code-block:: text # robin login user1 Password: User user1 is logged into t1 tenant After logging in, ensure that the necessary CA cert and user cert/key are present within the .helm directory present in the user's HOME directory. Once this is completely Helm 2 needs to be initialized within this namespace via the ``helm2 init`` command or otherwise in order to deploy Tiller into the user's assigned namespace. **Wait for Tiller to be deployed:** The below command needs to be repeated until no errors are returned. .. code-block:: text # helm2 list --tls --tiller-namespace=t003-u000004 Error: could not find tiller **Add the bitnami Helm repo for the current user:** .. code-block:: text # helm2 repo add bitnami https://charts.bitnami.com/bitnami "bitnami" has been added to your repositories **Install the bitnami/mysql Helm chart:** With respect to the helm2 command line below, note that ``persistence.storageClass`` is set equal to 'robin'. Using Robin Storage is a requirement for Helm release registration with Robin Platform. Also note the inclusion of the current user's assigned namespace in two places in the Helm command line. The ``--namespace`` parameter specifies which Kubernetes namespace the application resources will be bound to. The ``--tiller-namespace`` parameter tells Helm which namespace Tiller has been deployed to. The namespace for both parameters must be the same and it must be the namespace assigned to the user by Robin Platform. .. code-block:: text # helm2 install bitnami/mysql --tls --set persistence.storageClass=robin --namespace t003-u000004 --tiller-namespace=t003-u000004 NAME: billowing-tortoise LAST DEPLOYED: Wed Jan 22 21:55:24 2020 NAMESPACE: t003-u000004 STATUS: DEPLOYED RESOURCES: ==> v1/ConfigMap NAME AGE billowing-tortoise-mysql-test 0s ==> v1/Deployment NAME AGE billowing-tortoise-mysql 0s ==> v1/PersistentVolumeClaim NAME AGE billowing-tortoise-mysql 0s ==> v1/Pod(related) NAME AGE billowing-tortoise-mysql-d4f976d96-89x5c 0s ==> v1/Secret NAME AGE billowing-tortoise-mysql 0s ==> v1/Service NAME AGE billowing-tortoise-mysql 0s NOTES: MySQL can be accessed via port 3306 on the following DNS name from within your cluster: billowing-tortoise-mysql.t003-u000004.svc.cluster.local To get your root password run: MYSQL_ROOT_PASSWORD=$(kubectl get secret --namespace t003-u000004 billowing-tortoise-mysql -o jsonpath="{.data.mysql-root-password}" | base64 --decode; echo) To connect to your database: 1. Run an Ubuntu pod that you can use as a client: kubectl run -i --tty ubuntu --image=ubuntu:16.04 --restart=Never -- bash -il 2. Install the mysql client: $ apt-get update && apt-get install mysql-client -y 3. Connect using the mysql cli, then provide your password: $ mysql -h billowing-tortoise-mysql -p To connect to your database directly from outside the K8s cluster: MYSQL_HOST=127.0.0.1 MYSQL_PORT=3306 # Execute the following command to route the connection: kubectl port-forward svc/billowing-tortoise-mysql 3306 mysql -h ${MYSQL_HOST} -P${MYSQL_PORT} -u root -p${MYSQL_ROOT_PASSWORD} **Get the Helm2 release name:** Note that the ``--tls`` flag is required for all Helm commands because Helm and Tiller were configured to require the user’s TLS cert and key (coped to the .helm directory in a previous step). .. code-block:: text # helm list --tls --tiller-namespace=t003-u000004 NAME REVISION UPDATED STATUS CHART APP VERSION NAMESPACE billowing-tortoise 1 Wed Jan 22 21:55:24 2020 DEPLOYED mysql-1.6.2 5.7.28 t003-u000004 **Manually register Helm2 release as a HELM Application:** .. code-block:: text # robin app register mysql --app helm/billowing-tortoise -n robinapps Job: 114 Name: K8SAppRegister State: PREPARED Error: 0 Job: 114 Name: K8SAppRegister State: COMPLETED Error: 0 .. Note:: If the ``k8s_auto_registration`` config attribute is enabled and all of the aforementioned necessary conditions are met this step need not be performed. **Get a listing of all Robin Platform applications:** Note that the Robin Platform CLI command to list applications returns two application groupings. It returns a list of applications that were deployed by Robin Platform from Application Bundles. It will also include a list of applications that were registered with the cluster (Helm releases and FlexApps). Also note that RBAC control limits which applications a user is able to view. A user who has been assigned the **user** role (**user1** in this example) will only be able to view applications they own (created/registered). A user who has been assigned the **tenantadmin** role will be able to view all applications created/registered by all members of their tenant. A user who has been assigned the **superadmin** role (**admin** in this example) will be able to see all applications created/registered by all users across the entire cluster (e.g., for all tenants). Note that a user can only be **superadmin** if they are logged into the Administrators tenant. .. code-block:: text # robin app list ROBIN Bundle Apps: +-------+--------------+--------+--------+---------------+--------+-----+-----+-------------+--------+---------+-----------+-------+ | Name | Owner/Tenant | Type | Parent | Resource Pool | Vnodes | CPU | GPU | Memory (GB) | Status | LastOpr | Health | Error | +-------+--------------+--------+--------+---------------+--------+-----+-----+-------------+--------+---------+-----------+-------+ +-------+--------------+--------+--------+---------------+--------+-----+-----+-------------+--------+---------+-----------+-------+ Helm/Flex Apps: +--------+------+--------+--------------+--------------+-----------+---------+ | Name | Type | State | Owner/Tenant | Namespace | Snapshots | Backups | +--------+------+--------+--------------+--------------+-----------+---------+ | mysql | helm | ONLINE | user1/t1 | t003-u000004 | 0 | 0 | +--------+------+--------+--------------+--------------+-----------+---------+ **Get detailed information about the resulting application:** .. code-block:: text # robin app info mysql Name : mysql Kind : helm State : ONLINE Number of repos : 0 Number of snapshots : 0 Number of usable backups : 0 Number of archived/failed backups : 0 Query: ------- {'namespace': 't003-u000004', 'apps': ['helm/billowing-tortoise'], 'resources': [], 'selectors': []} .. Upload a Helm chart as a Bundle -------------------------------- In addition to supporting the registration of a Helm release as an application, Robin Platform also provides a mechanism for uploading a Helm chart to a Robin Platform cluster as a Helm Bundle. This allows for Helm chart installation and Helm release registration to be performed in a single operation. In addition, creating the application using a Helm Bundle will ensure that the application is deployed in the proper Kubernetes namespace (the current user's assigned namespace) and that the application uses Robin Storage (both requirements). The following steps outline how to upload a Helm chart to a Robin Platform cluster as a Helm Bundle and how to deploy an application using the uploaded bundle. The following example assumes that Robin Platform user **user1* who is a member of tenant **t1** already exists in the cluster. **Log in as user1:** .. code-block:: text # robin login user1 Password: User user1 is logged into t1 tenant **Search for the stable/mysql Helm chart:** .. code-block:: text # helm search stable/mysql NAME CHART VERSION APP VERSION DESCRIPTION stable/mysql 1.6.2 5.7.28 Fast, reliable, scalable, and easy to use open-source rel... stable/mysqldump 2.6.0 2.4.1 A Helm chart to help backup MySQL databases using mysqldump **Fetch a copy of the stable/mysql Helm chart from the Helm Repository:** .. code-block:: text # helm fetch stable/mysql **Upload the stable/mysql Helm chart to the Robin Platform cluster as a HELM Bundle:** .. code-block:: text # robin bundle add mysql helm-1.6.2 mysql-1.6.2.tgz --helmchart File upload: 100% -- (11063/11063) Job: 61 Name: BundleAdd State: VALIDATED Error: 0 Job: 61 Name: BundleAdd State: COMPLETED Error: 0 # robin bundle list Bundle Id | Type | Owner/Tenant | Name | Version | Zone Id | Content Id | Description | Group Id | #Templates | #Apps ----------+-------+----------------------+----------+------------+------------+----------------------------------+-------------+----------+------------+------- 1 | HELM | admin1/t1 | mysql | helm-1.6.2 | 1580884960 | 00f4243a24cc74624d7272a6217d425f | - | 3 | 0 | 0 **Create a HELM Application using the uploaded HELM Bundle:** .. code-block:: text # robin app create from-bundle mysql-hb1 3 --wait Job: 105 Name: K8SApplicationCreateHelm State: VALIDATED Error: 0 Job: 105 Name: K8SApplicationCreateHelm State: WAITING Error: 0 Job: 105 Name: K8SApplicationCreateHelm State: COMPLETED Error: 0 **Verify that the mysql-hb1 Helm release has been created:** .. code-block:: text # helm list --tls mysql-hb1 --tiller-namespace=t003-u000004 NAME REVISION UPDATED STATUS CHART APP VERSION NAMESPACE mysql-hb1 1 Wed Feb 5 16:20:13 2020 DEPLOYED mysql-1.6.2 5.7.28 t003-u000004 **Verify that the mysql-hb1 HELM Application has been registered:** Note that the listing will include all applications the current user is entitled to view. This would include applications created from Robin Bundles as well as registered applications of type ``helm`` and ``flexapp``. .. code-block:: text # robin app list ROBIN Bundle Apps: +-------+--------------+--------+--------+---------------+--------+-----+-----+-------------+--------+---------+-----------+-------+ | Name | Owner/Tenant | Type | Parent | Resource Pool | Vnodes | CPU | GPU | Memory (GB) | Status | LastOpr | Health | Error | +-------+--------------+--------+--------+---------------+--------+-----+-----+-------------+--------+---------+-----------+-------+ +-------+--------------+--------+--------+---------------+--------+-----+-----+-------------+--------+---------+-----------+-------+ Helm/Flex Apps: +-----------+------+--------+--------------+--------------+-----------+---------+ | Name | Type | State | Owner/Tenant | Namespace | Snapshots | Backups | +-----------+------+--------+--------------+--------------+-----------+---------+ | mysql-hb1 | helm | ONLINE | user1/t1 | t003-u000004 | 0 | 0 | +-----------+------+--------+--------------+--------------+-----------+---------+ Robin Helm Operations ===================== Helm is a package manager for Kubernetes that simplifies application deployment and management. It uses packages called *charts*, which contain all the necessary resources and configurations. Robin’s integrated Helm support provides a streamlined way to deploy and manage these charts within the CNP environment. The ``robin helm command`` manages Helm-related operations within Robin. Supported Helm Commands ------------------------ =============================== ================================================================================= ``install`` Use this command to install a Helm chart. ``list (ls)`` Use this command to get a list of all the Helm releases. ``get`` Use this command to get details about a Helm release. ``status`` Use this command to view the status of a Helm release. ``show`` Use this command to view details about a Helm chart. ``search`` Use this command to search for Helm charts. ``repo`` Use this command to manage Helm chart repositories. ``registry`` Use this command to manage OCI-compliant container registries for Helm charts. ``upgrade`` Use this command to upgrade a Helm release. ``uninstall`` Use this command to uninstall a Helm release. =============================== ================================================================================= Manage Helm repositories ------------------------- Use the ``robin helm repo`` command to manage the sources of Helm charts that can be deployed within Robin CNP. This command allows you to add, list, update, and remove Helm repositories, making charts available for deployment. **Subcommands:** * ``robin helm repo add`` * ``robin helm repo list`` * ``robin helm repo update`` * ``robin helm repo remove`` Add a Helm Repository ---------------------- You can add charts from public or private Helm repositories. To add a new Helm chart repository, run the following command: .. code-block:: text # robin helm repo add --username **Prerequisites** * The chart must exist in a configured repository or registry. * If you are trying to access charts in a private OCI registry, you need to use the ``robin helm registry add`` command *and* log in to the registry using ``robin helm registry login`` *before* attempting to install charts from it. * If the repository requires authentication (e.g., for a private repository), you must provide the necessary credentials using the ``--username`` and ``--password`` options, or the ``--ca-file``, ``--cert-file``, and ``--key-file`` options for certificate-based authentication. **Arguments** =============================== ================================================================================= ``repo_name`` (required) A unique name for the repository. This name is used to refer to the repository in other robin helm repo commands. ``url`` (required) The URL of the Helm chart repository. This is typically an HTTP or HTTPS address. =============================== ================================================================================= **Options** =============================== ================================================================================= ``--username USERNAME`` Authentication username for the repository (if required). ``--password PASSWORD`` Authentication password for the repository (if required). ``--ca-file CA_FILE`` Pathname for the CA certificate file, used for secure (TLS) communication with the Helm repository. Required if the repository uses a self-signed certificate or a certificate signed by an internal Certificate Authority. ``--cert-file CERT_FILE`` Pathname for the client certificate file, used for secure (TLS) communication with the Helm repository when client certificate authentication is required. ``--key-file KEY_FILE`` Pathname for the client key file, used in conjunction with --cert-file for client certificate authentication. ``--insecure-skip-tls-verify`` Skip TLS certificate checks for the repository. Warning: This option should only be used for testing purposes or with trusted repositories, as it bypasses security checks. ``--allow-deprecated-repos`` Allow adding official repositories that have been permanently deleted. This option is generally not recommended. ``--force-update`` Replace (overwrite) the repository if it already exists. Use this if you need to update the URL or authentication information for an existing repository. =============================== ================================================================================= **Example** .. code-block:: text robin helm repo add my-bitnami https://charts.bitnami.com/bitnami This example adds the Bitnami Helm repository with the name ``my-bitnami``. **Example with Authentication:** .. code-block:: text robin helm repo add my-private-repo https://my-private-repo.example.com --username myuser --password mypassword This example adds a private Helm repository that requires username and password authentication. .. note:: After adding a repository, it's important to run ``robin helm repo update`` to update the local cache of charts. List Helm Repositories ----------------------- To view a list of all configured Helm chart repositories, run the following command: .. code-block:: text robin helm repo list [options] **Options:** =============================== ================================================================================= ``--json`` Output the repository list in JSON format. This is useful for scripting and automation. =============================== ================================================================================= **Example** .. code-block:: text # robin helm repo list NAME | URL ----------+------------------------------------------------------ helmrepo2 | http://[fd74:ca9b:3a09:868c:10:9:61:97]/helm-charts/ helmrepo3 | http://[fd74:ca9b:3a09:868c:10:9:61:97]/helm-charts/ helmrepo0 | http://[fd74:ca9b:3a09:868c:10:9:61:97]/helm-charts/ helmrepo5 | http://[fd74:ca9b:3a09:868c:10:9:61:97]/helm-charts/ This command will display a list of the configured Helm repositories. Update Helm Repositories ------------------------- To update the list of Helm charts in the configured Helm chart repositories, run the following command: .. code-block:: text robin helm repo update [repo_name] **Arguments:** =============================== ================================================================================= ``repo_name`` (optional) The name of a specific repository to update. If no repository name is specified, all configured repositories will be updated. =============================== ================================================================================= **Example:** .. code-block:: text # robin helm repo update Successfully updated all Helm repositories This command updates all configured Helm repositories. **Example Updating a Specific Repository:** .. code-block:: text # robin helm repo update my-bitnami This command updates only the repository named ``my-bitnami``. .. note:: You should run this command periodically to keep your chart information up-to-date. Remove Helm Repositories ------------------------- To remove a configured Helm chart repository, run the following command: .. code-block:: text robin helm repo remove repo_name **Arguments** =============================== ================================================================================= ``repo_name`` (optional) The name of a specific repository to remove. =============================== ================================================================================= **Example:** .. code-block:: text # robin helm repo remove my-bitnami This command removes the Helm repository named ``my-bitnami``. .. note:: * Removing a repository does not uninstall any applications that were deployed from that repository. * Ensure you are not removing a repository that is required for existing deployments. Manage Helm Registries ------------------------ Use the ``robin helm registry`` command to manage the sources of Helm charts stored as OCI artifacts. OCI artifacts are files that are stored in container registries. The term OCI artifact refers to any file or collection of files that is stored in an OCI-compliant registry. To learn more about OCI registries, see `Helm | Use OCI-based registries `. This command allows you to add, list, log in to, log out from, update, and remove Helm registries, allowing you to access and deploy charts stored in these registries. **Subcommands:** * ``robin helm registry add`` * ``robin helm registry list`` * ``robin helm registry login`` * ``robin helm registry logout`` * ``robin helm registry update`` * ``robin helm registry remove`` Add a Helm Registry --------------------- To add a new Helm registry to the list of available registries, run the following command: .. code-block:: text robin helm registry add [options] name hostname project [registry_type] **Arguments:** =============================== ================================================================================= ``name`` (required) A unique name for the registry within the CNP. This name is used to refer to the registry in other robin helm registry commands. ``hostname`` (required) The hostname of the container registry (e.g., ``project`` (required) The project (or namespace) within the container registry where the Helm charts are stored (e.g., your Docker Hub username, a project in Harbor). ``registry_type`` (optional) The type of OCI-compliant container registry. Currently, supported values are 'DOCKER' or 'HARBOR'. Defaults to 'DOCKER'. =============================== ================================================================================= **Options:** =============================== ================================================================================= ``--username USERNAME`` Authentication username for the registry (if required). ``--password PASSWORD`` Authentication password for the registry (if required). ``--ca-file CA_FILE`` Pathname for the CA certificate file, used for secure (TLS) communication with the Helm registry. Required if the registry uses a self-signed certificate or a certificate signed by an internal Certificate Authority. ``--cert-file CERT_FILE`` Pathname for the client certificate file, used for secure (TLS) communication with the Helm registry when client certificate authentication is required. ``--key-file KEY_FILE`` Pathname for the client key file, used in conjunction with ``--cert-file`` for client certificate authentication. ``--insecure-skip-tls-verify`` Skip TLS certificate checks for the registry. **Warning:** This option should only be used for testing purposes or with trusted repositories, as it bypasses security checks. =============================== ================================================================================= **Exmaple:** .. code-block:: text robin helm registry add my-docker-hub docker.io myusername This example adds Docker Hub as a registry named ``my-docker-hub``, with ``myusername`` as the project. **Example with a Private Registry and Credentials:** .. code-block:: text robin helm registry add my-private-registry my-registry.example.com myproject --username myuser --password mypassword This example adds a private container registry named ``my-private-registry`` that requires username and password authentication. **Example with Harbor Registry:** .. code-block:: text robin helm registry add my-harbor-registry harbor.example.com myproject HARBOR --username myuser --password mypassword .. note:: After adding a registry, you typically need to log in using ``robin helm registry`` login. List Helm Repositories ----------------------- To list all configured Helm registries, run the following command: .. code-block:: text robin helm registry list [options] **Options:** =============================== ================================================================================= ``--json`` Output the registry list in JSON format. This is useful for scripting and automation. =============================== ================================================================================= **Example:** .. code-block:: text robin helm registry list This command will display a list of the configured Helm registries. Log In to a Helm Registry -------------------------- To log in to a configured Helm registry, run the following command: .. code-block:: text robin helm registry login [options] name **Arguments:** =============================== ================================================================================= ``name`` (required) The name of the registry to log in to (as defined when adding the registry with ``robin helm registry add``). =============================== ================================================================================= **Options:** =============================== ================================================================================= ``--username USERNAME`` Authentication username for the registry (if required). If not provided, you may be prompted to enter it. ``--password PASSWORD`` Authentication password for the registry (if required). If not provided, you may be prompted to enter it. =============================== ================================================================================= **Example:** .. code-block:: text robin helm registry login my-docker-hub .. note:: You must add the registry using ``robin helm registry add`` before you can log in. Log Out from a Helm Registry ----------------------------- To log out from a configured Helm registry, run the following command: .. code-block:: text robin helm registry logout name **Arguments:** =============================== ================================================================================= ``name`` (required) The name of the registry to log out from (as defined when adding the registry with ``robin helm registry add``). =============================== ================================================================================= **Example:** .. code-block:: text robin helm registry logout my-docker-hub This command logs out from the Docker Hub registry. .. note:: Logging out prevents you from pulling Helm charts from the registry until you log in again. Update Helm Registries ----------------------- To update the Helm registries, run the following command: .. code-block:: text robin helm registry update [registry_name] **Arguments:** =============================== ================================================================================= ``registry_name`` (optional) The name of a specific registry to update. If no registry name is specified, all configured registries will be updated. =============================== ================================================================================= **Example:** .. code-block:: text robin helm registry update my-docker-hub This command updates only the registry named ``my-docker-hub``. Remove a Helm Registry ----------------------- To remove a configured Helm registry, run the following command: .. code-block:: text robin helm registry remove name **Arguments:** =============================== ================================================================================= ``registry_name`` (optional) The name of a specific registry to remove (as defined when adding the registry with ``robin helm registry add``) =============================== ================================================================================= **Example:** .. code-block:: text robin helm registry remove my-docker-hub This command removes the Docker Hub registry. Search Helm charts ------------------- To search for available Helm charts in the configured Helm repositories, run the following command: .. code-block:: text robin helm search [options] [chart_name] **Arguments:** ========================= ============================================================================= ``chart_name`` (optional) The name of the chart to search for. If specified, the command will search for charts with that exact name (unless --pattern is used). If not specified, all the charts from all the repositories will be searched. ========================= ============================================================================= **Options:** =========================================================== ============================================================================= ``--repo-name REPO_NAME, --repo REPO_NAME`` The name of the Helm repository to search in. If specified, the command will only search in this repository. You can use robin helm repo list to see a list of configured repositories. ``--registry-name REGISTRY_NAME, --registry REGISTRY_NAME`` The name of the OCI registry to search in. If specified, the command will only search in this registry. You can use robin helm registry list to see a list of configured registries. ``--version VERSION`` The version of the chart to search for (only valid when chart_name is specified). If specified, the command will only search for charts with that specific version. ``--all-versions, --all`` List all available versions of the chart (only valid when chart_name is specified). If specified, the command will display all versions of the chart that are available. ``--pattern PATTERN`` A pattern to use when performing the Helm search (not valid when chart_name is specified). This option allows you to use wildcards or regular expressions to search for charts. ``--exact-match`` Exact match if chart_name is specified. ``--full`` Output additional information about each chart, such as its description, version, and maintainers. ``--json`` Output the search results in JSON format. This is useful for scripting and automation. =========================================================== ============================================================================= **Examples:** 1. Search for a chart named "nginx" in all configured repositories and registries: .. code-block:: text [root@hypervvm-63-117 ~]# robin helm search nginx NAME | VERSION | APP_VERSION -----------------------------------+---------+------------- helmrepo0/nginx | 18.3.1 | 1.27.3 helmrepo0/nginx-ingress-controller | 11.6.0 | 1.11.3 helmrepo0/nginx-intel | 2.1.15 | 0.4.9 helmrepo2/nginx | 18.3.1 | 1.27.3 helmrepo2/nginx-ingress-controller | 11.6.0 | 1.11.3 helmrepo2/nginx-intel | 2.1.15 | 0.4.9 helmrepo3/nginx | 18.3.1 | 1.27.3 helmrepo3/nginx-ingress-controller | 11.6.0 | 1.11.3 helmrepo3/nginx-intel | 2.1.15 | 0.4.9 2. Search for a chart named "nginx" in the "bitnami" repository: .. code-block:: text robin helm search nginx --repo helmrepo0 3. Search for a chart named "nginx" in the "my-docker-hub" registry: .. code-block:: text robin helm search nginx --registry my-docker-hub 4. Search for a specific version of the "nginx" chart: .. code-block:: text [root@hypervvm-63-117 ~]# robin helm search nginx --version 2.1.15 NAME | VERSION | APP_VERSION ----------------------+---------+------------- helmrepo0/nginx-intel | 2.1.15 | 0.4.9 helmrepo2/nginx-intel | 2.1.15 | 0.4.9 helmrepo3/nginx-intel | 2.1.15 | 0.4.9 helmrepo5/nginx-intel | 2.1.15 | 0.4.9 5. List all versions of the "nginx" chart: .. code-block:: text robin helm search nginx --all-versions 6. Search for charts with a name matching the pattern "redis" (starts with redis):* .. code-block:: text robin helm search --pattern "redis*" .. note:: * Make sure you have updated your repositories with robin helm repo update before searching. * Make sure you have added and logged into your registries using ``robin helm registry add`` and ``robin helm registry login`` before searching. Show details about a Helm chart -------------------------------- Use the robin helm show command to inspect the contents of a chart, including its metadata, default values, Custom Resource Definitions (CRDs), and README. To view detailed information about a Helm chart, run the following command: .. code-block:: text robin helm show [options] {all,chart,crds,readme,values} chart **Arguments:** .. code-block:: text {all,chart,crds,readme,values}(required): The type of chart information to return: ==================== ============================================================================= ``all`` Show all available information about the chart (combines the output of chart, crds, readme, and values). ``chart`` Show the chart's metadata (name, version, description, etc.). ``crds`` Show the Custom Resource Definitions (CRDs) defined in the chart. ``readme`` Show the chart's README file. ``values`` Show the chart's values.yaml file (the default configuration values). ``chart`` (required) The Helm chart reference. The format of the chart reference is'[:]/' (include ':' if the repository is OCI based). ==================== ============================================================================= **Options:** ===================== ============================================================================= ``--version VERSION`` The Helm chart version to show. If not specified, the latest version will be shown. ===================== ============================================================================= **Examples:** 1. Show all information about the latest version of the "nginx" chart from the Bitnami repository: .. code-block:: text robin helm show all bitnami/nginx 2. Show the chart metadata for version 2.1.15 of the "nginx" chart from the Bitnami repository: .. code-block:: text robin helm show chart bitnami/nginx --version 2.1.15 3. Show the CRDs for the latest version of the "cert-manager" chart from the Jetstack repository: .. code-block:: text robin helm show crds jetstack/cert-manager 4. Show the README file for the latest version of the "redis" chart from the Bitnami repository: .. code-block:: text robin helm show readme bitnami/redis 5. Show the values.yaml file for the latest version of the "nginx" chart from the Bitnami repository: .. code-block:: text robin helm show values bitnami/nginx 6. Show the values.yaml file for a chart in an OCI registry: .. code-block:: text robin helm show values docker.io/bitnami/nginx .. note:: If you are using a chart from a private repository or registry, you must have added the repository or registry and logged in before you can use this command. Install a Helm chart --------------------- Use the robin helm install command to install a Helm chart in your Kubernetes cluster. To install a helm chart and all its associated resources, run the following command: .. code-block:: text robin helm install [options] name chart_name [extra_options] **Arguments:** ============================ ============================================================================= ``name`` (required) The name of the Helm release. This name must be unique within the namespace where you are deploying the chart. ``chart_name`` (required) The Helm chart reference. This specifies the chart to install. The format is / for charts in a Helm repository or :/ for charts in an OCI registry. ``extra_options`` (optional) A string containing additional command-line options that need to be passed directly to the underlying helm command. This allows you to use Helm options that are not explicitly exposed by the robin helm install command. This string must be enclosed in double quotes and preceded by the -- parameter. ============================ ============================================================================= **Options:** ========================================= ============================================================================= ``--version VERSION`` The specific version of the chart to install. If not specified, the latest version will be used. ``--namespace NAMESPACE, -n NAMESPACE`` The namespace in which to install the release. If not specified, the user's current namespace will be used. ``--set SET_LIST`` Set values on the command line. This allows you to override individual values in the chart's values.yaml file. You can specify multiple values separated by commas (e.g., key1=val1,key2=val2). ``--skip-crds`` If set, no Custom Resource Definitions (CRDs) will be installed. By default, CRDs are installed if they are not already present in the cluster. ``--insecure-skip-tls-verify`` Skip TLS certificate checks for the repository. Warning: This option should only be used for testing purposes or with trusted repositories, as it bypasses security checks. ``--atomic`` If set, the installation process will delete the installation on failure. The --wait flag will be set automatically if --atomic is used. This ensures that failed installations are cleaned up, preventing orphaned resources. ``--helm-wait`` If set, will wait until all Pods, PVCs, Services, and a minimum number of Pods of a Deployment, StatefulSet, or ReplicaSet are in a ready state before marking the release as successful. It will wait for as long as --timeout. ``--timeout DURATION`` The time to wait for any individual Kubernetes operation (like Jobs for hooks) (default: 5m0s). ``--dry-run {true,false,client,server}`` Simulate an install. Options: true: No release will be installed. client: Helm will not attempt cluster connections. server: Helm will attempt cluster connections. false: (Default) No dry run will be performed. ``--wait`` Wait for the command to complete before returning. This option is useful for ensuring that the installation is successful before proceeding with other tasks. ========================================= ============================================================================= **Example:** 1. Install the latest version of the "nginx" chart from the Bitnami repository with the release name "my-nginx": .. code-block:: text robin helm install my-nginx bitnami/nginx 2. Perform a dry run of the installation: .. code-block:: text robin helm install my-chart bitnami/mychart --dry-run true 3. Install the "my-app" chart using a custom values.yaml file: .. code-block:: text robin helm install my-app bitnami/myapp --values my-values.yaml Listing all Helm releases -------------------------- To view a list of Helm releases in a specific namespace or in your current namespace, run the following command: .. code-block:: text robin helm list [--namespace] [--valuesyaml] [--json] name **Arguments:** =================== ============================================================================= ``name`` (required) The name of the Helm release to list. If omitted, all releases in the namespace are listed. =================== ============================================================================= **Options:** ========================= ============================================================================= ``--namespace Namespace`` Specifies the namespace to list releases from. If not provided, the user's current namespace is used. ``--values yaml`` Retrieves the values.yaml file for the specified release. ``--json`` Outputs the list of releases in JSON format. ========================= ============================================================================= **Examples:** List all releases in the current namespace: .. code-block:: text [root@hypervvm-63-117 ~]# robin helm list Name | Namespace | Revision | Status | Chart | App Version | Registered Appname | Owner/Tenant --------------------+-----------+----------+----------+--------------+-------------+--------------------+---------------------- helmapprepo5 | ns1 | 1 | deployed | mysql-12.2.0 | 8.4.3 | helmapprepo5 | robin/Administrators helmapprepo5ssclone | ns1 | 1 | deployed | mysql-12.2.0 | 8.4.3 | | multicommapp | ns1 | 1 | deployed | dpdk-0.1.0 | 1.0 | multicommapp | robin/Administrators View Status of a Helm release ------------------------------ To view the status of a Helm release, including information about its resources and current state, run the following command: .. code-block:: text robin helm status [--namespace] [--json] name **Arguments:** =================== ============================================================================= ``name`` (required) The name of the Helm release to list. If omitted, all releases in the namespace are listed. =================== ============================================================================= **Options:** ========================= ============================================================================= ``--namespace Namespace`` Specifies the namespace to list releases from. If not provided, the user's current namespace is used. ``--json`` Outputs the list of releases in JSON format. ========================= ============================================================================= **Example:** Get details about a Helm Release --------------------------------- Use the ``robin helm get`` command to inspect the configuration, manifests, hooks, and notes associated with a specific release. To retrieve detailed information about a deployed Helm release, run the following command: .. code-block:: text robin helm get [options] {all,hooks,manifest,metadata,notes,values} release **Arguments:** .. code-block:: text {all,hooks,manifest,metadata,notes,values} **Options:** ======================================= ============================================================================= ``--namespace NAMESPACE, -n NAMESPACE`` Specifies the namespace to get the release from. If not specified, the command will use the user's current namespace. ======================================= ============================================================================= **Examples:** 1. Show all information about the "my-nginx" release in the "my-namespace" namespace: .. code-block:: text robin helm get all my-nginx --namespace my-namespace 2. Show the hooks associated with the "my-redis" release in the current namespace: .. code-block:: text robin helm get hooks my-redis 3. Show the Kubernetes manifests for the "my-app" release in the "production" namespace: .. code-block:: text robin helm get manifest my-app --namespace production 4. Show the notes for the "my-chart" release in the current namespace: .. code-block:: text robin helm get notes my-chart 5. Show the values used to configure the "my-release" release in the "staging" namespace: .. code-block:: text robin helm get values my-release --namespace staging 6. Show the metadata for the "my-release" release in the "default" namespace: .. code-block:: text robin helm get metadata my-release --namespace default Upgrade Helm Releases ---------------------- Use the ``robin helm upgrade`` command to upgrade an existing Helm release to a newer version of the chart. This command allows you to update your deployed applications with new features, bug fixes, or configuration adjustments. .. code-block:: text # robin helm upgrade [options] release_name chart_name **Arguments:** ================ ============================================================================= ``release_name`` The name of the Helm release to upgrade. This is the name you specified when you initially installed the chart using robin helm install. ``chart_name`` The name of the chart to upgrade to. This can be the same chart name as the original deployment (to upgrade to a newer version) or a different chart name (to migrate to a different application). ================ ============================================================================= **Options:** ======================================= ============================================================================= ``--repo-name REPO_NAME`` The name of the Helm repository where the chart is located. If specified, the command will only search for the chart in this repository. If not specified, the command will search all configured repositories. ``--namespace NAMESPACE, -n NAMESPACE`` The namespace in which the release is deployed. If not specified, the command will use the user's current namespace. ``--version VERSION`` The specific version of the chart to upgrade to. If not specified, the latest version will be used. ``--values VALUES_PATH`` The pathname to a values.yaml file that contains configuration overrides. This file allows you to customize the deployment by overriding the default values in the chart. ``--wait`` Wait for the command to complete before returning. This option is useful for ensuring that the upgrade is successful before proceeding with other tasks. ======================================= ============================================================================= **Examples:** 1. Upgrade the "my-nginx" release to the latest version of the "nginx" chart from the Bitnami repository: .. code-block:: text robin helm upgrade my-nginx bitnami/nginx 2. Upgrade the "my-redis" release to version 6.2.6 of the "redis" chart from the Bitnami repository, waiting for the command to complete: .. code-block:: text robin helm upgrade my-redis bitnami/redis --version 6.2.6 --wait 3. Upgrade the "my-app" release using a custom values.yaml file: .. code-block:: text robin helm upgrade my-app bitnami/myapp --values my-values.yaml 4. Upgrade the "my-app" release from a specific repo: .. code-block:: text robin helm upgrade my-app myrepo/myapp Uninstall a Helm Release ------------------------ To uninstall a Helm release and delete all its associated resources, run the following command: .. code-block:: text # robin helm uninstall --namespace **Arguments:** =================== ============================================================================= ``name`` (required) The name of the Helm release to list. If omitted, all releases in the namespace are listed. =================== ============================================================================= **Options:** ========================= ============================================================================= ``--namespace Namespace`` Specifies the namespace to list releases from. If not provided, the user's current namespace is used. ========================= ============================================================================= **Example:** .. code-block:: text robin helm uninstall my-release Robin FlexApp Applications ========================== Robin Platform provides a very flexible mechanism for registering any set of Kubernetes resources as a Robin Application. The **FlexApp** construct uses label selector rules to group the resources together. For example, ``--select app=apache --select app=mysql`` would select Pods and PVCs for a web and database tier together into a single FlexApp object. To create a FlexApp, use this command: .. code-block:: text # robin app register --selector = --resource / --namespace --dry-run =================================================== ================================= ```` Name to assign to FlexApp ``--selector =`` Resources with these Kubernetes labels would be selected to be part of this FlexApp ``--resource /`` Resources of the specified type and name would be selected to be part of this FlexApp ``--namespace `` Namespace in which the Kubernetes resources are deployed. ``--dry-run`` Using this option would display the kind, name and status of the objects to be picked up. Note, this will not register the application. =================================================== ================================= **Selecting resources that have more than one matching label (AND condition):** This is achieved by comma-seperating label name=value pairs as follows: ``--select tier=frontend,env=dev`` will select resources that have both ``tier = frontend`` AND ``env = dev`` labels on it. **Selecting resources that have at least one of the matching labels (OR condition):** This is achieved by specifying the ``--select`` option multiple times. For example: ``--select env=dev --select env=prod`` will select any resource that has either ``env = dev`` or ``env = prod`` labels on it. **Selecting resources of a certain type with matching labels:** Let's say one wants to select only PersistentVolumeClaims and StatefulSelect type resources with matching labels. That is, any other resource with a matching label should not be selected. This is achieved by specifying the resource name as a prefix to the label name as follows: ``--select pvc,statefulset:tier=database`` **Explicitly selecting certain resources:** The ``--resource`` option is used to specify explicitly which Kubernetes resources are to be made part of the FlexApp. The format to specify this is as follows: ``--resource /``, where ```` is any of the resources ("Kind") that the Kubernetes cluster recognizes, such as PersistentVolumeClaims (pvc), StatefulSets, Services, etc. * Running ``kubectl api-resources`` would list all valid values of ```` * Running ``kubectl get `` would list all valid ```` of that specific resource type Create an Application ===================== Robin supports the creation of applications from a number of sources: ========================= =================== from-bundle Create an application from a ROBIN Application Bundle or Helm Bundle from-snapshot Create a clone of an existing application from one of the application's snapshots from-backup Create a new application instance from an application backup ========================= =================== Create an application from a Bundle ------------------------------------ .. tabs:: .. tab:: CLI An application instance can be created from either Robin Application or Helm based Bundle with the following command: .. code-block:: text # robin app create from-bundle [