Prerequisites
Managed services are in the new Ankra portal. Choose Managed services in its sidebar, or open/next/services on your portal’s address, for example https://platform.ankra.app/next/services. If the page says managed services are not offered to your organisation yet, contact support.
Before you start, check the following:
- The service cluster uses the native deployment engine. Services generate their credentials in the cluster, which only the native engine supports. New clusters use it by default. A cluster that still deploys with ArgoCD can be migrated.
- The service cluster has a default StorageClass. Every service keeps its data on persistent volumes from the cluster’s default StorageClass.
- Every cluster involved has a data policy. That means the cluster the service runs on and the clusters of the environments it connects to. See Declare a data policy.
- The application is deployed. Setup offers only the environments an application is actually deployed to, each one a namespace on a cluster. All environments that one service connects must be in the same data boundary.
- Your role allows it:
The built-in
owner, admin and operator roles hold all of them. See Roles and access.
Declare a data policy
A data policy says where a cluster keeps data. In the new portal, open the cluster’s Settings and find Where managed services may keep data.1
Open the policy
Choose Declare data policy, or Change data policy when the cluster already has one.
2
Enter the region and data boundary
Enter a Region, such as
eu-north, and a Data boundary, such as eu. Both take lowercase letters, digits and single hyphens, start with a letter, and are at most 63 characters.3
Choose whether services must stay on this cluster
Tick Services bound to this cluster must run on this cluster only if an application on this cluster may only use services running on the same cluster.
4
Review and confirm
Choose Review policy, read the summary, then Confirm data policy.
Set up the service
1
Open the package
In Managed services, open the Catalogue tab, choose the service and choose Set up. Catalogue cards also carry a Set up button.
2
Connect: choose the application environments
Find an application and tick the environments that will use the service. Each environment is listed as a namespace on a cluster, together with that cluster’s data policy. You can add environments from several applications, up to 50.Continue stays disabled while the chosen environments keep data in different boundaries, or while your role cannot operate one of their clusters. An application that is not deployed yet offers no environments: deploy it first.
3
Place: choose who runs it and where
Your infrastructure is how every service runs today: Ankra installs it on one of your clusters, and your team operates it.Choose the Service cluster from the clusters your environments run on. The page shows its region and data boundary. A cluster without a data policy offers Declare a data policy, and your choices are kept while you declare it. An environment that cannot use a service on the chosen cluster is listed with the reason before you continue. The usual reasons are a different data boundary, or a cluster that keeps its services local.
4
Configure: name it and size it
Service name is suggested from the application and the package, for example
storefront-postgresql. It must follow the name rules.Each setting shows its range and default. A package with more than three settings keeps the rest under More settings. Managed Service Settings explains each one.Choose Review setup. This records the chosen environments as consumers of managed services and asks Ankra to prepare a plan. It installs nothing.5
Review: confirm the plan
The plan lists the service name, the package and version, who operates it, the service cluster with its region and data boundary, every setting, and the connected environments.Choose Confirm setup before the review window ends, 10 minutes after the plan was prepared. The page shows when that is. Change choices takes you back. If the window passes, Review again prepares a fresh plan with the same choices.
Service name rules
The name becomes the service’s namespace and its stack name on the service cluster. It must:- be a DNS label: lowercase letters, digits and single hyphens, starting with a letter;
- be at most 36 characters;
- not be
default, and not start withkube-,ankra,cnpg-system,cert-manager,ingress-nginx,argocdorflux-system; - not already be used on that cluster, by a stack or by an earlier service. A name stays taken once its setup is confirmed, even if the installation then fails.
What confirming does
Confirming asks Ankra to install the service. It does not verify that the service is ready or that your applications can reach it. After you confirm:- The service appears in My services and its page opens with Setup confirmed. Deployment submitted; readiness is not yet verified.
- For PostgreSQL, Ankra makes sure the cluster runs the CloudNativePG operator. It is installed once per cluster, as its own stack
cloudnative-pgin thecnpg-systemnamespace. A cluster that already runs CloudNativePG, installed by Ankra or any other way, keeps its operator. The operator is shared by every PostgreSQL service on the cluster, so leave it in place while any of them run. - Ankra deploys the service as a stack named after the service, into a namespace of the same name.
Follow the installation
Open My services and choose the service. Deployment progress shows where it stands, and View cluster operations opens the cluster’s operations with the detail.
Every service also reads Readiness unverified. Check that it answers before you rely on it: see Check that the service answers.
Troubleshooting
Next steps
Connect to a managed service
Find the addresses and credentials, and wire them into your application.
Managed service settings
Every setting of each service, with its range and default.
Managed services
What the services are, how they run, and their current limits.
Deployment engines
The native engine, and moving a cluster to it from ArgoCD.