Servizi Kubernetes gestiti dai cloud provider pubblici: l’offerta include l’implementazione di piani di controllo resilienti e altamente disponibili. Questi servizi si integrano con le funzionalità native dei fornitori cloud, nonché con le implementazioni Kubernetes locali. Ma attenzione, segnalano gli esperti: questi servizi non sempre si integrano bene e facilmente con le offerte di altri fornitori di servizi cloud.
Servizi Kubernetes gestiti: quali sono i più affidabili
Quando ci si impegna con un singolo provider cloud, associando tutti i processi di orchestrazione della distribuzione sulla piattaforma del provider è meglio rivolgersi a fornitori affidabili come Amazon Kubernetes Service (EKS), Azure Kubernetes Service (AKS) e Google Kubernetes Engine (GKE). Nel caso su un’applicazione siano previste diverse eccezioni, infatti, meno è probabile che un singolo servizio Kubernetes gestito possa funzionare nel modo adatto.
Le organizzazioni che scelgono di lavorare con più fornitori di cloud devono essere consapevoli che l’integrazione delle attività di orchestrazione dei container in una distribuzione multi-cloud sia ostica.
Per determinare se un servizio Kubernetes gestito è adatto alla distribuzione cloud, bisogna seguire tre passaggi preliminari:
#1 Mappare la distribuzione
Il primo passo in qualsiasi strategia di orchestrazione dei container è mappare lo spazio di hosting, ovvero il set completo di risorse utilizzate per ospitare le applicazioni, il che potrebbe includere un data center locale e più provider di cloud pubblici. Per ogni applicazione, è necessario determinare l’ambito della sua distribuzione, incluso dove verranno ospitati tutti i suoi componenti.
Vulnerabilità di sicurezza del container e come evitarle
I candidati più forti per i servizi gestiti di Kubernetes avranno una mappa di orchestrazione che mostra due cose importanti:
- Avere in programma di utilizzare un solo provider cloud ed essere pronti a rielaborare la strategia operativa nel caso il provider venga cambiato.
- Avere tutte le applicazioni con componenti ospitati nel cloud e nel data center che si comportano con un failover minimo, nullo oppure andando ben oltre quel limite.
I candidati più deboli rispetto all’offerta di servizi gestiti di Kubernetes sono invece quelli che intendono utilizzare diversi provider di cloud pubblici utilizzandoli per spostare rapidamente le applicazioni tra l’uno e l’altro. Le aziende che prevedono di utilizzare tutte le risorse di hosting, incluso un data center locale come, ad esempio, un grande pool di risorse da cui possono attingere i componenti dell’applicazione non sono adatte a questi servizi gestiti.
#2 Determinare gli obiettivi multi-cloud
La maggior parte delle aziende sta nel mezzo di questi due estremi. In questo caso, il passaggio successivo è definire una strategia multi cloud. È importante determinare se si disponga di uno di questi due modelli:
- modello multi-cloud statico, in cui si posizionano i componenti dell’applicazione in gruppi di hosting di provider cloud fissi
- modello multi-cloud dinamico, in cui i componenti si spostano liberamente tra le diverse piattaforme di provider cloud
Con il modello statico, l’uso di un servizio Kubernetes gestito in ciascuno dei propri cloud pubblici è probabilmente giustificato, ma solo se il provider cloud integra strettamente Kubernetes con uno strumento, come Istio, che può distribuire lavoro e gestire processi distribuiti. In questo caso, l’uso degli strumenti di ciascun fornitore di servizi cloud migliorerebbe probabilmente le funzionalità di hosting dei container.
Le aziende che hanno adottato un modello multi-cloud dinamico, invece, molto probabilmente non trarranno vantaggio dai servizi Kubernetes gestiti dai provider cloud. Per queste organizzazioni l’esigenza è di poter contare su un approccio di orchestrazione globale che attraversi liberamente i confini della nuvola. Queste aziende dovrebbero cercare di implementare la propria piattaforma di orchestrazione Kubernetes con strumenti cloud-agnostici.
#3 Scegli come vuoi impegnarti
I servizi Kubernetes gestiti in cloud non si integrano con le funzionalità native di altri cloud provider. Ciò significa che, se ci si impegni con questi servizi in un modello multi-cloud, nella maggior parte dei casi ci si dovrà anche occupare di orchestrare separatamente ciascuno dei cloud pubblici.
Se si seleziona una distribuzione software di Kubernetes, come Red Hat OpenShift, bisognerà distribuire sia le proprie applicazioni che Kubernetes in ciascuno dei tuoi domini cloud, risolvendo la disponibilità degli elementi Kubernetes e la loro connettività sul piano di controllo.
Per rispondere alle esigenze aziendali di semplificare l’implementazione e l’amministrazione di Kubernetes in ambito enterprise è stato creato Rancher, piattaforma open source, indirizzata a liberare gli utenti da situazioni di lock-in, e progettata per gestire in modo completo a livello end-to-end, dal datacenter, al cloud, alla rete edge, molteplici cluster Kubernetes certificati. Creato da Rancher Labs, società fondata nel 2014 e recentemente acquisita da SUSE.
Un framework multi cloud comune per Kubernetes è Stackpoint.io e supporta i tre principali provider di cloud pubblico (AWS, Azure e Google) nonché i provider locali. Con NetApp Kubernetes Service (ex Stackpoint.io prima dell’acquisizoone di NetApp), le aziende possono creare un piano di controllo Kubernetes universale e multi-cloud in grado di unificare la distribuzione.
È importante anche considerare l’impegno del fornitore di cloud rispetto alla gestione di container, a partire dalla strategia per seguita per far evolvere gli ecosistemi di Kubernetes. Gli utenti di cloud ibrido hanno bisogno di uno strumento federativo per sovrintendere a Kubernetes nel cloud e nel data center. A farlo in questo momento sono principalmente i giganti del data center, tra cui Red Hat, VMware e IBM. I provider di cloud stanno ora cercando di offrire servizi che fondono Kubernetes gestiti e cloud ibrido: Google Anthos ne è un esempio. Probabilmente Microsoft lo affronterà nella sua piattaforma Azure tramite Azure Arc, sebbene ciò estenda il piano di controllo di Azure in più di una subduzione rispetto alla federazione. AWS, nel frattempo, continua a favorire un approccio specifico per il cloud.
