3.1.X
Search
⌃K

T4K Product FAQ

This section provides details on T4K's development methodology, deployment details, security, life cycle management, services integration, quality assurance, support and performance
General
Production Grade
Security and Compliance
Life Cycle Management
Quality Assurance
Support
Performance
Trilio uses only fully supported Kubernetes APIs and features. T4K has been developed to best practices, avoiding the use of Kubernetes alpha APIs and using hard-coded Kubernetes API versions.
Best practices for Trilio for Kubernetes software development include:
  1. 1.
    Deployable by a single Helm or Operator artifact.
  2. 2.
    Product editions are licensed as an item and are tied together by a Helm or Operator artifacts.
  3. 3.
    Supports consecutive Red Hat OpenShift Container Platform minor versions.
  4. 4.
    Software images are consistently maintained across offerings.
  5. 5.
    Binaries based on Red Hat UBI.
  6. 6.
    All Images are Red Hat Certified.
  7. 7.
    T4K has been integrated with Red Hat publishing per content guidelines.
  8. 8.
    T4K supports Operator based install.
  9. 9.
    T4K Operators are OLM (Operator Lifecycle Manager) enabled.
  10. 10.
    All T4K Custom Resource Definitions (CRDs) include application version.
  11. 11.
    All Operators provide a status. __
In order to be defined as Production Grade, all Red Hat apps must pass QA requirements for documentation, system requirements, best practices for resource usage, data integrity testing and cluster behaviors (scaling, recovery, dependancies)
  1. 1.
    Minimum cluster configuration and physical resources are published​
    1. 1.
      Cluster configurations are validated and updated on major product releases.
  2. 2.
    All persistent volumes storage access modes. RWO – ReadWriteOnce.
  3. 3.
    Trilio maintains Data integrity during pod or node failures.
  4. 4.
    Trilio for Kubernetes uses fully qualified hostnames to provide external access.
  5. 5.
    Trilio does NOT use custom ingress annotations for external access.
  6. 6.
    Trilio does NOT use Nodeports to provide external access.
  7. 7.
    Trilio supports advanced scheduling to ensure maximum resiliency.
  8. 8.
    To provide resiliency when unexpected failures occur , T4K supports graceful recovery when failure occurs
  9. 9.
    Monitoring provides application health and react to events.
  10. 10.
    Trilio data protection has the ability to run in multiple failure zones in a single cluster.
  11. 11.
    Deployments can scale horizontally with manual scaling
  12. 12.
    Scalability can be achieved by deploying multiple instances in a single cluster without conflict.
  1. 1.
    All images have been scanned using Red Hat Certification VA Scanner and Linter (IBM Approved scanning tools).
  2. 2.
    T4K follows a principle of least privilege and pod isolation
  3. 3.
    T4K uses an approved SCC definition
  4. 4.
    T4K provides exact capabilities required for SCC
  5. 5.
    All components of a workload are tracked, including Helm release, Namespace, Labels and Annotations, so if something is created maliciously this can be readily detected.
  6. 6.
    Workloads do not use the default service account
  7. 7.
    T4K Only exposes required ports/services from each container
  8. 8.
    T4K limits traffic between pods.
  9. 9.
    Containers do not communicate with the host.
  10. 10.
    All data is encrypted in transit using TLS 1.2 within the customer network between Pods.
  11. 11.
    Encryption for data at rest can be managed by the backup repository used by customer (NFS/S3). T4K doesn't encrypt at rest, this is left to the NFS or S3 repository
  12. 12.
    All Secrets are stored in an approved service
  13. 13.
    Logs are clear of all sensitive information and does not expose any sensitive data.
  14. 14.
    Helm release is clear of sensitive information and do not expose any sensitive data.
  15. 15.
    Kubernetes Resources (other than a secret) do not store sensitive information
  16. 16.
    Default credentials to be immediately updated by the customer are not supplied by Trilio.
  17. 17.
    All communication between containers and services uses TLS auth in order to restrict anonymous access.
  18. 18.
    T4K Uses an IBM approved certificate manager -Certificate type is X.509 and follows best practices for Public Key Infrastructure.
​Upgrade methods include:
  1. 1.
    In Place Upgrade
T4K Upgrade paths follow best practices for:
  1. 1.
    Provide non-disruptive patching for image updates.
  2. 2.
    Upgrade ensures no loss of vital data.
  3. 3.
    Upgrade path is documented in Release Notes.
  4. 4.
    Upgrade path tested.
T4K has defined methods for workload rollbacks using Kubernetes Native Rollback. T4K documentation of backup/recovery process includes
  1. 1.
    Backup points documented externally for clients
  2. 2.
    Recovery / restore is documented externally for clients
  3. 3.
    Backup and recovery of application and data is well tested for each major release
Trilio completes comprehensive testing. Broad tests are designed and performed for the product. A wide range of testing methodologies are used to ensure the quality of the product, including:
  1. 1.
    Unit testing
  2. 2.
    Integration testing
  3. 3.
    System testing
  4. 4.
    Availability testing
  5. 5.
    Install testing
  6. 6.
    Performance testing
  7. 7.
    Beta customer testing
Other QA items:
  1. 1.
    ​T4K documentation includes steps for customer to validate successful install. Customer-driven post-install tests allow for the customer to validate that your product was installed successfully and is running correctly.
  2. 2.
    T4K can also be installed in an air gap environment. T4K has a install process and verification for a disconnected network (air gap environment).
  3. 3.
    T4K has been tested on all Red Hat OCP versions that the product has declared support.
  4. 4.
    T4K has documented storage options that are supported and tested.
  1. 1.
    T4K provides a process for obtaining support
  2. 2.
    T4K licenses are available in the package source. All product licenses deployed by a workload are available with the source (Helm, Operators, or CASE).
  3. 3.
    All package source (Helm chart, Operator controller/CRD, CASE, scripts, dashboards) are Apache 2 licensed.
  4. 4.
    T4K licenses align appropriately for Docker images and package source. License files in the Docker images align with the license files put in the packaged source for your product.
  5. 5.
    T4K displays all relevant licenses for acceptance based on the deployment scenario for the workload.
Trilio uses the latest UBI minimal images as the starting point for all product images. UBI minimal images are substantially smaller than the regular UBI images and are a better starting point for product images.
  1. 1.
    Trilio reduces the number of unused files and image layers in all images.
  2. 2.
    Trilio uses only one runtime framework (Node.js, Python, Golang) in a container.
  3. 3.
    T4K uses only curl or wget to fetch packages from remote URLs.

****

​

Previous
Install AWS EBS CSI Driver
Next - Appendix
OpenShift OperatorHub Custom CatalogSource
Last modified 22h ago