Advanced Agent Configuration

Overview

The CloudCasa agent is composed of multiple containers, presided over by an Agent Manager. The Agent Manager acts somewhat like an operator, managing and updating the various agent components as necessary.

Some sites have complex requirements regarding labels, annotations, requests, limits, etc. that must be applied to the agent pods or namespaces. It is necessary to inform the Agent Manager of these, so that they are properly applied when agent components are updated/redeployed.

The Customize agent installation parameters section under Advanced options in the Add/Edit cluster page allows administrators to configure these properties using YAML.

The YAML document for this has the following schema:

common:
  annotations:
  labels:
azure-files-rbac:
  cluster-role:
    annotations:
    labels:
  cluster-role-binding:
    annotations:
    labels:
  role:
    annotations:
    labels:
  role-binding:
    annotations:
    labels:
  service-account:
    annotations:
    labels:
cluster-role-bindings:
  cloudcasa-io:
    annotations:
    labels:
roles:
  data-mover:
    annotations:
    labels:
role-bindings:
  data-mover:
    annotations:
    labels:
service-accounts:
  cloudcasa-io:
    annotations:
    labels:
  data-mover:
    annotations:
    labels:
namespaces:
  cloudcasa-io:
    annotations:
    labels:
    applyToAllTemporaryCloudCasaNamespaces:
deployments:
  kubeagent:
    annotations:
    labels:
  cloudcasa-kubeagent-manager:
    annotations:
    labels:
pods:
  kubeagent:
    annotations:
    labels:
    priorityClassName:
    securityContext:
    tolerations:
      - key:
        operator:
        value:
        effect:
        tolerationSeconds:
  cloudcasa-kubeagent-manager:
    annotations:
    labels:
    priorityClassName:
    securityContext:
    tolerations:
      - key:
        operator:
        value:
        effect:
        tolerationSeconds:
  data-mover:
    annotations:
    labels:
    priorityClassName:
    securityContext:
    tolerations:
      - key:
        operator:
        value:
        effect:
        tolerationSeconds:
  azure-files-mover:
    annotations:
    labels:
    priorityClassName:
    securityContext:
    tolerations:
      - key:
        operator:
        value:
        effect:
        tolerationSeconds:
  job-helper:
    annotations:
    labels:
    priorityClassName:
    securityContext:
    tolerations:
      - key:
        operator:
        value:
        effect:
        tolerationSeconds:
  file-access:
    annotations:
    labels:
    priorityClassName:
    securityContext:
    tolerations:
      - key:
        operator:
        value:
        effect:
        tolerationSeconds:
  file-service:
    annotations:
    labels:
    priorityClassName:
    securityContext:
    tolerations:
      - key:
        operator:
        value:
        effect:
        tolerationSeconds:
  repository-server:
    annotations:
    labels:
    priorityClassName:
    securityContext:
    tolerations:
      - key:
        operator:
        value:
        effect:
        tolerationSeconds:
containers:
  kubeagent:
    securityContext:
    requests:
        cpu:
        memory:
        ephemeral-storage:
    limits:
        cpu:
        memory:
        ephemeral-storage:
    env:
  kubeagent-backup-helper:
    securityContext:
    requests:
        cpu:
        memory:
        ephemeral-storage:
    limits:
        cpu:
        memory:
        ephemeral-storage:
    env:
  kubeagentmanager:
    securityContext:
    requests:
        cpu:
        memory:
        ephemeral-storage:
    limits:
        cpu:
        memory:
        ephemeral-storage:
    env:
  data-mover:
    securityContext:
    requests:
        ephemeral-storage:
    limits:
        ephemeral-storage:
    env:
  azure-files-mover:
    securityContext:
    requests:
        cpu:
        memory:
        ephemeral-storage:
    limits:
        cpu:
        memory:
        ephemeral-storage:
    env:
  job-helper:
    securityContext:
    requests:
        cpu:
        memory:
        ephemeral-storage:
    limits:
        cpu:
        memory:
        ephemeral-storage:
    env:
  file-access:
    securityContext:
    requests:
        cpu:
        memory:
        ephemeral-storage:
    limits:
        cpu:
        memory:
        ephemeral-storage:
    env:
  file-service:
    securityContext:
    requests:
        cpu:
        memory:
        ephemeral-storage:
    limits:
        cpu:
        memory:
        ephemeral-storage:
    env:
  repository-server:
    securityContext:
    requests:
        cpu:
        memory:
        ephemeral-storage:
    limits:
        cpu:
        memory:
        ephemeral-storage:
    env:
services:
  kubeagent:
    annotations:
    labels:
    portName:
network-policies:
  allow-kubeagent-manager-traffic:
    annotations:
    labels:

Pods for jobs and operations

CloudCasa starts a pod for each backup, restore or delete, and for some operations on NFS and SMB storage. These pods are configured under pods and containers with the following names:

job-helper: Runs a backup, restore or delete.
file-access: Keeps NFS or SMB storage mounted while CloudCasa validates it, browses a recovery point, or finishes a copy.
file-service: Prepares files to download from a recovery point on NFS or SMB storage.
repository-server: Serves a recovery point on NFS or SMB storage to the VM that CloudCasa starts to browse the files of a VM backup.

These pods run where the agent runs: they take the node selector, affinity, tolerations and priority class of the agent pod. Tolerations set for one of them are added to the agent’s, and a priority class replaces the agent’s.
The job-helper pod also takes the labels and annotations of the kubeagent pod entry, with its own on top. The other pods do not; set theirs in common or in their own entry.
The kubeagent-backup-helper settings are applied to the job-helper container first, and the job-helper settings on top of them.
Requests and limits of these pods can also be set for one NFS or SMB storage. See Advanced Gateway Configuration.
If a request of one of these pods ends up above its limit, CloudCasa raises the limit to the request.

Example

An example that simply configures CPU and memory requests and limits for the different agent components is:

containers:
  kubeagent:
    limits:
      cpu: 500m
      memory: 512Mi
    requests:
      cpu: 250m
      memory: 128Mi
  kubeagent-backup-helper:
    limits:
      cpu: 1000m
      memory: 1Gi
    requests:
      cpu: 500m
      memory: 128Mi
  kubeagentmanager:
    limits:
      cpu: 500m
      memory: 128Mi
    requests:
      cpu: 250m
      memory: 64Mi

An example that gives the pods of backups, restores and deletes 4Gi of memory, and lets the pods that prepare downloads run on nodes with a downloads taint:

containers:
  job-helper:
    limits:
      memory: 4Gi
pods:
  file-service:
    tolerations:
      - key: downloads
        operator: Exists
        effect: NoSchedule

Notes

Users must provide the entire securityContext section.
Annotations and labels set in the common section will be overwritten by the values set at the resource level.
Requests and limits for the condense pod should be set in the “data-mover” section.