As part of Oracle's resolution to make Oracle Database Kubernetes-native (that is, observable and operable by Kubernetes), Oracle released Oracle Database Operator for Kubernetes (OraOperator
or the operator). OraOperator extends the Kubernetes API with custom resources and controllers for automating Oracle Database lifecycle management.
In this v0.2.1 release, OraOperator
supports the following database configurations and infrastructure:
- Oracle Autonomous Database on shared Oracle Cloud Infrastructure (OCI) (ADB-S)
- Oracle Autonomous Database on dedicated Cloud infrastructure (ADB-D)
- Containerized Single Instance databases (SIDB) deployed in the Oracle Kubernetes Engine (OKE) and any k8s where OraOperator is deployed
- Containerized Sharded databases (SHARDED) deployed in OKE and any k8s where OraOperator is deployed
- Oracle Multitenant Databases (CDB/PDBs)
- Oracle Database Cloud Service (DBCS) (VMDB)
- Oracle Autonomous Container Database (ACD) (infrastructure) the infrastructure for provisionning Autonomous Databases.
Oracle will continue to extent OraOperator to support additional Oracle Database configurations.
This release of Oracle Database Operator for Kubernetes (the operator) supports the following lifecycle operations:
- ADB-S: Provision, Bind, Start, Stop, terminate (soft/hard), scale (up/down), Manual Backup, Manual Restore
- ADB-D: provision, bind, start, stop, terminate (soft/hard), scale (up/down), Manual Backup, Manual Restore
- ACD: provision, bind, restart, terminate (soft/hard)
- SIDB: 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), Oracle REST Data Service (ORDS) to support REST based SQL, PDB management, SQL Developer Web, and Application Express (Apex)
- SHARDED: Provision/deploy sharded databases and the shard topology, Add a new shard, Delete an existing shard
- Oracle Multitenant Database: Bind to a CDB, Create a PDB, Plug a PDB, Unplug a PDB, Delete a PDB, Clone a PDB, Open/Close a PDB
- Database Cloud Service: Provision, Bind, Scale Up/Down, Liveness Probe, Manual Backup
The upcoming releases will support new configurations, operations and capabilities.
CAUTION: The current release of OraOperator
(v0.2.1) is for development and testing only. DO NOT USE IN PRODUCTION.
This release has been installed and tested on the following Kubernetes platforms:
- Oracle Container Engine for Kubernetes (OKE) with Kubernetes 1.17 or later
- Oracle Linux Cloud Native Environment(OLCNE) 1.3 or later
- Minikube with version v1.21.0 or later
- Azure Kubernetes Service
- Amazon Elastic Kubernetes Service
- Red Hat OKD
- Red Hat OpenShift
Oracle strongly recommends that you ensure your system meets the following Prerequisites.
-
The operator uses webhooks for validating user input before persisting it in Etcd. Webhooks require TLS certificates that are generated and managed by a certificate manager.
Install the certificate manager with the following command:
kubectl apply -f https://github.com/jetstack/cert-manager/releases/latest/download/cert-manager.yaml
To install the operator in the cluster quickly, you can use a single oracle-database-operator.yaml file.
Run the following command
kubectl apply -f https://raw.githubusercontent.com/oracle/oracle-database-operator/main/oracle-database-operator.yaml
NOTE:
The above command will also upgrade the existing v0.2.0 OraOperator
installation to the latest version i.e. v0.2.1.
Ensure that the operator pods are up and running. For high availability, Operator pod replicas are set to a default of 3. You can scale this setting up or down.
$ kubectl get pods -n oracle-database-operator-system
NAME READY STATUS RESTARTS AGE
pod/oracle-database-operator-controller-manager-78666fdddb-s4xcm 1/1 Running 0 11d
pod/oracle-database-operator-controller-manager-78666fdddb-5k6n4 1/1 Running 0 11d
pod/oracle-database-operator-controller-manager-78666fdddb-t6bzb 1/1 Running 0 11d
- Check the resources
You should see that the operator is up and running, along with the shipped controllers.
For more details, see Oracle Database Operator Installation Instructions.
The quickstarts are designed for specific database configurations:
- Oracle Autonomous Database
- Oracle Autonomous Container Database
- Containerized Oracle Single Instance Database
- Containerized Oracle Sharded Database
- Oracle Multitenant Database
- Oracle Database Cloud Service
YAML file templates are available under /config/samples
. You can copy and edit these template files to configure them for your use cases.
To uninstall the operator, the final step consists of deciding whether you want to delete the custom resource definitions (CRDs) and Kubernetes APIServices introduced into the cluster by the operator. Choose one of the following options:
-
To delete all the CRD instances deployed to cluster by the operator, run the following commands, where is the namespace of the cluster object:
kubectl delete oraclerestdataservice.database.oracle.com --all -n <namespace> kubectl delete singleinstancedatabase.database.oracle.com --all -n <namespace> kubectl delete shardingdatabase.database.oracle.com --all -n <namespace> kubectl delete dbcssystem.database.oracle.com --all -n <namespace> kubectl delete autonomousdatabase.database.oracle.com --all -n <namespace> kubectl delete autonomousdatabasebackup.database.oracle.com --all -n <namespace> kubectl delete autonomousdatabaserestore.database.oracle.com --all -n <namespace> kubectl delete autonomouscontainerdatabase.database.oracle.com --all -n <namespace> kubectl delete cdb.database.oracle.com --all -n <namespace> kubectl delete pdb.database.oracle.com --all -n <namespace>
After all CRD instances are deleted, it is safe to remove the CRDs, APISerivces and operator deployment. Use the following command:
kubectl delete -f oracle-database-operator.yaml --ignore-not-found=true
Note: If the CRD instances are not deleted, and the operator is deleted by using the preceding command, then operator deployment and instance objects (pods, services, PVCs, and so on) are deleted. However, if that happens, then the CRD deletion stops responding. This is because the CRD instances have properties that prevent their deletion, and that can only be removed by the operator pod, which is deleted when the APIServices are deleted.
- Oracle Autonomous Database
- Components of Dedicated Autonomous Database
- Oracle Database Single Instance
- Oracle Database Sharding
- Oracle Database Cloud Service
See Contributing to this Repository
You can submit a GitHub issue, or you can also file an Oracle Support service request, using the product id: 14430.
Secure platforms are an important basis for general system security. Ensure that your deployment is in compliance with common security practices.
Kubernetes secrets are the usual means for storing credentials or passwords input for access. The operator reads the Secrets programmatically, which limits exposure of sensitive data. However, to protect your sensitive data, Oracle strongly recommends that you set and get sensitive data from Oracle Cloud Infrastructure Vault, or from third-party Vaults.
The following is an example of a YAML file fragment for specifying Oracle Cloud Infrastructure Vault as the repository for the admin password.
adminPassword:
ociSecretOCID: ocid1.vaultsecret.oc1...
Examples in this repository where passwords are entered on the command line are for demonstration purposes only.
See Reporting security vulnerabilities
Copyright (c) 2022 Oracle and/or its affiliates. Released under the Universal Permissive License v1.0 as shown at https://oss.oracle.com/licenses/upl/