Kubernetes Homelab built on Talos Linux, managed with GitOps using Flux and Renovate.

This repo is the source for my GitOps deployments as well as my personal knowledge bank with notes for my homelab. I decided to make it public in case someone finds it useful or interesting.

Currently most of the content is regarding my Kubernetes cluster and the applications I run on it. I'm looking to expand it with more general homelab stuff as well as time goes on.

The core of my homelab is a single server but it's sufficiently beefy to run everything I need. Specs:

• Motherboard: Gigabyte MC12-LE0. Cheap server motherboard with IPMI that uses regular Ryzen CPUs.
• CPU: AMD Ryzen 3700X.
• RAM: 64GB of ECC memory.
• Boot Storage/Proxmox storage: ZFS mirror with 2x500GB NVMe drives.
• Data Storage: 2x2TB Samsung 990 NVMe.

Since I have just the one server I virtualize everything from my router and other infrastructure applications to Kubernetes.

• Proxmox VE(BM): Debian and KVM based hypervisor. Everything runs on top of this.
• OPNsense(VM): FreeBSD based firewall and router. No, virtualizing your router/firewall isn't optimal but it's a calculated risk.
• UniFi Network Server(LXC): Used to manage my UniFi devices.
• AdGuard Home(LXC): Network-wide ad blocking, integrated with external-dns in Kubernetes.
• Home Assistant(VM): Home automation engine.
• Omni(LXC): Management tool for Talos Linux
• Talos Linux Kubernetes Cluster(VMs): A three-node Talos Linux kubernetes cluster.

I work with Kubernetes for a living so while some stuff might be overkill it helps me stay somewhat up to date with the tech which is essentially the goal of the homelab.

Here is an overview of the services I run, some of them have more detailed explanations and configuration notes in their respective folder in the kubernetes/apps folder.

(i.e stuff that enables me to deploy and manage other stuff)

• 1Password Connect & 1Password Operator: Secret management. Sync secrets from 1Password to Kubernetes.
• Flux: Facilitates GitOps. Automating the deployment of applications based on manifests in this git repo.
• cert-manager: Automatically provisions and renews certificates.
• Piraeus: Operator for running LINSTOR cluster in Kubernetes.
• ExternalDNS: Integrated with AdGuard Home and automatically configures DNS records from Kubernetes.
• Github ARC: Github Actions Runner Controller. Runs Github Actions runners in the cluster.
• Grafana: Visualization tool. Used to visualize metrics from the cluster and other sources.
• Ingress-Nginx: Ingress controller. A reverse proxy for services in the cluster.
• Kasten K10: Backup solution for Kubernetes applications. Since I deploy with GitOps this is mainly used for backing up data.
• MetalLB: Load balancer for bare metal Kubernetes clusters.
• VictoriaMetrics: Monitoring system for metrics and logs. Drop-in replacement for Prometheus.

• Authentik: Self-hosted IDP(Identity provider). Borderline infra app but I mainly set it up for fun.
• Headscale: Self-hosted Tailscale control server.
• Kromgo: Sort of a reverse proxy for prometheus metrics.
• Mealie: Self-hosted recepie manager.
• Morphos: Self-hosted file converter.
• OpenCloud: Self-hosted file storage with collaboration and sharing.
• Vikunja: Self-hosted todo app.

The ratio is a bit skewed but the platform stuff is where the learning is at 😎

All Kubernetes manifests are placed under kubernetes/apps/ and each application lives in its own directory named after the namespace it will be deployed to.

Each application directory typically contains:

• A kustomization.yaml that serves as the base entry point.
• A namespace.yaml defining the namespace for the app.
• A flux-kustomization.yaml defining the Flux Kustomization resource that applies the app manifests.
• An app/ subdirectory containing the actual Kubernetes manifests.

Flux is bootstrapped to kubernetes/apps/, and from there it automatically discovers each top-level kustomization.yaml within the application directories.

Each of these base Kustomizations is responsible for:

1. Creating the target namespace.
2. Applying the corresponding Flux Kustomization resource defined in flux-kustomization.yaml.

The Flux Kustomization then deploys the application itself using either HelmReleases or plain Kustomize depending on the app.