K3s.Cluster

Architettura K3s Multi-Master ad alta disponibilità distribuita su istanze OCI ARM64. Rete crittografata nativa via WireGuard Mesh, storage distribuito sincrono e automazione GitOps.

K3s v1.28+ Multi-MasterOracle ARM64 (OCI)Flannel + WireGuard MeshCloudflare DNS LB (Round-Robin)Traefik IngressLonghorn Distributed StorageAuthentik OIDCPrometheus + GrafanaArgoCD (GitOps)

Infrastruttura Declarativa

Nessuna configurazione manuale sui nodi. I workload, i volumi distribuiti e le policy di rete sono definiti al 100% via codice e sincronizzati tramite GitOps.

Mesh CNI

WireGuard Backend

Round-Robin

Multi-IP DNS LB

Cluster OCI Completo Multi-Master senza Single Point of Failure

L'infrastruttura esegue i servizi in produzione scalando orizzontalmente sul piano di controllo. I tre server operano simultaneamente come master, pronti ad accogliere nodi worker aggiuntivi senza ristrutturazioni logiche del network.

Architecture

Bare-metal Cloud ARM64

Datastore HA

Embedded etcd Quorum

Specifiche Hardware e Rete

Compute Topology

3x Nodi Control Plane (HA)

Istanze Oracle Cloud Infrastructure Ampere ARM64 in configurazione interamente Multi-Master con datastore etcd integrato. L'assenza di nodi worker dedicati ottimizza le risorse e garantisce l'alta affidabilità: se un nodo fallisce, il cluster mantiene il quorum senza downtime.

WireGuard Mesh Network

Flannel Overlay VPN

La comunicazione inter-nodo e il traffico pod-to-pod della CNI Flannel sono incapsulati in un tunnel cifrato point-to-point via WireGuard nativo del kernel. Questo isola completamente il cluster a livello di rete, mettendo in sicurezza il piano di controllo anche su nodi geograficamente distanti.

Edge Routing & Load Balancing

Cloudflare LB + Traefik

Il bilanciamento del traffico in ingresso è gestito a monte da Cloudflare tramite record DNS multipli in Round-Robin puntati sui 3 IP pubblici separati delle istanze. A valle, le richieste HTTPS ereditano i certificati di origine Cloudflare e vengono instradate da Traefik Ingress verso i servizi interni.

Pipeline di Continuous Integration & Deployment

Step 01CI - Source Control

Forgejo Git Engine

I sorgenti delle applicazioni e i file manifest YAML di Kubernetes sono ospitati localmente sul server Git privato, eliminando la dipendenza da piattaforme esterne SaaS.

Step 02CI - Container Build

Forgejo Actions Runner

All'attivazione di un push, i runner nativi compilano il codice, eseguono i test ed effettuano il build di immagini Docker multi-architettura ottimizzate per ARM64, effettuando il push nel registry locale.

Step 03CD - GitOps Pull

ArgoCD Orchestrator

ArgoCD intercetta le modifiche sul repository, calcola il diff con lo stato attuale del cluster ed esegue il deployment sincronizzato eliminando i disallineamenti di configurazione.

Risorse e Workload in Esecuzione

Forgejo & Actions

ns / devops

Piattaforma Git self-hosted e runner nativi ARM64 per build Docker isolate. Gestione temporanea delle variabili d'ambiente e dei Secret tramite Forgejo Secrets, con migrazione architetturale pianificata verso HashiCorp Vault esterno.

ArgoCD

ns / devops

Continuous Delivery basato su GitOps. Monitora costantemente i manifesti dichiarativi sul repository Forgejo e applica automaticamente le modifiche sul cluster tramite Rolling Update sincroni, azzerando il disallineamento manuale.

Distributed Storage

ns / longhorn-system

Storage distribuito a blocchi gestito tramite Longhorn. Sincronizza e replica in modo sincrono i Persistent Volumes (PV) sui tre nodi ARM64, garantendo la persistenza e la disponibilità dei dati anche in caso di perdita di un intero nodo.

Identity & Observability

ns / monitoring-iam

Stack aziendale centralizzato: Authentik gestisce l'autenticazione OIDC unificata per tutte le dashboard web, mentre Prometheus e Grafana si occupano del recupero metriche del cluster, dei container e dell'hardware.