Let the Oracle Database Operator for Kubernetes Do the Job

Hello everyone! New Year, New Life, and finally, old dreams and goals are coming out of the paper. For my first blog, at the beginning of 2022, I chose to talk about Oracle Database Kubernetes Operator, a.k.a OraOperator. 

In this post, I'll talk about Oracle Database Kubernetes Operator, a.k.a OraOperator, and offer a gentle introduction to Kubernetes Operator and Cloud-Native Architecture -- base for all.

Introduction to Kubernetes Operator

Why write a Kubernetes operator? What is an Operator, and why is it vital to the specialized system to run over Kubernetes in symbiosis? I will try to explain in this gentle introduction to Operator.

The Cloud Native Design Principles

First, as a baseline, a Cloud Native Architecture is a set of principles focused on optimizing systems to the unique capabilities of the Cloud, like agility, elasticity, scalability, and resilience, to list some of them. To accomplish these principles, CNCF creates a design representing the fundamental baseline to this architecture. The following picture summarizes the Cloud Native Design Principles:

The Kubernetes project is the engine in charge of dynamically orchestrating the containers, leveraging the capabilities of the containers managing their whole lifecycle, and providing capabilities such as self-healing and reconciliation.

But containers are by best practices ephemerals, which means that if they die, there isn't a state saved, or better, you lose everything inside it. This stateless approach follows the sixth factor from the 12-factor app methodology, which recommends "execute the app as one or more stateless processes.".

And, also, Kubernetes was not projected to manage the state by default. Thus, how can we take advantage of containerizing and dynamic orchestrating coming from Kubernetes to run highly distributed data stores, like a Database? How can we "adapt" our stateful application to use Kubernetes and at the same time persist state, apply data replication, failover automation (again manage state), and so on?

Ok, it is possible to do it handmade, which means writing code to overpass the stateless environment and provide what we require, but to be honest, it is an error-prone and Herculius task. This is where the Operator takes place.

The Kubernetes Operator

Using an existing idea, "Everything as a Code," an operator pattern is a way to put the system operator, our well-known sysadmin or dba, "as a Code.". The Operator has three components, a specialized or domain-oriented Worker -- the Controller -- that stay in the loop, observing an application or an infrastructure, to guarantee that its states during execution -- the current state -- are the desired and documented by the declared state in a domain-specific language.

Looking for Kubernetes, a most concise description from Jimmy Zelinskie is "An operator is a Kubernetes Controller that understands two domains: Kubernetes and something else. Combining both domains' knowledge can automate tasks that usually require a human operator that understands both domains".

The below diagram explains this observability state from the Operator to maintain the desired state based on comparing declared and current states.

Thus when we have a stateful application or infrastructure to deploy and manage and decide to build an Operator, we create a Kubernetes Controller with the capabilities to understand and interact with Kubernetes Domain and its APIs. And, at the same time, to understand that specialized domain and operates to provide stateful management, failover automation without breaking the application consistency, also administrative functions like backup/restore, besides many other crucial operational tasks, all "as Code."

In addition to the Controller, the Operator also includes Custom Resources and Custom Resource Definitions (CRDs). The desired state of the application is encapsulated in one or more CRDs using the domain-specific language, and the Controller has the operational knowledge lead with these definitions and gets the objects from the application to the desired state.

For further details about Kubernetes Operator, I recommend the CNCF Operator White Paper.

Oracle Database Operator for Kubernetes (a.k.a. OraOperator)

I am not afraid to say that Kubernetes is the infrastructure orchestrator of the Cloud, providing the dynamic mechanism to handle the Containers, providing resilience, self-healing, a kind of operational elasticity. And, running and taking advantage of this fantastic technology is key to success on Cloud Native deployments.

It is fantastic that Oracle has decided to make Oracle Database Kubernetes-native, which makes the most critical and adopted Database of the World operable and observable by the essential building block of Cloud Native infrastructure.

Oracle Database is a stateful infrastructure and requires enterprise-ready operational capabilities, like backup/restore, resilience, failover automation, etc. Thus, to make it viable to run over Kubernetes, Oracle released the Oracle Database Operator for Kubernetes [ OraOperator ], which follows Operator Pattern—creating the integration between the infrastructure of the Kubernetes and the infrastructure of the Oracle Database, allowing them to work together to deliver one of the most powerful Cloud-Native Data Management platforms.

The OraOperator project implemented Kubernetes resources like Controllers and Custom Resources Definitions for automating some tasks from Oracle Database lifecycle management. For example, the bellow code of the CRD for Sharding Database.

---
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  annotations:
    controller-gen.kubebuilder.io/version: v0.6.1
  creationTimestamp: null
  name: shardingdatabases.database.oracle.com
spec:
  group: database.oracle.com
  names:
    kind: ShardingDatabase
    listKind: ShardingDatabaseList
    plural: shardingdatabases
    singular: shardingdatabase
  scope: Namespaced
  versions:
  - name: v1alpha1
    schema:
      openAPIV3Schema:
        description: ShardingDatabase is the Schema for the shardingdatabases API
    .....

Operator Support Configurations

The current release (v0.1.0) also supports off-Kubernetes-cluster management tasks, which helps the Database Reliable Engineers (DBRE) with their daily job throughout Kubernetes -- kubectl -- commands. This means that it is possible to operate Oracle Autonomous Database (ADB) using the OraOperator.

The bellow list summarizes which Oracle Database Configuration and their supported operations:

• off-K8s-cluster
  • Database Configuration: Autonomous DB [1]
    • Operations: provision, bind, start, stop, terminate (soft/hard), scale (down/up)
• in-K8s-cluster
  • Database Configuration: Single Instance databases (SIDB) [2]
    • Operations: provision, clone, patch (in-place/out-of-place), update database initialization parameters, update database configuration (Flashback, archiving), Oracle Enterprise Manager (EM) Express (a basic observability console)
  • Database Configuration: Containerized Sharded databases (SHARDED)
    • Operations: provision/deploy sharded databases and the shard topology, add a new shard, delete an existing shard

A Big Picture of the Operator for Sharded Database

As a usage example, the below diagram shows the adoption of the OraOperator for deploying the Oracle Database Sharded option. After installing the Operator inside OKE [3], we will install our database sharded with two containers for sharded DBs instances, two containers with GMS, and one Catalog instance.

Release Review

This is the 0.1.0 release and comes with many valuable features for us developers, and BDRE works with the enterprise-ready Oracle Database, including in our computer using Minikude, for example. The following release will grow the number of certified third-party Kubernetes clusters and in Database Configuration like On-premises Databases (CDB/PDB).

Also, it is essential the attention that the current release of OraOperator (v0.1.0) is for development and test only. DO NOT USE IT IN PRODUCTION.

References

Some references to continue study:

• Oracle Database Operator for Kubernetes GitHub
• Material from my friend and project leader Kuassi Mensah (Director of Product Management for Java access to Oracle DB)
  • Making Oracle Database Kubernetes-native
  • Youtube: Why Use the Kubernetes Operator for Oracle Database? 

What Next?

Yes, this article is the pilot from a Serie about Oracle Database Operator for Kubernetes, and the Next Episode will be about "Getting started with OraOperator for Single Instance databases."

[1]: Oracle Autonomous Database on shared Oracle Cloud Infrastructure (OCI), also known as ADB-S
[2]: Containerized Single Instance databases (SIDB)
[3]: Oracle Container Engine for Kubernetes (OKE) is an Oracle-managed Kubernetes service from Oracle Cloud Infrastructure.