Kanister Pod Override
In some cases, there can be a requirement to override Kanister
jobs pods specifications with custom values, such as
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
namespace so that K10 applies the configuration to all Kanister Job Pods.
When the helm option for providing a Root CA to K10
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
For example, the following ConfigMap defines a Pod Specification, which
tolerations to node taints, and a
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 upgradewith the
kanisterPodCustomLabels: "key1=value1,key2=value2" kanisterPodCustomAnnotations: "key1=value1,key2=value2"
Modifying the resource values one at a time with the