Patroni provides automated fail-over in the event the master pod should fail. DCS (etcd) is also precisely what Kubernetes uses in the control plane to keep track of it’s own resources. What Patroni does is set up a small process that manages a PostgreSQL instance - using a distributed config store to keep track of which instance is the primary instance in a cluster of multiple nodes. Patroni is a template for high availability PostgreSQL. Let’s take a look at the software that exists, and then walk through the installation and usage for running PostgreSQL in Google Kubernetes Engine. For the developers, they gain control of their database config that they can deploy and control in the same manner as the other components. That means we can focus more or less solely on the software side of the stack. In fact, we don’t have to worry too much about availability - Kubernetes is supposed to solve that for us (even if challenges remain). With Kubernetes in the cloud, a lot of this changes. It’s easy to place a whole lot of eggs in one basket in this case. If you need to manage many clusters, this has a very noticeable effect on the time you spend keeping them in the desired state - up, available, healthy and backed up. Imagine doing that over many clusters that run even on virtual machines. Speaking of backups - you should test recovering them regularly. Additionally, a lot of effort is placed on making sure the installation is highly available, and that backups are taken to separate hardware. They are often set up as streaming replication clusters, with a primary r/w instance, and one or more replicating r/o secondaries. The typical PostgreSQL installation has been based on bare metal, or, the past few years, virtual machines. For these customers, the old-school way of running PostgreSQL is becoming a bit cumbersome: Kubernetes has changed the way they work, and is acting as an effective catalyst empowering their developers. Several Redpill Linpro customers are now in the Kubernetes way of delivery. WAL-G is a more modern and faster implementation of cloud backups for PostgreSQL) Kubebuilder is maintained by the official Kubernetes API Machinery Special Interest Group (SIG).(Update: This post has been updated to reflect changing backup tool from WAL-E to WAL-G. It was developed with the framework Kubebuilder version 3, an SDK for building Kubernetes APIs using CRDs. It is Open-Source and available on GitHub here Just install the Kubernetes controller once and deploy as many PostgreSql clusters as you need by simply deploying the official container of the PostgreSql community. It works with the official PostgreSql docker image: it does not ship nor require an additional Docker image to work. It is resilient, has over 55 automatized tests cases and has been running in production. It provides a very simple YAML with properties specialised for PostgreSql. It has a data backup option allowing to dump PostgreSql data regularly in a given volume. It manages fail-over: if a Primary PostgreSql crashes, it automatically promotes a Replica PostgreSql as a Primary. It creates a cluster of PostgreSql servers with data replication enabled: it creates a Primary PostgreSql pod and a number of Replica PostgreSql pods and replicates primary’s database in real-time to Replica pods. It brings simplicity when using PostgreSql considering how complex managing stateful-set’s life-cycle and data replication could be with Kubernetes. Kubegres is an open-source Kubernetes operator allowing to deploy a cluster of PostgreSql instances with data replication enabled out-of-the box.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |