Dashboard Overview

The K10 dashboard is broken up into a number of different sections. A brief description is provided in the sections below.

It is also possible to perform an interactive walkthrough of the K10 dashboard via a Guided Tour. The tour is available when the K10 dashboard is accessed for the first time or via the Interface page of the Settings menu in the navigation sidebar.

System Overview

The top of the K10 dashboard displays a list of applications (currently mapped to namespaces), any policies that might exist in the system, and a summary of the cluster's backup data footprint.

After filtering to only include applications that have stateful services (defined as containing a persistent volume), the above screen breaks down each section into three categories:

• Unmanaged: There are no protection policies that cover this object

• Non-compliant: A policy applies to this object but the actions associated with the policy are failing (e.g., due to underlying storage slowness, configuration problems, etc.) or the actions haven't been invoked yet (e.g., right after policy creation)

• Compliant: Objects that both policies apply to and the policy SLAs are being respected

Applications, Namespaces, and Workloads

The K10 platform by default equates namespaces to applications for ease of use and consistency with Kubernetes best practices, use of RBAC, and to mirror the most common application deployment pattern. However, as shown later, policies can be defined to operate on more than one namespace or only operate on a subset of an application residing in a single namespace.

Assuming you have already installed applications, clicking on the Applications card on the dashboard will take you to the following view. Note that if you clicked on one of the Compliant/Non-Compliant/Unmanaged buttons, it would automatically filter the below view for you.

Note

K10 classifies Pods, VirtualMachines, StatefulSets, Deployments and DeploymentConfigs as workloads.

An application, in turn, is made up of multiple Kubernetes resources and workloads. In the above diagram, the GitLab card shows that the application is composed of four volumes, seven network resources, three workloads, and two other pieces of application configuration. You can get more information about the application by clicking on the details icon.

Policies

Within K10, policies are used to automate your data management workflows. Going back to the main dashboard, you will find a section on how to manage policies right next to the Applications card. To achieve this, they combine actions you want to take (e.g., snapshot), a frequency or schedule for how often you want to take that action, and selection criteria for the resources you want to manage.

If you click on the Policies card, you will notice in the above screenshot that no default policies are created at install time but a policy can be either created from this page or from the application page shown earlier.

Settings

Accessible via the navigation sidebar, the Settings menu is where you can access and configure:

• System Information (Logs download, upgrade status, etc.)

• Licenses (K10 product licenses)

• K10 Disaster Recovery

• Interface (Light/Dark Mode, Guided Tour)

Support

Located at the bottom of the navigation sidebar Get Support is where you can find links to open a Support case, this documentation, and the Knowledge Base articles.

Activity

Below the policy management section of the dashboard, you will find activity data. This consists of a graph that shows all activity in the system. As there are no default policies, you will not see any activity after the initial install but, once policies are defined, the graph will start displaying activity. Mousing over the graph will display action information such as status, action duration, action start time, and action completion time.

Some of the same activity information can also be viewed in tabular form under the graph. In particular, the dashboard first displays a summary of activity in the system including total actions, average action duration, number of data artifacts, the size of those artifacts, etc.

Following the activity and artifact summary, information on recent actions is displayed. This includes the Policy that generated the action which may include the number of child actions, the number of applications included in the Policy run, and start and completion times. The display for manual actions, such as manual snapshots, will be slightly different listing the phases and number of artifacts included in the action. You can also filter the displayed actions by the originating Policy, type of action, failed actions, and completed actions.

Actions listed as "Policy Run" can be expanded by clicking on the row, bringing up the policy run page for that action. This page states the number of actions included in the policy run along the the names of the applications.

Actions in the running state can be cancelled. Click the running action in the actions list and look for the "Cancel Action" button on the action details panel. Cancellation is best-effort and may not take effect until the next cancellation checkpoint, typically between phases. See API Cancellation for more details.

Manual Actions

Apart from policies, it is also possible to manually create a one-off application snapshot or export. From the Applications page, simply click on the relevant icon.

With manual snapshots it is possible to set an expiration date for the snapshot. If this is not set then the snapshot will exist until it is manually deleted from the underlying system. Via the API this is done by setting spec.expiresAt.