Integrating anynines Data Services

Prerequisite

These instructions assume that the Klutch Control Plane Cluster has been set up.

The anynines Data Services (a9s/a8s) offer a versatile range of managed data services, deployable on either VM-based infrastructure (a9s) or directly on Kubernetes (a8s).

This guide empowers the Control Plane with the execution logic and connectivity required to successfully provision, manage, and expose a catalog of a9s and a8s data services to App Clusters.

1. Install Composition Functions

Klutch utilizes Crossplane® Composition Functions to process resource requests. These components provide the common, reusable logic necessary to template configurations, patch resources, and determine service readiness across all a9s/a8s Compositions.

info

If you have installed other data services previously, some or all of the required functions may already be installed in the cluster. Use the following command to check which functions are currently installed and apply only the remaining ones.

  kubectl get function

View and Apply Composition Functions Manifest

kubectl apply -f - <<EOF
apiVersion: pkg.crossplane.io/v1
kind: Function
metadata:
  name: function-patch-and-transform
spec:
  package: xpkg.upbound.io/crossplane-contrib/function-patch-and-transform:v0.9.1
---
apiVersion: pkg.crossplane.io/v1beta1
kind: Function
metadata:
  name: function-go-templating
spec:
  package: xpkg.upbound.io/crossplane-contrib/function-go-templating:v0.11.0
EOF

Verification:

kubectl get function -w

Wait until the functions are HEALTHY.

2. Install Data Service Configurations

Next, install the dataservices configuration package. This package contains the Data Service Configurations that comprise the API definitions (what App Clusters can request) and the Compositions (how to build services) that target the a9s and a8s automation backends.

Prerequisite

To run the command below, you need the Crossplane CLI installed locally. If you haven't installed it yet, please follow the instructions in the Control Plane Cluster prerequisites.

crossplane xpkg install configuration public.ecr.aws/w5n9a2g2/anynines/dataservices:v1.5.1

Verification:

kubectl get configuration -w

Wait until the configuration is HEALTHY.

3. Connect the Automation Backend

The connection process for the backend infrastructure depends on the chosen deployment model. If intending to use both a9s and a8s, complete the steps under both tabs below.

a9s (VM-based Data Services)

A. Deploy Connectivity Layer

The Crossplane® Provider for a9s is deployed to translate Klutch's requests into API calls for the underlying VM-based backend.

kubectl apply -f https://raw.githubusercontent.com/anynines/klutchio/refs/heads/main/crossplane-api/deploy/provider-anynines.yaml

Verification:

kubectl get provider -w

Wait until provider-anynines is HEALTHY.

B. Configure Credentials and Connection

A ProviderConfig resource is required to supply the Control Plane with the necessary credentials and URL to access the anynines automation backend.

1. Obtain Credentials: Get the credentials for the specific a9s data services (e.g., a9s PostgreSQL) and base64 encode them:

   echo -n 'username' | base64

2. Map Data Service Values: Replace <data-service> in the manifest with the required value (e.g., postgresql).

3. Edit and Apply Manifest: Replace all placeholder values (<>) with the base64-encoded credentials and service URLs, then apply the manifest.

View ProviderConfig Manifest (Service Broker and Backup Manager)

apiVersion: v1
kind: Secret
metadata:
  name: <data-service>-service-broker-creds
  namespace: crossplane-system
type: Opaque
data:
  username: <service-broker-username-base64-encoded>
  password: <service-broker-password-base64-encoded>
---
apiVersion: dataservices.anynines.com/v1
kind: ProviderConfig
metadata:
  name: <data-service>-service-broker
spec:
  url: <service-broker-url> # e.g. http://example.com:3000
  # Whether the service is a Service Broker or a Backup Manager.
  serviceType: servicebroker
  # Optional custom TLS settings.
  tls:
    # The name in the Service Broker's certificate. Required if it differs from the Service Broker hostname.
    overrideServerName: <cert-host-name> # e.g. example.com
    # Set to true to disable certificate chain and hostname validation (insecure).
    insecureSkipVerify: false
    # Secret containing a custom CA bundle (PEM). Omit if using a trusted CA.
    caBundleSecretRef:
      key: cert
      name: <data-service>-service-broker-creds
      namespace: crossplane-system
  healthCheckEndpoint: "/osb_ext/v1/healthy"
  providerCredentials:
    source: Secret
    username:
      secretRef:
        namespace: crossplane-system
        name: <data-service>-service-broker-creds
        key: username
    password:
      secretRef:
        namespace: crossplane-system
        name: <data-service>-service-broker-creds
        key: password
---
apiVersion: v1
kind: Secret
metadata:
  name: <data-service>-backup-manager-creds
  namespace: crossplane-system
type: Opaque
data:
  username: <backup-manager-username-base64-encoded>
  password: <backup-manager-password-base64-encoded>
---
apiVersion: dataservices.anynines.com/v1
kind: ProviderConfig
metadata:
  name: <data-service>-backup-manager
spec:
  url: <backup-manager-url> # e.g. http://example.com:3000
  # Whether the service is a service broker or a backup manager.
  serviceType: backupmanager
  # Optional custom TLS settings.
  tls:
    # The name in the Backup Manager's certificate. Required if it differs from the Backup Manager hostname.
    overrideServerName: <cert-host-name> # e.g. example.com
    # Set to true to disable certificate chain and hostname validation (insecure).
    insecureSkipVerify: false
    # Secret containing a custom CA bundle (PEM). Omit if using a trusted CA.
    caBundleSecretRef:
      key: cert
      name: <data-service>-backup-manager-creds
      namespace: crossplane-system
  healthCheckEndpoint: "/v2/healthy" # Use "/instances" for a9s Backup Managers below v68
  providerCredentials:
    source: Secret
    username:
      secretRef:
        namespace: crossplane-system
        name: <data-service>-backup-manager-creds
        key: username
    password:
      secretRef:
        namespace: crossplane-system
        name: <data-service>-backup-manager-creds
        key: password

note

The healthCheckEndpoint fields in the above ProviderConfigs default to /instances when not set. This endpoint is common to both service brokers and backup managers. For improved performance and scalability, dedicated health check endpoints are available and recommended. The appropriate endpoint depends on whether the ProviderConfig is for a service broker or backup manager. See the following table for information on which one to use.

Provider type	Recommended endpoint	Default endpoint
service broker	/osb_ext/v1/healthy	/instances
backup manager	/v2/healthy in versions v68 and above	/instances

a8s (K8s-based Data Services)

A. Install a8s Framework

The a8s Framework is required to provision and manage the lifecycle of containerized data services. Follow the Install the a8s Control Plane instructions to install the framework components into the Control Plane cluster.

B. Deploy Connectivity Layer

The Crossplane® Provider for Kubernetes is deployed to allow the Control Plane to communicate with the local Kubernetes API for managing containerized data service instances.

kubectl apply -f https://raw.githubusercontent.com/anynines/klutchio/refs/heads/main/crossplane-api/deploy/provider-kubernetes.yaml

Verification:

kubectl get provider -w

Wait until provider-kubernetes is HEALTHY.

C. Establish Connection (In-Cluster)

A ProviderConfig authorizes the connectivity layer to manage resources within this local Control Plane cluster, effectively treating it as the a8s automation backend. This uses InjectedIdentity for authentication.

kubectl apply -f https://raw.githubusercontent.com/anynines/klutchio/refs/heads/main/crossplane-api/deploy/config-in-cluster.yaml

Verification:

kubectl get providerconfigs.kubernetes.crossplane.io

Remote Topology

The instructions above assume the Control Plane also serves as the automation backend. When integrating with a separate, remote Kubernetes cluster hosting a8s, the setup requires a different configuration.

4. Publish Data Service APIs

The final step exposes the supported data services to App Clusters by creating APIServiceExportTemplates.

View and Apply Bindable Klutch APIs Manifest

kubectl apply -f - <<EOF
apiVersion: bind.anynines.com/v1alpha1
kind: APIServiceExportTemplate
metadata: { name: "servicebindings", namespace: crossplane-system }
spec:
  APIServiceSelector: { resource: servicebindings, group: anynines.com }
  permissionClaims:
    - group: ""
      resource: secrets
      version: v1
      selector: { owner: Provider }
    - group: ""
      resource: configmaps
      version: v1
      selector: { owner: Provider }
---
apiVersion: bind.anynines.com/v1alpha1
kind: APIServiceExportTemplate
metadata: { name: "backups", namespace: crossplane-system }
spec:
  APIServiceSelector: { resource: backups, group: anynines.com }
---
apiVersion: bind.anynines.com/v1alpha1
kind: APIServiceExportTemplate
metadata: { name: "restores", namespace: crossplane-system }
spec:
  APIServiceSelector: { resource: restores, group: anynines.com }
EOF

For each data service configured in Step 3, an APIServiceExportTemplate must be created and applied. This allows App Clusters to access and bind the Klutch APIs.

1. Identify Resource Name: Use the table below to find the required resource name for your chosen service.

   Data Service	Resource Name (<RESOURCE_NAME>)	Applies to Backend(s)
   PostgreSQL	postgresqlinstances	a9s / a8s
   MariaDB	mariadbinstances	a9s
   MongoDB	mongodbinstances	a9s
   Messaging	messaginginstances	a9s
   Search	searchinstances	a9s
   Prometheus	prometheusinstances	a9s
   Logme2	logme2instances	a9s

2. Create and Apply Manifest: For each desired service, replace <RESOURCE_NAME> in the template below, save it (e.g., postgresql-export.yaml), and apply it.

   View APIServiceExportTemplate Manifest Template

   apiVersion: bind.anynines.com/v1alpha1
   kind: APIServiceExportTemplate
   metadata:
     name: "<RESOURCE_NAME>"
     namespace: crossplane-system
   spec:
     APIServiceSelector:
       resource: <RESOURCE_NAME>
       group: anynines.com

   For example, to configure PostgreSQL create postgresql-export.yaml with the following content:

   View PostgreSQL APIServiceExportTemplate Manifest

   apiVersion: bind.anynines.com/v1alpha1
   kind: APIServiceExportTemplate
   metadata:
     name: postgresqlinstances
     namespace: crossplane-system
   spec:
     APIServiceSelector:
       resource: postgresqlinstances
       group: anynines.com

   Apply the configuration:

   kubectl apply -f postgresql-export.yaml

Next Steps

The Control Plane is now fully configured with the necessary provisioning logic and exposed APIs for a9s/a8s data services.

If you want to add managed cloud services like RDS PostgreSQL and S3 to your service catalog, you can configure the AWS Cloud Backend at any time.

Otherwise, you can proceed to bind an App Cluster to the Control Plane to start consuming a9s/a8s data services and other configured services.