Restrictions

Here is an list of known limitations in the current K10 release. A number of them will be addressed in upcoming releases.

On-Premises Storage Providers

Currently, on-premises K10 deployments are only supported if storage is provisioned via the Container Storage Interface (CSI).

With this in mind the following limitations exist if you have an unsupported storage provider:

  • Applications for which a Kanister blueprint (or a blueprint binding) is available but does not use volume-snapshots will be fully supported.

  • Any deployments and stateful sets that use a persistent volume that are not associated with a Kanister blueprint (or a blueprint binding) will fail on snapshots unless you are using the Generic Storage Backup and Restore Kanister approach with sidecar containers.

Please refer to Kanister for more details.

Cloning Applications

When cloning applications, one needs to be aware of both external dependencies outside of the application namespace as well as namespace-dependent configuration. For example, if there is a duplicated ingress setup, they will conflict and the results might be non-deterministic.

Restore

Please refer to Limitations for restore limitations.

Migration Restrictions

  • Multi and hybrid-cloud volume migration is fully supported as long as K10 has support for snapshots on the source side. For unsupported storage providers, please use Kanister for now.

  • When migrating Kanister-enabled applications across clusters, the destination cluster also needs access to all buckets where Kanister artifacts are stored. This restriction will be removed in an upcoming release where Kanister artifacts will be copied into the migration bucket.

GitOps Managed Applications

When restoring applications that are managed by external controllers, one needs to be aware of the following conditions.

  • An external controller can interrupt K10 operations that may lead to restore failures. Ensure that there is no external controller handling the resource lifecycle during the restore by disabling the auto-sync mechanism in the GitOps tools used, or scaling down the controller, etc.

  • To avoid conflict with external controller after the restore has taken place, it is recommended that you perform a data-only restore. Please refer to Data-Only Restore for more details.

TLS Version Compatibility

During authentication attempts, an error occurs, suggesting a potential TLS protocol version mismatch. If the authentication service fails to start after a version upgrade, it is due to an unsupported TLS protocol version 1.3. It is recommended to use TLS versions less than 1.3 for smooth communication with the authentication service. For more information on TLS version compatibility for each authentication type, see the Authentication topic.