Prerequisites

Prerequisites

The following is required prior to installing Crunchy PostgreSQL Operator using Ansible:

• postgres-operator playbooks source code for the target version
• Ansible 2.4.6+

Kubernetes Installs

• Kubernetes v1.11+
• Cluster admin privileges in Kubernetes
• kubectl configured to communicate with Kubernetes

OpenShift Installs

• OpenShift v3.09+
• Cluster admin privileges in OpenShift
• oc configured to communicate with OpenShift

Installing from a Windows Host

If the Crunchy PostgreSQL Operator is being installed from a Windows host the following are required:

• Windows Subsystem for Linux (WSL)
• Ubuntu for Windows

Permissions

The installation of the Crunchy PostgreSQL Operator requires elevated privileges.
It is required that the playbooks are run as a cluster-admin to ensure the playbooks can install:

• Custom Resource Definitions
• Cluster RBAC
• Create required namespaces

Obtaining Operator Ansible Role

The Crunchy PostgreSQL Operator Roles are available here:

• Clone the postgres-operator project

GitHub Installation

All necessary files (inventory, main playbook and roles) can be found in the ansible directory in the postgres-operator project.

Configuring the Inventory File

The inventory file included with the PostgreSQL Operator Playbooks allows installers to configure how the operator will function when deployed into Kubernetes. This file should contain all configurable variables the playbooks offer.

The following are the variables available for configuration:

Minimal Variable Requirements

The following variables should be configured at a minimum to deploy the Crunchy PostgreSQL Operator:

• backrest_storage
• ccp_image_prefix
• ccp_image_tag
• kubernetes_context
• namespace
• openshift_host
• openshift_password
• openshift_skip_tls_verify
• openshift_token
• openshift_user
• pgo_admin_username
• pgo_admin_password
• pgo_client_install
• pgo_image_prefix
• pgo_image_tag
• pgo_operator_namespace
• pgo_tls_no_verify
• primary_storage
• replica_storage
• storage<ID>_access_mode
• storage<ID>_class
• storage<ID>_fs_group
• storage<ID>_size
• storage<ID>_supplemental_groups
• storage<ID>_type

Storage

Kubernetes and OpenShift offer support for a variety of storage types. The Crunchy PostgreSQL Operator must be configured to utilize the storage options available by configuring the storage options included in the inventory file.

Considerations for Multi-Zone Cloud Environments

When using the Operator in a Kubernetes cluster consisting of nodes that span multiple zones, special consideration must betaken to ensure all pods and the volumes they require are scheduled and provisioned within the same zone. Specifically, being that a pod is unable mount a volume that is located in another zone, any volumes that are dynamically provisioned must be provisioned in a topology-aware manner according to the specific scheduling requirements for the pod. For instance, this means ensuring that the volume containing the database files for the primary database in a new PostgreSQL cluster is provisioned in the same zone as the node containing the PostgreSQL primary pod that will be using it.

For instructions on setting up storage classes for multi-zone environments, see the PostgreSQL Operator Documentation.

Examples

The following are examples on configuring the storage variables for different types of storage classes.

Generic Storage Class

To setup storage1 to use the storage class fast

storage1_access_mode='ReadWriteOnce'
storage1_size='10G'
storage1_type='dynamic'
storage1_class='fast'

To assign this storage definition to all primary pods created by the Operator, we can configure the primary_storage=storage1 variable in the inventory file.

GKE

The storage class provided by Google Kubernetes Environment (GKE) can be configured to be used by the Operator by setting the following variables in the inventory file:

storage1_access_mode='ReadWriteOnce'
storage1_size='10G'
storage1_type='dynamic'
storage1_class='standard'
storage1_fs_group=26

To assign this storage definition to all primary pods created by the Operator, we can configure the primary_storage=storage1 variable in the inventory file.

Understanding pgo_operator_namespace & namespace

The Crunchy PostgreSQL Operator can be configured to be deployed and manage a single namespace or manage several namespaces. The following are examples of different types of deployment models configurable in the inventory file.

Single Namespace

To deploy the Crunchy PostgreSQL Operator to work with a single namespace (in this example our namespace is named pgo), configure the following inventory settings:

pgo_operator_namespace='pgo'
namespace='pgo'

Multiple Namespaces

To deploy the Crunchy PostgreSQL Operator to work with multiple namespaces (in this example our namespaces are named pgo, pgouser1 and pgouser2), configure the following inventory settings:

pgo_operator_namespace='pgo'
namespace='pgouser1,pgouser2'

Deploying Multiple Operators

The 4.0 release of the Crunchy PostgreSQL Operator allows for multiple operator deployments in the same cluster.
To install the Crunchy PostgreSQL Operator to multiple namespaces, it’s recommended to have an inventory file for each deployment of the operator.

For each operator deployment the following inventory variables should be configured uniquely for each install.

For example, operator could be deployed twice by changing the pgo_operator_namespace and namespace for those deployments:

Inventory A would deploy operator to the pgo namespace and it would manage the pgo target namespace.

# Inventory A
pgo_operator_namespace='pgo'
namespace='pgo'
...

Inventory B would deploy operator to the pgo2 namespace and it would manage the pgo2 and pgo3 target namespaces.

# Inventory B
pgo_operator_namespace='pgo2'
namespace='pgo2,pgo3'
...

Each install of the operator will create a corresponding directory in $HOME/.pgo/<PGO NAMESPACE> which will contain the TLS and pgouser client credentials.

Deploying Grafana and Prometheus

PostgreSQL clusters created by the operator can be configured to create additional containers for collecting metrics.
These metrics are very useful for understanding the overall health and performance of PostgreSQL database deployments over time. The collectors included by the operator are:

• Node Exporter - Host metrics where the PostgreSQL containers are running
• PostgreSQL Exporter - PostgreSQL metrics

The operator, however, does not install the necessary timeseries database (Prometheus) for storing the collected metrics or the front end visualization (Grafana) of those metrics.

Included in these playbooks are roles for deploying Granfana and/or Prometheus. See the inventory file for options to install the metrics stack.