When running VoltDB in Kubernetes, you are implicitly managing two separate technologies: the database cluster — that consists of "nodes" and the server processes that run on them — and the collection of Kubernetes "pods" the database cluster runs on. There is a one-to-one relationship between VoltDB nodes and Kubernetes pods and it is important that these two technologies stay in sync.
The good news is that the VoltDB Operator and Helm manage the orchestration of Kubernetes and the VoltDB servers. If a database server goes down, Kubernetes recognizes that the corresponding pod is not "live" and spins up a replacement. On the other hand, if you intentionally stop the database without telling the Operator or Kubernetes, Kubernetes insists on trying to recreate it.
Therefore, whereas on traditional servers you use voltadmin and sqlcmd to manage both the cluster and the database content, it is important in a Kubernetes environment that you use the correct utilities for the separate functions:
Use kubectl and helm to manage the cluster and the database configuration
Use voltadmin and sqlcmd to manage the database contents.
The following sections explain how to access and use each of these utilities. Subsequent chapters explain how to perform common cluster and database management functions using these techniques.
The key advantage to using Kubernetes is that it automates common administrative tasks, such as making sure the cluster keeps running. This is because the VoltDB Operator and Helm charts manage the synchronization of VoltDB and Kubernetes for you. But it does mean you must use helm or kubectl, and not the equivalent voltadmin commands, to perform operations that affect Kubernetes, such as starting and stopping the database, resizing the cluster, changing the configuration, and so on.
When you start the database for the first time, you specify the VoltDB Helm chart and a set of properties that define how the cluster and database are configured. The result is a set of Kubernetes pods and VoltDB server processes known as a Helm "release".
To manage the cluster and database configuration you use the helm upgrade command to update the
release and change the properties associated with the feature you want to control. For example, to change the frequency of
periodic snapshots in the mydb release to 30 minutes, you specify the new value for the
cluster.config.deployment.snapshot.frequency property, like so:
$ helm upgrade mydb voltdb/voltdb \ --reuse-values \ --set cluster.config.deployment.snapshot.frequency=30m
It is also possible to use the kubectl patch command to change release properties, specifying the new property value and action to take as a JSON string. However, the examples in this book use the helm upgrade equivalent wherever possible as the helm command tends to be easier to read and remember.
One caveat to using the helm upgrade command is that it not only upgrades the release, it checks to see if there is a new version of the original chart (in this example, voltdb/voltdb) and upgrades that too. Problems could occur if there are changes to the original chart between when you first start the cluster and when you need to stop or resize it.
The public charts are not changed very frequently. But if your database is in production for an extended period of time it could be an issue. Fortunately, there is a solution. To avoid any unexpected changes, you can tell Helm to use a specific version of the chart — the version you started with.
First, use the helm list command to list all of the releases (that is, database instances) you have installed. In the listing it will include both the name and version of the chart in use. For example:
Documentation$ helm list
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
mydb default 1 2020-08-12 12:45:30 deployed voltdb-1.0.0 10.0.0You can then specify the specific chart version when your upgrade the release, thereby avoiding any unexpected side effects:
$ helm upgrade mydb voltdb/voltdb \
--reuse-values \
--set cluster.clusterSpec.replicas=7 \
--version=1.0.0