Running Postgres in Kubernetes [pdf]

📰 Hacker News · craigkerstiens

Learn to run Postgres-as-a-Service in Kubernetes for consistency, portability, and low latency

intermediate Published 29 Jun 2020
Action Steps
  1. Deploy Postgres in Kubernetes using the Zalando Postgres Operator or Crunchy Data PostgreSQL Operator
  2. Configure high availability and scaling capabilities for Postgres in Kubernetes
  3. Use Persistent Volume Claims (PVCs) for database storage and consider table spaces for different storage types
  4. Implement automated failover within a K8S cluster for high availability
  5. Monitor Postgres performance and adjust resources as needed using K8S integration
Who Needs to Know This

DevOps and database teams can benefit from running Postgres in Kubernetes for streamlined management and high availability

Key Insight

💡 Running Postgres in Kubernetes can provide consistency, portability, and low latency, but requires careful configuration and management

Share This
🚀 Run Postgres-as-a-Service in Kubernetes for consistency, portability, and low latency! 🚀

Key Takeaways

Learn to run Postgres-as-a-Service in Kubernetes for consistency, portability, and low latency

Full Article

Title: Running Postgres-as-a-Service in Kubernetes

URL Source: https://static.sched.com/hosted_files/ossna2020/fc/Running%20Postgres-as-a-Service%20in%20Kubernetes.pdf

Published Time: Fri, 19 Jun 2020 20:21:03 GMT

Number of Pages: 44

Markdown Content:
> @LukasFittl

## Running Postgres-as-a-Service

## In Kubernetes @LukasFittl Why (not) run Postgres in Kubernetes? Consistency - Kubernetes manages all workloads,

## including databases Better Portability - Consistent deployment experience

## across clouds, instead of relying on cloud-specific APIs Low Latency - Co-locating Compute and Database,

## allows certain workloads to perform better High Effort - Running anything in Kubernetes is

## complex, and databases are worse How to deploy Postgres in Kubernetes Postgres Postgres

High Availability

Scale Out

Capabilities

Backups

Connection

Pooling

Monitoring

K8S

Integration Zalando Postgres Operator Crunchy Data PostgreSQL Operator PostgreSQL Hyperscale - Azure Arc Postgres

High Availability

Scaling

Capabilities

Backups

Connection

Pooling

Monitoring

K8S

Integration K8S Integration

CLIs, Operators & API Servers

Namespace handling

Storage Zalando Postgres Operator

Operator Postgres postgresql CRD “pgo” CLI

Operator

API Server

Postgres

Crunchy Data PostgreSQL Operator

Zalando Postgres Operator

Operator Postgres

Pgcluster CRD

postgresql CRD

Pgpolicy CRD

Pgreplica CRD

Pgtask CRD “pgo” CLI

“azdata” CLI

Operator

API Server

Postgres

Operator

API Server

Postgres (Coordinator)

PostgreSQL Hyperscale - Azure Arc

Postgres (Data Node)

Postgres (Data Node)

Crunchy Data PostgreSQL Operator

Zalando Postgres Operator

Operator Postgres

Pgcluster CRD

postgresql CRD

Pgpolicy CRD

Pgreplica CRD

Pgtask CRD

DatabaseService CRD

DatabaseServiceTask CRD kind: DatabaseService

metadata:

...

spec:

docker:

...

engine:

type: Postgres

version: 12

monitoring:

...

scale:

shards: 2

scheduling:

default:

resources:

requests:

memory: 256Mi

service:

port: 5432

type: NodePort

storage:

volumeSize: 1Gi

kind: postgresql

metadata:

...

spec:

databases:

foo: zalando

numberOfInstances: 2

postgresql:

version: "12"

preparedDatabases:

bar: {}

teamId: acid

users:

foo_user: []

zalando:

- superuser

- createdb

volume:

size: 1Gi

kind: Pgcluster

metadata:

...

spec:

ArchiveStorage:

...

BackrestStorage:

...

PrimaryStorage:

...

ReplicaStorage:

...

WALStorage:

...

...

clustername: hippo

database: hippo

exporterport: "9187"

limits: {}

name: hippo

namespace: pgo

podAntiAffinity:

default: preferred

port: "5432"

primaryhost: hippo

replicas: "0"

resources:

memory: 128Mi

rootsecretname: hippo-postgres-secret

syncReplication: null

tablespaceMounts: {}

tlsOnly: false

Zalando Postgres Operator Crunchy Data PostgreSQL Operator PostgreSQL Hyperscale - Azure Arc Namespace handling

Crunchy Data’ Postgres Operator Namespace Modes :

dynamic :

Operator can create, delete, update any namespaces and manage RBAC.

Operator requires ClusterRole privilege.

readonly :

Namespaces need to be pre-created and RBAC pre-configured.

Operator requires ClusterRole privilege.

disabled :

Deploy to single namespace, no ClusterRole privilege required. Storage

Generally, expect Persistent Volume Claims (PVCs) to be utilized for the database

storage.

Crunchy Data PostgreSQL Operator also supports table spaces, to utilize different

storage types within the same database server (be careful when using it)

> Postgres Persistent Volume Persistent Volume Claim Network Storage

Postgres

High Availability

Scaling

Capabilities

Backups

Connection

Pooling

Monitoring

K8S

Integration Scenario 1: Automated Failover within a K8S cluster

K8S Cluster 1

PG1

Primary

PG2

Secondary

Sync Rep

Operator Scenario 1: Automated Failover wit
Read full article → ← Back to Reads