Managed Services

A managed service is a backing service your applications use, such as a database, a cache or a queue, set up from a package Ankra publishes. You choose the application environments that will use it, the cluster it runs on and its size. Ankra prepares a plan from those choices, and nothing is installed until you confirm it. Ankra then installs the service on your cluster and shows its progress under Managed services.

​

The services

Ankra publishes seven services, each built on an open-source engine: Managed Service Settings lists every setting of each one.

​

Who runs it

Every service in the catalogue runs on Your infrastructure: Ankra installs it on one of your clusters, and your team operates it. You own the cluster, the service’s availability and the cost of the capacity it uses. Ankra supplies the package, installs the plan you confirmed and keeps a record of the installation. Ankra-hosted services, which Ankra would run for you, are not available yet.

​

How a service runs

• One stack, one namespace. Each service is deployed as a stack named after the service, into a namespace of the same name. Several services can share a cluster, including several of the same kind.
• Credentials are generated in the cluster. When a service is first installed, it generates its own password or keys and keeps them in a Kubernetes Secret in its namespace. Every later apply reuses them. Ankra never sees or stores the values.
• Cluster-internal only. Nothing is exposed outside the cluster. Applications reach the service at fixed in-cluster addresses; see Connect to a Managed Service.
• Native deployment engine. The credentials are generated with a Helm lookup against the live cluster, which only Ankra’s native deployment engine evaluates. On an ArgoCD cluster every sync would generate new credentials under running applications, so Ankra only places services on native-engine clusters.

​

Data policies

Every cluster a service touches needs a data policy: the region the cluster keeps data in and its data boundary. That covers the cluster the service runs on and the clusters of the application environments it connects to. Your organisation declares the policy in the cluster’s settings. Ankra records who declared it and does not verify the location. The policy decides where a service may run:

• One service connects only environments within one data boundary. Environments in two boundaries need two services.
• A cluster can declare that services bound to it must run on that cluster only.

​

Limits and good to know

• Readiness is not verified. When the deployment finishes, a service shows Verification needed, and that is as far as it goes today. A PostgreSQL service can report its deployment finished 30 to 100 seconds before the database accepts connections.
• Credentials are not delivered to your applications. Ankra shows where the credentials are, and applications in other namespaces must be given the values by you. Ankra will deliver credentials into application environments in a later release.
• No backups. Ankra does not back these services up yet. Do not keep data you cannot recreate in them without a backup of your own.
• Settings are fixed after setup. Changing, upgrading, recovering or deleting a service from Managed services is not available yet.
• NATS runs a single server. The nats package has no clustered option yet.
• OpenSearch runs a single node. An index created with replicas stays yellow. To create an OpenSearch service again under a name you used before on the same cluster, delete the old service’s namespace first: the old data volume rejects the new password.
• SeaweedFS keeps its data on one volume. It runs as a single pod and is unavailable while that pod restarts, which happens once, for about 40 seconds, the first time Ankra reconciles it after installation.

​

Related