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) or using the Ceph RBD provisioner.
With this in mind the following limitations exist if you have an unsupported storage provider:
Applications for which a Kanister blueprint 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 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.
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.
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.