kubectl
: To manage the Kubernetes clusterhelm
: To install SurrealDB server and TiKVKIND
and Docker: To run a local Kubernetes cluster inside a Docker containerSurreal CLI
: To interact with the SurrealDB serverKIND
ClusterFirst, we need to create a KIND
cluster. KIND is a tool for running local Kubernetes clusters using Docker container “nodes”. It’s a great tool for experimenting with Kubernetes without spending a lot of time creating a full-featured cluster.
Run the following command to create a cluster:
Create new clusterkind create cluster -n surreal-demo
Run the following command to verify that we can interact with the created cluster:
Verify clusterkubectl config current-context
The output of this command should be:
kind-surreal-demo
Run the following command to verify that the nodes are running:
kubectl get ns
The output of this command should be:
NAME STATUS AGE default Active 79s kube-node-lease Active 79s kube-public Active 79s kube-system Active 79s local-path-storage Active 75s
Now that we have a Kubernetes cluster, we can deploy the TiDB operator
. TiDB operator is a Kubernetes operator that manages the lifecycle of TiDB clusters deployed to Kubernetes.
You can deploy it following these steps:
CRDS installationkubectl create -f https://raw.githubusercontent.com/pingcap/tidb-operator/v1.4.5/manifests/crd.yaml
Update HELM repositorieshelm repo add pingcap https://charts.pingcap.org helm repo update helm install \ -n tidb-operator \ --create-namespace \ tidb-operator \ pingcap/tidb-operator \ --version v1.4.5
Get pod statuskubectl get pods --namespace tidb-operator -l app.kubernetes.io/instance=tidb-operator
The output of this command should look like this:
NAME READY STATUS RESTARTS AGE tidb-controller-manager-56f49794d7-hnfz7 1/1 Running 0 20s tidb-scheduler-8655bcbc86-66h2d 2/2 Running 0 20s
Now that we have the TiDB Operator running, it’s time to define a TiDB Cluster and let the Operator do the rest. One of the TiDB Cluster components is the TiKV, which we are interested in. Given this is a demo, we will use a basic example cluster, but there are several examples in the official GitHub repo in case you need a more production-grade deployment
Run the following commands to deploy the TiKV cluster:
Run the following command to create a namespace for the TiDB cluster:
kubectl create ns tikv
Run the following command to create the TiDB cluster:
TiDB cluster creationkubectl apply -n tikv -f https://raw.githubusercontent.com/pingcap/tidb-operator/v1.4.5/examples/basic/tidb-cluster.yaml
Run the following command to check the cluster status and wait until it’s ready:
Verify TiDB clusterkubectl get -n tikv tidbcluster
The output of this command should look like this:
NAME READY PD STORAGE READY DESIRE TIKV STORAGE READY DESIRE TIDB READY DESIRE AGE basic False pingcap/pd:v6.5.0 1Gi 1 1 1Gi 1 1 41s $ kubectl get -n tikv tidbcluster NAME READY PD STORAGE READY DESIRE TIKV STORAGE READY DESIRE TIDB READY DESIRE AGE basic True pingcap/pd:v6.5.0 1Gi 1 1 pingcap/tikv:v6.5.0 1Gi 1 1 pingcap/tidb:v6.5.0 1 1 5m
Now that we have a TiDB cluster running, we can deploy SurrealDB. For this guide, we will use the SurrealDB Helm chart. Run the following commands to deploy SurrealDB:
Run the following command to add the SurrealDB Charts repository:
Add Helm repositoryhelm repo add surrealdb https://helm.surrealdb.com helm repo update
Run the following command to get the TiKV PD service URL:
Get TiKV URLkubectl get -n tikv svc/basic-pd
The output of this command should look like this:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE basic-pd ClusterIP 10.96.208.25 <none> 2379/TCP 10h
Then set the TIKV_URL variable to the PD service URL:
Set TIKV_URL varexport TIKV_URL=tikv://basic-pd.tikv:2379
Now we can install the SurrealDB Helm chart with TIKV_URL
defined above and auth disabled so that we can create the initial credentials:
Install SurrealDB HELM charthelm install --set surrealdb.path=$TIKV_URL --set surrealdb.unauthenticated=true --set image.tag=latest surrealdb-tikv surrealdb/surrealdb
We can then connect to the cluster and define the initial credentials (see the section below to connect):
surreal sql -e http://... > DEFINE USER root ON ROOT PASSWORD 'StrongSecretPassword!' ROLES OWNER;
Verify you can connect to the database with the new credentials:
surreal sql -u root -p 'StrongSecretPassword!' -e http://... > INFO FOR ROOT [{ accesses: { }, namespaces: { }, nodes: { "0e87c953-68d7-40e1-9090-3dfc404af25e": 'NODE 0e87c953-68d7-40e1-9090-3dfc404af25e SEEN 1742869518357 ACTIVE' }, system: { available_parallelism: 14, cpu_usage: 4.321133613586426f, load_average: [2.2265625f, 2.2138671875f, 2.044921875f], memory_allocated: 13428527, memory_usage: 154812416, physical_cores: 14, threads: 32 }, users: { root: "DEFINE USER root ON ROOT PASSHASH '...' ROLES OWNER DURATION FOR TOKEN 1h, FOR SESSION NONE" } }]
Authentication can be enabled now that the initial credentials have been created:
Update SurrealDB Helm Charthelm upgrade --set surrealdb.path=$TIKV_URL --set image.tag=latest surrealdb-tikv surrealdb/surrealdb
Now that we have SurrealDB running, we can run some experiments to verify that everything is working as expected. For this guide, we will use the Surreal CLI. Run the following commands to run some experiments:
kubectl port-forward svc/surrealdb-tikv 8000
OutputForwarding from 127.0.0.1:8000 -> 8000 Forwarding from [::1]:8000 -> 8000
Use the following command to connect to the SurrealDB server using the CLI from another shell:
surreal sql --conn 'http://localhost:8000' --user root --pass surrealdb
Use the following to create a SurrealDB database and try out a few queries:
surreal sql --conn 'http://localhost:8000' --user root --pass surrealdb > USE NS ns DB db; ns/db> CREATE record; { id: record:wbd69kmc81l4fbee7pit } ns/db> CREATE record; { id: record:vnyfsr22ovhmmtcm5y1t } ns/db> CREATE record; { id: record:se49petzb7c4bc7yge0z } ns/db> SELECT * FROM record; [{ id: record:se49petzb7c4bc7yge0z }, { id: record:vnyfsr22ovhmmtcm5y1t }, { id: record:wbd69kmc81l4fbee7pit }] ns/db>
The data created above has been persisted to the TiKV cluster. Let’s verify it by deleting the SurrealDB server and let Kubernetes recreate it.
We will first use get pod
to get the names of the existing pods:
Get podkubectl get pod
The output of this command should look like this:
NAME READY STATUS RESTARTS AGE surrealdb-tikv-7488f6f654-lsrwp 1/1 Running 0 13m
We can then grab the name and use delete pod
to delete it.
kubectl delete pod surrealdb-tikv-7488f6f654-lsrwp
A get pod
command shows us that the pod has been recreated under a different name.
kubectl get pod
OutputNAME READY STATUS RESTARTS AGE surrealdb-tikv-7488f6f654-bnkjz 1/1 Running 0 4s
We can now connect again and verify the data is still there (you may need to re-run the port-forwarding command):
surreal sql --conn 'http://localhost:8000' --user root --pass surrealdb > USE NS ns DB db; ns/db> SELECT * FROM record; [{ id: record:se49petzb7c4bc7yge0z }, { id: record:vnyfsr22ovhmmtcm5y1t }, { id: record:wbd69kmc81l4fbee7pit }] ns/db>
NoteGiven we are using KIND, we use
port-forwarding
for demonstration purposes. In a full-featured Kubernetes cluster, you could setingress.enabled=true
when installing the SurrealDB Helm Chart and it would create a Load Balancer in front of the SurrealDB server pods.
This guide demonstrated how to deploy SurrealDB on Kubernetes using TiKV as a datastore. From here, you could try and deploy to EKS
, GKE
or AKS
, and play with the different configurations for the TiKV cluster.