Skip to main content
Astra Control Center
A newer release of this product is available.

Start managing apps

Contributors netapp-mwallis

After you add a cluster to Astra Control management, you can install apps on the cluster (outside of Astra Control) and then go to the Applications page in Astra Control to start managing the apps and their resources.

For more information, see App management requirements.

Supported app installation methods

Astra Control supports the following application installation methods:

  • Manifest file: Astra Control supports apps installed from a manifest file using kubectl. For example:

    kubectl apply -f myapp.yaml
  • Helm 3: If you use Helm to install apps, Astra Control requires Helm version 3. Managing and cloning apps installed with Helm 3 (or upgraded from Helm 2 to Helm 3) are fully supported. Managing apps installed with Helm 2 is not supported.

  • Operator-deployed apps: Astra Control supports apps installed with namespace-scoped operators that are, in general, designed with a "pass-by-value" rather than "pass-by-reference" architecture. An operator and the app it installs must use the same namespace; you might need to modify the deployment .yaml file for the operator to ensure this is the case.

    The following are some operator apps that follow these patterns:

    • Apache K8ssandra

      Note For K8ssandra, in-place restore operations are supported. A restore operation to a new namespace or cluster requires that the original instance of the application to be taken down. This is to ensure that the peer group information carried over does not lead to cross-instance communication. Cloning of the app is not supported.
    • Jenkins CI

    • Percona XtraDB Cluster

Astra Control might not be able to clone an operator that is designed with a “pass-by-reference” architecture (for example, the CockroachDB operator). During these types of cloning operations, the cloned operator attempts to reference Kubernetes secrets from the source operator despite having its own new secret as part of the cloning process. The clone operation might fail because Astra Control is unaware of the Kubernetes secrets in the source operator.

Install apps on your cluster

After you've added your cluster to Astra Control, you can install apps or manage existing apps on the cluster. Any app that is scoped to a single namespace can be managed.

Manage apps

After Astra Control discovers namespaces on your clusters, you can define applications that you want to manage. You can choose to manage an entire namespace as a single application or manage one or more apps in the namespace individually. It all comes down to the level of granularity that you need for data protection operations.

Although Astra Control enables you to separately manage both levels of the hierarchy (the namespace and the apps in that namespace), the best practice is to choose one or the other. Actions that you take in Astra Control can fail if the actions take place at the same time at both the namespace and app level.

Tip As an example, you might want to set a backup policy for "maria" that has a weekly cadence, but you might need to back up "mariadb" (which is in the same namespace) more frequently than that. Based on those needs, you would need to manage the apps separately and not as a single-namespace app.
What you'll need

Before you begin, you should also understand managing standard and system namespaces.

For instructions on how to manage apps using the Astra Control API, see the Astra Automation and API information.

Additional app management options

Define resources to manage as an app

You can specify the Kubernetes resources that make up an app that you want to manage with Astra Control. Defining an app enables you to group elements of your Kubernetes cluster into a single app. This collection of Kubernetes resources is organized by namespace and label selector criteria.

Defining an app gives you more granular control over what to include in an Astra Control operation, including clone, snapshot, and backups.

Warning When defining apps, ensure that you do not include a Kubernetes resource in multiple apps with protection policies. Overlapping protection policies on a Kubernetes resources can cause data conflicts. Read more about best practices.
  1. From the Applications page, select Define.

  2. In the Define application window, enter the app name.

  3. Choose the cluster on which your application is running in the Cluster drop-down list.

  4. Choose the namespace of your application from the Namespace drop-down list.

    Note Apps can be defined only within a specified namespace on a single cluster. Astra Control does not support the ability for apps to span multiple namespaces or clusters.
  5. Enter a label for the app and namespace. You can specify a single label or label selector criteria (query).

    Tip To learn more about Kubernetes labels, see the official Kubernetes documentation.
  6. After you select Define, repeat the process for other apps, as needed.

After you finish defining an app, the app appears in the list of apps on the Applications page. You are now able to clone it and create backups and snapshots.

Note The app you just added might have a warning icon under the Protected column, indicating that it is not backed up and not scheduled for backups yet.
Tip To see details of a particular app, select the app name.

Define a namespace to manage as an app

You can add all Kubernetes resources in a namespace to Astra Control management by defining the resources of that namespace as an application. This method is preferable to defining apps individually if you intend to manage and protect all resources in a particular namespace in a similar way and at common intervals.

  1. From the Clusters page, select a cluster.

  2. Select the Namespaces tab.

  3. Select the Actions menu for the namespace that contains the app resources you want to manage and select Define as application.

    Tip If you want to manage multiple namespaces, select the namespaces and select the Actions button in the upper-left corner and select manage.
    Note Select the Show system namespaces checkbox to reveal system namespaces that are usually not used in app management by default. A screenshot that shows the <strong>Show system namespaces</strong> option that is available in the Namespaces tab. Read more.

After the process completes, the applications that are associated with the namespace appear in the Associated applications column.

Unmanage apps

When you no longer want to back up, snapshot, or clone an app, you can stop managing it.

Note If you unmanage an app, any backups or snapshots that were created earlier will be lost.
  1. From the left navigation bar, select Applications.

  2. Select the app.

  3. From the menu in the Actions column, select Unmanage.

  4. Review the information.

  5. Type "unmanage" to confirm.

  6. Select Yes, Unmanage Application.

What about system namespaces?

Astra Control also discovers system namespaces on a Kubernetes cluster. We don't show you these system namespaces by default because it's rare that you'd need to back up system app resources.

You can display system namespaces from the Namespaces tab for a selected cluster by selecting the Show system namespaces check box.

A screenshot that shows the <strong>Show system namespaces</strong> option that is available in the Namespaces tab.

Tip Astra Control itself is not a standard app; it is a "system app." You should not try to manage Astra Control itself. Astra Control itself isn't shown by default for management.

Example: Separate Protection Policy for different releases

In this example, the devops team is managing a "canary" release deployment. The team's cluster has three pods running NginX. Two of the pods are dedicated to the stable release. The third pod is for the canary release.

The devops team's Kubernetes admin adds the label deployment=stable to the stable release pods. The team adds the label deployment=canary to the canary release pod.

The team's stable release includes a requirement for hourly snapshots and daily backups. The canary release is more ephemeral, so they want to create a less aggressive, short-term Protection Policy for anything labeled deployment=canary.

In order to avoid possible data conflicts, the admin will create two apps: one for the "canary" release, and one for the "stable" release. This keeps the backups, snapshots, and clone operations separate for the two groups of Kubernetes objects.

Find more information