NetBackup™ Deployment Guide for Kubernetes Clusters

• Your Azure Kubernetes cluster must be created with appropriate network and configuration settings.

  For a complete list of supported Kubernetes cluster version, see the NetBackup Compatibility List for all Versions.

• While creating the cluster, assign appropriate roles and permissions.

  Refer to the 'Concepts - Access and identity in Azure Kubernetes Services (AKS)' section in Microsoft Azure Documentation.

• Use an existing Azure container registry or create a new one. Your Kubernetes cluster must be able to access this registry to pull the images from the container registry. For more information on the Azure container registry, see 'Azure Container Registry documentation' section in Microsoft Azure Documentation.

• Deploying the Primary and Media server installation on the same node pool (node) is possible. For optimal performance, it is recommended to create separate node pools. Select the Scale method as Autoscale. The autoscaling feature allows your node pool to scale dynamically by provisioning and de-provisioning the nodes as required automatically.

• A dedicated node pool for Primary server must be created in Azure Kubernetes cluster.

  The following table lists the node configuration for the primary and media servers.

  Node type		D16ds v4
  Disk type		P30
  vCPU		16
  RAM		64 GiB
  Total disk size per node (TiB)		1 TB
  Number of disks/node		1
  Cluster storage size	Small (4 nodes)	4 TB
  	Medium (8 nodes)	8 TB
  	Large (16 nodes)	16 TB

• Another dedicated node pool must be created for Snapshot Manager (if it has to be deployed) with auto scaling enabled.

  Following is the minimum configuration required for Snapshot Manager data plane node pool:

  Node type		B4ms
  RAM		8 GB
  Number of nodes		Minimum 1 with auto scaling enabled.
  Maximum pods per node		6 (system) + 4 (static pods) + RAM*2 (dynamic) = 26 pods or more

  Following are the different scenario's on how the NetBackup Snapshot Manager calculates the number of job which can run at a given point in time, based on the above mentioned formula:

  • For 2 CPU's and 8 GB RAM node configuration:

    CPU		More than 2 CPU's
    RAM		8 GB
    Maximum pods per node		6 (system) + 4 (static pods) + 8*2 = 16 (dynamic pods) = 26 or more
    Autoscaling enabled		Minimum number =1 and Maximum = 3

    Note:

    Above configuration will run 8 jobs per node at once.

  • For 2/4/6 CPU's and 16 GB RAM node configuration:

    CPU		More than 2/4/6 CPU's
    RAM		16 GB
    Maximum pods per node		6 (system) + 4 (Static pods) + 16*2=32 (Dynamic pods) = 42 or more
    Autoscaling enabled		Minimum number =1 and Maximum = 3

    Note:

    Above configuration will run 16 jobs per node at once.

• All the nodes in the node pool must be running the Linux operating system. Linux based operating system is only supported with default settings.

• Taints and tolerations allows you to mark (taint) a node so that no pods can schedule onto it unless a pod explicitly tolerates the taint. Marking nodes instead of pods (as in node affinity/anti-affinity) is particularly useful for situations where most pods in the cluster must avoid scheduling onto the node.

  Taints are set on the node pool while creating the node pool in the cluster. Tolerations are set on the pods.

• If you want to use static private IPs and fully qualified domain names for the load balancer service, private IP addresses and FQDNs must be created in AKS before deployment.

• If you want to bind the load balancer service IPs to a specific subnet, the subnet must be created in AKS and its name must be updated in the annotations key in the networkLoadBalancer section of the custom resource (CR).

  For more information on the network configuration for a load balancer service, refer to the How-to-Guide section of the Microsoft Azure Documentation.

  For more information on managing the load balancer service, See About the Load Balancer service.

• Create a storage class with Azure file storage type with file.csi.azure.com and allows volume expansion. It must be in LRS category with Premium SSD. It is recommended that the storage class has , Retain reclaim. Such storage class can be used for primary server as it supports Azure premium files storage only for catalog volume.

  For more information on Azure premium files, see 'Azure Files CSI driver' section of Microsoft Azure Documentation.

  For example,

  kind: StorageClass
  apiVersion: storage.k8s.io/v1
  metadata:
    name: {{ custome-storage-class-name }}
  provisioner: file.csi.azure.com
  reclaimPolicy: Retain
  allowVolumeExpansion: true
  volumeBindingMode: WaitForFirstConsumer
  parameters:
    storageaccounttype: Premium_LRS
    protocol: nfs
  

• Create a storage class with Managed disc storage type with allowVolumeExpansion = true and ReclaimPolicy=Retain. This storage class will be used for Primary server data and log volume. Media server storage details support azure disks only.

• Customer's Azure subscription should have Network Contributor role.

  For more information, see 'Azure built-in roles' section of Microsoft Azure Documentation.

AKS-specific

• Linux operating system: For a complete list of compatible Linux operating systems, refer to the Software Compatibility List (SCL) at:

  NetBackup Compatibility List for all Versions

• Install Docker on the host to install NetBackup container images through tar, and start the container service.

  Install Docker Engine

• Prepare the host to manage the AKS cluster.

  • Install Azure CLI.

    For more information, see 'Install the Azure CLI on Linux' section of the Microsoft Azure Documentation.

  • Install Kubernetes CLI

    For more information, see 'Install and Set Up kubectl on Linux' section of the Kubernetes Documentation.

  • Log in to the Azure environment to access the Kubernetes cluster by running this command on Azure CLI:

    az login - identity

    az account set --subscription <subscriptionID>

    az aks get-credentials --resource-group

    <resource_group_name> --name <cluster_name>

    az resource list -n $cluster_name --query [*].identity.principalId --out tsv

    az role assignment create --assignee <identity.principalId> --role 'Contributor' --scope /subscriptions/$subscription_id/resourceGroups/NBUX-QA-BiDi- RG/providers/Microsoft.Network/virtualNetworks/NBUX-QA-BiDiNet01/subnets/$subnet

    az login --scope https://graph.microsoft.com//.default

  • Log in to the container registry:

    az acr login -n <container-registry-name>

EKS-specific

• Install AWS CLI.

  For more information on installing the AWS CLI, see Install or update the latest version of the AWS CLI' section of the AWS Command Line Interface User Guide.

• Install Kubectl CLI.

  For more information on installing the Kubectl CLI, see 'Installing kubectl' section of the Amazon EKS User Guide.

• Configure docker to enable the push of the container images to the container registry.

• Create the OIDC provider for the AWS EKS cluster.

  For more information on creating the OIDC provider, see 'Create an IAM OIDC provider for your cluster' section of the Amazon EKS User Guide.

• Create an IAM service account for the AWS EKS cluster.

  For more information on creating an IAM service account, see 'Configuring a Kubernetes service account to assume an IAM role' section of the Amazon EKS User Guide.

• If an IAM role needs an access to the EKS cluster, run the following command from the system that already has access to the EKS cluster:

  kubectl edit -n kube-system configmap/aws-auth

  For more information on creating an IAM role, see Enabling IAM user and role access to your cluster.

• Login to the AWS environment to access the Kubernetes cluster by running the following command on AWS CLI:

  aws eks --region <region_name> update-kubeconfig --name <cluster_name>

• Free space of approximately 13GB on the location where you copy and extract the product installation TAR package file. If using docker locally, there should be approximately 8GB available on the /var/lib/docker location so that the images can be loaded to the docker cache, before being pushed to the container registry.

• AWS EFS-CSI driver should be installed for static PV/PVC creation of primary catalog volume.