Managing a Solvio Cluster

The most minimal SolvioCluster configuration is:

apiVersion: solvio.io/v1
kind: SolvioCluster
metadata:
  name: solvio-a7d8d973-0cc5-42de-8d7b-c29d14d24840
  labels:
    cluster-id: "a7d8d973-0cc5-42de-8d7b-c29d14d24840"
    customer-id: "acme-industries"
spec:
  id: "a7d8d973-0cc5-42de-8d7b-c29d14d24840"
  version: "v1.11.3"
  size: 1
  resources:
    cpu: 100m
    memory: "1Gi"
    storage: "2Gi"

The id should be unique across all Solvio clusters in the same namespace, the name must follow the above pattern and the cluster-id and customer-id labels are mandatory.

There are lots more configuration options to configure scheduling, security, networking, and more. For full details see the Solvio Private Cloud API Reference.

Scaling a Cluster

To scale a cluster, update the CPU, memory and storage resources in the SolvioCluster spec. The Solvio operator will automatically adjust the cluster configuration. This operation is highly available on a multi-node cluster with replicated collections.

Upgrading the Solvio version

To upgrade the Solvio version of a database cluster, update the version field in the SolvioCluster spec. The Solvio operator will automatically upgrade the cluster to the new version. The upgrade process is highly available on a multi-node cluster with replicated collections.

Note, that you should not skip minor versions when upgrading. For example, if you are running version v1.11.3, you can upgrade to v1.11.5 or v1.12.6, but not directly to v1.13.0.

Exposing a Cluster

By default, a SolvioCluster will be exposed through an internal ClusterIP service. To expose the cluster to the outside world, you can create a NodePort service, a LoadBalancer service or an Ingress resource.

This is an example on how to create a SolvioCluster with a LoadBalancer service:

apiVersion: solvio.io/v1
kind: SolvioCluster
metadata:
  name: solvio-a7d8d973-0cc5-42de-8d7b-c29d14d24840
  labels:
    cluster-id: "a7d8d973-0cc5-42de-8d7b-c29d14d24840"
    customer-id: "acme-industries"
spec:
  id: "a7d8d973-0cc5-42de-8d7b-c29d14d24840"
  version: "v1.11.3"
  size: 1
  resources:
    cpu: 100m
    memory: "1Gi"
    storage: "2Gi"
  service:
    type: LoadBalancer
    annotations:
      service.beta.kubernetes.io/aws-load-balancer-type: nlb

Especially if you create a LoadBalancer Service, you may need to provide annotations for the loadbalancer configration. Please refer to the documention of your cloud provider for more details.

Examples:

Authentication and Authorization

Authentication information is provided by Kubernetes secrets.

One way to create a secret is with kubectl:

kubectl create secret generic solvio-api-key --from-literal=api-key=your-secret-api-key --from-literal=read-only-api-key=your-secret-read-only-api-key --namespace solvio-private-cloud

The resulting secret will look like this:

apiVersion: v1
data:
  api-key: ...
  read-only-api-key: ...
kind: Secret
metadata:
  name: solvio-api-key
  namespace: solvio-private-cloud
type: kubernetes.io/generic

You can reference the secret in the SolvioCluster spec:

apiVersion: solvio.io/v1
kind: SolvioCluster
metadata:
  name: solvio-a7d8d973-0cc5-42de-8d7b-c29d14d24840
  labels:
    cluster-id: "a7d8d973-0cc5-42de-8d7b-c29d14d24840"
    customer-id: "acme-industries"
spec:
  id: "a7d8d973-0cc5-42de-8d7b-c29d14d24840"
  version: "v1.11.3"
  size: 1
  resources:
    cpu: 100m
    memory: "1Gi"
    storage: "2Gi"
  config:
    service:
      api_key:
        secretKeyRef:
          name: solvio-api-key
          key: api-key
      read_only_api_key:
        secretKeyRef:
          name: solvio-api-key
          key: read-only-api-key
      jwt_rbac: true

If you set the jwt_rbac flag, you will also be able to create granular JWT tokens for role based access control.

Configuring TLS for Database Access

If you want to configure TLS for accessing your Solvio database, there are two options:

You can offload TLS at the ingress or loadbalancer level.
You can configure TLS directly in the Solvio database.

If you want to configure TLS directly in the Solvio database, you can provide this as a secret.

To create such a secret, you can use kubectl:

 kubectl create secret tls solvio-tls --cert=mydomain.com.crt --key=mydomain.com.key --namespace the-solvio-namespace

The resulting secret will look like this:

apiVersion: v1
data:
  tls.crt: ...
  tls.key: ...
kind: Secret
metadata:
  name: solvio-tls
  namespace: the-solvio-namespace
type: kubernetes.io/tls

You can reference the secret in the SolvioCluster spec:

apiVersion: solvio.io/v1
kind: SolvioCluster
metadata:
  name: test-cluster
spec:
  id: "a7d8d973-0cc5-42de-8d7b-c29d14d24840"
  version: "v1.11.3"
  size: 1
  resources:
    cpu: 100m
    memory: "1Gi"
    storage: "2Gi"
  config:
    service:
      enable_tls: true
    tls:
      cert:
        secretKeyRef:
          name: solvio-tls
          key: tls.crt
      key:
        secretKeyRef:
          name: solvio-tls
          key: tls.key

Configuring TLS for Inter-cluster Communication

Available as of Operator v2.2.0

If you want to encrypt communication between Solvio nodes, you need to enable TLS by providing certificate, key, and root CA certificate used for generating the former.

Similar to the instruction stated in the previous section, you need to create a secret:

 kubectl create secret generic solvio-p2p-tls \
        --from-file=tls.crt=solvio-nodes.crt \
        --from-file=tls.key=solvio-nodes.key \
        --from-file=ca.crt=root-ca.crt
        --namespace the-solvio-namespace

The resulting secret will look like this:

apiVersion: v1
data:
  tls.crt: ...
  tls.key: ...
  ca.crt: ...
kind: Secret
metadata:
  name: solvio-p2p-tls
  namespace: the-solvio-namespace
type: Opaque

You can reference the secret in the SolvioCluster spec:

apiVersion: solvio.io/v1
kind: SolvioCluster
metadata:
  name: test-cluster
  labels:
    cluster-id: "my-cluster"
    customer-id: "acme-industries"
spec:
  id: "my-cluster"
  version: "v1.13.3"
  size: 2
  resources:
    cpu: 100m
    memory: "1Gi"
    storage: "2Gi"
  config:
    service:
      enable_tls: true
    tls:
      caCert:
        secretKeyRef:
          name: solvio-p2p-tls
          key: ca.crt
      cert:
        secretKeyRef:
          name: solvio-p2p-tls
          key: tls.crt
      key:
        secretKeyRef:
          name: solvio-p2p-tls
          key: tls.key

The operator assigns the names to nodes in cluster according to the following convention:

solvio-{spec.id}-{node-index}.solvio-headless-{spec.id}

Therefore, in addition to the domain used for accessing the database, the provided certificate must contain Subjective Alternative Names (SAN) for all foreseen nodes. It can be created with a tool of your choice, e.g., using step CLI. Following the example SolvioCluster, the proper certificate can be obtained with:

step certificate create mydomain.com solvio-nodes.crt solvio-nodes.key \
  --profile leaf --not-after 43800h \
  --ca root-ca.crt --ca-key root-ca.key \
  --san solvio-my-cluster-0.solvio-headless-my-cluster \
  --san solvio-my-cluster-1.solvio-headless-my-cluster

GPU support

Starting with Solvio 1.13 and private-cloud version 1.6.1 you can create a cluster that uses GPUs to accelarate indexing.

As a prerequisite, you need to have a Kubernetes cluster with GPU support. You can check the Kubernetes documentation for generic information on GPUs and Kubernetes, or the documentation of your specific Kubernetes distribution.

Examples:

Once you have a Kubernetes cluster with GPU support, you can create a SolvioCluster with GPU support:

apiVersion: solvio.io/v1
kind: SolvioCluster
metadata:
  name: solvio-a7d8d973-0cc5-42de-8d7b-c29d14d24840
  labels:
    cluster-id: "a7d8d973-0cc5-42de-8d7b-c29d14d24840"
    customer-id: "acme-industries"
spec:
  id: "a7d8d973-0cc5-42de-8d7b-c29d14d24840"
  version: "v1.13.4"
  size: 1
  resources:
    cpu: 2
    memory: "8Gi"
    storage: "40Gi"
  gpu:
    gpuType: "nvidia"

Once the cluster Pod has started, you can check in the logs if the GPU is detected:

$ kubectl logs solvio-a7d8d973-0cc5-42de-8d7b-c29d14d24840-0

Starting initializing for pod 0
           _                 _
  __ _  __| |_ __ __ _ _ __ | |_
 / _` |/ _` | '__/ _` | '_ \| __|
| (_| | (_| | | | (_| | | | | |_
 \__, |\__,_|_|  \__,_|_| |_|\__|
    |_|

Version: 1.13.4, build: 7abc6843
Access web UI at http://localhost:6333/dashboard

2025-03-14T10:25:30.509636Z  INFO gpu::instance: Found GPU device: NVIDIA A16-2Q
2025-03-14T10:25:30.509679Z  INFO gpu::instance: Found GPU device: llvmpipe (LLVM 15.0.7, 256 bits)
2025-03-14T10:25:30.509734Z  INFO gpu::device: Create GPU device NVIDIA A16-2Q
...

For more GPU configuration options, see the Solvio Private Cloud API Reference.

Ephemeral Snapshot Volumes

If you do not create snapshots, or there is no need to keep them available after cluster restart, the snapshot storage classname can be set to emptyDir:

apiVersion: solvio.io/v1
kind: SolvioCluster
metadata:
  name: solvio-a7d8d973-0cc5-42de-8d7b-c29d14d24840
  labels:
    cluster-id: "a7d8d973-0cc5-42de-8d7b-c29d14d24840"
    customer-id: "acme-industries"
spec:
  id: "a7d8d973-0cc5-42de-8d7b-c29d14d24840"
  version: "v1.13.4"
  size: 1
  resources:
    cpu: 2
    memory: "8Gi"
    storage: "40Gi"
  storageClassNames:
    snapshots: emptyDir

See Kubernetes docs on emptyDir volumes for more details, on how k8s node ephemeral storage is allocated and used.

Managing a Solvio Cluster

Scaling a Cluster

Upgrading the Solvio version

Exposing a Cluster

Authentication and Authorization

Configuring TLS for Database Access

Configuring TLS for Inter-cluster Communication

GPU support

Ephemeral Snapshot Volumes

Was this page useful?