Het idee van een volledig standalone cluster dat onafhankelijk van internet of externe diensten draait is de overtreffende trap van de homelab-filosofie!
Als je niet afhankelijk wilt zijn van GitHub.com, Docker Hub of externe cloudproviders, kan je cluster 100% lokaal functioneren. Om dit met Talos Linux, GitOps en een standalone workflow te bereiken, zijn er uitstekende lokale alternatieven en een heldere architectuur.
1. Een eigen lokale Git-server: Forgejo / Gitea
Om GitOps (en OpenCode) lokaal te laten werken zonder GitHub, heb je een lokale Git-server op je cluster nodig.
- Forgejo (of Gitea): Dit is een extreem lichte, snelle en volledige Git-server die je binnen een paar minuten op K3s of Talos draait. Het heeft precies dezelfde functies als GitHub (repositories, pull requests, webhooks, en zelfs GitHub Actions-compatible CI/CD runners).
- Hoe start je dit op (de Kip-of-het-Ei probleem): Bij de allereerste bootstrap heeft je cluster nog geen Forgejo. Je bootstrapt Talos en de basiselementen (zoals Forgejo) eenmalig via OpenTofu/Helm vanaf je laptop. Zodra Forgejo op de cluster draait, neem je die lokale repository in gebruik als jouw Single Source of Truth.
2. Hoe werkt GitOps in een Standalone Cluster?
In plaats van handmatig kubectl apply -f manifest.yaml uit te voeren, zet je ArgoCD of FluxCD in het cluster.
- Jij of OpenCode past een YAML-bestand of Helm-chart aan en commit/pusht dit naar je lokale Forgejo Git-server.
- ArgoCD (die continu binnen het cluster draait) ziet dat de Git-repo veranderd is.
- ArgoCD past de cluster-status automatisch aan.
Het grote voordeel voor Zero Maintenance: Als er een node crasht of een pod vastloopt, merkt ArgoCD dat de fysieke situatie afwijkt van wat er in je lokale Git-server staat. ArgoCD sloopt de foute pod en herbouwt deze automatisch volgens de specificatie in Git.
3. De 3 Bausteinen voor een 100% Standalone Talos Cluster
Als je de afhankelijkheid van het internet écht naar nul wilt terugbrengen, heb je naast een lokale Git-server nog twee dingen nodig op de cluster:
A. Lokale Container Registry (bijv. Harbor of CNCF Distribution)
- Waarom: Zonder internet kan Kubernetes geen images (zoals
nginx:latestofpostgres:15) downloaden van Docker Hub. - Oplossing: Je draait een lokale image registry op de cluster (of mirrored veelgebruikte basis-images naar je lokale registry).
B. Lokale Persistent Storage (bijv. Longhorn of Rook-Ceph)
- Waarom: Talos Linux heeft een read-only bestandssysteem. Gegevens van Forgejo, databases en backups moeten op een betrouwbare, gerepliceerde schijf opgeslagen worden.
- Oplossing: Longhorn is een lichtgewicht, cloud-native opslagoplossing voor Kubernetes. Het verdeelt de data over de SSD’s van je 3 laptops via de snelle Thunderbolt-interconnectie. Als laptop 1 uitvalt, staan je Git-repositories en backups nog steeds op laptop 2 en 3!
C. Lokale Backup & Restore (Velero + MinIO)
- S3 Storage: Draai MinIO (lokale Amazon S3-compatible opslag) op de cluster of op een externe schijf/NAS.
- Velero: Maakt periodiek volledige cluster-snapshots van ArgoCD, Forgejo en je apps richting MinIO. OpenCode kan bij een calamiteit direct een herstelcommando naar Velero sturen.
4. Het bootstrap-stappenplan voor OpenCode
Wanneer je dit standalone concept wilt gaan bouwen met OpenCode, verdeel je de uitrol in 3 fases:
- Fase 1: Bare Bootstrap (Vanaf je laptop)
- OpenCode genereert de Talos Linux machine-configuraties (inclusief IP-over-Thunderbolt netwerk).
- OpenCode voert
talosctluit om de 3 laptops te bootstrappen naar een werkend Talos/Kubernetes cluster.
- Fase 2: Core Platform Services (Eenmalig)
- OpenCode installeert via Helm/OpenTofu:
- Longhorn (Gerepliceerde opslag over Thunderbolt)
- Forgejo (Je lokale Git-server)
- ArgoCD (Je GitOps-engine)
- Fase 3: GitOps Overname (Vanaf nu 100% standalone)
- Abstraheer alle overige configuraties naar de Git-repository op Forgejo.
- Vanaf dit punt hoeft OpenCode alleen nog maar YAML/OpenTofu code te pushen naar Forgejo op
[http://forgejo.local](http://forgejo.local). ArgoCD regelt de rest!