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 using storage other than Ceph or storage provisioned via Cinder only support data management operations using the Kanister framework. There are a number of storage provider plug-ins under development, including full CSI support, that will expand the set of fully supported platforms in the very near future.
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 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.
Cross-project migration within Google is currently unsupported.