Skip to main content

How can we help you?

Druva Documentation

Register New Clusters

To begin registering a new Kubernetes cluster, you need to grant CloudRanger permissions for cluster discovery. To do this, create or update your CloudFormation template to provision access to your Kubernetes environment.

The overall data protection and restore workflow of your Kubernetes clusters and application groups is illustrated below:

1_Reg New.png


Verify that the following tools are installed:

  • kubectl (v 1.19 and later), Kubernetes CLI tool
  • Helm (v 3.6.0), the package manager 
  • AWS Command Line Interface (CLI) v2, a unified tool to manage your AWS services
  • Generate the IAM keys from your AWS Management Console and configure them.
  • CSI External-Snapshotter (v 4.1.0)
  • The latest CSI driver for Amazon EBS, (to be installed post the installation of External Snapshotter)
  • Cert Manager (v 1.1.0 and later) and Service Catalog

For more information, see Prerequisites

Step 1: Grant Permissions for Cluster Discovery

  • Log in to the Druva CloudRanger console and navigate to Resources > Kubernetes. Click Register New Cluster.

1_Reg Cluster.png

  • Deploy the Kubernetes connection router to your Cluster’s VPC: To deploy the connection router, specify the parameters on the Register New Cluster page, and then test your connection.
Field Description

Simple (or) Advanced

  • Select the Advanced deployment option to generate a CloudFormation template that will install a Private connection router in your AWS account. 
    The Advanced deployment method is selected by default.

Note:You will need to select a Private Subnet if you select this deployment method.

  • Select the Simple deployment option to generate a CloudFormation template that will install a Public connection router in your AWS account.

Note: The following options will be enabled based on the deployment method selected.

Select Cluster VPC

Note: The Check VPC Connection option applies only to the Advanced deployment method.

Select the appropriate VPC that your Kubernetes cluster has been deployed to. You can select the VPC by name or by ID depending on your business nomenclature.
For more information, see Cluster VPC considerations.

Configure Connection Router

Subnets for connection router placement

Security Groups with cluster network access

Note: Subnets and Security Groups will need to be defined only for the Advanced deployment method.

  • To configure the connection router, select the Subnets that have access to the cluster endpoint.
  • Select the Security Groups that have inbound TCP/443 permissions on the Kubernetes cluster.
    The cluster security group allows traffic from the control plane and managed node groups to flow freely between each other. 


Note: The Region option applies only to the Simple deployment method.

Select the AWS Region that your Kubernetes cluster has been deployed to.

CloudFormation Template

Get Template

Download the CloudFormation Template or click Launch AWS Console with CF Template to be automatically directed to the CloudFormation section of your AWS account. The details are pre-populated in the required sections.
Run the CloudFormation template as a stack or stackset in your AWS environment. This will create or update the IAM role and deploy the traffic router within the selected VPC.

  • Once you configure the connection router and update your AWS access role, click Test Connection to test your network access.

Note: Deploying the connection router to your cluster VPC will provision access to your Kubernetes cluster endpoint.

Step 2: Fetch Helm Charts

Note: During installation, you may need to toggle between terminal console and the Druva CloudRanger web console.

Once the VPC connection router is deployed, you will need to authorize Helm to fetch the chart repository:

1_Reg Cluster2.png

Execute the following commands to authorize Helm to fetch the charts:

  • Enable Open Container Initiative (OCI) support: Helm 3 supports OCI for package distribution. Chart packages are able to be stored and shared across OCI-based registries. Before authenticating with the Helm registry, set the following parameters:


Note: Currently OCI support is considered experimental. For more information, see Enabling OCI Support.

  • Authenticate with OCI registry (AWS ECR): Once you have Helm ready, you can add a chart repository. To authenticate with the OCI registry, use the following format on CLI:

aws ecr get-login-password --region <Region> | helm registry login --username AWS --password-stdin <Registry>

Region indicates your AWS Region where the AWS ECR is located
Registry indicates the AWS ECR registry

  • Pull the following Helm charts: Once you authenticate the Helm charts, run the following commands to pull the charts for Druva Backup Operator (DBO) and the applications that you wish to protect.

To pull charts for Druva backup CRDs, run the following command (mandatory):

helm chart pull <Registry>/<Chart_Tag>`

To pull charts for Druva Backup Operator, run the following command (mandatory):

helm chart pull <Registry>/<Chart_Tag>

Registry indicates the AWS ECR registry
Chart_Tag indicates the Helm chart tag

  • Export the following Helm charts: To export charts for Druva backup CRDs, run the following command (mandatory):

helm chart export <Registry>/<Chart_Tag>

To export charts for Druva Backup Operator, run the following command (mandatory):

helm chart export <Registry>/<Chart_Tag>

Registry indicates the AWS ECR registry
Chart_Tag indicates the Helm chart tag

Step 3: Install Backup CRDs

Execute the following commands to install the backup CRDs.

1_Reg Cluster3.png

To export charts for Druva backup CRDs, execute the following command:

helm install druva-backup-crds./druva-backup-crds --namespace druva-system --create-namespace

Step 4: Deploy Druva Backup Operator

Execute Helm commands to deploy Druva Backup Operator and discover new clusters or specific applications.

1_Reg Cluster4.png

  •  To install charts for Druva Backup Operator, execute the following command (mandatory):

helm install druva-backup-operator ./druva-backup-operator \
--namespace druva-system \
--atomic --render-subchart-notes \
--set druva-backup-config.nameOverride=druva-backup-config \
--set global.image.registry=<Registry> --set global.image.tag=<Image_Tag> \
--set bootstrap.token=<Registration_Token> \
--set bootstrap.clusterURI=<Cluster_URI> --set bootstrap.clusterURL=<Cluster_URL> \
--set prometheus.monitoring.enabled=false \
--set catalogue.url=<CR_Catalgoue_URL> `

Registration Token indicates the bootstrap token to authenticate your Kubernetes cluster with Druva CloudRanger
Image_Tag indicates the version of the image
Cluster_URL indicates the API Server endpoint of Kubernetes Cluster
Cluster_URI indicates the unique identifier for the Cluster
Catalogue_URL indicates the CloudRanger catalogue endpoint for cluster registration

Note: The registration token generated from the CloudRanger console will need to be provided to the Kubernetes Admin to be authenticated via CLI. Once the cluster is authenticated, it will appear on the main Cluster listing page.


To verify if Backup Operator is installed, run the following command:

get cluster druva-cluster -n druva-system

Next Steps

Post cluster registration, you may want to proceed in one of the following ways: 

Application Group Definition:

To define your Kubernetes Application Group and prepare for application data backup, you must first define the Application Group detail and the associated backup recipes. The Kubernetes Admin will need to assign Application Group definitions to Application Admins, as appropriate. 

  • Druva Backup Operator creates an ApplicationGroup object in every namespace. The DBO-created ApplicationGroup object allows the Kubernetes Admin and/or Application Admin to perform backup of the entire namespace, as long as the required permissions are granted to the AppAdmin role.
  • The ApplicationGroup object is created by the name of the namespace. When the Kubernetes Admin creates a new namespace, DBO creates an associated ApplicationGroup object and prepares the newly created namespace for backup. 

For more information, see Application Group Definition

Recipe Definition:

Recipes are labels that define the state of data by which the backup must be performed, as defined by the Application Admin. Recipes are the backup definition criteria for the data state upon backup execution, for example, application consistent, crash consistent, and so on. You can define one or more recipes for each Application Group, and each recipe is unique to that application. For more information, see Recipe Definition

To get started with configuring and managing your Kubernetes clusters, refer to the Quick Start Guide to Kubernetes Protection.