Dustin
d08cc6fb0f
I never ended up using _Step CA_ for anything, since I was initially focused on the SSH CA feature and I was unhappy with how it worked (which led me to write _SSHCA_). I didn't think about it much until I was working on deploying Grafana Loki. For that project, I wanted to use a certificate signed by a private CA instead of the wildcard certificate for _pyrocufflink.blue_. So, I created *DCH CA R3* for that purpose. Then, for some reason, I used the exact same procedure to fetch the certificate from Kubernetes as I had set up for the _pyrocufflink.blue_ wildcard certificate, as used by Frigate. This of course defeated the purpose, since I could have just as easily used the wildcard certificate in that case. When I discovered that Grafana Loki expects to be deployed behind a reverse proxy in order to implement access control, I took the opportunity to reevaluate the certificate issuance process. Since a reverse proxy is required to implement the access control I want (anyone can push logs but only authenticated users can query them), it made sense to choose one with native support for requesting certificates via ACME. This would eliminate the need for `fetchcert` and the corresponding Kubernetes API token. Thus, I ended up deciding to redeploy _Step CA_ with the new _DCH CA R3_ for this purpose. |
||
|---|---|---|
| argocd | ||
| authelia | ||
| autoscaler | ||
| cert-manager | ||
| dch-root-ca | ||
| dch-webhooks | ||
| device-plugins | ||
| docker-distribution | ||
| dynk8s-provisioner | ||
| firefly-iii | ||
| grafana | ||
| home-assistant | ||
| hudctrl | ||
| ingress | ||
| invoice-ninja | ||
| jenkins | ||
| keyserv | ||
| kitchen | ||
| metrics | ||
| ntfy | ||
| paperless-ngx | ||
| photoframesvc | ||
| phpipam | ||
| postgresql | ||
| prometheus_speedtest | ||
| rent-reminder | ||
| scanservjs | ||
| sealed-secrets | ||
| setup | ||
| sshca | ||
| step-ca | ||
| storage | ||
| victoria-metrics | ||
| websites | ||
| xactfetch | ||
| 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.