Connect to a Managed Service

How your application receives the connection

1. A Secret named <service>-connection in the application’s namespace, with <service> standing for the service name. Ankra copies its values inside the cluster from the service’s own credentials Secret.
2. A reference to that Secret, which a deploy of the application adds to every container and init container of its Deployments, StatefulSets and DaemonSets through envFrom, so each of the Secret’s keys becomes an environment variable. The names are listed under Variable names. A deploy adds the reference while the service is still being set up too. The reference is optional, so the application starts while the Secret does not exist yet.

• The workloads reference the Secret but none of their pods runs, for example because they are scaled to zero: Ankra writes the Secret, and each pod reads the variables when it starts.
• The workloads do not reference the Secret, because the application was deployed before the service was connected: Ankra writes the Secret, and the application reads it after its next deploy adds the reference.
• Running pods reference the Secret, for example because the application was deployed while the service was being set up: Ankra leaves the Secret to a deploy. Deploy the application once the service is ready: the deploy writes the Secret and rolls the workloads that reference it together onto it.
• Running pods read the Secret but started before it existed: they run without its variables until they restart. Ankra never restarts them by itself.
• A variable the connection would add is defined twice, by the connection and by another source the workloads read, such as one of the application’s environment secrets: the connection is not delivered, by Ankra on its own or by a deploy, until you remove the other definition or choose another service, or none, to provide those names, as under Variable names.

Variable names

• Ankra AI or MCP: set_service_connection_default with the application, cluster, namespace, the kind (postgres, redis, nats, opensearch, s3, victorialogs or victoriametrics) and the service’s instance id, or none: true.
• API: PUT /api/v1/org/service-admission/connection-defaults with application_id, cluster_id, namespace, protocol and instance_id (null for none).

Find the connection details

• the namespace, which is the service name;
• each address, with a Copy button;
• the name of the Secret that holds the credentials;
• under Read a credential yourself, for each key in that Secret, an Ankra CLI command that prints its value, with a Copy button. The command names the service’s cluster and also uses jq, as in Read a value.

Addresses and Secrets

Read a value

ankra cluster select <cluster>
ankra cluster get secrets <secret> -n <service> --reveal -o json

ankra cluster get secrets postgresql-app -n orders-db --reveal -o json | jq -r '.data["password"]' | base64 -d

ankra cluster get secrets opensearch-credentials -n search --reveal -o json | jq -r '.data["ca.crt"]' | base64 -d > opensearch-ca.crt

Connect from another cluster

ankra cluster get secrets postgresql-app -n orders-db --reveal -o json \
  | jq -r '.data["password"]' | base64 -d \
  | ankra application env-secrets set <application-id> PGPASSWORD
ankra application env-secrets apply <application-id>

Notes per service

• PostgreSQL. DATABASE_URL and JDBC_DATABASE_URL carry the operator’s fqdn-uri and fqdn-jdbc-uri. The operator also writes uri, jdbc-uri and host keys, but they name the short host postgresql-rw, which resolves only inside the service’s own namespace. You connect as app, the owner of the database app, and superuser access is off. The read-only address reaches replicas only, so it answers only when instances is above 1, and no variable names it. The image includes the pgvector and pgaudit extensions.
• Valkey. Authenticate as the app user, which REDIS_USERNAME carries, with REDIS_PASSWORD; REDIS_URL is a complete redis:// URL that carries both. Write to the primary address. The read-replicas address serves reads from every pod.
• NATS. Connect as app. NATS_URL carries no credentials, so pass NATS_USER and NATS_PASSWORD separately. JetStream is on; memory-backed streams are disabled.
• OpenSearch. Use HTTPS with basic auth as admin, the only user. The certificate is signed by a private CA generated in the cluster: have your client trust OPENSEARCH_CA_CERT, which holds that CA’s certificate.
• SeaweedFS. Use the S3 API over plain HTTP inside the cluster, with path-style addressing. The admin key pair, the one delivered, can read, write, list and administer buckets. The read-only key pair can only read, and is in the service’s Secret only.
• VictoriaLogs. Send logs over HTTP with basic auth, as JSON lines, Loki push, OpenTelemetry or Elasticsearch bulk, and query them with LogsQL. No log collector is installed, so ship logs with your own agent.
• VictoriaMetrics. Push metrics with basic auth using Prometheus remote_write, OpenTelemetry, InfluxDB or another supported protocol, and query with PromQL or MetricsQL on the Prometheus HTTP API. It scrapes nothing itself, so push from vmagent, a Prometheus agent or an OpenTelemetry Collector.

OpenAI-compatible inference

curl "$OPENAI_BASE_URL/chat/completions" \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d "{\"model\": \"$OPENAI_MODEL\", \"messages\": [{\"role\": \"user\", \"content\": \"Hello\"}]}"

import os
from openai import OpenAI

client = OpenAI()  # reads OPENAI_BASE_URL and OPENAI_API_KEY
response = client.chat.completions.create(
    model=os.environ["OPENAI_MODEL"],
    messages=[{"role": "user", "content": "Hello"}],
)
print(response.choices[0].message.content)

Check that the service answers

ankra cluster get pods -n <service>

ankra cluster describe Cluster postgresql -n <service> --group postgresql.cnpg.io

Next steps