Features
A list of impactful Trilio for Kubernetes features and use cases
Trilio for Kubernetes (T4K) is a cloud native application, built based on Kubernetes principles. It consists of a collection of CRDs and Controllers that manages Trilio objects that are Kubernetes resources. Like any other cloud native application, Trilio supports two Operator deployment methods:
- 1.Helm based Operator
- 2.Operator Lifecycle Management Operator
Trilio can be deployed and managed using these tools.
Trilio provides an innovative approach to backup applications based on:
- 1.Helm charts - if an application is provisioned via the helm packaging methodology, T4K can back it up by providing it the name of the release and the helm version.
- 2.Operators - Operators are meant to manage the install, updates and life cycle of applications. Trilio can protect Operator based applications.
- 3.Custom Labels - Labels in Kubernetes are like tags that are applied to resources for better identification. Customers can choose to protect applications based on labels of its components. Labels are very powerful and can be used in various permutations and combinations to detect and find application resources.
- 4.Namespaces - Trilio provides a CR known as
BackupPlanfor users to define a set of applications to protect within a namespace. Users also end up using Namespaces themselves as the boundary to define their protection scope. Trilio for Kubernetes supports namespace based backups as well.
The architecture of Trilio for Kubernetes is similar to the architecture and operating model of Kubernetes environments. As a result, a customer does not have to learn any new concepts or frameworks to operate Trilio for Kubernetes. If a customer understands Kubernetes architecture, they understand T4K architecture.
Kubernetes Native also means that the Trilio application can be run and supported on any Kubernetes distribution.
Application aware backups have been around for quite some time. Application aware backups make sure the backups are "application consistent" and not "crash consistent". When backups provide application consistency, during backup processes, backup applications invoke application specific hooks within the container that give the application the ability to flush any in-memory data structures to disk and makes sure the disk structure are in a consistent state. Backup applications then perform a point in time copy of the application. This will make sure when these applications are restored, applications can restart reliably.
Application aware backups are relatively easy when the application is running in a single virtual machine. However cloud native applications are comprised of more than one Pod or PV. Hence, the invocation of application hooks need to be orchestrated based on the data flow in the application. Trilio provides a means to express the application hooks and the order in which these hooks need to be invoked to accomplish application consistent backups.
T4K integrates with de facto tools for monitoring and logging for Kubernetes clusters. Prometheus is a data collector engine for metrics and Grafana is a visualization tool of those metrics. T4K provides default dashboards along with standard installation, but customers can create more detailed charts and meaningful visualizations of their data protection metrics based on their needs.
RBAC is built into Kubernetes clusters by design. Since T4K is built on the same principles on which Kubernetes is built, it automatically supports RBAC. T4K can be installed into individual namespaces or the entire cluster. Namespaces are generally the units used for multi-tenancy within Kubernetes.
Another key attribute of Trilio for Kubernetes is the format in which the backup is stored. T4K stores backups in an open QCOW2 format - which means that the backup is not stored in any proprietary format and thus augments the ‘open’ nature of cloud-native environments.
There are several advantages provided by a QCOW2 format.
- 1.Open - No hydration required for moving backup data. Scanning of data from a security perspective is also enabled.
- 2.Enables data efficiency by enabling a software only de-duplication solution. Only unique blocks are copied for incremental backups with pointers to the base image.
The most popular backup target medias are NFS and S3 compatible storage types. Trilio supports both these storage types as backup targets.
Trilio users can configure more than one backup target for their backup needs. They can have NFS based local storage for mission critical apps and s3 based cloud storage for other applications.
All backups, both incremental and full backups will reside on the same backup target as per the configured BackupPlan .
Incremental backups provide both space savings and efficient network bandwidth utilization. Trilio supports forever incremental backups which means all backups are incrementals after the first full backup is taken (concatenating diffs). This will enhance your TCO of the solution as it uses less storage and network bandwidth.
Though Trilio supports forever incremental backups, organizations only need to keep a certain number of backups at a given time, determined either by the backup count or by the date of the backups. Any older backups that exceed the count or the expiration date should be deleted to conserve backup storage. Since Trilio supports forever incrementals, it cannot delete all last backups. It will break the backup chain and more recent backups becomes unusable. Trilio creates and manages full synthetic backups, where Trilio merges all backups that were marked for deletion into one full backup and retains the full backup. All other backups are deleted from the backup media. This way Trilio continues to take incremental backups, but still maintains the list of backups according to user retention needs.
Trilio for Kubernetes provides the ability to inject commands before and after a backup as well as before and after a restore. As a result, customers can take application consistent backups of their application or have the ability to extend their backup and restore workflows to achieve additional use cases within their environments.
Backup retention is a way to retain backup images that meets your business needs. Business reasons could be compliance, risk tolerance, data analytics, etc. Trilio supports retention policies that can be defined to meet your business needs.
Trilio Retention policy
You can define retention policies by number of yearly backups, monthly backups, weekly backups and daily backups. The above diagram explains how the backup retention works in Trilio.
In a microservices oriented architecture, components are loosely connected or are completely independent of each other. Another aspect is that applications, workloads or plain objects reference Kubernetes abstractions specific to a namespace or cluster. As a result, when migrating applications from one cluster/namespace to another, it becomes important for users to be able to change or edit the Kubernetes resources of an application so that it can function successfully in the target environment that it is being ported into. T4K 2.0 onwards, customers have the ability to transform and edit the metadata associated with their applications before it is restored into a target environment.
Metadata information such as storageclass or nodeport can be easily changed using the RestoreTransform feature.
For the transformation examples, please follow Restore with Transformations (StorageClass) and Restore with Transformations (NodePort) section.
In order to enable seamless Disaster Recovery or migration scenarios, Trilio for Kubernetes provides the ability to browse the contents of a target repository (where backups are kept), so that applications can be restored without having access to the original cluster or the metadata of the backup operation from the original cluster. As a result, a target can be connected to any cluster and applications can be readily restored from them. Target browsing is supported via the management console as well as the CLI.
Trilio supports multi-cloud management (MCM) by allowing users to manage multiple T4K instances via its management console. As a result, application and data management between multiple Kubernetes clusters is simplified via a single pane of glass.
Trilio's MCM feature is built as a peer-to-peer model. Any cluster can be the primary cluster and any cluster can be the secondary cluster as per the users preference. Since Trilio's management console is completely stateless and aligned with Kubernetes RBAC, each user can connect clusters as per their RBAC and that view will be saved specifically for that user upon next login activity.
Trilio provides a DRPlan feature that enables users to perform disaster recovery operations as part of a single workflow from the management console. Users can pick and choose backups from various backup repositories to create a plan in terms of restoring business operations. The plans can be focused on backend apps, frontend apps, middleware/ecosystem apps etc.
The DRPlan is created and saved at the destination cluster - which means that the plan can be executed even when the source cluster is not available.
Trilio for Kubernetes provides the capability to encrypt backups. Encryption is enabled at the BackupPlan level and different keys will be created for each backupPlan. Encryption keys are stored as Kubernetes secrets, and integration with Vault will be provided soon. Trilio leverages the LUKS encryption format to protect data. LUKS is extremely flexible and secure providing a range of cipher suites.
Trilio provides the ability to create immutable T4K backups, so that they cannot be deleted from until the user defined retention period is over. Trilio interfaces with the backup storage target's locking and versioning feature to provide immutability. Immutability is set at the backupPlan level, so users have the granular capability to specify which applications need immutability support. Currently, any S3-compatible device (AWS S3, MinIO, Wasabi etc.) that allows locking is supported.
Independent Kubernetes
objects and kinds can now be selected for capture within a backupPlan. As a result, any Kubernetes object as well as capture of objects by kind (pods, secrets etc.) can now be protected. This feature also enables users to override certain objects that Trilio has determined to have no bearing as part of data management and protection and include them in the backup. This feature also enables users to include objects from other namespaces as well, thus extending the backup scope from a namespace only, to namespace and objects from other namespaces - for example a user may be interested in capturing an entire namespace and just one secret from another namespace. Include/Exclude GVKO now enables this.Trilio enables users to automatically protect an application that has been restored. A flag that controls this behavior allows Trilio to recreate resources like hooks, policies, backupPlans and automatically have the application protected as it moves from one environment to another. As a result, no matter where your application is running, once it is protected by T4K it is always protected.
Trilio now supports authentication to the management console via OIDC, LDAP and many more in conjunction to supporting the original kubeconfig methods of authentication. As a result, Trilio offers a wide range of authentication support. Trilio leverages the tool called Dex to support authentication and all the connectors provided by Dex are supported by Trilio. For OpenShift environments, configuration to the management console is handled by Trilio by default.
In order to simplify management of multiple clusters, the ability to share T4K resources like policies, hooks, targets etc. is required, so that users can create a resource once and use it across many Kubernetes clusters. Trilio provides the ability to share T4K native resources across namespaces and clusters so as to enable simplified global management. This feature also supports creation of the resource based on a suffix and counter so as to avoid conflicts in case of cloning to multiple clusters at the same time.
Trilio provides the ability to automatically clean up a restore in case it fails. Enabled as a flag, this feature enables quick retry attempts of a restore instead of manually cleaning out objects that may have failed. The flag can also be applied (patched) after a failure and the objects etc. will still be cleaned up. The Trilio restore object will be left behind for customers to look at error messages and logs.
Through the continuous restore feature, users can restore a certain number of backups of an application on a set of remote clusters. Remote clusters can read the backup images from the backup target and create a set of PVs from the backup data. Users can use these PVs to quickly failover an application to the remote cluster. The Continuous Restore feature significantly reduces the RTO of applications in DR scenarios. This feature can also be used for other use cases, including test/dev, blue/green deployments, migration, DR plan testing, etc.