This document discusses running databases in Kubernetes. It covers Kubernetes stateful fundamentals like persistent storage and stable network identifiers. It also discusses volumes, persistent volume claims, statefulsets, and deploying databases using Helm charts. Setting up highly available databases is described as complicated, requiring additional components like pgpool and repmgr. Operators are introduced as a way to manage multi-component workloads like databases. Both benefits and challenges of running databases in Kubernetes are listed.

1. Databases in K8s world
16. CNCF - Kubernetes Slovensko Meetup
Dávid Kőszeghy, MAKERS

2. Agenda
● K8s stateful fundamentals
● Hands on: Simple setup to get up and running
● Helm with DB setup
● HA and why it gets complicated really fast
● Operators - CRD for the workloads
● Hands on: PostgreSQL as first class citizen
● Why to run DBs at K8s in the first place

3. Fundamentals

4. K8s stateful fundamentals
● Stateful applications usually need one or more from:
○ Stable, persistent storage so they can save the state and reload after downtime
○ Stable, persistent identifiers on network so they can be resolved for connections (i.e DNS)
○ Ordered, graceful deployment and scaling, i.e master <> slave relations can be established, replicas,
voted
○ Ordered rolling updates - once triggered you need to follow-up on all instances to finish
For this, Kubernetes has a specific Workload API resource: Statefulsets

5. Volumes in K8s - intro
● Uncommitted files to a container layer are in the essence ephemeral, any kill and
start of new container will wipe them
● Docker popularized the concept of volumes - bind mount a hostPath or use named
volume created before
● K8s provides a lot of volume types with specific types, for starters you should know
about
○ PersistentVolumeClaims & their lifecycle
○ EmptyDir, HostPath
○ ConfigMap, Secret

6. Persistent Volumes & Lifecycle
Persistent
Volume
Block
Storage
K8s API
ICT
● Azure/AWS/GCP
Disk
● Ceph/GlusterFS
● hostPath
● Local
● NFS
● CSI
...
Container
Pod
ContainerSpec
VolumeMount v1 core
Persistent
Volume
Claim
PodSpec
Volume v1 core
PersistentVolumeClaimSpec v1 core
LabelSelector

7. Statefulset Workload API
● Naming convention which leads to expectable DNS names via headless service
● VolumeClaimTemplate definition inside Statefulset results in PV creation per Pod
(scaling creates more PVs for Pods)
● Simple rules for Deployment and Scaling (configurable)
pod-0
pod-1
pod-2
StatefulSet
pvc-pod-0
pvc-pod-1
pvc-pod-2
pv-pod-0
pv-pod-1
pv-pod-2
headless-svc

8. Simple setup to get up and running
A wrong approach
● Deployment
(Stateless)
● PVC
● PV
● Service (JDBC
expose)
A slightly better solution
● StatefulSet
● PVC
● PV
● Service (JDBC
expose)
● Headless Service
A simple stateful workload
● StatefulSet
● PVC
● StorageClass
● Service (JDBC expose)
● Headless Service

9. Advanced Topics

10. Deployment with Helm Chart
● Direct DB workload deployment to the K8s can be considered just test (not even
PoC)
● Relation DBs and usual NoSQL databases were not designed with K8s/containers in
mind
● A lot of configs/envs/secrets - separate files, even maybe some binary commands
● To manually address this is not a time spent wisely
● One approach would be to use Helm Charts that are maintained as open-source
charts
○ For example from Bitnami: https://github.com/bitnami/charts/tree/master/bitnami

11. HA DBs and why it gets complicated really fast
● As advanced topics, I’ll showcase it on PostgreSQL as one of the most popular
relation DBs out there
● Disclaimer: HA has become almost buzz word nowadays, but the CAP theorem is
real, and with DBs and cluster of nodes it becomes a distributed data store
● Usually applications are not prepared to handle HA, when problems with a
network occur, and they presume ACID is present as a baseline..
● Bottom line, to save the pain, be sure that you really, really need the HA.

12. HA DBs and why it gets complicated really fast
● Deploy statefulset of PostgreSQL nodes
● Use pg-pool II to LB the connections and have a fail-over setup from pgpool
● Use repmgr to replicate the state and the ability to ensure standby-node will
assume the primary role in case of a problem
As you can see above, the case of statefulset deployment got complicated by adding
more domain specific parts. These parts are different for each technology and as such
that’s why it’s important to have DBA (preferably with cloud & k8s knowledge).

13. Operators - CRD for the workloads
● Ensuring in multiple component deployments for workloads (such as HA DBs) that
everything is configured properly and you are able to react to system events is one
of the main aspects that the operators were created for
● More on the topic of operators is in Attila’s presentation from the 5th Kubernetes
Slovensko Meetup
● I’ll showcase a Operator setup for PostgreSQL

14. Why to run DBs at K8s in the first place
Benefits:
● Cloud Ecosystem usable on DB workloads
● Portability across environments
● Services are isolated for better security
● Easy replication of the setup for yet another
application that requires DB
● Upgrade of the DBs via operator is
semi-managed
● More streamlined ConOps after learning curve
results in less Ops time
Problems:
● Running DBs reliably is already a task of it self,
combining it with K8s creates a complex task
with new case of problems that you need to be
prepared for
● Kelsey Hightower told you not to but it was in
2016
● Distributed systems are hard

15. Why to run DBs at K8s in the first place
● It boils down to Ops budget, required functionality & number of nodes
To run or not to run a database on Kubernetes: What to consider

16. Dávid Kőszeghy
david.koszeghy@makers.sk
+421 901 744 988