Getting Started with Trilio on Google Kubernetes Engine (GKE)

Learn how to install, license and test Trilio for Kubernetes (T4K) in the Google Cloud (GKE) environment.

Table of Contents

What is Trilio for Kubernetes?

Trilio for Kubernetes is a cloud-native backup and restore application. Being a cloud-native application for Kubernetes, all operations are managed with CRDs (Customer Resource Definitions).
Trilio utilizes Control Plane and Data Plane controllers to carry out the backup and restore operations defined by the associated CRDs. When a CRD is created or modified the controller reconciles the definitions to the cluster.
Trilio gives you the power and flexibility to backup your entire cluster or select a specific namespace(s), label, Helm chart, or Operator as the scope for your backup operations.
In this tutorial, we'll show you how to install and test operation of Trilio for Kubernetes on your GKE deployment.


  • Confirm Compatibility
Before installing Trilio for Kubernetes, please review the compatibility matrix to ensure Trilio can function smoothly in your Kubernetes environment.
  • Verify that a CSI Driver which provides Snapshot functionality
Trilio for Kubernetes requires a compatible Container Storage Interface (CSI) driver that provides the Snapshot feature.
Check the Kubernetes CSI Developer Documentation to select a driver appropriate for your backend storage solution. See the selected CSI driver's documentation for details on the installation of the driver in your cluster.
Trilio will assume that the selected storage driver is a supported CSI driver when the volumesnapshotclass and storageclassare utilized.
  • Verify that the Required Custom Resource Definitions (CRD) are installed
Trilio for Kubernetes requires the following Custom Resource Definitions (CRD) to be installed on your cluster:VolumeSnapshot, VolumeSnapshotContent, and VolumeSnapshotClass.
Installing the Required VolumeSnapshot CRDs
Before attempting to install the VolumeSnapshot CRDs, it is important to confirm that the CRDs are not already present on the system.
To do this, run the following command:
kubectl api-resources | grep volumesnapshot
If CRDs are already present, the output should be similar to the output displayed below. The second column displays the version of the CRD installed (v1 in this case). Ensure that it is the correct version required by the CSI driver being used.
volumesnapshotclasses snapshot.storage.k8s.io/v1 false VolumeSnapshotClass
volumesnapshotcontents snapshot.storage.k8s.io/v1 false VolumeSnapshotContent
volumesnapshots snapshot.storage.k8s.io/v1 true VolumeSnapshot
Installing CRDs
Be sure to only install v1 version of VolumeSnapshot CRDs
  1. 2.
    Run the following commands to install directly, check the repo for the latest version:
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/release-${RELEASE_VERSION}/client/config/crd/snapshot.storage.k8s.io_volumesnapshotclasses.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/release-${RELEASE_VERSION}/client/config/crd/snapshot.storage.k8s.io_volumesnapshotcontents.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/release-${RELEASE_VERSION}/client/config/crd/snapshot.storage.k8s.io_volumesnapshots.yaml
  • Network Access Requirements
For non-air-gapped environments, the following URLs must be accessed from your Kubernetes cluster.
  • Network Port Requirements
If the Kubernetes cluster's control plane and worker nodes are separated by a firewall, then the firewall must allow traffic on the following port(s)
  • 9443

Verify Prerequisites with the Trilio Preflight Check

Make sure your cluster is ready to Install Trilio for Kubernetes by installing the Preflight Check Plugin and running the Trilio Preflight Check.
Trilio provides a preflight check tool that allows customers to validate their environment for Trilio installation.
The tool generates a report detailing all the requirements and whether they are met or not.
If you encounter any failures, please send the Preflight Check output to your Trilio Professional Services and Solutions Architect so we may assist you in satisfying any missing requirements before proceeding with the installation.


Google's Kubernetes Engine (GKE) utilizes the flexibility of upstream Kubernetes. Consequently, the same documentation provided for installing Trilio for Kubernetes in Upstream environments are applicable for the T4K on GKE.

Follow the steps for Trilio for Upstream Kubernetes


The T4K user interface facilitates authentication through kubeconfig files, which house elements such as tokens, certificates, and auth-provider information. However, in some Kubernetes cluster distributions, the kubeconfig might include cloud-specific exec actions or auth-provider configurations to retrieve the authentication token via the credentials file. By default, this is not supported.
When using kubeconfig on the local system, any cloud-specific action or config in the user section of the kubeconfig will seek the credentials file in a specific location. This allows the kubectl/client-go library to generate an authentication token for use in authentication. However, when the T4K Backend is deployed in the Cluster Pod, the credentials file necessary for token generation is not accessible within the Pod.
To rectify this, T4K features cloud distribution-specific support to manage and generate tokens from these credential files.

Using credentials for login

  1. 1.
    In a GKE cluster, a local binary known as gcloud is used pull the credentials from a sqlite credentials file named credentials.db.
  2. 2.
    This file is located under the path $HOME/.config/gcloud and is used to generate an authentication token.
  3. 3.
    All required parameters for generating this token are present within the same credentials.db file. When a user attempts to log into the T4K user interface deployed in the GKE cluster, they are expected to supply the credentials.db file from the location $HOME/.config/gcloud for successful authentication.

Example of Default kubeconfig

apiVersion: v1
- cluster:
name: gke_amazing-chalice-243510_us-east1-b_dev-cluster
- context:
cluster: gke_amazing-chalice-243510_us-east1-b_dev-cluster
user: gke_amazing-chalice-243510_us-east1-b_dev-cluster
name: gke_amazing-chalice-243510_us-east1-b_dev-cluster
current-context: gke_amazing-chalice-243510_us-east1-b_dev-cluster
kind: Config
preferences: {}
- name: gke_amazing-chalice-243510_us-east1-b_dev-cluster
cmd-args: config config-helper --format=json
cmd-path: /home/trilio/google-cloud-sdk/bin/gcloud
expiry-key: '{.credential.token_expiry}'
token-key: '{.credential.access_token}'
name: gcp

Example of Credentials pulled from credentials.db

Pulling Credentials from credential.db

Licensing Trilio for Kubernetes

To generate and apply the Trilio license, perform the following steps:
Although a cluster license enables Trilio features across all namespaces in a cluster, the license only needs to be applied in the namespace where Trilio is installed. For example, trilio-system namespace.
1. Obtain a license by getting in touch with us here. The license file will contain the license key.
2. Apply the license file to a Trilio instance using the command line or UI:
Command line
Management Console (UI)
  1. 1.
    Execute the following command:
kubectl apply -f <licensefile> -n trilio-system
2. If the previous step is successful, check that the output generated is similar to the following:
trilio-system license-sample Active Cluster License Activated successfully. 4 FreeTrial 10 2025-07-08T00:00:00Z 8
Additional license details can be obtained using the following:
kubectl get license -o json -m trilio-system
  1. 1.
    Authenticate access to the Management Console (UI). Refer to UI Authentication.
  2. 2.
    Configure access to the Management Console (UI). Refer to Configuring the UI.
If you have already executed the above prerequisites, then refer to the guide for applying a license in the UI: Actions: License Update

Upgrading a license

A license upgrade is required when moving from one license type to another.
Trilio maintains only one instance of a license for every installation of Trilio for Kubernetes.
To upgrade a license, run kubectl apply -f <licensefile> -n <install-namespace> against a new license file to activate it. The previous license will be replaced automatically.

Create a GCP Storage Bucket

  1. 1.
    Create a storage bucket from the Google cloud console.
  1. 1.
    Name the storage bucket and choose a region.
  1. 3.
    Select the preferred access control setting.
  1. 4.
    Select the desired protection setting
  1. 5.
    Create or select access credentials with required permissions
To add a GCP storage bucket as a backup target within T4K, specific bucket permissions are required.
  • Create a custom role with the following required permissions
# permission list
# GCloud command
gcloud iam roles create <ROLE-NAME> --project=<PROJECT-ID> \
--title="tvk-gcp-target-role" --description="Role with required GCP bucket access for T4K target" \
--permissions="storage.objects.create,storage.objects.delete,storage.objects.get,storage.objects.list,storage.objects.update" --stage=GA
  • Associate the created role with a service account whose access key and secret key is going to be used while creating target in T4K
  • If a service account does not have access key and secret key, follow this guide to generate a new access key and secret key which will be required while creating target.
Copy Credentials to use for Backup Target

Create a Backup Target

The Target CR (Customer Resource) is defined from the Trilio Management Console or from your own self-prepared YAML.
The Target object references the NFS or S3 backup storage share you provide as a target for your backups. Trilio will create a validation pod in the namespace where Trilio is installed and attempt to validate the NFS or S3 settings you have defined in the Target CR.
Trilio makes it easy to automatically create your backup Target CRD from the Management Console.
  1. 1.
    Select Other from the Dropdown
  1. 2.
    Provide all required details
    • Configured Bucket Name
    • GCP Storage URI: https://storage.googleapis.com
    • Provide Service User Access key and Secret key from GCP Cloud Storage / Settings / Interoperability / Access
  1. 3.
    Finally, select a name for this Target. Additional Backup Targets can be created with the same details, however the name must be unique.
  2. 4.
    Confirm that Target Status is Available, indicating that the Backup Target has been created successfully.

Configure a Backup Target as YAML

Take control of Trilio and define your own self-prepared YAML and apply it to the cluster using the kubectl tool.

Example S3 Target

kubectl apply -f sample-secret.yaml
kubectl apply -f demo-s3-target.yaml
apiVersion: v1
kind: Secret
name: sample-secret
type: Opaque
accessKey: AKIAS5B35DGFSTY7T55D
secretKey: xWBupfGvkgkhaH8ansJU1wRhFoGoWFPmhXD6/vVDcode
apiVersion: triliovault.trilio.io/v1
kind: Target
name: demo-s3-target
type: ObjectStore
vendor: AWS
region: us-east-1
bucketName: trilio-browser-test
name: sample-secret
thresholdCapacity: 5Gi

Testing Backup and Restore Operation

Trilio is a cloud-native application for Kubernetes, therefore all operations are managed with CRDs (Custom Resource Definitions). We will discuss the purpose of each Trilio CRD and provide examples of how to create these objects Automatically in the Trilio Management Console or from the kubectl tool.

About Backup Plans and Backups

  • The Backup Plan CR is defined from the Trilio Management Console or from your own self-prepared YAML.
The Backup Plan CR must reference the following:
  1. 1.
    Your Application Data (label/helm/operator)
  2. 2.
    Backup Target CR
  3. 3.
    Scheduling Policy CR
  4. 4.
    Retention Policy CR
  • A Target CR is defined from the Trilio Management Console or from your own self-prepared YAML. Trilio will test the backup target to ensure it is reachable and writable. Look at Trilio validation pod logs to troubleshoot any backup target creation issues.
  • Retention and Schedule Policy CRs are defined from the Trilio Management Console or from your own self-prepared YAML.
    • Scheduling Policies allow users to automate the backup of Kubernetes applications on a periodic basis. With this feature, users can create a scheduling policy that includes multiple cron strings to specify the frequency of backups.
    • Retention Policies make it easy for users to define the number of backups they want to retain and the rate at which old backups should be deleted. With the retention policy CR, users can use a simple YAML specification to define the number of backups to retain in terms of days, weeks, months, years, or the latest backup. This provides a flexible and customizable way to manage your backup retention policy and ensure you meet your compliance requirements.
  • The Backup CR is defined from the Trilio Management Console or from your own self-prepared YAML.
    The backup object references the actual backup Trilio creates on the Target. The backup is taken as either a Full or Incremental backup as defined by the user in the Backup CR.

Creating a Backup Plan and Backup

Trilio makes it easy to automatically create your backup plans and all required target and policy CRDs from the Management Console.
Take control of Trilio, define your self-prepared YAML, and apply it to the cluster using the kubectl tool.

Example Namespace Scope BackupPlan:

# kubectl apply -f ns-backupplan.yaml
apiVersion: triliovault.trilio.io/v1
kind: BackupPlan
name: ns-backupplan
namespace: default
name: demo-s3-target
kubectl apply -f sample-schedule.yaml
kind: "Policy"
apiVersion: "triliovault.trilio.io/v1"
name: "sample-schedule"
type: "Schedule"
- "0 0 * * *"
- "0 */1 * * *"
- "0 0 * * 0"
- "0 0 1 * *"
- "0 0 1 1 *"
kubectl apply -f sample-retention.yaml
apiVersion: triliovault.trilio.io/v1
kind: Policy
name: sample-retention
type: Retention
default: false
latest: 2
weekly: 1
dayOfWeek: Wednesday
monthly: 1
dateOfMonth: 15
monthOfYear: March
yearly: 1
kubectl apply -f sample-backup.yaml
apiVersion: triliovault.trilio.io/v1
kind: Backup
name: sample-backup
type: Full
name: sample-application
namespace: default

About Restores

A Restore CR (Custom Resource) is defined from the Trilio Management Console or from your own self-prepared YAML. The Restore CR references a backup object which has been created previously from a Backup CR.
In a Migration scenario, the location of the backup should be specified within the desired target as there will be no Backup CR defining the location.
Trilio restores the backup into a specified namespace and upon completion of the restore operation, the application is ready to be used on the cluster.

Creating a Restore

Trilio makes it easy to automatically create your Restore CRDs from the Management Console.
Take control of Trilio, define your self-prepared YAML, and apply it to the cluster using the kubectl tool.
kubectl apply -f sample-restore.yaml
apiVersion: triliovault.trilio.io/v1
kind: Restore
name: sample-restore
type: Backup
name: sample-backup
namespace: default


Problems? Learn about Troubleshooting Trilio for Kubernetes