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 add one from the application that will use it, or from the catalogue. 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, its health and how to connect to it under Managed services and on the Services card of each application it serves. Once the service is ready, Ankra delivers its connection into the namespace of each application it serves on the same cluster, and the application’s containers read it as environment variables. When one application no longer needs a service, you disconnect that application through a reviewed plan, and the service keeps running for the others. When you no longer need a service at all, you delete it through a reviewed plan. While managed services are in the pilot, Ankra charges nothing for them. Their running time and storage are recorded as usage.

The services

Ankra publishes these services, each built on open-source software: 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.
• The service owns its stack. Deleting the stack on its own is refused, and so is deleting the cluster the service runs on until the service is deleted. Deleting an application the service serves is refused until you disconnect the application from it or delete the service. A cluster whose agent has been offline for 15 minutes, and a playground, can still be deleted: see A cluster or application a service depends on. To remove the service, delete it: that removes the stack and then deletes the namespace with its data, after you review the plan.
• 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, and deleting the service deletes them with its namespace.
• Cluster-internal only. Nothing is exposed outside the cluster. Applications reach the service at fixed in-cluster addresses. Inside the cluster, PostgreSQL, Valkey, NATS, OpenSearch and SeaweedFS admit their client port (5432 for PostgreSQL) only from the service’s own namespace, the namespace of the cluster’s Ankra agent and the namespaces of the applications connected to the service, where the cluster’s network plugin enforces NetworkPolicy. A service installed on a package version older than the one that narrowed it (postgresql 1.5.0, valkey 1.4.0, nats 1.2.0, opensearch 1.4.0, seaweedfs 1.4.0) keeps that port open to every namespace. VictoriaLogs and VictoriaMetrics admit their client port from every namespace.
• Connections are delivered inside the cluster. Each application environment the service was set up for, on the service’s cluster, receives a <service>-connection Secret in its own namespace, copied in the cluster from the service’s credentials Secret, and its workloads read it as environment variables such as DATABASE_URL. Once the service is ready, Ankra writes the Secret without a redeploy while none of the application’s running pods references it, and otherwise leaves it to the application’s next deploy. Ankra never sees the values. 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.

Health and readiness

Ankra reports two things about a running service, and they answer different questions: whether it is running as planned (health), and whether a client can connect to it (readiness).

Health

Ankra observes each service about once a minute from its own synced view of the service’s cluster: the service’s workload against the size you chose, the Kubernetes Service its addresses name, the credentials Secret with every key the connection details list, and the stack that owns it. It never reads the Secret’s values. Each observation stands for five minutes. Health checks lists what is checked for each service. Health describes the running service, not the operation that deployed it: a failed deployment whose workloads all run reads serving, and one that left a workload missing reads degraded at once. A cluster that is offline reads unknown, never degraded. In the portal, each service in My services carries a Health badge, and the service’s page has a Service health section with the state, when it was observed and what decided it. Until Ankra has observed the service, the section reads Not observed. Health is not shown for a deleted service or while a service is being deleted.

Readiness

Health does not prove that your applications can connect. A serving PostgreSQL service has a ready primary and its credentials Secret, but that does not show a client can reach it and log in. Readiness does. Ankra checks readiness for every service it publishes, about every five minutes. The cluster’s agent starts a short-lived pod in the service’s namespace that connects to the address the service publishes, as a client would, with the credentials taken from the service’s credentials Secret by reference, and does one small round trip: Everything a check writes is its own, named after the check run, and deleted in the same run. The one exception is the VictoriaLogs line: VictoriaLogs cannot delete single lines, so it stays in the ankra_canary stream until your retention removes it. A query that selects your own streams never sees it. The GPU chat check writes nothing, but its one-token completion is recorded as one request on the client key’s spend. The credentials never leave the cluster, and Ankra keeps no log of the check. A result stands for 15 minutes. Readiness is reported on the service in the API, as readiness and readiness_check on Get a managed service instance. The portal shows it on the service’s page and in My services: Ready, Verifying, Not ready (degraded), Not checked recently (stale) or Not verified (unverified). While a service reads unverified, check it yourself before you rely on it: see Check that the service answers.

Data policies

A data policy declares the region a cluster keeps data in and its data boundary. It is optional: you can set up services without one. Declare a policy when services must keep data within a boundary. Your organisation declares it in the cluster’s settings. Ankra records who declared it and does not verify the location. A cluster without a declared policy reads region and data boundary unspecified. That boundary is shared by every cluster without a policy, and cannot be declared by hand. Once a cluster declares a policy, it decides where a service may run:

• One service connects only environments within one data boundary. Environments in two boundaries need two services. A cluster that declares a policy and one that does not are in different boundaries, so one service cannot serve both.
• A cluster can declare that services bound to it must run on that cluster only.

A plan records the policy it was reviewed against. A review prepared before a cluster declares or changes its policy needs a new review.

Managed services and projects

A managed service has no project of its own. It belongs to the project of the cluster it runs on, and moves with the cluster.

• A project member sees a service only if they can read every cluster its plan names.
• A new consuming application environment must be in the selected project. A consumer already in another project can still be disconnected or retired.
• Setting up a service still needs a role on the organisation, so a project-only member cannot create one.
• Billing and usage stay with the organisation.

Limits and good to know

• A finished deployment is not yet a ready service. A PostgreSQL service can report its deployment finished 30 to 100 seconds before the database accepts connections; any service’s readiness reads verifying until a check passes.
• Readiness checks need a pod they can start. The check pods pull their images from Docker Hub (postgres:16-alpine for PostgreSQL, valkey/valkey, natsio/nats-box and curlimages/curl for the others); a cluster that cannot pull the image in time cannot run the check, and readiness then reads stale. Every check pod runs as non-root, with privilege escalation off, every capability dropped and the RuntimeDefault seccomp profile, which a namespace that enforces the restricted Pod Security Standard admits. The check pods other than PostgreSQL’s also have a read-only root filesystem. On a cluster whose DNS domain is not cluster.local the checks fail, as the published addresses do.
• Connections are delivered within one cluster, without restarting anything on their own. Once the service is ready, Ankra writes an application environment’s connection by itself only while none of the application’s running pods references it. When running pods do, Ankra leaves it to the application’s next deploy, which writes it and rolls those workloads together, so pods restarting one by one never read different values. A workload deployed before the service was connected reads the connection only after its next deploy adds the reference to it. An application on another cluster than the service is not connected for you: give it the values yourself, as in Connect from another cluster.
• Only PostgreSQL is backed up. In an organisation with backups enabled, a PostgreSQL service is protected into the organisation’s backup vault: its write-ahead log is archived continuously and a base backup is taken daily, kept for 7 days. It is installed without backups on a playground cluster, whose data is for testing, and when the organisation has no verified backup vault or more than one; the installation then says so, and ankra cluster stacks protect <service> --vault <vault> protects it later (the --vault flag is always required). A PostgreSQL service on package 1.3.0 or earlier was installed without backups. Restoring a service from Managed services is not available yet, and a restore point that carries a CloudNativePG database cannot be restored in place yet either. Valkey, NATS, OpenSearch, SeaweedFS, VictoriaLogs and VictoriaMetrics are not backed up: do not keep data you cannot recreate in them without a backup of your own.
• Settings are fixed after setup. Changing, upgrading or recovering a service from Managed services is not available yet. You can delete a service and set it up again, which starts it with new credentials and none of its data.
• 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.
• 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