Dustin
b07e141fa3
By default, Authelia uses a local SQLite database for persistent data (e.g. authenticator keys, TOTP secrets, etc.) and keeps session data in memory. Together, these have some undesirable side effects. First, since needing access to the filesystem to store the SQLite database means that the pod has to be managed by a StatefulSet. Restarting StatefulSet pods means stopping them all and then starting them back up, which causes downtime. Additionally, the SQLite database file needs to be backed up, which I never got around to setting up. Further, any time the service is restarted, all sessions are invalidated, so users have to sign back in. All of these issues can be resolved by configuring Authelia to store all of its state externally. The persistent data can be stored in a PostgreSQL database and the session state can be stored in Redis. Using a database managed by the existing Postgres Operator infrastructure automaticaly enables high availability and backups as well. To migrate the contents of the database, I used [pgloader]. With Authelia shut down, I ran the migration job. Authelia's database schema is pretty simple, so there were no problems with the conversion. Authelia started back up with the new database configuration without any issues. Session state are still stored only in memory of the Redis process. This is probably fine, since Redis will not need restarted often, except for updates. At least restarting Authelia to adjust its configuration will not log everyone out. [pgloader]: https://pgloader.readthedocs.io/en/latest/ref/sqlite.html |
||
|---|---|---|
| argocd | ||
| authelia | ||
| autoscaler | ||
| cert-manager | ||
| dch-root-ca | ||
| dch-webhooks | ||
| device-plugins | ||
| docker-distribution | ||
| dynk8s-provisioner | ||
| firefly-iii | ||
| home-assistant | ||
| hudctrl | ||
| ingress | ||
| jenkins | ||
| kitchen | ||
| metrics | ||
| ntfy | ||
| paperless-ngx | ||
| photoframesvc | ||
| phpipam | ||
| postgresql | ||
| prometheus_speedtest | ||
| scanservjs | ||
| sealed-secrets | ||
| setup | ||
| step-ca | ||
| 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.