Since transitioning to externalIPs for TCP services, it is no longer possible to use the HTTP.01 ACME challenge to issue certificates for services hosted in the cluster, because the ingress controller does not listen on those addresses. Thus, we have to switch to using the DNS.01 challenge. I had avoided using it before because of the complexity of managing dynamic DNS records with the Samba AD server, but this was actually pretty to work around. I created a new DNS zone on the firewall specifically for ACME challenges. Names in the AD-managed zone have CNAME records for their corresponding *_acme-challenge* labels pointing to this new zone. The new zone has dynamic updates enabled, which _cert-manager_ supports using the RFC2136 plugin. For now, this is only enabled for _rabbitmq.pyrocufflink.blue_. I will transition the other names soon. |
||
---|---|---|
20125 | ||
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 | ||
keepalived | ||
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 | ||
updatebot | ||
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.