Kanister Pod Override

In some cases, there can be a requirement to override Kanister jobs pods specifications with custom values, such as tolerations for taints, nodeSelector, or serviceAccountName. This can serve a use-case when the pods need to be scheduled on a particular node, or use a ServiceAccount which provides limited access. Changing these values manually for Kanister Job pods will not be feasible.

To handle specifying the custom pod override for all Kanister Pods, a ConfigMap named pod-spec-override must be created in the kasten-io namespace so that K10 applies the configuration to all Kanister Job Pods.

Note

When the helm option for providing a Root CA to K10 (i.e., cacertconfigmap.name) is enabled, the Kanister Backup/Restore workflow will create a new ConfigMap, in the application namespace to provide the Root CA to the sidecar. This ConfigMap in the application namespace would be a copy of the Root CA ConfigMap residing in the K10 namespace, which would be deleted at the end of the workflow. To override this, the Root CA ConfigMap can be created in the application namespace and the respective Volume and VolumeMounts in the pod-spec-override in kasten-io namespace.

For example, the following ConfigMap defines a Pod Specification, which contains tolerations to node taints, and a nodeSelector.

 apiVersion: v1
 data:
   override: |
     kind: Pod
     spec:
       nodeSelector:
         disktype: ssd
       tolerations:
         - effect: NoSchedule
           key: app
           operator: Equal
           value: mysql
       serviceAccountName: abcd
       containers:
         - name: container
           volumeMounts:
             - mountPath: /etc/ssl/certs/custom-ca-bundle.pem
               name: custom-ca-bundle-store
               subPath: custom-ca-bundle.pem
       volumes:
         - configMap:
             defaultMode: 420
             name: custom-ca-bundle-store
           name: custom-ca-bundle-store
 kind: ConfigMap
 metadata:
   name: pod-spec-override
   namespace: kasten-io
...

This ConfigMap now would be merged with all Kanister job Pod specifications. The Kanister restore job Pods would look like:

 apiVersion: v1
 kind: Pod
 metadata:
   name: restore-data-*
   namespace: mysql
 spec:
   containers:
     - name: container
       imagePullPolicy: IfNotPresent
       volumeMounts:
         - mountPath: /etc/ssl/certs/custom-ca-bundle.pem
           name: custom-ca-bundle-store
           subPath: custom-ca-bundle.pem
   nodeSelector:
     disktype: ssd
   serviceAccount: abcd
   serviceAccountName: abcd
   tolerations:
     - effect: NoSchedule
       key: app
       operator: Equal
       value: mysql
   volumes:
     - configMap:
         defaultMode: 420
         name: custom-ca-bundle-store
       name: custom-ca-bundle-store
...

Configuring custom labels and annotations

Kanister pods launched during K10 operations can be configured with additional custom labels and annotations through Helm Values.

Custom labels can be configured through Helm in following ways:

• Providing the path to one or more YAML files during helm install or helm upgrade with the --values flag:

  kanisterPodCustomLabels: "key1=value1,key2=value2"
  kanisterPodCustomAnnotations: "key1=value1,key2=value2"
  

• Modifying the resource values one at a time with the --set flag during helm install or helm upgrade:

  --set=kanisterPodCustomLabels="key1=value1,key2=value2"
  --set=kanisterPodCustomAnnotations="key1=value1,key2=value2"