Modifying Default T4K Configuration
This page describes how to make changes to default configurations for various components of the Trilio for Kubernetes application.
There are different types of configuration for T4K which are helpful in tuning T4K as per requirements/cluster constraints. The available configurations are:
- InstanceName and LogLevel
- Job Resource Requirements
- Scheduling Configuration
- Application Scope
- Ingress Configuration
- CSI Configuration
T4K configuration is used to:
- provide the InstanceName for the T4K installation.
- configure the logLevel across the product.
- the available log levels are as follows:
Job Resource Requirement is used to modify the default resources requirements like CPU and memory for all the pods which are created as part of product installation as well as backup and restore operation. There are different fields for setting resource requirements for different types of pods.
- metadataJobResources - Specifies the resource requirements for all meta-data related and target mounting jobs like target-validator, meta-snapshot, pre-restore-validation, meta-restore, etc
- dataJobResources : Specifies the resource requirements for Datamover jobs
- deploymentLimits : Specifies limits for helm chart deployments. Not applicable for OCP
T4K provides a way to put a constraint on the pods it creates by itself and schedule those pods on a specific set of nodes in the cluster. T4K leverages the existing kubernetes scheduling mechanisms to schedule its pods.
There are three fields to put scheduling constraints on pods of T4K, they are:
Affinity: Affinity is used when a pod should schedule or prefer to schedule on a particular set of nodes. Affinity is of two types viz. - Node Affinity and Pod Affinity. On the other hand, Pod Anti-Affinity is opposite of Pod Affinity where a pod should not or prefer not to schedule on a particular set of nodes. User can specify both the Affinity and Anti-Affinity. Refer to the official Kubernetes documentation on Affinity and anti-affinity for more information.
Toleration: Kubernetes allows nodes to add taints so that nodes can repel a set of pods which do not tolerate the given taints. To tolerate a taint, a pod must specify toleration. User can specify the tolerations with matching taints, so that T4K pods will be able to schedule themselves in a cluster with tainted nodes. Refer to the official Kubernetes documentation on Taints and Tolerations for more information.
Application Scope denotes T4K installation scope. Installation scope can be of two types - Cluster and Namespaced. When T4K is installed in Namespaced scope, the cluster scoped CRDs will not be installed. The cluster scoped CRDs are:
In namespaced scope installation, the cluster scoped features such as - multi-namespace backup and restore and continuous-restore won't be enabled for use. The working of T4K will be restricted to it's installation namespace only.
User can configure the external access to T4K services using the Ingress through HTTP or HTTPS. There four configurable fields related to Ingress. They are:
IngressClass: Name of the IngressClass resource which contains additional information regarding Ingress' parameters and the name of the controller that implements this particular IngressClass.
Annotations: Extra annotations to be added on the required Ingress resource.
Host: Name based virtual host against the IP address on which the external traffic will be received.
TLSSecretName: Name of the TLS secret that contains a private key and certificate. When TLS secret name is specified, the external traffic to Ingress will use HTTPS protocol (port 443). The TLS secret should be present in the namespace where T4K is to be installed.
Annotationsfields should be empty when
componentConfiguration.ingress-controllermap contains key-value
CSI configuration is used to configure the CSI provisioners which do not support Volume Snapshot functionality. For full details about this, refer to T4K For Volumes with Generic Storage. To enable this configuration there are 3 lists:
defaultCSI Provisioner list: Known list of CSI provisioners which do not support Volume Snapshot. Maintained by T4K. This list will be updated as and when new non-snapshot CSI provisioners are discovered.
includeCSI Provisioner list: User given list of CSI provisioners which do not support Volume Snapshot.
excludeCSI Provisioner list: User given list of CSI provisioners which need to be ignored from Default list.
Input for the aforementioned T4K configuration is provided through the TVM CR. The following section explains how to modify the T4K configuration:
ingressClass: alb # specify `ingressClass` only when you are not using trilio's ingress controller
- key: host
- weight: 1
- key: arch
- key: host
- weight: 100
- key: host
- key: "key1"
- key: "key2"
Job Resource Requirements:
spec.dataJobResourcesfor data job resource requirements
spec.metadataJobResourcesfor meta job resource requirements
spec.logLevelfor logLevel. Default is
spec.datamoverLogLevelfor datamover jobs logLevel. Default is
spec.tvkInstanceNamefor T4K instance name
spec.nodeSelectorfor running pods on a particular set of nodes
spec.affinity.nodeAffinityfor scheduling pods with node affinity
spec.affinity.podAffinityfor scheduling pods with pod affinity
spec.affinity.podAntiAffinityfor scheduling pods with anti affinity
spec.tolerationsto make pods tolerant of the taints mentioned on nodes
spec.applicationScopeto set the scope of T4K installation. Default is
spec.ingressConfig.ingressClassto set the IngressClass resource
spec.ingressConfig.hostto set the host name to route external HTTP(S) traffic
spec.ingressConfig.annotationsto add extra annotations on the Ingress resource
spec.ingressConfig.tlsSecretNameto set the TLS secret to use the TLS port 443 for external Ingress traffic.
spec.csiConfig.includelist for including the CSI provisioners in the non-snapshot functionality category
spec.csiConfig.excludelist for excluding the CSI provisioners from the non-snapshot functionality category