****************************** 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 =============================== ================================================================================= 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. To command to create/register a FlexApp, is detailed in the sections below. 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. - Releases 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. .. Register a Helm Release ^^^^^^^^^^^^^^^^^^^^^^^ *Helm 3 workflow goes here* Register a Helm Release (Helm 2) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ .. note:: Support for Helm 2 and Tiller is deprecated and will be removed in the next release. Following is a step-by-step walkthrough, showing how to configure the Helm environment 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** **Deploy Tiller objects for user1's assigned namespace:** The following command creates a number of Kubernetes resources (tiller ServiceAccount and RoleBinding) that will be needed by Tiller when it gets deployed into the user's assigned namespace. .. code-block:: text # robin k8s deploy-tiller-objects t003-u000004 Tiller objects were successfully deployed for namespace 't003-u000004' **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 **Set up Helm and deploy Tiller in user1's assigned namespace:** The following command sets up Helm for use by the current Robin Platform user (user1). It first copies the CA cert and the user’s cert and key into the .helm directory in the user’s HOME directory. It then issues a 'helm2 init' command to deploy Tiller into the user's assigned namespace. .. code-block:: text # robin k8s helm-setup t003-u000004 Helm initialized successfully **Wait for Tiller to be deployed:** .. code-block:: text # helm2 list --tls --tiller-namespace=t003-u000004 Error: could not find tiller Repeat the above command until no errors are returned **Add the stable Helm repo for the current user:** .. code-block:: text # helm2 repo add stable https://kubernetes-charts.storage.googleapis.com "stable" has been added to your repositories **Install the stable/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 # helm install stable/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 Helm 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 Helm release as a HELM Application:** .. code-block:: text # robin app register mysql --app helm/billowing-tortoise -n t003-u000004 Job: 114 Name: K8SAppRegister State: PREPARED Error: 0 Job: 114 Name: K8SAppRegister State: COMPLETED Error: 0 **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 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 [