Skip to main content
Closed beta. Deleting a service is part of Managed services, which is in closed beta and enabled per organisation on request. Contact support to have it turned on for your organisation.
Deleting a managed service removes its stack from the cluster, then deletes its namespace with the data in it. It takes two steps: you acknowledge what the deletion does, Ankra prepares a plan of exactly what is removed and kept, and you confirm that plan by typing the service’s name. Nothing is deleted until you confirm.
Deleting a service deletes its data, and it cannot be undone. The service’s namespace is deleted with every volume claim and Secret in it, including the credentials the service generated, and anything else placed in that namespace, even objects Ankra did not create. No export is made first. Copy out anything you need before you confirm.

​
Prerequisites

  • The installation has finished. A service whose status is Installation requested or Deployment in progress cannot be deleted yet. A service whose installation or deployment needs attention can be.
  • Your role allows it:
The built-in owner, admin and operator roles hold all of them. Without them the service’s page shows no Delete service section, and the deletion page says Your role cannot delete this service. See Roles and access.

​
What is removed and what is kept

The volumes behind the deleted claims are erased where the StorageClass reclaims them with reclaim policy Delete, the usual default. Ankra never put the service’s credentials into your application namespaces, so deleting the service removes nothing there. A Secret you copied into an application’s namespace yourself, as in Wire it into an application, stays until you delete it. Applications still configured with the service’s address lose their connection.

​
Delete the service

1

Open the service

In the new Ankra portal, open Managed services, then My services, and choose the service. The Delete service section is at the bottom of its page. Choose Delete service.
2

Acknowledge what the deletion does

Under Environments that lose this service, tick each application environment the service serves. Each one stops using the service; the application itself is not changed.Then tick I understand that deleting <service> deletes its data and generated credentials, and that no export is made first.Choose Review deletion. Reviewing prepares a plan. It deletes nothing.
3

Review the plan

The plan is what the platform resolved for this service, and what the deletion will do:
  • Service, Cluster and Namespace deleted.
  • Removed from the cluster: the stack, and each member with the namespace it deploys into.
  • Environments that lose it: each application environment the service serves.
  • Kept: shared stacks the service needed, such as the CloudNativePG operator.
  • What happens to the data: the platform’s statement of what is deleted, including whether volumes on a Retain StorageClass stay behind.
If nothing was ever deployed for the service, the plan says so: deleting it then removes nothing on the cluster and only releases its name.
4

Type the name and confirm

Type the service’s name exactly in Type <service> to confirm, then choose Delete service. Confirm within the review window, 10 minutes after the plan was prepared; the page shows when it ends. When the window passes, Review again prepares a fresh plan for the same acknowledgements.
Start over returns to the first step. A plan you do not confirm expires on its own and deletes nothing. Each person can hold at most 10 deletion reviews waiting for confirmation, and each organisation 50.

​
Follow the deletion

After you confirm, the service’s page shows Deletion confirmed. and the deletion’s progress, one step at a time:
  1. Removing the service’s stack
  2. Waiting for the cluster to remove the stack: Ankra waits up to an hour for the cluster’s agent to report every member removed.
  3. Deleting the service’s namespace and its data: Ankra first checks that no other Ankra-managed workload deploys into the namespace, then deletes it and waits up to 30 minutes to see it gone.
My services shows the service as Deleting. View cluster operations opens the cluster’s operations with the detail. The service’s health and connection details are no longer shown once the deletion starts.

​
Verify

When the namespace is gone, the page becomes a Service deleted receipt with the status Deleted: the stack was removed, the namespace was deleted and seen gone from the cluster, and the name was released. The receipt lists what is kept, and My services shows the service as Retired. To check the cluster yourself (see Kubeconfig for access):
The answer is NotFound. On a StorageClass with reclaim policy Retain, the service’s volumes are left with status Released. Delete them once you no longer need their data:
The name is free again. A new service set up under the same name on the same cluster generates new credentials and starts with none of the old data.

​
When a deletion stops short

Only Deleted removes the service. Any other outcome leaves the service and its name in place, says why under What happened, and the Delete service section offers Review the deletion again.

​
A service’s stack is deleted through the service

The service owns its stack. Deleting the stack directly - in the portal, through the API, with ankra cluster stacks delete or by asking the AI Assistant - is refused with:
Delete the service instead, as above.
Removing a service’s stack from the cluster’s GitOps repository is not refused yet. It removes the service’s deployment while the service and its name stay in My services. Delete the service from its page instead.

​
Delete through the API

The API calls a deletion a retirement. It takes the same two steps, with an API token whose holder has the permissions above:
  1. Read the service with Get a managed service instance for its generation and the id of each of its consumers.
  2. Prepare a managed-service retirement review with expected_generation, disconnect_consumer_ids (every consumer id, each once) and acknowledge_data_loss: true. The answer carries the plan, its digest and its expires_at, 10 minutes later. Nothing changes on the cluster.
  3. Confirm a managed-service retirement by its digest with that digest. Confirming again with the same digest returns the same receipt, never a second deletion.
  4. Follow retirement on the service, or Get a managed-service retirement: its phase while it runs, then its outcome and reason. Only the outcome retired deleted the service.

​
Troubleshooting

​
Next steps

Managed services

How services run, their health and readiness, and their current limits.

Set up a managed service

Set up a service again, under the same name or a new one.