Gestione di cluster Kubernetes multi-cloud

Strumenti e dashboard frammentati per cloud

Un cluster GKE su GCP per una business unit, EKS per un'altra, un cluster RKE2 on-premise per un carico di lavoro regolamentato e ora un cluster OVHcloud per il calcolo sovrano nell'UE. Ognuno di questi provider offre la propria console, la propria CLI, il proprio modo di fare le cose. Non esiste una visione globale dello stato di salute, della capacità o della policy di sicurezza dei cluster in tutti gli ambienti, solo N provider e N set di strumenti, ognuno dei quali richiede competenze specifiche. 

La visibilità è la prima vittima e ogni altra attività operativa diventa più difficile senza di essa. Ogni cloud aggiuntivo moltiplica la superficie che il tuo team deve coprire e nulla di tutto ciò rende più affidabile il carico di lavoro dell'applicazione in esecuzione.

Proliferazione dell'RBAC e deriva della configurazione tra i cluster

Il servizio Kubernetes gestito di ogni provider ha il proprio modello di identità e autorizzazione, quindi cloud multipli significano modelli multipli. Definire una policy di sicurezza coerente per un ingegnere, per gli sviluppatori o per un revisore significa ripetere la stessa configurazione in tre o quattro console e sintassi. La deriva non è un rischio qui, è una certezza, ed è la sfida che scala peggio. Un permesso concesso su un cluster e dimenticato su un altro è una lacuna di conformità che emerge durante un audit, non prima.

La deriva si estende ben oltre i permessi. Le regole di rete, le quote di risorse, l'isolamento dei carichi di lavoro e le regole di ammissione che erano coerenti alla configurazione iniziale divergono silenziosamente man mano che ogni cluster viene patchato, aggiornato o regolato manualmente da chiunque sia di turno. La deriva della governance della sicurezza è la versione più costosa: una regola di hardening applicata su un cluster e mai propagata è invisibile finché un incidente o un audit non la espone.

GitOps che si interrompe al confine tra i cloud

GitOps dovrebbe fornire un'unica fonte di verità per ciò che viene eseguito dove e un'unica pipeline di distribuzione continua per ogni ambiente. In pratica, la maggior parte dei team esegue istanze separate di Fleet o ArgoCD per ogni cloud, o mantiene pipeline per singolo cloud, ognuna con le proprie credenziali, logica di sincronizzazione e gestione degli errori. Ogni pipeline aggiunta è un ulteriore punto di errore. 

Nel momento in cui un'applicazione deve essere distribuita in modo coerente su più ambienti, su GKE in GCP, su EKS e on-premise contemporaneamente, la promessa di un unico repository Git si divide in tre pipeline di distribuzione parallele che divergono. La gestione del traffico segue la stessa strada: bilanciatori di carico, routing globale del traffico e policy del traffico tra cluster gestiti cloud per cloud invece che come un'unica regola di rete. Nemmeno gli strumenti ancorati agli hyperscaler risolvono questo problema in modo pulito, perché instradano i dati di telemetria e di autorizzazione attraverso l'infrastruttura statunitense anche quando i nodi worker si trovano in una regione dell'UE, indipendentemente dalla posizione fisica dell'hardware.

Il costo nascosto dell'hosting autonomo di Rancher

L'hosting autonomo è una soluzione alla sfida cloud-agnostic, poiché un singolo strumento incentrato su Kubernetes gestisce quindi qualsiasi cluster conforme alla CNCF. Ne crea una nuova: ora il tuo team gestisce quello strumento. La configurazione ad alta disponibilità, un datastore di supporto, la rotazione dei certificati e gli aggiornamenti trimestrali finiscono tutti nel tuo backlog, oltre ai cluster sottostanti. Un livello di gestione autogestito è un prodotto a sé stante, con un'impronta infrastrutturale che deve essere dimensionata e patchata correttamente, con la stessa attenzione SRE riservata al patrimonio che governa. Una soluzione ospitata rimuove quel livello.

Architettura: il Manager su OVHcloud, agenti su ogni cluster

Una distinzione architettonica è fondamentale: OVHcloud non gestisce direttamente i tuoi cluster su GKE, EKS o AKS. Il Manager è ciò che viene ospitato su OVHcloud, nella regione UE di tua scelta, un'unica posizione sotto un'unica giurisdizione. Un agente leggero, solo in uscita, viene eseguito su ciascuno dei tuoi cluster Kubernetes, ovunque si trovino, e invia i report. I tuoi cluster GKE, EKS, AKS o on-premise esistenti rimangono dove sono, sotto i tuoi account e la tua responsabilità.

Ogni tipo di cluster, che sia gestito dal cloud, autogestito o nativo di OVHcloud, appare nella stessa interfaccia utente, dietro la stessa API, e può essere sottoposto a provisioning tramite le stesse risorse Terraform. Anche i team che si standardizzano su Ansible o Pulumi mantengono tali flussi di lavoro. Se i tuoi cluster condividono un archivio di immagini container, OVHcloud Managed Private Registry fornisce un registro basato su Harbor da cui ogni cluster può eseguire il pull, indipendentemente dal cloud o dalla regione in cui viene eseguito.

Pattern A: importa cluster GKE, EKS, AKS o on-premise esistenti

Se esegui già cluster Kubernetes su GCP, AWS, Azure o nei tuoi data center, non migri nulla. Installa l'agente su ogni cluster esistente; esso apre una connessione solo in uscita verso il Manager e il cluster appare nel giro di pochi minuti. Non c'è re-platforming, nessuna interruzione del deployment e nessun cambiamento nel modo in cui distribuisci le applicazioni su quel cluster oggi. I carichi di lavoro esistenti continuano a essere eseguiti esattamente come prima.

Pattern B: esegui il provisioning di nuovi cluster RKE2 o k3s su qualsiasi infrastruttura

Per i nuovi cluster, anziché quelli importati, utilizza il Manager per eseguire il provisioning di RKE2, una distribuzione Kubernetes di livello produzione, rafforzata secondo i benchmark CIS, o k3s, una distribuzione leggera adatta alle implementazioni edge. Entrambi vengono eseguiti su qualsiasi infrastruttura con risorse di calcolo disponibili: bare metal on-premise, VM o istanze IaaS su qualsiasi provider cloud, in qualsiasi regione. Il flusso di lavoro di provisioning, l'RBAC e il monitoraggio centralizzato sono identici in ogni regione, ovunque si trovino fisicamente i nodi risultanti.

Pattern C: aggiungi OVHcloud MKS come cluster sovrano dell'UE

Il terzo pattern di architettura è la soluzione sovrana: un cluster nativo OVHcloud per qualsiasi carico di lavoro che richieda specificamente la sovranità dell'UE. I cluster del servizio Kubernetes gestito di OVHcloud si registrano nello stesso Manager dei cluster importati e sottoposti a provisioning, e appaiono come elementi di primo livello accanto a essi, con la stessa interfaccia utente, lo stesso RBAC e le stesse pipeline GitOps. A differenza dei cluster su cloud di terze parti, OVHcloud gestisce interamente il piano di controllo MKS, quindi questo è l'unico tipo di cluster nel tuo parco risorse che non comporta alcun onere operativo per il piano di controllo da parte tua.

Controllo degli accessi unificato su ogni cluster, definisci una volta, propaga ovunque

Definisci un ruolo una volta sola e propagalo a ogni cluster Kubernetes, invece di ripeterlo in tre o quattro console separate. Gli utenti accedono tramite lo stesso provider di identità ovunque. Ogni concessione, revoca e modifica delle autorizzazioni per singolo utente confluisce in un'unica traccia di controllo coerente, il che fa la differenza tra una revisione degli accessi che richiede un pomeriggio e una che ne richiede una settimana.

L'onboarding di un nuovo ingegnere diventa un unico passaggio di provisioning, non una checklist per ogni cloud, e i ticket su chi può accedere a cosa smettono di essere progetti di ricerca. Per un'organizzazione che esegue cluster su più di un cloud, quel singolo punto di controllo è ciò che rende gestibile un audit di conformità e ciò che le consente di dimostrare gli impegni di protezione dei dati presi nei confronti dei propri utenti.

GitOps multi-cluster con Rancher Fleet

Fleet ti permette di definire le applicazioni una sola volta in un repository GitHub e di sincronizzarle tramite selettore di etichette, ad esempio tutti i cluster di produzione UE o ogni ambiente di staging, invece di mantenere una pipeline separata per provider. Lo scostamento tra ciò che è dichiarato in Git e ciò che è in esecuzione viene rilevato e riconciliato automaticamente su ogni cluster nel selettore; si tratta di controllo di versione applicato all'infrastruttura e non solo al codice.

Questa è una gestione centralizzata sia per l'isolamento dei carichi di lavoro che per le policy dei namespace: le stesse regole si applicano ovunque, il che è l'unico modo per garantire coerenza su cluster che nessuno controlla spesso. È la soluzione diretta alla frammentazione della pipeline di distribuzione, con un'unica fonte di verità e un unico motore di sincronizzazione, indipendentemente dal fatto che il carico di lavoro di destinazione venga eseguito su GKE, on-prem o su OVHcloud MKS. La nostra guida alla gestione multi-cluster è il posto giusto per saperne di più sulle operazioni quotidiane una volta configurata un'infrastruttura e su come i team semplificano i rilasci tra le regioni.

Ciclo di vita del cluster: aggiornamenti, provisioning, deprovisioning tramite interfaccia utente, API o Terraform

Gli aggiornamenti della versione di Kubernetes sono orchestrati su ogni cluster con impostazioni di surge configurabili, invece di finestre di manutenzione separate per cluster per cloud. Puoi automatizzare il provisioning, l'aggiornamento e il deprovisioning tramite la stessa interfaccia utente, la stessa API, le stesse risorse Terraform o i tuoi flussi di lavoro Ansible esistenti, e ottieni visibilità sullo stato attuale senza cambiare console, senza dipendere da altro che dal cluster stesso.

I comandi che i tuoi ingegneri già conoscono continuano a funzionare in modo identico. Cambia contesto, quindi esegui le stesse operazioni:

kubectl create namespace payments-staging
kubectl get events --all-namespaces

Questa coerenza trasforma la gestione del ciclo di vita da un esercizio soggetto a errori in uno ripetibile e automatizzato. Elimina la complessità che altrimenti crescerebbe con ogni distribuzione multi-regione complessa, consentendo a un piccolo team di gestire efficacemente un'ampia infrastruttura su larga scala, dallo sviluppo alla produzione.

Monitoraggio e registrazione centralizzati con Prometheus e Grafana

Prometheus e Grafana si integrano su scala di infrastruttura, offrendoti uno stack di osservabilità unificato e multi-cluster su ogni cluster invece di uno strumento e una configurazione diversi per ogni cloud. L'archiviazione delle metriche e l'aggregazione dei log sono abilitate allo stesso modo su ogni nodo in ogni regione, e si applicano le stesse dashboard, regole di avviso e guide ai runbook, indipendentemente dal fatto che un avviso venga attivato su un cluster GKE, un cluster RKE2 on-prem o un nodo OVHcloud MKS. Le domande sull'affidabilità ottengono una risposta unica invece di una per provider, e le tendenze di utilizzo e traffico diventano visibili in un'unica vista globale.

Perché aggiungere un cluster sovrano UE (CLOUD Act, dipendenza da un singolo hyperscaler)

Se ogni cluster che esegui si trova su un hyperscaler statunitense, tutti i dati del piano di controllo sono soggetti allo US CLOUD Act, indipendentemente dalla posizione fisica dei worker node. La soluzione è aggiungere OVHcloud Managed Kubernetes Service: un cluster il cui piano di controllo viene eseguito in una regione europea senza una società madre statunitense e senza esposizione strutturale al CLOUD Act.

Questo è importante per qualsiasi organizzazione, indipendentemente dallo strumento utilizzato per gestire il resto dei cluster. Questo approccio riduce la dipendenza da un singolo hyperscaler per qualsiasi carico di lavoro critico e offre ai team regolamentati nei settori sanitario, dei servizi finanziari e pubblico un'opzione sotto giurisdizione UE senza abbandonare i cluster già in esecuzione altrove.

MKS Free: aggiungi un cluster OVHcloud a costo zero

MKS è disponibile come livello gratuito in tutte le 14 regioni, senza necessità di carta di credito, quindi convalidare un cluster sovrano UE non costa nulla. Viene eseguito all'interno del tuo progetto Public Cloud esistente, accanto a qualsiasi altra risorsa e nodo già utilizzato dal tuo team. Per un carico di lavoro di produzione, MKS Standard viene eseguito in 3-AZ nella regione di Parigi con un accordo sul livello di servizio del 99,99%. Entrambi i livelli si registrano esattamente come qualsiasi altro cluster, con lo stesso RBAC, lo stesso GitOps e lo stesso monitoraggio, nella regione scelta.

100% open source, zero lock-in: il tuo percorso di uscita è l'auto-hosting, non la migrazione

Rancher è rilasciato con licenza Apache 2.0 e le distribuzioni RKE2 e k3s che fornisce sono progetti CNCF. OVHcloud non esegue un fork proprietario né aggiunge un livello di funzionalità chiuso: è l'identico progetto upstream, cloud-agnostic e ospitato per te come soluzione gestita. Se in seguito decidi di riportare la gestione internamente, il tuo percorso di uscita consiste nell'auto-ospitare lo stesso progetto, non in una migrazione né in una riscrittura della configurazione dei tuoi cluster. I cluster non ne risentono in alcun modo, perché non sono mai stati vincolati ad altro che a Kubernetes standard e ad agent standard.