19. Cloud Native Computing - Kubernetes - Bratislava - Databases in K8s world
- 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
- 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 [email protected] +421 901 744 988