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:
Crete new clusterkind create cluster -n surreal-demo
Verify clusterkubectl config current-context
The output of this command should be:
Outputkind-surreal-demo
Verify nodeskubectl get ns
The output of this command should be:
OutputNAME 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:
Installkubectl 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
Verify Podskubectl get pods --namespace tidb-operator -l app.kubernetes.io/instance=tidb-operator
The output of this command should look like this:
OutputNAME 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:
kubectl create ns tikv
Create TIDB Clusterkubectl apply -n tikv -f https://raw.githubusercontent.com/pingcap/tidb-operator/v1.4.5/examples/basic/tidb-cluster.yaml
Verify TIDB Clusterkubectl get -n tikv tidbcluster
The output of this command should look like this:
OutputNAME 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:
Add SurrealDB Helm repositoryhelm repo add surrealdb https://helm.surrealdb.com helm repo update
Get TIKV PD service URLkubectl get -n tikv svc/basic-pd
the output of this command should look like this:
OutputNAME 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 variableexport TIKV_URL=tikv://basic-pd.tikv:2379
Install SurrealDB HELM charthelm install --set surrealdb.path=$TIKV_URL --set surrealdb.auth=false --set image.tag=latest surrealdb-tikv surrealdb/surrealdb
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 [{ namespaces: { }, users: { root: "DEFINE USER root ON ROOT PASSHASH '...' ROLES OWNER" } }]
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
surreal sql --conn 'http://localhost:8000' --user root --pass surrealdb
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.
Get podkubectl get pod
The output of this command should look like this:
OutputNAME READY STATUS RESTARTS AGE surrealdb-tikv-7488f6f654-lsrwp 1/1 Running 0 13m
Delete podkubectl delete pod surrealdb-tikv-7488f6f654-lsrwp
Get podkubectl get pod
OutputNAME READY STATUS RESTARTS AGE surrealdb-tikv-7488f6f654-bnkjz 1/1 Running 0 4s
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.