Release notes
Start managing apps
Suggest changes
PDFs
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:
-
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.
-
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.
|
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. |
-
A Kubernetes cluster added to Astra Control.
-
One or more installed apps on the cluster. Read more about supported app installation methods.
-
One or more active pods.
-
Namespaces specified on the Kubernetes cluster that you added to Astra Control.
-
(Optional) Kubernetes label on any supported Kubernetes resources.
A label is a key/value pair you can assign to Kubernetes objects for identification. Labels make it easier to sort, organize, and find your Kubernetes objects. To learn more about Kubernetes labels, see the official Kubernetes documentation.
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.
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.
|
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. |
-
From the Applications page, select Define.
-
In the Define application window, enter the app name.
-
Choose the cluster on which your application is running in the Cluster drop-down list.
-
Choose the namespace of your application from the Namespace drop-down list.
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. -
Enter a label for the app and namespace. You can specify a single label or label selector criteria (query).
To learn more about Kubernetes labels, see the official Kubernetes documentation. -
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.
|
|
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. |
|
|
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.
-
From the Clusters page, select a cluster.
-
Select the Namespaces tab.
-
Select the Actions menu for the namespace that contains the app resources you want to manage and select Define as application.
If you want to manage multiple namespaces, select the namespaces and select the Actions button in the upper-left corner and select manage.
Select the Show system namespaces checkbox to reveal system namespaces that are usually not used in app management by default. 
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.
|
|
If you unmanage an app, any backups or snapshots that were created earlier will be lost. |
-
From the left navigation bar, select Applications.
-
Select the app.
-
From the menu in the Actions column, select Unmanage.
-
Review the information.
-
Type "unmanage" to confirm.
-
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.
|
|
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.