Cloud Native PostgreSQL

… and where do you plan to be in the future?
Where are you now in your
Cloud Native journey with
Kubernetes?

How do you “feel” about using
Kubernetes for both stateless
applications and database
workloads with PostgreSQL?

Cloud Native
PostgreSQL
Gabriele Bartolini
Webinar
3 March 2021
Version 1.1.0

© Copyright EnterpriseDB Corporation, 2021. All rights reserved.
4
Introducing Gabriele Bartolini
• Based in Prato (Tuscany, Italy)
• PostgreSQL user since ~2000
• Community member since 2006
• Co-founder of PostgreSQL Europe
• 2ndQuadrant, from 2008 to 2020
• Co-founder
• Head of Global Support
• Cloud Native Initiative Lead
• Founding member of Barman
• Now with EDB

Kubernetes Patterns, Ibryam and Huß, O’Reilly
(about Cloud Native)
“Principles, Patterns, Tools to automate
containerized microservices at scale”

6
Agenda page
• General information
• Architectures
• Operator capabilities
• Configuration
• Storage for Postgres workloads in Kubernetes
• Conclusions

8
The largest dedicated PostgreSQL company
• More customers: Than any dedicated PostgreSQL company
• More experts: Leading PostgreSQL contributors
• More innovation: Positioned to lead in enterprise PostgreSQL
and hybrid cloud
EDB acquires 2ndQuadrant in Sept 2020
+

9
EDB and Kubernetes
• Kubernetes Certified Service Provider (KCSP)
• First PostgreSQL Company to reach this status
• Silver Member of CNCF & Linux Foundation
• Red Hat Certified Kubernetes Operators
• Cloud Native PostgreSQL (aka PostgreSQL Operator)
• Cloud Native BDR (aka BDR Operator)

10
Cloud Native Postgres and BDR
EDB products in Cloud Native
• Operators for Kubernetes
• Written in Go language, like Kubernetes
• Designed for Kubernetes
• Fully integrated with Kubernetes API server
• No requirements for tools designed for traditional contexts
• Repmgr, Patroni, Stolon, Failover Manager
• Immutable application containers for:
• PostgreSQL 10+ or EDB Postgres Advanced 10+
• BDR (3.6 on EDB Postgres Extended in Q1/2021)

11
What’s a Kubernetes operator?
• A Kubernetes operator automates actions of a human being, in a programmatic way
• A PostgreSQL cluster is a complex application
• Deployment and configuration
• Failure detection and Failover
• Updates and switchovers
• Backup and Recovery
• Relies on Kubernetes’ native components and capabilities:
• Self-healing, high availability, scalability, resource control, access, …
• Declarative and fully automated
Extends Kubernetes controller and defines how a complex application works

12
Imperative vs Declarative
Imperative Declarative
• Create a PostgreSQL 13 instance
• Configure for replication
• Clone a second one
• Set it as a replica
• Clone a third one
• Set it as a replica
There’s a PostgreSQL 13 cluster with 2
replicas
(At any time)

13
States in Kubernetes
• Definition of the desired state of an object and the overall infrastructure as configuration
• Reconciliation loops:
• Current state of the infrastructure matches the desired one
• If not, the operator reacts to restore the desired state
• Foundation of self-healing
The role of the Kubernetes controller

14
Desired state Actual state
RW RW

15
Cloud Native PostgreSQL is aka CNP
Cloud Native PostgreSQL in a nutshell
• Operator for Kubernetes
• Written in Go Language, like
Kubernetes
• Implements Primary/Standby
architecture
• Works with both:
• PostgreSQL 10+
• EDB Postgres Advanced 10+
• Container images are hosted on Quay.io
• Generally Available (BIS EAR)
• EDB Limited Use License
• Documentation
• docs.enterprisedb.io

16
Container images
All Container images are based on RedHat UBI 8
• Operator Container image
• Operand Container images (Postgres Application)
• PostgreSQL:
• The Postgres License (PostgreSQL)
• GNU GPL 3 (Barman Cloud)
• EDB Postgres Advanced Server:

17
Target Cloud environments
• Private Cloud (self-managed):
• Kubernetes 1.16+
• OpenShift 4.5+
• Public Cloud (provider-managed):
• Microsoft Azure (AKS) - 2021/Q1
• Amazon Web Services (EKS) - 2021/Q2
• Google Cloud (GKS) - 2021/Q2
• Hybrid Cloud and Multicloud
Run Postgres wherever Kubernetes runs

18
Designed for Kubernetes
• Fully integrated with Kubernetes API server
• No external tool required
• Repmgr, Patroni, Stolon
• Immutable Application Containers
• Running PostgreSQL only
• Very light
• Declarative configuration
• Relies on “kubectl” - official Kubernetes client command line tool
• YAML manifest
• Infrastructure as Code (IaC)

20
System architectures
Main classification is based on where the application reside
Use case 1: Application and Database in K8s Use case 2: Application outside K8s

21
Application and Database in K8s
• Stateless application as a deployment
• Rolling upgrades
• ReplicaSet for scaling and HA
• Custom application images (Go,
Django, Java, Python, C, C++, …)
• Stateful database using our operator
• Embeds primary/standby logic
• Service for RW and Read operations
• Rolling upgrades, scaling, HA, …
• “Cluster” CRD

22
PostgreSQL cluster architecture
• One PostgreSQL primary
• Zero or more hot standby servers
• PostgreSQL native streaming replication
• Async (default) and Sync (quorum-based)
• Required for HA
• Transparent support for pg_rewind
• Provides apps with two K8s Services:
• -rw suffix (read-write workloads)
• -r suffix (read-only workloads)
• -ro suffix (read-only workloads - in 1.1.0)

23
Read-write workloads (“-rw” service)
Kubernetes service for the PostgreSQL Primary
App App App
PostgreSQL
Primary
PostgreSQL
Standby
PostgreSQL
Standby

24
Read workloads (“-r” service)
Kubernetes service for the PostgreSQL Read-Only operations
App App App
PostgreSQL
Primary
PostgreSQL
Standby
PostgreSQL
Standby
Round Robin

26
The “Operator Capability Levels” Framework
Defined by Operator SDK (RedHat) - source sdk.operatorframework.io/docs/
CNP users can currently expect "Level III - Full Lifecycle"

27
Cluster management
• Self-healing capabilities
• Probes for liveness and readiness
• Failover of the primary
• Automated creation of a replica
• Planned switchover of the primary
• Promotion of a selected replica
• Rolling updates
• Scale up/down capabilities

28
Storage management
• Support for Persistent Volume Claims (PVC)
• Automatic generation of PVC
• Support for PVC templates
• Reuse of storage for Pods in the same cluster
• Storage classes
• Freedom of choice
• Local storage
• Network storage

29
Rolling updates
• Update of a deployment with zero downtime
• Incremental update of Pod instances with new ones
• Standby servers are updated first
• Then the primary, following a switchover
• supervised / unsupervised
• When they are triggered:
• Update of the operator
• Minor update of PostgreSQL
• Configuration changes when restart is required
• Reason why we did not use replicasets or statefulsets

30
Security
• 4C security model
• Cloud, Cluster, Container, Code
• Pod Security Policies and Security Contexts
• No privileged (root) mode required for containers
• No privileged (root) mode for volume access
• TLS encrypted connections
• Creation of PostgreSQL secrets
• Static code analysis
• Linters and Coverity Scan

31
About TLS (ex-SSL) support
• Native and fully automated
• Certification authority for the Operator
• Certification authority for each Postgres cluster
• TLS connections enabled by default
• Client authentication based on TLS certificates
• “kubectl cnp” plugin to issue client certificates
• Out of the box for standby streaming replication

32
Continuous physical backup
• Scheduled and on-demand
• Initial support for object stores (S3 compatible)
• Public clouds
• Private clouds (e.g. MinIO)
• Rely on Barman Cloud technology
• barman-cloud-wal-archive
• barman-cloud-backup

33
Recovery
• Create a new cluster from a backup
• Restore the base backup
• Full or PITR
• Pull and replay backup WAL files
• Rely on Barman Cloud technology
• barman-cloud-restore
• barman-cloud-wal-restore

35
Custom Resource Definition (CRD)
• “Cluster” resource
• Extends the Kubernetes controller
• Responsible for the deployment
• “instances” parameter
• number of PostgreSQL instances in the cluster
• hot standby replicas = instances - 1
• Supports Async and Sync replication for RPO=0

36
Convention over configuration
apiVersion: postgresql.k8s.enterprisedb.io/v1
kind: Cluster
metadata:
name: myapp-db
spec:
instances: 3
imageName: quay.io/enterprisedb/postgresql:13.2
storage:
size: 10Gi

37
Declarative deployment
# Install the operator in the cluster
kubectl apply -f <OPERATOR_MANIFEST_URL>
# Deploy the cluster (declarative)
kubectl apply -f myapp-cluster.yaml

38
PostgreSQL configuration
Refer to “PostgreSQL configuration” for details
kind: Cluster
metadata:
name: cluster-example
spec:
instances: 3
postgresql:
parameters:
work_mem: "8MB"
# …
# ...

39
Synchronous replication
kind: Cluster
metadata:
name: cluster-example
spec:
instances: 3
minSyncReplicas: 1
maxSyncReplicas: 2
storage:
size: 1Gi
Refer to “Streaming replication overview” for details

40
Plugin for kubectl
kubectl cnp status cluster-example
Cluster in healthy state
Name: cluster-example
Namespace: default
PostgreSQL Image: quay.io/enterprisedb/postgresql:13
Primary instance: cluster-example-1
Instances: 3
Ready instances: 3
Instances status
Pod name Current LSN Received LSN Replay LSN System ID Primary Replicating Replay paused Pending restart
-------- ----------- ------------ ---------- --------- ------- ----------- ------------- ---------------
cluster-example-1 0/6000060 6927251808674721812 ✓ ✗ ✗ ✗
cluster-example-2 0/6000060 0/6000060 6927251808674721812 ✗ ✓ ✗ ✗
cluster-example-3 0/6000060 0/6000060 6927251808674721812 ✗ ✓ ✗ ✗
Refer to “Streaming replication overview” for details

Storage for Postgres
workloads in
Kubernetes

42
Required capabilities
Expected capabilities:
• Availability
• Scalability
• Performance
• Consistency
• Durability
Storage is critical in database contexts

43
Storage architectures in Kubernetes (simplified)
Network storage Local storage
• Access via network
• The K8s pattern
• Storage location options:
• Outside K8s (e.g. NFS)
• Inside K8s (e.g. Portworx)
• Data replication options:
• File level (K8s way)
• Application level (Postgres way)
• Cons: throughput and latency
• Direct access to the OS storage
• Local to the K8s node of the Pod
• What database people want
• The K8s anti-pattern
• Shared nothing architecture
• K8s is changing:
• “local” persistent volumes (1.14+)
• OpenEBS Local PV, topoLVM, …
• Cons: scalability

44
Storage outside K8s with Postgres replication
Not recommended for
Cloud Native Postgres
Common setup

45
Local storage with Postgres replication
Recommended for
Cloud Native Postgres

46
Shared-nothing architecture
What database people want
• Rely on dedicated storage of the K8s node
• On-board disks, dedicated DAS or NAS
• High-Performing Network is the only share
• Better resilience of a PostgreSQL cluster
• Postgres instances spread over multiple K8s nodes
• Also in different availability zones of the same region
• Pod uses local storage from the K8s nodes it runs on
• Consider latency with applications

47
Local storage benchmarks
Our team pioneered local storage use case in K8s
• Public benchmarks, released in May 2020
• Goal: publish an updated version as EDB
• Bare metal
• bonnie++ from OS on directly attached storage
• Kubernetes
• Local storage: OpenEBS Local PV using hostpath
• Network storage: OpenEBS cStor via iSCSI

48
Local storage benchmarks scenario
• Kubernetes 1.18 cluster:
• Dedicated rackspace
• 3 Kubernetes master nodes
• 4 Kubernetes worker nodes:
• 16 cores - 128GB of RAM
• OS volume: 2x 240 GB SSD, HW RAID 1 (BBU cache)
• App data volume: 2x 3.84 TB SSD, HW RAID 1 (BBU cache)
• High performing dedicated private network
• Dual 10Gb/s NICs in bonding

49
Storage Benchmarks Results
Workload Disks (manufacturer spec) Bare metal OpenEBS Local
(Persistent)
OpenEBS cStor (Pool)
Sequential
reads
Up to 550MB/s 1000MB/s 964MB/s
(-3.6%)
54MB/s
(-96.4%)
Sequential
writes
Up to 530MB/s 500MB/s 496MB/s
(-0.8%)
54MB/s
(-89.2%)

50
PostgreSQL benchmarks
• Cloud Native PostgreSQL
• Using pgbench
• OLTP like benchmarks results:
• 4.2k tps on bare metal
• 3.8k tps on K8s with OpenEBS Local PV (-10%)
• See the diagram on the right
• 500 tps on K8s with OpenEBS cStor
• Comparable to typical scenarios

51
A new frontier
• Performance on local storage close to bare metal
• Minimal impact of containers
• We used OpenEBS LocalPV
• Kubernetes is investing in local storage scenarios
• Get the best of the two worlds:
• Cloud Native and Kubernetes benefits
• Workloads business continuity
• High performance
• When needed by some PostgreSQL database workloads (VLDB)

53
There’s more coming …
• Observability
• Monitoring with a native
Prometheus exporter (Q1/2021)
• Logging (Fluentbit/Fluentd)
• Pooling
• pgBouncer support
• Replica cluster
• PostgreSQL online upgrades
• Major versions via logical
replication
• Backup
• Barman operator
• Snapshots
• Kubernetes Federation
• Multi-cluster Kubernetes

54
Evaluate it now!
Operator with PostgreSQL Operator with EDB Postgres Advanced
• No trial license key required
• No reconciliation attempt after 30d
• From the creation of each Postgres
cluster
• A trial license key is required
• Expiry date = 60d from license request
• No reconciliation attempt after expiry date
Start at docs.enterprisedb.io

55
Why Cloud Native PostgreSQL?
• PostgreSQL/Kubernetes
• Applications co-exist in the same system
• PostgreSQL databases are applications (workloads)
• Business Continuity
• PostgreSQL cluster is always up
• Auto pilot mode
• Complexity for HA is entirely hidden
• Services are the only interface for Applications
• Focus on applications and velocity
• Retain full control of your data

Cloud Native PostgreSQL

Related slideshows

More Related Content

Cloud Native PostgreSQL