Condividi tramite

Considerazioni sulla gestione delle operazioni per servizio Azure Kubernetes

  • Articolo

Kubernetes è una tecnologia relativamente nuova, in rapida evoluzione con un ecosistema straordinario. Di conseguenza, può essere difficile gestirlo e proteggerlo.

Baseline delle operazioni per il servizio Azure Kubernetes

È possibile lavorare verso l'eccellenza operativa e il successo dei clienti progettando correttamente la soluzione servizio Azure Kubernetes (servizio Azure Kubernetes) tenendo presente la gestione e il monitoraggio.

Considerazioni relative alla progettazione

Prendere in considerazione i fattori seguenti:

  • Tenere presenti i limiti del servizio Azure Kubernetes. Usare più istanze del servizio Azure Kubernetes per aumentare le risorse oltre tali limiti.
  • Considerare le soluzioni per isolare i carichi di lavoro dal punto di vista logico all'interno di un cluster e dal punto di vista fisico in cluster separati.
  • Considerare le soluzioni per controllare l'utilizzo delle risorse da parte dei carichi di lavoro.
  • Considerare le soluzioni per consentire a Kubernetes di conoscere lo stato di integrità dei carichi di lavoro.
  • Tenere presente le varie dimensioni delle macchine virtuali e l'impatto dell'uso di uno o dell'altro. Le macchine virtuali di dimensioni maggiori possono gestire un carico maggiore. Le macchine virtuali di dimensioni minori possono essere sostituite più facilmente con altre quando non sono disponibili a causa di interventi di manutenzione pianificata e non pianificata. Tenere inoltre presente i pool di nodi e le macchine virtuali in un set di scalabilità, consentendo alle macchine virtuali di dimensioni diverse nello stesso cluster. Le macchine virtuali di dimensioni maggiori sono più ottimali perché il servizio Azure Kubernetes riserva una percentuale inferiore delle risorse, rendendo disponibili più risorse per i carichi di lavoro.
  • Considerare le soluzioni per monitorare e registrare il servizio Azure Kubernetes. Kubernetes è costituito da vari componenti e il monitoraggio e la registrazione devono fornire informazioni dettagliate sull'integrità, le tendenze e i potenziali problemi.
  • Basandosi sul monitoraggio e la registrazione, è possibile generare molti eventi da Kubernetes o dalle applicazioni in esecuzione. Gli avvisi consentono di distinguere tra le voci di log con finalità cronologiche e quelle che richiedono un intervento immediato.
  • Tenere presenti gli aggiornamenti da eseguire. A livello di Kubernetes sono disponibili versioni principali, secondarie e patch. Il cliente deve applicare questi aggiornamenti per rimanere supportati in base ai criteri in Kubernetes upstream. A livello di host del ruolo di lavoro, le patch del kernel del sistema operativo potrebbero richiedere un riavvio, che il cliente deve eseguire e eseguire l'aggiornamento alle nuove versioni del sistema operativo. Oltre ad aggiornare manualmente un cluster, è possibile impostare un canale di aggiornamento automatico nel cluster.
  • Tenere presente le limitazioni delle risorse del cluster e i singoli carichi di lavoro.
  • Tenere presenti le differenze tra scalabilità automatica orizzontale dei pod e scalabilità automatica del cluster
  • Valutare la possibilità di proteggere il traffico tra pod usando criteri di rete e il plug-in Criteri di Azure
  • Per risolvere i problemi relativi all'applicazione e ai servizi in esecuzione nel servizio Azure Kubernetes, potrebbe essere necessario visualizzare i log generati dai componenti del piano di controllo. È possibile abilitare i log delle risorse per il servizio Azure Kubernetes perché la registrazione non è abilitata per impostazione predefinita.

Consigli

  • Conoscere i limiti del servizio Azure Kubernetes:

  • Usare l'isolamento logico a livello di spazio dei nomi per separare applicazioni, team, ambienti e business unit. Isolamento cluster e multi-tenancy. Inoltre, i pool di nodi possono essere utili per i nodi con specifiche di nodo diverse e la manutenzione, ad esempio Gli aggiornamenti di Kubernetes comportano l'aggiornamento di più pool di nodi

  • Pianificare e applicare quote di risorse a livello di spazio dei nomi. Se i pod non definiscono le richieste di risorse e i limiti, rifiutare la distribuzione usando criteri e così via. Questo non si applica ai pod kube-system perché non tutti i pod kube-system hanno richieste e limiti. Monitorare l'utilizzo delle risorse e modificare le quote in base alle esigenze. Funzionalità di base dell'utilità di pianificazione

  • Aggiungere probe di integrità ai pod. Assicurarsi che i pod contengano livenessProbeprobe di integrità , readinessProbee startupProbe del servizio Azure Kubernetes.

  • Usare dimensioni delle macchine virtuali sufficienti per contenere più istanze di contenitori, in modo da ottenere i vantaggi di una maggiore densità, ma non così grande che il cluster non possa gestire il carico di lavoro di un nodo con errori.

  • Usare una soluzione di monitoraggio. Le informazioni dettagliate sui contenitori di Monitoraggio di Azure sono configurate per impostazione predefinita e consentono di accedere facilmente a molte informazioni dettagliate. È possibile usare l'integrazione di Prometheus se si vuole approfondire la questione o sperimentare l'uso di Prometheus. Se si vuole anche eseguire un'applicazione di monitoraggio nel servizio Azure Kubernetes, è consigliabile usare anche Monitoraggio di Azure per monitorare l'applicazione.

  • Usare gli avvisi delle metriche delle metriche dei contenitori di Monitoraggio di Azure per fornire notifiche quando sono necessarie azioni dirette.

  • Usare la funzionalità di ridimensionamento automatico del pool di nodi unitamente alla scalabilità automatica orizzontale dei pod per soddisfare le richieste dell'applicazione e per ridurre i carichi delle ore di punta.

  • Usare Azure Advisor per ottenere raccomandazioni sulle procedure consigliate sui costi, la sicurezza, l'affidabilità, l'eccellenza operativa e le prestazioni. Usare anche Microsoft Defender per il cloud per prevenire e rilevare minacce come le vulnerabilità delle immagini.

  • Usare Kubernetes abilitato per Azure Arc per gestire cluster Kubernetes non del servizio Azure Kubernetes usando Criteri di Azure, Defender per il cloud, GitOps e così via.

  • Usare richieste e limiti del pod per gestire le risorse di calcolo in un cluster del servizio Azure Kubernetes. Le richieste e i limiti dei pod informano l'utilità di pianificazione kubernetes sulle risorse di calcolo da assegnare a un pod.

Continuità aziendale/ripristino di emergenza per proteggere e ripristinare il servizio Azure Kubernetes

L'organizzazione deve progettare funzionalità a livello di piattaforma del servizio Azure Kubernetes per soddisfare i requisiti specifici. Questi servizi dell'applicazione hanno requisiti correlati all'obiettivo del tempo di ripristino (RTO) e all'obiettivo del punto di ripristino (RPO). Ci sono diverse considerazioni di cui tenere conto per il ripristino di emergenza del servizio Azure Kubernetes. Il primo passaggio consiste nel definire un contratto di servizio per l'infrastruttura e l'applicazione. Informazioni sul contratto di servizio per il servizio Azure Kubernetes. Per informazioni sul calcolo del tempo di attività mensile, vedere la sezione Dettagli del contratto di servizio.

Considerazioni relative alla progettazione

Prendere in considerazione i fattori seguenti:

  • Il cluster del servizio Azure Kubernetes deve usare più nodi in un pool di nodi per fornire il livello minimo di disponibilità per l'applicazione.

  • Impostare limiti e richieste di pod. L'impostazione di questi limiti consente a Kubernetes di:

    • Assegnare in modo efficiente le risorse di CPU e memoria ai pod.
    • Avere una maggiore densità di contenitori in un nodo.

    I limiti possono anche aumentare l'affidabilità con costi ridotti grazie a un migliore utilizzo dell'hardware.

  • Idoneità del servizio Azure Kubernetes per zone di disponibilità o set di disponibilità.

    • Scegliere un'area che supporta la funzionalità Zone di disponibilità.
    • Le zone di disponibilità possono essere impostate solo quando viene creato il pool di nodi e non possono essere modificate in un secondo momento. Il supporto per più zone si applica solo ai pool di nodi.
    • Per ottenere un vantaggio completo dalle zone, anche tutte le dipendenze del servizio devono supportare le zone. Se un servizio dipendente non supporta le zone, un errore di zona potrebbe causare un errore del servizio.
    • Eseguire più cluster del servizio Azure Kubernetes in aree abbinate diverse per una maggiore disponibilità oltre a quanto zone di disponibilità possibile ottenere. Se una risorsa di Azure supporta la ridondanza geografica, specificare la posizione in cui il servizio ridondante ha l'area secondaria.

  • È necessario conoscere le linee guida per il ripristino di emergenza nel servizio Azure Kubernetes. Valutare quindi se sono applicabili ai cluster del servizio Azure Kubernetes utilizzati per Azure Dev Spaces.

  • Creare in modo coerente backup per applicazioni e dati.

    • Un servizio senza stato può essere replicato in modo efficiente.
    • Se è necessario archiviare lo stato nel cluster, eseguire spesso il backup dei dati nell'area abbinata. Una considerazione è che l'archiviazione corretta dello stato nel cluster può essere complicata.

  • Aggiornamento e manutenzione dei cluster.

    • Mantenere sempre aggiornato il cluster.
    • Tenere presente il processo di versione e deprecazione.
    • Pianificare gli aggiornamenti e la manutenzione.

  • Connettività di rete in caso di failover.

    • Scegliere un router per il traffico in grado di distribuire il traffico tra zone o aree, a seconda delle esigenze. Questa architettura distribuisce Azure Load Balancer perché può distribuire il traffico non Web tra le zone.
    • Se è necessario distribuire il traffico tra aree, è consigliabile usare il servizio Frontdoor di Azure.

  • Failover pianificati e non pianificati.

    • Quando si configura un servizio di Azure, scegliere le funzionalità che supportano il ripristino di emergenza. Ad esempio, questa architettura abilita Registro Azure Container per la replica geografica. È comunque possibile eseguire il pull delle immagini dall'area replicata in caso di arresto di un'area.

  • Gestire le funzionalità DevOps di progettazione per raggiungere gli obiettivi a livello di servizio.

  • Determinare se è necessario un contratto di servizio con copertura finanziaria per l'endpoint del server delle API Kubernetes.

Suggerimenti per la progettazione

Di seguito sono riportate le procedure consigliate per la progettazione:

  • Usare tre nodi per il pool di nodi di sistema. Per il pool di nodi utente, iniziare con almeno due nodi. Se è necessaria una disponibilità più elevata, configurare più nodi.

  • Isolare l'applicazione dai servizi di sistema inserendola in un pool di nodi separato. In questo modo, i servizi Kubernetes vengono eseguiti in nodi dedicati e non sono in competizione con altri servizi. Usare tag, etichette e taint per identificare il pool di nodi per pianificare il carico di lavoro.

  • La manutenzione regolare del cluster, ad esempio l'esecuzione tempestiva degli aggiornamenti, è fondamentale per l'affidabilità. Tenere presente la finestra di supporto per le versioni di Kubernetes nel servizio Azure Kubernetes e pianificare gli aggiornamenti. È inoltre consigliabile monitorare l'integrità dei pod tramite probe.

  • Quando possibile, rimuovere lo stato del servizio dai contenitori interni. In alternativa, usare una soluzione PaaS (piattaforma distribuita come servizio) che supporta la replica in più aree.

  • Garantire le risorse dei pod. È consigliabile che le distribuzioni specifichino i requisiti per le risorse dei pod. L'utilità di pianificazione può quindi pianificare in modo appropriato il pod. Affidabilità depreca quando i pod non sono pianificati.

  • Configurare più repliche nella distribuzione per gestire le interruzioni, ad esempio gli errori hardware. Per eventi pianificati come aggiornamenti e aggiornamenti, un budget di interruzione può garantire che il numero necessario di repliche pod esista per gestire il carico previsto dell'applicazione.

  • Le applicazioni possono usare Archiviazione di Azure per i propri dati. Poiché le applicazioni sono distribuite in più cluster del servizio Azure Kubernetes in aree diverse, è necessario mantenere sincronizzata l'archiviazione. Questi sono due modi comuni per replicare l'archiviazione:

    • Replica asincrona basata sull'infrastruttura
    • Replica asincrona basata sull'applicazione

  • Stimare i limiti dei pod. Testare e stabilire una baseline. Iniziare con valori uguali per le richieste e i limiti. Quindi, regolare gradualmente tali valori fino a quando non viene stabilita una soglia che può causare instabilità nel cluster. I limiti dei pod possono essere specificati nei manifesti della distribuzione.

    Le funzionalità incorporate offrono una soluzione alla complessa attività di gestione degli errori e delle interruzioni nell'architettura del servizio. Queste configurazioni consentono di semplificare l'automazione della progettazione e della distribuzione. Quando un'organizzazione ha definito uno standard per il contratto di servizio e gli obiettivi RTO e RPO, può usare i servizi predefiniti in Kubernetes e Azure per raggiungere gli obiettivi aziendali.

  • Impostare i budget per l’interruzione dei pod. Questa impostazione controlla il numero di repliche in una distribuzione che è possibile disattivare durante un evento di aggiornamento.

  • Applicare quote di risorse agli spazi dei nomi del servizio. La quota di risorse in uno spazio dei nomi garantisce che le richieste e i limiti dei pod siano impostati correttamente in una distribuzione.

    • L'impostazione delle quote di risorse a livello di cluster può causare problemi durante la distribuzione dei servizi partner che non hanno richieste e limiti appropriati.

  • Archiviare le immagini del contenitore in Registro Azure Container ed eseguire la replica geografica del registro in ogni area del servizio Azure Kubernetes.

  • Usare il contratto di servizio tempo di attività per abilitare un contratto di servizio con supporto finanziario e superiore per tutti i cluster che ospitano carichi di lavoro di produzione. Il contratto di servizio relativo al tempo di attività garantisce il 99,95% di disponibilità dell'endpoint del server dell'API Kubernetes per i cluster che usano zone di disponibilità e il 99,9% della disponibilità per i cluster che non usano zone di disponibilità. I nodi, i pool di nodi e altre risorse sono coperti dal contratto di servizio. Il servizio Azure Kubernetes offre un livello gratuito con un obiettivo del livello di servizio (SLO) del 99,5% per i componenti del piano di controllo. I cluster senza il contratto di servizio tempo di attività abilitato non devono essere usati per i carichi di lavoro di produzione.

  • Usare più aree e posizioni di peering per la connettività di Azure ExpressRoute.

    Se si verifica un'interruzione che interessa un'area di Azure o una posizione del provider di peering, un'architettura di rete ibrida ridondante può garantire una connettività cross-premise senza interruzioni.

  • Interconnettere le aree con il peering di reti virtuali globale. Se i cluster devono comunicare tra loro, la connessione tra entrambe le reti virtuali può essere ottenuta tramite il peering di reti virtuali. Questa tecnologia interconnette le reti virtuali tra loro, fornendo una larghezza di banda elevata attraverso la rete backbone di Microsoft, anche in aree geografiche diverse.

  • Usando il protocollo anycast basato su split TCP, Frontdoor di Azure garantisce che gli utenti finali possano connettersi immediatamente al punto di presenza Frontdoor più vicino. Altre funzionalità di Frontdoor di Azure includono:

    • Terminazione TLS
    • Dominio personalizzato
    • Web application firewall
    • Riscrittura URL
    • Affinità di sessione

    Esaminare le esigenze di traffico dell'applicazione per determinare la soluzione più adatta.