Categoria: Cloud

Cloud Modern Application

Pubblicato il

Ricostruire un Cluster RKE2 con Storage Synology CSI + Snapshot

L’obiettivo del presente articolo è illustrare come realizzare un cluster Kubernetes basato su RKE2, con la seguente architettura:

Reinstallazione Pulita di RKE2

Dopo i test precedenti, al fine di avere una situazione pulita ho deciso di ripartire da zero.

Disinstallazione completa

Su ogni nodo:

  • sudo /usr/local/bin/rke2-uninstall.sh
  • sudo rm -rf /var/lib/rancher /var/lib/kubelet /etc/cni /var/lib/cni /opt/cni

Pulizia mount iSCSI eventualmente attivi:

  • sudo umount -l /var/lib/kubelet/plugins/kubernetes.io/csi/*/*/globalmount

Reboot nodi.

Installazione RKE2 Server (Management Node)

Configurazione /etc/rancher/rke2/config.yaml:

  • write-kubeconfig-mode: “0644”
  • tls-san:
  •   – “IP”
  • node-ip: “IP”

In Kubernetes (k8s), TLS SAN è l’acronimo di  Subject Alternative Name. E’ un’estensione del certificato SSL/TLS X.509 utilizzata per specificare molteplici nomi host (DNS) o indirizzi IP validi per un singolo certificato

Installazione:

  • curl -sfL https://get.rke2.io | sh –
  • sudo systemctl enable rke2-server –now

Esportazione kubeconfig:

  • export KUBECONFIG=/etc/rancher/rke2/rke2.yaml

Join Worker Nodes

Su ciascun worker:

  • curl -sfL https://get.rke2.io | INSTALL_RKE2_TYPE=”agent” sh –

All’interno del file di configurazione /etc/rancher/rke2/config.yaml è necessario aggiungere le voci server e il token di accesso

  • server: https://ip-management:9345
  • token: <server_token>

NB: per generare il token sul management lanciare il comando:

  • sudo cat /var/lib/rancher/rke2/server/node-token

Avvio: sudo systemctl enable rke2-agent –now

Al fine di separare i diversi ruoli nel cluster conviene assegnare delle label ai worker con i seguenti comandi:

  • kubectl label node nuc-01 workload=apps
  • kubectl label node nuc-02 workload=apps
  • kubectl label node nuc-03 workload=apps

Taint Management: Il taint (macchia/marchio) di Kubernetes è una proprietà applicata a un nodo per “respingere” i pod, impedendo loro di pianificarvi sopra a meno che non abbiano una specifica toleration (tolleranza). Nel nostro caso viene applicato al nodo di mangement.

  • kubectl taint nodes nuc-mng node-type=management:NoSchedule

Risultato: Nessun microservizio girerà sul management, lo scheduling è forzato sui worker

Ingress NGINX: Un controller Kubernetes Ingress è un componente software specializzato che gestisce il traffico in entrata verso le applicazioni in esecuzione 

Installazione via Helm:

  • helm install ingress-nginx ingress-nginx/ingress-nginx \
  •   –namespace ingress-nginx \
  •   –create-namespace \
  •   –set controller.nodeSelector.workload=apps

Cert-Manager: cert-manager è un add-on open-source per Kubernetes che automatizza la gestione, l’emissione e il rinnovo dei certificati TLS/SSL

Installazione CRD:

  • kubectl apply -f https://github.com/cert-manager/cert-manager/releases/latest/download/cert-manager.crds.yaml
  • Installazione Helm (disabilitando startupapicheck nel lab):
  • helm install cert-manager jetstack/cert-manager \
  •   –namespace cert-manager \
  •   –create-namespace \
  •   –set startupapicheck.enabled=false \
  •   –set nodeSelector.workload=apps

Installazione Synology CSI Driver

E’ necessario che ogni singolo worker veda via iSCSI lo storage in modo che il comando sudo iscsiadm -m discovery -t sendtargets -p <IP_NAS> mostri i target.

Per installare il csi driver:

  • git clone https://github.com/SynologyOpenSource/synology-csi.git
  • cd synology-csi

Nella cartella

Modificare il file ~/synology-csi/config/client-info.yaml inserendo le credenziali richieste

Creare un secret:

kubectl -n kube-system create secret generic synology-csi-secret \
–from-literal=username='<DSM_USER>’ \
–from-literal=password='<DSM_PASSWORD>’

e per ultimo caricare il config.yaml nel config map:

kubectl -n kube-system create configmap synology-csi-config \
–from-file=config.yml=./config.yml

Gli ultimi passaggi sono quelli di creare una Storage Class (sc) e una Volume Snapshot Class al fine di rendere il cluster k8s in grado di:

  • Gestire snapshot nativi
  • Ripristini di PVC da snapshot
  • Pronto per integrazione con Kasten K10

🏁 Stato Finale del Cluster

✔ RKE2
✔ Calico
✔ Ingress NGINX
✔ Cert-Manager
✔ Synology CSI (iSCSI)
✔ Snapshot Kubernetes
✔ Separazione Management / Workload

Prossimi step: 

  • Kasten K10
  • Disaster Recovery test
  • AI workload
  • Database stateful

Pubblicato il

Snapshot e protezione dei dati

Con lo storage ormai integrato nel cluster, il passo successivo è  “salvare dati”, anche se preferisco la dizione proteggerli.
In questo capitolo il desiderio è stato quello di far passare il laboratorio da semplice piattaforma Kubernetes a sistema resiliente.

Perché gli snapshot sono fondamentali

In Kubernetes i dati vivono dentro volumi persistenti (PVC), ma senza snapshot:

  • non puoi fare rollback
  • non puoi fare restore veloci
  • non puoi garantire recovery point affidabili

Gli snapshot sono l’equivalente moderno dei checkpoint delle macchine virtuali, ma applicati ai volumi containerizzati.

Snapshot CSI: la base tecnologica

Tramite Il CSI driver di Synology, il cluster ha ottenuto una nuova capacità:

K8s può chiedere allo storage di creare snapshot dei volumi.

Questo introduce tre nuove entità:

  • VolumeSnapshotClass
  • VolumeSnapshot
  • VolumeSnapshotContent

Non sono file.
Sono oggetti Kubernetes che rappresentano snapshot reali creati sul NAS.

Il legame tra Kubernetes e Synology

Quando Kubernetes crea un VolumeSnapshot:

  • Il CSI driver invia la richiesta al Synology
  • Il NAS crea uno snapshot iSCSI nativo
  • Kubernetes riceve l’ID dello snapshot
  • Il VolumeSnapshot diventa ReadyToUse

A questo punto lo snapshot è:

  • consistente (non da un punto di vista applicativo)
  • puntuale
  • indipendente dal pod

Ed è pronto per essere usato per backup o restore.

Validazione degli snapshot

Nel laboratorio è stato creato un PVC di test con dati scritti da un pod.
Da lì sono stati generati snapshot CSI e verificato che:

  • esistono nel NAS
  • sono visibili come oggetti Kubernetes
  • possono essere usati per creare nuovi volumi

Questo ha dimostrato che lo storage era snapshot-aware, requisito essenziale per Kasten K10.

Perché questo passaggio è cruciale per il backup

Kasten K10 non lavora direttamente con i filesystem ma lavora con Snapshot CSI consistenti.

Senza questa aggiunta, Kasten avrebbe potuto solo fare backup “file based”, con gli snapshot, invece è possibile effettuare:

  • backup istantanei
  • consistenza applicativa
  • restore rapidi

È qui che nasce la vera data protection cloud-native.

Risultato

Alla fine di questo step il cluster possiede:

  • Storage persistente
  • Snapshot nativi
  • API Kubernetes per gestirli

Il laboratorio è pronto per introdurre un altro protagonista:
Kasten K10.

Pubblicato il

Storage e k8s cluster

Con il cluster Kubernetes operativo, il passo successivo è quello di gestire la cosa più critica di tutte i dati.

Un cluster senza storage persistente è solo una piattaforma di calcolo.
Un cluster con storage condiviso diventa invece una piattaforma applicativa reale 🙂

Il problema da risolvere

Le applicazioni Kubernetes non possono dipendere dai dischi locali dei nodi:

  • un pod può spostarsi da un nodo all’altro
  • un nodo può spegnersi
  • un container può essere ricreato

Quindi se i dati restano legati al nodo, vengono persi.

Serve quindi uno storage:

  • condiviso tra i nodi
  • persistente
  • gestito dinamicamente da Kubernetes

Lo storage esterno: Synology e WD

Nel laboratorio erano disponibili due sistemi di storage esterni:

  • Synology → usato come storage primario con supporto iSCSI e snapshot
  • WD NAS → usato come repository NFS per la seconda copia (backup)

Integrazione dello storage con Kubernetes

Per permettere a Kubernetes di usare lo storage Synology come se fosse nativo, è stato installato:

  • CSI Driver di Synology
  • Snapshot Controller CSI

Questi componenti trasformano lo storage fisico in risorse Kubernetes:

  • PersistentVolumes
  • PersistentVolumeClaims
  • VolumeSnapshots

In pratica, Kubernetes ha iniziato a parlare direttamente con il NAS, senza script o mount manuali.

Le StorageClass

Una volta installato il driver, sono state create le StorageClass, che definiscono:

  • tipo di storage (iSCSI)
  • policy di cancellazione
  • supporto snapshot

Ogni applicazione che richiede storage non chiede più “un disco”, ma chiede una Storage Class con determinate caratteristiche.

Ed è K8s, tramite il CSI driver, che crea automaticamente i volumi sul NAS.

Verifica con PV, PVC e Pod

Per validare l’integrazione sono stati creati:

  • un PVC (PersistentVolumeClaim)
  • un PV (creato dinamicamente dal NAS)
  • un Pod di test che scrive dati sul volume

In quel momento è stato verificato che:

  • il volume esiste realmente sul Synology
  • il pod può scrivere dati
  • i dati sopravvivono al riavvio del pod

Questo è stato il primo vero test di persistenza reale del cluster.

Risultato

Il cluster è diventato un cluster Kubernetes con storage condiviso.

Ora il sistema era pronto per:

  • snapshot
  • backup
  • restore
  • disaster recovery

Prossimo capitolo, usare Kasten K10 per proteggere l’ambiente.

Pubblicato il

Configurazione dei NUC dopo l’installazione di Ubuntu

Scopo di questa fase

Una volta installato Ubuntu Server su ciascun Intel NUC, l’obiettivo non è ancora Kubernetes, ma creare una base stabile, sicura e coerente su cui costruire il cluster.

In questa fase si definisce il “DNA” dei nodi:

  • come si collegano in rete
  • come vengono amministrati
  • come vengono identificati
  • come possono essere automatizzati

Se questa base è solida, tutto il resto (Kubernetes, storage, backup) sarà affidabile.

Allineamento del sistema operativo

Ogni NUC deve partire dallo stesso stato logico in modo che reagiscano allo stesso modo in caso di problemi e che le performance non decadano se i workload vengono automaticamente spostati

  • Sistema aggiornato
  • Pacchetti base installati
  • Kernel e firmware allineati
  • Tool di rete, NFS, iSCSI e storage pronti
  • Questo garantisce che:

Identità dei nodi

Si configurano:

  • hostname univoci (nuc-01, nuc-02, nuc-03, nuc-mngt)
  • risoluzione DNS o /etc/hosts coerente

Questo è fondamentale perché Kubernetes non lavora con IP casuali, ma con identità logiche dei nodi.

Networking a più interfacce

Ogni NUC ha più schede di rete, con ruoli distinti:

Rete Scopo
Management SSH, API, controllo cluster
Storage iSCSI / NFS verso NAS
(opzionale) Frontend traffico applicativo

La separazione delle reti è una best practice enterprise per evitare che il traffico storage o backup rallenti k8s.

Configurazione firewall e sicurezza

  • porte aperte per Kubernetes
  • porte per SSH
  • porte per storage (iSCSI, NFS)
  • tutto il resto bloccato

Questo crea una superficie di attacco minima, fondamentale quando si parla di dati.

Abilitazione dell’accesso remoto sicuro

Tutti i nodi vengono resi amministrabili via SSH. permettendo :

  • gestione remota
  • automazione
  • troubleshooting
  • integrazione con strumenti di orchestrazione

È la base per poter gestire il cluster come una piattaforma, non come singole macchine.

Verifica delle interfacce di rete e dello storage

Prima di installare Kubernetes, si verifica che:

  • ogni nodo veda gli storage (Synology, WD)
  • le interfacce di rete siano attive
  • le rotte siano corrette
  • i NAS rispondano

In questa fase si valida un principio chiave:

k8s non può essere più affidabile dell’infrastruttura che lo sostiene.

Risultato

Alla fine di questa fase, i NUC non sono più “PC con Ubuntu”, ma diventano:

  • nodi di un’infrastruttura
  • pronti per lavorare insieme
  • collegati allo storage
  • gestibili in modo centralizzato

Questa è la fondazione fisica e logica su cui verrà costruito il cluster Kubernetes.

Pubblicato il

Da Bare-Metal a Kubernetes Cyber-Resiliente – Introduzione

Introduzione

Negli ambienti Kubernetes moderni, la vera sfida non è far girare i container, ma proteggere i dati.
Applicazioni, database e servizi stateful richiedono una piattaforma che garantisca:

  • Persistenza
  • Snapshot
  • Backup off-cluster
  • Ripristino affidabile

Questo progetto nasce con l’obiettivo di costruire, partendo da hardware fisico, una piattaforma Kubernetes pronta per ambienti enterprise, in grado di offrire resilienza dei dati e protezione da eventi critici come guasti o ransomware.

Obiettivo del progetto

L’obiettivo non era creare un semplice laboratorio, ma una piattaforma cloud-native completa, in cui:

  • Lo storage è condiviso e ridondato
  • I volumi sono gestiti da Kubernetes tramite CSI
  • I dati possono essere snapshot-tati
  • I backup sono esportati fuori dal cluster

In altre parole: Kubernetes diventa una piattaforma dati, non solo di calcolo.

Architettura di base

L’architettura si basa su tre elementi fondamentali:

  1. Nodi di calcolo (Intel NUC) per eseguire Kubernetes
  2. Storage esterno (Synology e WD) per ospitare i dati
  3. Rete dedicata per collegare compute e storage

Questo modello separa fisicamente calcolo, dati e gestione, una best practice delle architetture enterprise.

Abilitazione dello storage persistente

Lo storage esterno viene esposto a Kubernetes tramite:

  • iSCSI (Synology)
  • NFS (WD)

e integrato nel cluster attraverso CSI (Container Storage Interface).

Questo permette a Kubernetes di creare, montare e gestire volumi come risorse native.

Snapshot e consistenza dei dati

Sul CSI sono stati abilitati i componenti di snapshot, che consentono di:

  • Congelare lo stato di un volume
  • Proteggere database e file
  • Consentire backup applicativi consistenti

Questa è la base di qualsiasi strategia di data protection moderna.

Protezione dei workload con Kasten K10

Sopra Kubernetes è stato installato Kasten K10, la piattaforma di data management per Kubernetes, che fornisce:

  • Policy di backup
  • Snapshot orchestrati
  • Esportazione su storage esterno
  • Restore applicativo

Grazie a Kasten, i workload non sono più solo container, ma entità protette.

Storage di backup off-cluster

Un NAS Wester Digital collegatovia NFS è stato configurato come destinazione di backup al fine di mantenere una copia dei dati fuori dal cluster, requisito essenziale per:

  • Disaster recovery
  • Protezione ransomware
  • Isolamento dei backup

Risultato finale

Il risultato è una piattaforma Kubernetes che:

  • Gestisce storage persistente
  • Supporta snapshot CSI
  • Effettua backup applicativi
  • Replica i dati su storage esterno

In pratica:

K8s pronto per ambienti di produzione e cyber-resilienza.

Pubblicato il

VMware Broadcom – Cosa fare ?

Broadcom's Acquisition of VMware Closed: What Now?

Broadcom ha dato una grande scossa al  2024.

Dagli ultimi rumors, sembra che il licensing della appena acquisita VMware verrà pesantemente rivisto.

Uno dei primi risultati è che molti clienti si chiedono cosa sia giusto fare.

Non ho la pretesa di conoscere la risposta corretta.

Ho effettuato alcune riflessioni che mi hanno portato a pensare a quattro futuri scenari  dei quali vi parlerò nel presente articolo.

  1. Il cliente continua la collaborazione con VMware/Broadcom.
  2. Il cliente sostituisce la tecnologia Hypervisor.
  3. Il cliente migra il proprio datacenter verso un Hyperscaler o  un Service Cloud Provider Locale.
  4. Il cliente trasforma il proprio Datacenter in un  “Datacenter as a Software”.

Per ogni scenario andrò ora a descrivere i macroscopici pro e contro.

1. Credo che il desiderato di Broadcom sia quello di semplificare il più possibile il licensing al fine di avere a portfolio soluzioni snelle e semplici da proporre.

Ciò implica eliminare alcune delle soluzioni ora presenti per concentrare le  energie unicamente su quelle a maggior rilevanza d’uso e guadagno.

Ora vi domando: Le soluzioni VMware ora presenti nel vostro datacenter sono quelle strategiche anche per Broadcom?

E ancora, siamo certi che l’ottimizzazione Broadcom non toccherà il dipartimento R&D di VMware che sviluppa le soluzioni divenute ora strategiche?

E non per ultimo, quale sarà il prezzo per poter rimanere nell’ecosistema Broadcom-VMware?

2. La prima sfida è quella di fornirsi di strumenti in grado di migrare le VM da una tecnologia HyperVisor all’altra.

La seconda è quella di proteggerle.

(NDR. Meno male che Veeam Backup & Replication permette di realizzare con un solo strumento entrambe le cose 🙂 )

Aggiungo, che bisognerà essere anche fortunati nello scegliere un vendor che non sia nel mirino di una nuova Broadcom, perché finire nello stesso giro dantesco sarebbe diabolico.

Pensare ad una tecnologia open-source based?

3. Il modello degli Hyper-Scaler è quello di fornire una serie di servizi  personalizzabili.

Spesso sento qualcuno affermare che esistano dei “costi nascosti”.  Non è vero, sono tutti ben illustrati, solo che capirli preventivamente è spesso molto difficile.

Avrà quindi particolare importanza la fase di creazione del progetto di migrazione che dovrà essere particolarmente accurata al fine di non ritrovarsi brutte sorprese  a fine mese .

4. Data Center as a Software è sinonimo di un’architettura Cloud Native.

Ciò implica riscrivere applicazioni e servizi in modo tale che siano  indipendenti dal HyperVisor.

E’ il nuovo approccio che negli anni diventerà un comune standard per scrivere codice.

Nel sito troverete una serie di articoli sul mondo Container e kubernetes ai quali vi rimando.

Tante domande, una sola risposta giusta?

No, credo che la migliore strategia sia quella di ricercare il miglior bilanciamento nell’utilizzo delle diverse opzioni disponibili, per arrivare a regime con la soluzione che si adatta al meglio alle necessità della vostra azienda in un corretto bilanciamento tra costi e benefici.

Ultima nota: Non dimenticate mai di aggiungere dei piani di formazione del personale perchè il training on the job in scenari particolarmente complessi NON è mai la via migliore per rendere sicuri i vostri sistemi ovunque questi siano