Dashboard Overview

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

../_images/guided_tour.png

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 Dashboard option on the Settings page.

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.

../_images/dashboard_top.png

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 every 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 names 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.

../_images/overview_apps.png

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

../_images/application_details.png

Policies

../_images/dashboard_top.png

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.

../_images/policies_none.png

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

../_images/overview_settings.png

Accessible via the top right corner of the dashboard, the settings page is where you can configure:

Activity

../_images/dashboard_activity.png

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 job information such as status, job duration, job start time, and job 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 jobs, average job duration, number of data artifacts, the size of those artifacts, etc.

Following the activity and artifact summary, information on recent jobs is displayed. This includes the policy that generated the job, the job phases, type of generated artifacts, and the start and completion times. You can also filter the displayed jobs by the originating policy, type of job, failed jobs, and completed jobs.