Dustin
ffffe9d3c8
While I was preparing to deploy PostgreSQL for Firefly III, I was thinking it would be a neat idea to write an operator that uses custom resources to manage PostgreSQL roles and databases. Then I though, surely something like that must exist already. As it turns out, the [Postgres Operator][0] does exactly that, and a whole lot more. The *Postgres Operator* handles deploying PostgreSQL server instances, including primary/standby replication with load balancers. It uses custom resources to manage the databases and users (roles) in an instance, and stores role passwords in Secret resources. It supports backing up instances using `pg_basebackup` and WAL archives (i.e. physical backups) via [WAL-E][1]/[WAL-G][2]. While various backup storage targets are supported, *Postgres Operator* really only works well with the cloud storage services like S3, Azure, and Google Cloud Platform. Fortunately, S3-compatible on-premises solutions like MinIO are just fine. I think for my use cases, a single PostgreSQL cluster with multiple databases will be sufficient. I know *Firefly III* will need a PostgreSQL database, and I will likely want to migrate *Paperless-ngx* to PostgreSQL eventually too. Having a single instance will save on memory resources, at the cost of per-application point-in-time recovery. For now, just one server in the cluster is probably sufficient, but luckily adding standby servers appears to be really easy should the need arise. [0]: https://postgres-operator.readthedocs.io/en/latest/ [1]: https://github.com/wal-e/wal-e [2]: https://github.com/wal-g/wal-g |
||
|---|---|---|
| authelia | ||
| autoscaler | ||
| cert-manager | ||
| docker-distribution | ||
| dynk8s-provisioner | ||
| hudctrl | ||
| ingress | ||
| jenkins | ||
| kitchen | ||
| metrics | ||
| ntfy | ||
| paperless-ngx | ||
| phpipam | ||
| postgresql | ||
| prometheus_speedtest | ||
| scanservjs | ||
| setup | ||
| storage | ||
| README.md | ||
README.md
Dustin's Kubernetes Cluster
This repository contains resources for deploying and managing my on-premises Kubernetes cluster
Cluster Setup
The cluster primarily consists of libvirt/QEMU+KVM virtual machines. The Control Plane nodes are VMs, as are the x86_64 worker nodes. Eventually, I would like to add Raspberry Pi or Pine64 machines as aarch64 nodes.
All machines run Fedora, using only Fedora builds of the Kubernetes components
(kubeadm, kubectl, and kubeadm).
See Cluster Setup for details.
Jenkins Agents
One of the main use cases for the Kubernetes cluster is to provide dynamic agents for Jenkins. Using the Kubernetes Plugin, Jenkins will automatically launch worker nodes as Kubernetes pods.
See Jenkins Kubernetes Integration for details.
Persistent Storage
Persistent storage for pods is provided by Longhorn. Longhorn runs within the cluster and provisions storage on worker nodes to make available to pods over iSCSI.
See Persistent Storage Using Longorn for details.