Condividi tramite

Automazione della piattaforma e DevOps per il servizio Azure Kubernetes

  • Articolo

In quanto piattaforma nativa del cloud, Kubernetes richiede un approccio nativo del cloud alla distribuzione e alle operazioni. Azure e Kubernetes sono piattaforme aperte ed estendibili con API complete e ben architettate, che offrono opportunità e possibilità di automatizzare in modo completo. Pianificare un approccio DevOps e altamente automatizzato basandosi sulle procedure consigliate generali e per l'automazione di DevOps.

Considerazioni relative alla progettazione

Ecco alcune considerazioni relative alla progettazione per l'automazione e l'automazione della piattaforma del servizio Azure Kubernetes e di DevOps:

  • Quando si stabilisce l'approccio da adottare per la progettazione e l'automazione, prendere in considerazione le limitazioni dei servizi di Azure e l'ambiente di integrazione continua e recapito continuo (CI/CD). Per un altro esempio, vedere le limitazioni per l'utilizzo di GitHub.

  • Quando si protegge e si protegge l'accesso agli ambienti di sviluppo, test, domande e risposte e produzione, prendere in considerazione le opzioni di sicurezza dal punto di vista CI/CD. Le distribuzioni sono automatiche, quindi eseguire il mapping del controllo di accesso di conseguenza.

  • Valutare la possibilità di usare prefissi e suffissi con convenzioni ben definite per identificare in modo univoco ogni risorsa distribuita. Queste convenzioni di denominazione evitano conflitti nella distribuzione di soluzioni una accanto all'altra e migliorano la velocità effettiva e l'agilità complessiva del team.

  • Inventariare i flussi di lavoro per supportare la progettazione, l'aggiornamento e la distribuzione della soluzione in regimi normali e DRP (Disaster Recovery Plan). Valutare la possibilità di eseguire il mapping delle pipeline in base a tali flussi di lavoro, allo scopo di incrementare familiarità e produttività.

    Ecco alcuni scenari e pipeline di esempio da considerare:

    • Distribuzione, applicazione di patch e aggiornamento dei cluster
    • Distribuzione e aggiornamento delle applicazioni
    • Distribuzione e gestione dei componenti aggiuntivi
    • Failover per il ripristino di emergenza
    • Distribuzioni blu-verde
    • Gestione di ambienti canary

  • È consigliabile usare una mesh di servizi per aggiungere altre funzionalità di sicurezza, crittografia e registro ai carichi di lavoro.

  • Valutare la possibilità di distribuire altre risorse, ad esempio sottoscrizioni, assegnazione di tag ed etichette, per supportare l'esperienza di DevOps tramite il rilevamento e l'analisi delle distribuzioni e degli artefatti correlati.

  • Considerare l'impatto del cambio di paradigma associato all'analogia Pets vs Cattle. Prevedere che i pod e altri aspetti di Kubernetes siano temporanei e allineare l'infrastruttura di automazione e pipeline di conseguenza. Non fare affidamento su indirizzi IP o altre risorse per essere fissi o permanenti.

Suggerimenti per la progettazione

Ecco alcune raccomandazioni relative alla progettazione per l'automazione e l'automazione della piattaforma del servizio Azure Kubernetes e di DevOps:

  • Basarsi su pipeline o azioni per:

    • Ottimizzare le procedure applicate all'interno del team.
    • Rimuovere gran parte dell'onere di dover reinventare una soluzione già disponibile.
    • Offrire prevedibilità e dati analitici in termini di qualità e agilità complessive.

  • Distribuire in anticipo e frequentemente usando pipeline pianificate e basate su trigger. Le pipeline basate su trigger assicurano che le modifiche vengano convalidate correttamente, mentre le pipeline pianificate gestiscono il comportamento negli ambienti soggetti a modifiche.

  • Separare la distribuzione dell'infrastruttura dalla distribuzione delle applicazioni. L'infrastruttura di base è meno soggetta a variazioni rispetto alle applicazioni. Considerare ogni tipo di distribuzione come un flusso e una pipeline separati.

  • Usare opzioni native del cloud per la distribuzione. Usare l'infrastruttura distribuita come codice per distribuire l'infrastruttura, incluso il piano di controllo, e usare Helm e il modello Operatore in Kubernetes per distribuire e gestire i componenti nativi di Kubernetes.

  • Usare GitOps per distribuire e gestire le applicazioni. GitOps usa il repository GIT come unico sistema SSOT (Single Source of Truth), evitando variazioni della configurazione e incrementando produttività e affidabilità durante i rollback e le routine correlate.

  • Usare identità gestite dai pod e il provider di Azure Key Vault per il driver CSI dell'archivio segreti per proteggere segreti, certificati e stringhe di connessione.

  • Cercare di ottimizzare la concorrenza della distribuzione evitando impostazioni e elementi di configurazione hardcoded.

  • Fare affidamento su convenzioni note tra le distribuzioni correlate all'infrastruttura e alle applicazioni. Usare controller di ammissione combinati con il componente aggiuntivo Criteri di Azure per Kubernetes per convalidare e applicare le convenzioni tra gli altri criteri definiti.

  • Adottare lo spostamento a sinistra in modo coerente con gli elementi seguenti:

    • Sicurezza, aggiungendo strumenti di analisi delle vulnerabilità come l'analisi dei contenitori nelle prime fasi della pipeline.
    • Criteri, usando i criteri distribuiti come codice e applicando i criteri in modo nativo del cloud tramite controller di ammissione.

  • Considerare ogni guasto, errore o interruzione come un'opportunità per automatizzare e migliorare la qualità complessiva della soluzione. Integrare questo approccio nel framework SRE (Site Reliability Engineering) e di spostamento a sinistra.