Known limitations

Contributors netapp-mwallis netapp-bcammett netapp-dbagwell

Known limitations identify platforms, devices, or functions that are not supported by this release of the product, or that do not interoperate correctly with it. Review these limitations carefully.

General limitations

The following limitations affect Astra Control Service’s management of Kubernetes clusters in any supported Kubernetes deployment.

Astra Trident isn’t uninstalled from a cluster

When you unmanage a cluster from Astra Control Service, Astra Trident isn’t automatically uninstalled from the cluster. To uninstall Astra Trident, you’ll need to follow these steps in the Astra Trident documentation.

Existing connections to a Postgres pod causes failures

When you perform operations on Postgres pods, you shouldn’t connect directly within the pod to use the psql command. Astra Control Service requires psql access to freeze and thaw the databases. If there is a pre-existing connection, the snapshot, backup, or clone will fail.

Limitations for management of GKE clusters

The following limitations apply to the management of Kubernetes clusters in Google Kubernetes Engine (GKE).

Google Marketplace apps haven’t been validated

NetApp hasn’t validated apps that were deployed from the Google Marketplace. Some users report issues with discovery or back up of Postgres, MariaDB, and MySQL apps that were deployed from the Google Marketplace.

No matter which type of app that you use with Astra Control Service, you should always test the backup and restore workflow yourself to ensure that you can meet your disaster recovery requirements.

App management limitations

The following limitations affect Astra Control Service’s management of applications.

Multiple applications that use the same namespace cannot be restored collectively to a different namespace

If you manage multiple applications that use the same namespace (by creating multiple app definitions in Astra Control), you cannot restore all of the applications to a different single namespace. You need to restore each application to its own separate namespace.

Astra Control does not automatically assign default buckets for cloud instances

Astra Control does not automatically assign a default bucket for any cloud instance. You need to manually set a default bucket for a cloud instance. If a default bucket is not set, you won’t be able to perform app clone operations between two clusters.

In-place restore operations of apps that use a certificate manager are not supported

This release of Astra Control Service does not support in-place restore of apps with certificate managers. Restore operations to a different namespace and clone operations are supported.

App clones fail after an application is deployed with a set storage class

After an application is deployed with a storage class explicitly set (for example, helm install …​-set global.storageClass=netapp-cvs-perf-extreme), subsequent attempts to clone the application require that the target cluster have the originally specified storage class.
Cloning an application with an explicitly set storage class to a cluster that does not have the same storage class will fail. There are no recovery steps in this scenario.

Clones of apps installed using pass by reference operators can fail

Astra Control supports apps installed with namespace-scoped operators. These operators are generally designed with a "pass-by-value" rather than "pass-by-reference" architecture. The following are some operator apps that follow these patterns:

  • Apache K8ssandra

    Note For K8ssandra, in-place restore operations are supported. A restore operation to a new namespace or cluster requires that the original instance of the application to be taken down. This is to ensure that the peer group information carried over does not lead to cross-instance communication. Cloning of the app is not supported.
  • Jenkins CI

  • Percona XtraDB Cluster

Note that Astra Control might not be able to clone an operator that is designed with a "pass-by-reference" architecture (for example, the CockroachDB operator). During these types of cloning operations, the cloned operator attempts to reference Kubernetes secrets from the source operator despite having its own new secret as part of the cloning process. The clone operation might fail because Astra Control is unaware of the Kubernetes secrets in the source operator.

Note During clone operations, apps that need an IngressClass resource or webhooks to function properly must not have those resources already defined on the destination cluster.

Role-based Access Control (RBAC) limitations

The following limitations apply to the way Astra Control limits user access to resources or capabilities.

A user with namespace RBAC constraints can add and unmanage a cluster

A user with namespace RBAC constraints should not be allowed to add or unmanage clusters. Due to a current limitation, Astra does not prevent such users from unmanaging clusters.

A Member user with namespace constraints cannot access cloned or restored apps until an Admin user adds the namespace to the constraint

Any member user with RBAC constraints by namespace name/ID can clone or restore an app to a new namespace on the same cluster or to any other cluster in their organization’s account. However, the same user cannot access the cloned or restored app in the new namespace. After a new namespace is created by a clone or restore operation, the account admin/owner can edit the member user account and update role constraints for the affected user to grant access to the new namespace.