Zigbee2MQTT commits the cardinal sin of storing state in its configuration file. This means the file has to be writable and thus stored in persistent storage rather than in a ConfigMap. As a consequence, making changes to the configuration when the application is not running is rather difficult. Case in point: when I added the internal alias for _mqtt.pyrocufflink.blue_ pointing to the in-cluster service, Zigbee2MQTT became unable to connect to the broker because it was using the node port instead of the internal port. Since it could not connect to the broker, it refused to start, and thus the container would not stay running long enough to fix the configuration to point to the correct port. Fortunately, Zigbee2MQTT also allows configuring settings via environment variables, which can be managed with a ConfigMap. Luckily, the values read from environment variables override those from the configuration file, so pointing to the correct broker port with the environment variable was sufficient to allow the application to start. |
||
---|---|---|
argocd | ||
authelia | ||
autoscaler | ||
cert-manager | ||
collectd | ||
dch-root-ca | ||
dch-webhooks | ||
device-plugins | ||
docker-distribution | ||
dynk8s-provisioner | ||
firefly-iii | ||
fleetlock | ||
grafana | ||
home-assistant | ||
hudctrl | ||
ingress | ||
invoice-ninja | ||
jenkins | ||
keyserv | ||
kitchen | ||
loki-ca | ||
metrics | ||
ntfy | ||
paperless-ngx | ||
photoframesvc | ||
phpipam | ||
postgresql | ||
prometheus_speedtest | ||
promtail | ||
rabbitmq | ||
rent-reminder | ||
restic-exporter | ||
scanservjs | ||
sealed-secrets | ||
setup | ||
sshca | ||
step-ca | ||
storage | ||
victoria-metrics | ||
websites | ||
xactfetch | ||
xactmon | ||
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.