Condividi tramite

Regolare le soluzioni di piattaforma applicativa moderna

  • Articolo

Cloud Adoption Framework fornisce una metodologia per migliorare in modo sistematico e incrementale la governance del portfolio cloud. Questo articolo illustra come estendere l'approccio di governance ai cluster Kubernetes distribuiti in Azure o in altri cloud pubblici o privati.

Base iniziale per la governance

La governance inizia con una base di governance iniziale spesso definita MVP di governance. Questa base distribuisce i prodotti Azure di base necessari per garantire la governance nell'ambiente cloud.

La base di governance iniziale è incentrata sui seguenti aspetti della governance:

  • Connettività e rete ibrida di base.
  • Controllo degli accessi in base al ruolo di Azure per il controllo delle identità e degli accessi.
  • Standard di denominazione e assegnazione di tag per un'identificazione coerente delle risorse.
  • Organizzazione delle risorse usando gruppi di risorse, sottoscrizioni e gruppi di gestione.
  • Usare Criteri di Azure per applicare i criteri di governance.

Queste funzionalità della base di governance iniziale possono essere usate per gestire le istanze di soluzioni moderne della piattaforma applicativa. Prima di tutto, è necessario aggiungere alcuni componenti alla base iniziale per applicare Criteri di Azure ai contenitori. Dopo la configurazione, è possibile usare Criteri di Azure e la base di governance iniziale per eseguire la governance dei seguenti tipi di contenitori:

Espandere le discipline di governance

La base di governance iniziale può essere usata per espandere diverse discipline di governance per garantire approcci di distribuzione coerenti e stabili in tutte le istanze di Kubernetes.

La governance dei cluster Kubernetes può essere esaminata in base a cinque prospettive diverse.

Governance delle risorse di Azure

La prima è la prospettiva delle risorse di Azure. Assicurarsi che tutti i cluster rispettino i requisiti dell'organizzazione. Sono inclusi concetti come la topologia di rete, il cluster privato, i ruoli Controllo degli accessi in base al ruolo di Azure per i team SRE, le impostazioni di diagnostica, la disponibilità dell'area, le considerazioni sul pool di nodi, la governance di Registro Azure Container, le opzioni di Azure Load Balancer, i componenti aggiuntivi del servizio Azure Kubernetes e così via. Questa governance garantisce coerenza nell’"aspetto" e nella "topologia" dei cluster nelle organizzazioni. Questo dovrebbe estendersi anche al bootstrap post-distribuzione dei cluster, ad esempio quali agenti di sicurezza devono essere installati e come devono essere configurati.

È difficile eseguire la governance dei cluster Snowflake in qualsiasi capacità centrale. Ridurre al minimo le discrepanze tra i cluster in modo che i criteri possano essere applicati in modo uniforme e i cluster anomali siano evitati e rilevabili. Possono essere incluse anche le tecnologie usate per distribuire i cluster, ad esempio ARM, Bicep o Terraform.

Criteri di Azure applicati a livello di gruppo di gestione/sottoscrizione possono contribuire ad attuare molte di queste considerazioni, ma non tutte.

Governance dei carichi di lavoro Kubernetes

Poiché Kubernetes è di per sé una piattaforma, la seconda è la governance di quanto accade all'interno di un cluster. Sono inclusi elementi come le linee guida per gli spazi dei nomi, i criteri di rete, il controllo degli accessi in base al ruolo di Kubernetes, i limiti e le quote. Si tratta di governance applicata ai carichi di lavoro, meno al cluster. Ogni carico di lavoro sarà univoco, perché tutti risolvono problemi aziendali diversi e verranno implementati in vari modi con varie tecnologie. Potrebbero non esserci molte procedure di governance adatte a tutti gli scopi, ma è consigliabile prendere in considerazione la governance per la creazione/utilizzo di artefatti OCI, i requisiti della supply chain, l'utilizzo del registro contenitori pubblico, il processo di messa in quarantena delle immagini, la governance della pipeline di distribuzione.

È consigliabile anche standardizzare gli strumenti e i modelli comuni, se possibile. Inserire raccomandazioni su tecnologie come Helm, mesh di servizi, controller in ingresso, operatori GitOps, volumi persistenti e così via. È inclusa anche la governance per l'uso dell'identità gestita di pod e l'acquisizione di segreti da Key Vault.

Creare forti aspettative sull'accesso ai dati di telemetria, per garantire ai proprietari dei carichi di lavoro l'accesso appropriato alle metriche e ai dati necessari per migliorare il prodotto, garantendo al tempo stesso agli operatori del cluster l'accesso alla telemetria del sistema per migliorare l'offerta di servizio. I dati spesso devono essere correlati tra i due, assicurandosi che i criteri di governance siano applicati per garantire l'accesso appropriato quando necessario.

Criteri di Azure per il servizio Azure Kubernetes applicati a livello di cluster possono contribuire ad attuare alcune di queste considerazioni, ma non tutte.

Ruoli degli operatori di cluster (DevOps, SRE)

La terza è la governance dei ruoli degli operatori di cluster. Come interagiscono i team SRE con i cluster? Qual è la relazione tra questo team e il team responsabile dei carichi di lavoro? Coincidono? Gli operatori di cluster devono avere un playbook chiaramente definito per le attività di valutazione dei cluster, ad esempio il modo in cui accedono ai cluster, da dove accedono ai cluster, le autorizzazioni di cui dispongono sui cluster e quando vengono assegnate tali autorizzazioni. Assicurarsi che vengano fatte eventuali distinzioni nella documentazione, nei criteri e nei materiali di training relativi alla governance tra l'operatore dei carichi di lavoro e l'operatore di cluster in questo contesto. A seconda dell'organizzazione, potrebbero coincidere.

Cluster per carico di lavoro o molti carichi di lavoro per cluster

La quarta è la governance della multi-tenancy. In poche parole, i cluster devono contenere un "raggruppamento simile" di applicazioni tutte di proprietà, per definizione, dello stesso team dei carichi di lavoro e rappresentare un set singolo di componenti correlati dei carichi di lavoro? Oppure i cluster devono essere, a livello di progettazione, multi-tenant per natura con più carichi di lavoro e proprietari di carichi di lavoro diversi, eseguiti e gestiti come un'offerta di servizio gestito all'interno dell'organizzazione? La strategia di governance è molto diversa per ciascun caso e, di conseguenza, è necessario controllare che la strategia scelta venga applicata. Se è necessario supportare entrambi i modelli, assicurarsi che il piano di governance definisca chiaramente quali criteri si applicano a quali tipi di cluster.

Questa scelta dovrebbe essere stata effettuata durante la fase di strategia perché ha un impatto significativo sul personale, sul budget e sull'innovazione.

Attività di aggiornamento

La quinta riguarda le operazioni, come l'aggiornamento delle immagini dei nodi (applicazione di patch) e il controllo delle versioni di Kubernetes. Chi è responsabile degli aggiornamenti delle immagini dei nodi, del monitoraggio delle patch applicate, del controllo e della definizione dei piani di correzione per le esposizioni e le vulnerabilità comuni di Kubernetes e del servizio Azure Kubernetes? I team dei carichi di lavoro devono essere coinvolti nel processo di convalida del funzionamento della soluzione negli aggiornamenti dei cluster e se i cluster non sono aggiornati non rientreranno nel supporto di Azure. La presenza di una governance solida per le attività di aggiornamento è fondamentale nel servizio Azure Kubernetes e lo è ancora di più nella maggior parte delle altre piattaforme in Azure. Ciò richiederà una collaborazione molto stretta con i team delle applicazioni e un tempo dedicato, almeno mensile, alla convalida dei carichi di lavoro per garantire che i cluster siano sempre aggiornati. Assicurarsi che tutti i team con una dipendenza da Kubernetes comprendano i requisiti e i costi di questo impegno costante, che durerà fino a quando sono nella piattaforma.

Baseline di sicurezza

È possibile aggiungere le seguenti procedure consigliate alla baseline di sicurezza, per garantire la sicurezza dei cluster del servizio Azure Kubernetes:

Identità

Esistono molte procedure consigliate che è possibile applicare alla baseline di identità per garantire una gestione coerente delle identità e degli accessi nei cluster Kubernetes:

Passaggio successivo: gestire soluzioni moderne della piattaforma applicativa

I seguenti articoli forniscono linee guida per punti specifici del percorso di adozione del cloud per consentire la riuscita dello scenario di adozione del cloud.