New to KubeDB? Please start here.

PostgresOpsRequest

What is PostgresOpsRequest

PostgresOpsRequest is a Kubernetes Custom Resource Definitions (CRD). It provides declarative configuration for Postgres administrative operations like database version updating, horizontal scaling, vertical scaling, etc. in a Kubernetes native way.

PostgresOpsRequest CRD Specifications

Like any official Kubernetes resource, a PostgresOpsRequest has TypeMeta, ObjectMeta, Spec and Status sections.

Here, some sample PostgresOpsRequest CRs for different administrative operations is given below,

Sample PostgresOpsRequest for updating database:

apiVersion: ops.kubedb.com/v1alpha1
kind: PostgresOpsRequest
metadata:
  name: pg-ops-update
  namespace: demo
spec:
  databaseRef:
    name: pg-group
  type: UpdateVersion
  updateVersion:
    targetVersion: 8.0.35
status:
  conditions:
  - lastTransitionTime: "2020-06-11T09:59:05Z"
    message: The controller has scaled/updated the Postgres successfully
    observedGeneration: 3
    reason: OpsRequestSuccessful
    status: "True"
    type: Successful
  observedGeneration: 3
  phase: Successful

Sample PostgresOpsRequest for horizontal scaling:

apiVersion: ops.kubedb.com/v1alpha1
kind: PostgresOpsRequest
metadata:
  name: myops
  namespace: demo
spec:
  databaseRef:
    name: pg-group
  type: HorizontalScaling  
  horizontalScaling:
    replicas: 3
status:
  conditions:
  - lastTransitionTime: "2020-06-11T09:59:05Z"
    message: The controller has scaled/updated the Postgres successfully
    observedGeneration: 3
    reason: OpsRequestSuccessful
    status: "True"
    type: Successful
  observedGeneration: 3
  phase: Successful

Sample PostgresOpsRequest for vertical scaling:

apiVersion: ops.kubedb.com/v1alpha1
kind: PostgresOpsRequest
metadata:
  name: myops
  namespace: demo
spec:
  databaseRef:
    name: pg-group
  type: VerticalScaling  
  verticalScaling:
    postgres:
      resources:
        requests:
          memory: "1200Mi"
          cpu: "0.7"
        limits:
          memory: "1200Mi"
          cpu: "0.7"
status:
  conditions:
  - lastTransitionTime: "2020-06-11T09:59:05Z"
    message: The controller has scaled/updated the Postgres successfully
    observedGeneration: 3
    reason: OpsRequestSuccessful
    status: "True"
    type: Successful
  observedGeneration: 3
  phase: Successful

Here, we are going to describe the various sections of a PostgresOpsRequest cr.

PostgresOpsRequest Spec

A PostgresOpsRequest object has the following fields in the spec section.

spec.databaseRef

spec.databaseRef is a required field that point to the Postgres object where the administrative operations will be applied. This field consists of the following sub-field:

• spec.databaseRef.name : specifies the name of the Postgres object.

spec.type

spec.type specifies the kind of operation that will be applied to the database. Currently, the following types of operations are allowed in PostgresOpsRequest.

• Upgrade / UpdateVersion
• HorizontalScaling
• VerticalScaling
• volumeExpansion
• Restart
• Reconfigure
• ReconfigureTLS

You can perform only one type of operation on a single PostgresOpsRequest CR. For example, if you want to update your database and scale up its replica then you have to create two separate PostgresOpsRequest. At first, you have to create a PostgresOpsRequest for updating. Once it is completed, then you can create another PostgresOpsRequest for scaling. You should not create two PostgresOpsRequest simultaneously.

spec.updateVersion

If you want to update your Postgres version, you have to specify the spec.updateVersion section that specifies the desired version information. This field consists of the following sub-field:

• spec.updateVersion.targetVersion refers to a PostgresVersion CR that contains the Postgres version information where you want to update.

You can only update between Postgres versions. KubeDB does not support downgrade for Postgres.

spec.horizontalScaling

If you want to scale-up or scale-down your Postgres cluster, you have to specify spec.horizontalScaling section. This field consists of the following sub-field:

• spec.horizontalScaling.member indicates the desired number of members for your Postgres cluster after scaling. For example, if your cluster currently has 4 members and you want to add additional 2 members then you have to specify 6 in spec.horizontalScaling.member field. Similarly, if you want to remove one member from the cluster, you have to specify 3 in spec.horizontalScaling.member field.

spec.verticalScaling

spec.verticalScaling is a required field specifying the information of Postgres resources like cpu, memory etc that will be scaled. This field consists of the following sub-fields:

• spec.verticalScaling.postgres indicates the Postgres server resources. It has the below structure:

requests:
  memory: "200Mi"
  cpu: "0.1"
limits:
  memory: "300Mi"
  cpu: "0.2"

Here, when you specify the resource request for Postgres container, the scheduler uses this information to decide which node to place the container of the Pod on and when you specify a resource limit for Postgres container, the kubelet enforces those limits so that the running container is not allowed to use more of that resource than the limit you set. you can found more details from here

• spec.verticalScaling.exporter indicates the exporter container resources. It has the same structure as spec.verticalScaling.postgres and you can scale the resource the same way as postgres container.

You can increase/decrease resources for both postgres container and exporter container on a single PostgresOpsRequest CR.

spec.timeout

Timeout for each step of the ops request in second. If a step doesn’t finish within the specified timeout, the ops request will result in failure.

spec.apply

Apply is to control the execution of OpsRequest depending on the database state.

PostgresOpsRequest Status

.status describes the current state and progress of the PostgresOpsRequest operation. It has the following fields:

status.phase

status.phase indicates the overall phase of the operation for this PostgresOpsRequest. It can have the following three values:

status.observedGeneration

status.observedGeneration shows the most recent generation observed by the PostgresOpsRequest controller.

status.conditions

status.conditions is an array that specifies the conditions of different steps of PostgresOpsRequest processing. Each condition entry has the following fields:

• types specifies the type of the condition. PostgresOpsRequest has the following types of conditions:

• The status field is a string, with possible values "True", "False", and "Unknown".
  • status will be "True" if the current transition is succeeded.
  • status will be "False" if the current transition is failed.
  • status will be "Unknown" if the current transition is denied.
• The message field is a human-readable message indicating details about the condition.
• The reason field is a unique, one-word, CamelCase reason for the condition’s last transition. It has the following possible values:

• The lastTransitionTime field provides a timestamp for when the operation last transitioned from one state to another.
• The observedGeneration shows the most recent condition transition generation observed by the controller.