Come risparmiare risorse e tempo quando si lanciano decine di cluster OpenShift

Chiunque abbia distribuito Kubernetes o OpenShift in produzione conosce questo problema. Vuoi creare un piccolo cluster isolato per staging o per un team separato, ma distribuire almeno tre nodi per i nodi master con etcd e i controller è eccessivo. Se hai bisogno di dieci, trenta o cento cluster, le fatture del cloud diventano astronomiche e il tempo per creare un altro ambiente si allunga fino a decine di minuti.

Gli ingegneri Red Hat si sono trovati davanti allo stesso problema e hanno rilasciato una soluzione come open source. Il progetto si chiama HyperShift (o Hosted Control Planes). In sostanza, è uno strato che sposta il control plane del cluster da nodi separati in pod regolari all'interno di un cluster di gestione centrale.

Esploriamo come funziona e chi ne beneficia.

Il focus architetturale principale

In una configurazione classica di OpenShift o Kubernetes, ogni cluster ha le proprie macchine virtuali o fisiche dedicate per l'API server, etcd, i controller e lo scheduler. Paghiamo per questi nodi anche se il cluster è per lo più inattivo.

HyperShift separa il control plane dai nodi worker.

Hai un grande cluster di gestione. Quando devi creare un nuovo cluster OpenShift per utenti o team di sviluppo, HyperShift distribuisce i componenti di gestione del nuovo cluster — etcd, kube-apiserver, openshift-apiserver — come pod standard (Deployment e StatefulSet) direttamente nel cluster di gestione.

Nel frattempo, i nodi worker vengono creati separatamente dove ne hai bisogno: in AWS, Azure o su bare metal. Si connettono all'API server in esecuzione come pod nell'infrastruttura di gestione.

Perché cambiare l'approccio familiare

Se gestisci più cluster, i benefici sono immediatamente evidenti in tre aree.

Prima di tutto — efficienza dei costi. Invece di acquistare almeno tre VM per i nodi master per ogni singolo cluster, sfrutti le risorse di un cluster di gestione esistente. Di conseguenza, decine di control plane vengono eseguiti su un unico pool di risorse, ottenendo un packing molto più denso.

Seconda cosa — velocità di provisioning dell'infrastruttura. Il bootstrap di un nodo completo con sistema operativo, configurazione etcd e inizializzazione dei componenti richiede dai 15 ai 45 minuti. I pod del control plane in HyperShift si avviano in pochi minuti o addirittura secondi. Questo cambia completamente l'approccio agli ambienti dev/test: un cluster diventa una risorsa temporanea facile da avviare per un task e veloce da eliminare.

Terza cosa — separazione delle responsabilità e sicurezza. Gli sviluppatori e le applicazioni hanno accesso solo ai propri nodi worker e all'API server. Non hanno accesso fisico o di rete alle macchine che eseguono il control plane o etcd. Il team operativo aggiorna e monitora centralmente tutti gli API server in un unico posto.

Come appare nella pratica

HyperShift mantiene il 100% di compatibilità con l'API standard di Kubernetes e gli strumenti di OpenShift Container Platform (OCP). Dal punto di vista di uno sviluppatore o di una pipeline CI/CD, il cluster creato è indistinguibile da uno normale: ottieni un kubeconfig standard e lavori tramite kubectl o oc.

La gestione avviene attraverso l'utility CLI hypershift o tramite Custom Resources (CRD), che si integra perfettamente con approcci GitOps come ArgoCD.

Ecco un esempio di come appare la creazione di un cluster in AWS tramite CLI:

hypershift create cluster aws \
  --name dev-cluster \
  --node-pool-replicas 2 \
  --base-domain example.com \
  --pull-secret /path/to/pull-secret.json \
  --aws-creds /path/to/aws-credentials

Dietro le quinte, il comando creerà le CRD HostedCluster e NodePool. HyperShift avvierà i pod del control plane nel cluster di gestione, eseguirà il provisioning di un paio di istanze EC2 in AWS per i nodi worker e li collegherà insieme.

Sotto il cofano e sfumature

Il progetto è scritto in Go ed è sviluppato attivamente dal team OpenShift. Il repository ha già oltre 500 fork, anche se le stelle sono ancora relativamente poche — poco più di cinquecento. Questo perché HyperShift è stato per molto tempo una tecnologia interna Red Hat per il servizio ROSA (Red Hat OpenShift Service on AWS), e ora sta gradualmente diventando lo standard per le installazioni on-premises e multi-cloud.

Le caratteristiche importanti includono:

• Isolamento completo tra il cluster di gestione e i carichi di lavoro dei client.
• Supporto per la distribuzione di nodi worker su provider diversi: AWS, Azure, KubeVirt, Bare Metal.
• Vettore di aggiornamento unificato. L'aggiornamento della versione di OpenShift per il control plane può essere fatto indipendentemente cambiando la versione nella CRD senza riavviare immediatamente tutti i nodi worker.

Ci sono delle insidie? Certo. Il cluster di gestione diventa un singolo punto di guasto per i control plane di tutti i cluster client. Se il cluster di gestione va giù, i servizi in esecuzione sui nodi worker continueranno a funzionare, ma la gestibilità andrà persa fino al ripristino dell'infrastruttura. Pertanto, l'affidabilità del cluster di gestione e i backup di etcd hanno requisiti elevati.

Chi dovrebbe dargli un'occhiata

HyperShift non è necessario se hai un singolo cluster monolitico per l'intera azienda. Ma diventa una salvezza se:

• Stai costruendo una piattaforma per team interni e vuoi fornire cluster isolati on demand.
• Stai vendendo una soluzione SaaS basata su Kubernetes con separazione fisica dei client.
• Sei stanco di pagare per nodi master inattivi nei cloud pubblici.

Puoi provare il progetto usando la documentazione ufficiale su hypershift.pages.dev. Avrai bisogno di un cluster OpenShift 4.x esistente come cluster di gestione e accesso ad AWS o VM locali per la creazione dei worker.