How to quickly spin up an Oracle Database on Kubernetes

With the availability of a full-fledged Kubernetes Operator for Oracle Database, spinning up that Oracle database has never been simpler! And with a whole range of options to chose from for the persistence of your data, you can now manage the lifecycle management of your database in the same way as your Kubernetes-based applications

Oracle Database on Kubernetes

Choosing your deployment model

The Database Operator actually supports 3 different deployment models:

• Creating a new Pluggable database on top of an existing Database — in this case you need to have access to an already existing classic database, which is interesting if this is how your organization is managing Data segregation for microservices. But it still requires you to leverage some corporate resources in order to manage that original classic database setup, so for a quick try-out of a new application prototype this is probably not going to be your first choice. If on the other hand you want to deploy an enterprise-grade application with full corporate DBA support this will make much more sense.
• Creating an Autonomous database instance — this use-case requires you to have access to an OCI (Oracle Cloud) environment, and you actually can spin up 2 “free” Oracle DB instances as part of a personal trial account. Depending on the location of your application this cloud-based database might be acceptable or not (latency will be an important element!). If on the other hand you have access to a corporate OCI environment, you are not limited to these 2 instances, but you will incur a cost when spinning up an instance.
• But as the title of this article already indicated, we are going to explore the 3rd option — running the database inside Kubernetes as a container, which has now become much easier as all the heavy lifting of the persistency is done for you by the operator.

Deployment options of the Database Operator

Looking at the Persistency options for your data

Running your database inside Kubernetes forces you to think about how you want to persist your data beyond the lifespan of the actual pod running your database. In case your are just running a quick test with some sample data this might not be a concern at all, so the first option to create a dynamically allocated block volume created on the local K8S node is the solution for this.

In case you want some more resilience and allow for K8S node failure without losing your data, you might opt for the use of a statically allocated NFS filesystem that can be mounted on all nodes of the K8S cluster, and thus be available for a restart of your database on a different node in case of a node outage.

A slightly different approach to persistence is using the Sharding features of the Oracle Database, and using a Kubernetes statefulset and the Oracle Data Services Image. This approach offers better scalability and high availability, but should really be a topic for a separate article.

So how do you spin up a database ?

After you have decided on your persistence, it’s time to take a look at the yaml file that will define your database configuration. You can find an example config file here.

In the top level section of the file, the parameter kindrefers to the type of database to create, in this case we will be launching a DB in a container running on the Kubernetes cluster, known as a Single Instance Database. The parameter name defines the oracle database name we'll be creating, as well as the name used to refer to the database via the various kubectl commands

apiVersion: database.oracle.com/v1alpha1
kind: SingleInstanceDatabase
metadata:
  name: sidb-test1
  namespace: default

The secretName defines the name of the secret containing the database password. You can specify to remove this secret after creation for enhanced security using the parameter keepSecret.

adminPassword:
  secretName: admin-secret
  keepSecret: true

The image section specifies where to pull the database container image from. In this case we use the default image provided by Oracke, you could build a custom image and refer to that image instead. The parameter pullSecrets refers to the name of the secret where we stored the credentials of the container repo, in this case the Oracle Container Repository.

image:
  pullFrom: container-registry.oracle.com/database/enterprise:latest
  pullSecrets: oracle-container-registry-secret

The section persistence defines the type of persistent storage to use. In this case we'll use the class oci to use an OCI Block Volume. The parameter accessMode specifies this is a block volume that can only be mounted on a single node of the cluster. In the next lab we'll be using an NFS volume which can be mounted on multiple nodes at the same time.

persistence:
  size: 100Gi
  storageClass: "oci"
  accessMode: "ReadWriteOnce"

And finally the parameter replicasspecifies how many pods we want to have up and running. As this is a block-based volume that can only be mounted on a single node of the cluster we are using 1.

replicas: 1

Testing it all out

OK, so all these options have gotten you curious to test this out for yourself ? Easiest way is to run the Oracle Livelab entitled Oracle Database Kubernetes Operator.

LiveLab for testing the Database Operator

This lab will guide you to obtain a free Oracle Cloud tenancy, set up a managed Kubernetes cluster (OKE) and spin up the database in the various flavours described in this article !