Revisione di Azure Well-Architected Framework - servizio Azure Kubernetes (servizio Azure Kubernetes)

  • Articolo

Questo articolo fornisce procedure consigliate per l'architettura per servizio Azure Kubernetes (servizio Azure Kubernetes). Le linee guida si basano sui cinque pilastri dell'eccellenza dell'architettura:

  • Affidabilità
  • Sicurezza
  • Ottimizzazione dei costi
  • Eccellenza operativa
  • Efficienza delle prestazioni

Si supponga di comprendere i principi di progettazione del sistema, avere una conoscenza funzionante di servizio Azure Kubernetes e sono ben esperti con le sue caratteristiche. Per altre informazioni, vedere servizio Azure Kubernetes.

Prerequisiti

Comprendere i pilastri di Well-Architected Framework può contribuire a produrre un'architettura cloud di alta qualità, stabile ed efficiente. È consigliabile esaminare il carico di lavoro usando la valutazione di revisione di Azure Well-Architected Framework .

Per il contesto, valutare la possibilità di esaminare un'architettura di riferimento che rifletta queste considerazioni nella progettazione. È consigliabile iniziare con l'architettura di base per un cluster servizio Azure Kubernetes (AKS) e un'architettura di microservizi in servizio Azure Kubernetes. Esaminare anche l'acceleratore di zona di destinazione del servizio Azure Kubernetes, che fornisce un approccio architetturale e un'implementazione di riferimento per preparare le sottoscrizioni di zona di destinazione per un cluster servizio Azure Kubernetes (AKS) scalabile.

Affidabilità

Nel cloud si riconosce che gli errori possono verificarsi. Invece di provare a evitare completamente gli errori, l'obiettivo deve essere quello di ridurre al minimo gli effetti di un singolo componente in errore. Usare le informazioni seguenti per ridurre al minimo le istanze non riuscite.

Quando si discute dell'affidabilità con servizio Azure Kubernetes, è importante distinguere tra affidabilità del cluster e affidabilità del carico di lavoro. L'affidabilità del cluster è una responsabilità condivisa tra l'amministratore del cluster e il provider di risorse, mentre l'affidabilità del carico di lavoro è il dominio di uno sviluppatore. servizio Azure Kubernetes ha considerazioni e raccomandazioni per entrambi questi ruoli.

Nell'elenco di controllo di progettazione e nell'elenco delle raccomandazioni riportate di seguito vengono effettuate chiamate per indicare se ogni scelta è applicabile all'architettura del cluster, all'architettura del carico di lavoro o a entrambi.

Elenco di controllo della progettazione

  • Architettura del cluster: Per i carichi di lavoro critici, usare le zone di disponibilità per i cluster del servizio Azure Kubernetes.
  • Architettura del cluster: Pianificare lo spazio indirizzi IP per garantire che il cluster possa essere ridimensionato in modo affidabile, inclusa la gestione del traffico di failover nelle topologie multi-cluster.
  • Architettura del cluster: Abilitare Informazioni dettagliate sui contenitori per monitorare il cluster e configurare gli avvisi per gli eventi con impatto sull'affidabilità.
  • Architettura del carico di lavoro: Assicurarsi che i carichi di lavoro siano compilati per supportare la scalabilità orizzontale e segnalare l'idoneità e l'integrità delle applicazioni.
  • Architetture di cluster e carichi di lavoro: Verificare che il carico di lavoro sia in esecuzione nei pool di nodi utente e scegliere lo SKU di dimensioni appropriato. Includere almeno due nodi per i pool di nodi utente e tre nodi per il pool di nodi di sistema.
  • Architettura del cluster: Usare il contratto di servizio tempo di attività del servizio Azure Kubernetes per soddisfare gli obiettivi di disponibilità per i carichi di lavoro di produzione.

Raccomandazioni per la configurazione del servizio Azure Kubernetes

Esplorare la tabella seguente di consigli per ottimizzare la configurazione del servizio Azure Kubernetes per l'affidabilità.

Recommendation Vantaggi
Architetture di cluster e carichi di lavoro: Controllare la pianificazione dei pod usando selettori di nodo e affinità. che consentono all'utilità di pianificazione di Kubernetes di isolare in modo logico i carichi di lavoro in base all'hardware nel nodo. A differenza delle tolleranze, i pod senza un selettore di nodo corrispondente possono essere pianificati in nodi etichettati, che consente di utilizzare le risorse inutilizzate nei nodi, ma assegna priorità ai pod che definiscono il selettore di nodo corrispondente. Usare l'affinità tra nodi per una maggiore flessibilità, poiché è possibile definire quali azioni devono essere eseguite se il pod non può essere abbinato ad alcun nodo.
Architettura del cluster: Assicurarsi di selezionare correttamente il plug-in di rete in base ai requisiti di rete e al dimensionamento del cluster. Il plug-in Azure CNI è necessario per scenari specifici, ad esempio pool di nodi basati su Windows, requisiti di rete specifici e criteri di rete Kubernetes. Per altre informazioni, vedere Kubenet e Azure CNI .
Architetture di cluster e carichi di lavoro: Usare il contratto di servizio tempo di attività del servizio Azure Kubernetes per i cluster di livello di produzione. Il contratto di servizio per il tempo di attività del servizio Azure Kubernetes garantisce:
- 99.95% di disponibilità dell'endpoint del server dell'API Kubernetes per i cluster AKS che usano zone di disponibilità di Azure
- 99.9% di disponibilità per i cluster che non usano zone di disponibilità di Azure.
Architetture di cluster e carichi di lavoro: Configurare il monitoraggio del cluster con Informazioni dettagliate sui contenitori. Informazioni dettagliate sui contenitori consentono di monitorare l'integrità e le prestazioni dei controller, dei nodi e dei contenitori disponibili in Kubernetes tramite l'API Metriche. L'integrazione con Prometheus consente la raccolta di metriche dell'applicazione e del carico di lavoro.
Architettura del cluster: Usare le zone di disponibilità per ottimizzare la resilienza all'interno di un'area di Azure distribuendo i nodi dell'agente del servizio Azure Kubernetes tra data center separati fisicamente. Distribuendo i pool di nodi tra più zone, i nodi in un pool di nodi continueranno a essere in esecuzione anche se un'altra zona è inattiva. Se esistono requisiti di colocalità, è possibile usare una normale distribuzione del servizio Azure Kubernetes basata su VMSS in una singola zona o in gruppi di posizionamento di prossimità per ridurre al minimo la latenza internode.
Architettura del cluster: Adottare una strategia di multiregione distribuendo cluster del servizio Azure Kubernetes distribuiti in aree di Azure diverse per ottimizzare la disponibilità e garantire la continuità aziendale. I carichi di lavoro con connessione Internet devono sfruttare Frontdoor di Azure o Gestione traffico di Azure per instradare il traffico a livello globale tra i cluster del servizio Azure Kubernetes.
Architetture di cluster e carichi di lavoro: Definire le richieste e i limiti delle risorse pod nei manifesti della distribuzione dell'applicazione e applicarli con Criteri di Azure. I limiti delle risorse di CPU e memoria del contenitore sono necessari per evitare l'esaurimento delle risorse nel cluster Kubernetes.
Architetture di cluster e carichi di lavoro: Mantenere il pool di nodi di sistema isolato dai carichi di lavoro dell'applicazione. I pool di nodi di sistema richiedono uno SKU di vm di almeno 2 vCPU e 4 GB di memoria, ma è consigliabile usare almeno 4 vCPU. Per informazioni dettagliate sui requisiti, vedere Pool di nodi utente e di sistema.
Architetture di cluster e carichi di lavoro: Separare le applicazioni in pool di nodi dedicati in base a requisiti specifici. Le applicazioni possono condividere la stessa configurazione e necessitano di macchine virtuali abilitate per GPU, CPU o macchine virtuali ottimizzate per la memoria o la possibilità di ridimensionare fino a zero. Evitare un numero elevato di pool di nodi per ridurre il sovraccarico di gestione aggiuntivo.
Architettura del cluster: Usare un gateway NAT per i cluster che eseguono carichi di lavoro che effettuano molte connessioni in uscita simultanee. Per evitare problemi di affidabilità con limitazioni di Azure Load Balancer con traffico in uscita simultaneo elevato, è invece disponibile un gateway NAT per supportare il traffico in uscita affidabile su larga scala.

Per altri suggerimenti, vedere Principi del pilastro dell'affidabilità.

Criteri di Azure

servizio Azure Kubernetes offre un'ampia gamma di criteri di Azure predefiniti che si applicano sia alla risorsa di Azure come criteri di Azure tipici che, usando il componente aggiuntivo Criteri di Azure per Kubernetes, anche all'interno del cluster. Esistono numerosi criteri e i criteri chiave correlati a questo pilastro sono riepilogati qui. Per una visualizzazione più dettagliata, vedere Definizioni di criteri predefinite per Kubernetes.

Architettura del cluster e del carico di lavoro

  • I cluster dispongono di probe di integrità di disponibilità o di disponibilità configurati per la specifica del pod.

Oltre alle definizioni di Criteri di Azure predefinite, è possibile creare criteri personalizzati sia per la risorsa servizio Azure Kubernetes che per il componente aggiuntivo Criteri di Azure per Kubernetes. In questo modo è possibile aggiungere ulteriori vincoli di affidabilità da applicare nell'architettura del cluster e del carico di lavoro.

Sicurezza

La sicurezza è uno degli aspetti essenziali di qualsiasi architettura. Per scoprire in che modo il servizio Azure Kubernetes può rafforzare la sicurezza del carico di lavoro dell'applicazione, è consigliabile esaminare i principi di progettazione della sicurezza. Se il cluster servizio Azure Kubernetes deve essere progettato per eseguire un carico di lavoro sensibile che soddisfi i requisiti normativi dello Standard di sicurezza dei dati del settore delle carte di pagamento (PCI-DSS 3.2.1), esaminare il cluster regolamentato del servizio Azure Kubernetes per PCI-DSS 3.2.1.

Per informazioni sul supporto e i requisiti di DoD Impact Level 5 (IL5) con il servizio Azure Kubernetes, vedere Azure per enti pubblici requisiti di isolamento IL5.

Quando si discute della sicurezza con servizio Azure Kubernetes, è importante distinguere tra sicurezza del cluster e sicurezza del carico di lavoro. La sicurezza del cluster è una responsabilità condivisa tra l'amministratore del cluster e il provider di risorse, mentre la sicurezza del carico di lavoro è il dominio di uno sviluppatore. servizio Azure Kubernetes ha considerazioni e raccomandazioni per entrambi questi ruoli.

Nell'elenco di controllo di progettazione e nell'elenco delle raccomandazioni riportate di seguito vengono effettuate chiamate per indicare se ogni scelta è applicabile all'architettura del cluster, all'architettura del carico di lavoro o a entrambi.

Elenco di controllo della progettazione

  • Architettura del cluster: Usare le identità gestite per evitare di gestire e ruotare i principi del servizio.
  • Architettura del cluster: Usare il controllo degli accessi in base al ruolo di Kubernetes con Microsoft Entra ID per l'accesso con privilegi minimi e ridurre al minimo la concessione dei privilegi di amministratore per proteggere la configurazione e l'accesso ai segreti.
  • Architettura del cluster: Usare Microsoft Defender per i contenitori con Azure Sentinel per rilevare e rispondere rapidamente alle minacce nel cluster e nei carichi di lavoro in esecuzione.
  • Architettura del cluster: Distribuire un cluster del servizio Azure Kubernetes privato per garantire che il traffico di gestione del cluster nel server API rimanga nella rete privata. In alternativa, usare l'elenco di indirizzi consentiti del server API per i cluster non privati.
  • Architettura del carico di lavoro: Usare un Web application firewall per proteggere il traffico HTTP(S).
  • Architettura del carico di lavoro: Verificare che la pipeline CI/CID sia avanzata con l'analisi compatibile con i contenitori.

Consigli

Esplorare la tabella seguente di consigli per ottimizzare la configurazione del servizio Azure Kubernetes per la sicurezza.

Recommendation Vantaggi
Architettura del cluster: Usare l'integrazione Microsoft Entra. L'uso di Microsoft Entra ID centralizza il componente di gestione delle identità. Qualsiasi modifica all'account utente o allo stato del gruppo viene aggiornata automaticamente nell'accesso al cluster servizio Azure Kubernetes. Gli sviluppatori e i proprietari delle applicazioni del cluster Kubernetes hanno bisogno di accedere a risorse diverse.
Architettura del cluster: Eseguire l'autenticazione con Microsoft Entra ID per Registro Azure Container. Il servizio Azure Kubernetes e Microsoft Entra ID abilita l'autenticazione con Registro Azure Container senza l'uso di imagePullSecrets segreti. Per altre informazioni, vedere Eseguire l'autenticazione con Registro Azure Container da servizio Azure Kubernetes.
Architettura del cluster: Proteggere il traffico di rete verso il server API con un cluster del servizio Azure Kubernetes privato. Per impostazione predefinita, il traffico di rete tra i pool di nodi e il server API viaggia la rete backbone Microsoft; usando un cluster privato, è possibile garantire che il traffico di rete verso il server API rimanga solo nella rete privata.
Architettura del cluster: Per i cluster del servizio Azure Kubernetes non privati, usare gli intervalli IP autorizzati del server API. Quando si usano cluster pubblici, è comunque possibile limitare il traffico che può raggiungere il server API dei cluster usando la funzionalità intervallo IP autorizzato. Includere origini come gli indirizzi IP pubblici degli agenti di compilazione della distribuzione, la gestione delle operazioni e il punto di uscita dei pool di nodi , ad esempio Firewall di Azure.
Architettura del cluster: Proteggere il server API con Microsoft Entra controllo degli accessi in base al ruolo. La protezione dell'accesso al server dell'API Kubernetes è una delle operazioni più importanti per proteggere il cluster. Integrare il controllo degli accessi in base al ruolo di Kubernetes con Microsoft Entra ID per controllare l'accesso al server API. Disabilitare gli account locali per applicare l'accesso a tutti i cluster usando identità basate su Microsoft Entra ID.
Architettura del cluster: Usare i criteri di rete di Azure o Calico. Proteggere e controllare il traffico di rete tra i pod in un cluster.
Architettura del cluster: Proteggere cluster e pod con Criteri di Azure. Criteri di Azure può essere utile per applicare l'applicazione e le misure di sicurezza su larga scala nei cluster in modo centralizzato e coerente. Può anche controllare quali funzioni vengono concesse ai pod e se sono in esecuzione componenti che non rispettano i criteri aziendali.
Architettura del cluster: Proteggere l'accesso ai contenitori alle risorse. Limitare l'accesso alle azioni che i contenitori possono eseguire. Concedere il minor numero possibile di autorizzazioni ed evitare l'uso dell'accesso radice o dell'escalation dei privilegi.
Architettura del carico di lavoro: Usare un Web application firewall per proteggere il traffico HTTP(S). Per analizzare il traffico in ingresso per individuare potenziali attacchi, usare un web application firewall, ad esempio Azure Web application firewall (WAF) in gateway applicazione di Azure o frontdoor di Azure.
Architettura del cluster: Controllare il traffico in uscita del cluster. Verificare che il traffico in uscita del cluster passi attraverso un punto di sicurezza di rete, ad esempio Firewall di Azure o un proxy HTTP.
Architettura del cluster: Usare il driver CSI ID dei carichi di lavoro di Microsoft Entra open source e l'archivio segreti con Azure Key Vault. Proteggere e ruotare segreti, certificati e stringhe di connessione in Azure Key Vault con crittografia avanzata. Fornisce un log di controllo di accesso e mantiene i segreti principali dalla pipeline di distribuzione.
Architettura del cluster: Usare Microsoft Defender per i contenitori. Monitorare e gestire la sicurezza dei cluster, dei contenitori e delle applicazioni.

Per altri suggerimenti, vedere Principi del pilastro della sicurezza.

Azure Advisor consente di garantire e migliorare il servizio Azure Kubernetes. Fornisce raccomandazioni su un sottoinsieme degli elementi elencati nella sezione dei criteri seguente, ad esempio i cluster senza controllo degli accessi in base al ruolo configurati, la configurazione di Microsoft Defender mancante, l'accesso alla rete senza restrizioni al server API. Analogamente, fornisce raccomandazioni per il carico di lavoro per alcuni degli elementi dell'iniziativa di sicurezza dei pod. Esaminare le raccomandazioni.

Definizioni dei criteri

Criteri di Azure offre varie definizioni di criteri predefinite che si applicano sia alla risorsa di Azure che al servizio Azure Kubernetes, come le definizioni di criteri standard, e l'uso del componente aggiuntivo Criteri di Azure per Kubernetes, anche all'interno del cluster. Molti dei criteri delle risorse di Azure sono disponibili sia in Audit/Deny, che in una variante Deploy If Not Exists (Distribuisci se non esiste).

Esistono numerosi criteri e i criteri chiave correlati a questo pilastro sono riepilogati qui. Per una visualizzazione più dettagliata, vedere Definizioni di criteri predefinite per Kubernetes.

Architettura del cluster

  • Microsoft Defender per i criteri basati sul cloud
  • Modalità di autenticazione e criteri di configurazione (Microsoft Entra ID, controllo degli accessi in base al ruolo, disabilitare l'autenticazione locale)
  • Criteri di accesso alla rete del server API, incluso il cluster privato

Architettura del cluster e del carico di lavoro

  • Iniziative di sicurezza dei pod del cluster Kubernetes basate su Linux
  • Includere criteri di funzionalità dei pod e dei contenitori, ad esempio AppArmor, sysctl, limiti di sicurezza, SELinux, seccomp, contenitori con privilegi, credenziali api cluster di montaggio automatico
  • Montare, driver di volume e criteri di file system
  • Criteri di rete dei pod/contenitori, ad esempio rete host, porta, indirizzi IP esterni consentiti, punti di protezione hardware e servizi di bilanciamento del carico interni

servizio Azure Kubernetes distribuzioni spesso usano anche Registro Azure Container per i grafici Helm e le immagini dei contenitori. Registro Azure Container supporta anche un'ampia gamma di criteri di Azure che si estendono su restrizioni di rete, controllo di accesso e Microsoft Defender per cloud, che integra un'architettura del servizio Azure Kubernetes sicura.

Oltre ai criteri predefiniti, è possibile creare criteri personalizzati sia per la risorsa del servizio Azure Kubernetes che per il componente aggiuntivo Criteri di Azure per Kubernetes. In questo modo è possibile aggiungere altri vincoli di sicurezza da applicare nell'architettura del cluster e del carico di lavoro.

Per altri suggerimenti, vedere Concetti di sicurezza del servizio Azure Kubernetes e valutare le raccomandazioni per la protezione avanzata della sicurezza in base al benchmark di Kubernetes CIS.

Ottimizzazione dei costi

L'ottimizzazione dei costi riguarda la comprensione delle diverse opzioni di configurazione e delle procedure consigliate per ridurre le spese non necessarie e migliorare l'efficienza operativa. Prima di seguire le indicazioni in questo articolo, è consigliabile esaminare le risorse seguenti:

Quando si discute dell'ottimizzazione dei costi con servizio Azure Kubernetes, è importante distinguere tra il costo delle risorse del cluster e il costo delle risorse del carico di lavoro. Le risorse del cluster sono responsabilità condivisa tra l'amministratore del cluster e il provider di risorse, mentre le risorse del carico di lavoro sono il dominio di uno sviluppatore. servizio Azure Kubernetes ha considerazioni e raccomandazioni per entrambi questi ruoli.

Nell'elenco di controllo di progettazione e nell'elenco di raccomandazioni vengono effettuate chiamate per indicare se ogni scelta è applicabile all'architettura del cluster, all'architettura del carico di lavoro o a entrambi.

Per l'ottimizzazione dei costi del cluster, passare al calcolatore dei prezzi di Azure e selezionare servizio Azure Kubernetes dai prodotti disponibili. È possibile testare diverse configurazioni e piani di pagamento nel calcolatore.

Elenco di controllo della progettazione

  • Architettura del cluster: Usare lo SKU della macchina virtuale appropriato per ogni pool di nodi e istanze riservate in cui è prevista la capacità a lungo termine.
  • Architetture di cluster e carichi di lavoro: Usare il livello e le dimensioni del disco gestito appropriati.
  • Architettura del cluster: Esaminare le metriche delle prestazioni, a partire da CPU, memoria, archiviazione e rete, per identificare le opportunità di ottimizzazione dei costi in base a cluster, nodi e spazio dei nomi.
  • Architettura del cluster e del carico di lavoro: Usare i ridimensionatori automatici per aumentare le prestazioni quando i carichi di lavoro sono meno attivi.

Consigli

Esplorare la tabella seguente di consigli per ottimizzare la configurazione del servizio Azure Kubernetes per i costi.

Recommendation Vantaggi
Architetture di cluster e carichi di lavoro: Allineare la selezione dello SKU e le dimensioni del disco gestito ai requisiti del carico di lavoro. La corrispondenza tra la selezione e le richieste del carico di lavoro garantisce che non vengano pagate risorse non necessarie.
Architettura del cluster: Selezionare il tipo di istanza di macchina virtuale corretto. La selezione del tipo di istanza di macchina virtuale corretta è fondamentale perché influisce direttamente sul costo delle applicazioni in esecuzione nel servizio Azure Kubernetes. La scelta di un'istanza a prestazioni elevate senza un utilizzo appropriato può comportare una spesa dispendiosa, mentre la scelta di un'istanza potente può causare problemi di prestazioni e tempi di inattività maggiori. Per determinare il tipo di istanza di macchina virtuale corretto, prendere in considerazione le caratteristiche del carico di lavoro, i requisiti delle risorse e le esigenze di disponibilità.
Architettura del cluster: Selezionare le macchine virtuali in base all'architettura arm. Il servizio Azure Kubernetes supporta la creazione di nodi agente Ubuntu ARM64, nonché una combinazione di nodi di architettura Intel e ARM all'interno di un cluster che può offrire prestazioni migliori a un costo inferiore.
Architettura del cluster: Selezionare Azure Spot Macchine virtuali. Le macchine virtuali spot consentono di sfruttare la capacità di Azure non utilizzata con sconti significativi (fino al 90% rispetto ai prezzi con pagamento in base al consumo). Se Azure necessita di capacità indietro, l'infrastruttura di Azure rimuove i nodi Spot.
Architettura del cluster: Selezionare l'area appropriata. A causa di molti fattori, il costo delle risorse varia in base all'area in Azure. Valutare i requisiti di costo, latenza e conformità per assicurarsi di eseguire il carico di lavoro in modo conveniente e non influisce sugli utenti finali o creare costi di rete aggiuntivi.
Architettura del carico di lavoro: Mantenere immagini piccole e ottimizzate. La semplificazione delle immagini consente di ridurre i costi perché i nuovi nodi devono scaricare queste immagini. Creare immagini in modo che consentano l'avvio del contenitore il prima possibile per evitare errori o timeout delle richieste utente durante l'avvio dell'applicazione, causando potenzialmente il provisioning eccessivo.
Architettura del cluster: Abilitare la scalabilità automatica del cluster per ridurre automaticamente il numero di nodi dell'agente in risposta alla capacità di risorse in eccesso. Il ridimensionamento automatico del numero di nodi nel cluster del servizio Azure Kubernetes consente di eseguire un cluster efficiente quando la domanda è bassa e aumentare le prestazioni quando viene restituita la domanda.
Architettura del cluster: Abilitare il provisioning automatico dei nodi per automatizzare la selezione dello SKU della macchina virtuale. Il provisioning automatico del nodo semplifica il processo di selezione dello SKU e decide, in base ai requisiti delle risorse dei pod in sospeso, la configurazione ottimale della macchina virtuale per l'esecuzione dei carichi di lavoro nel modo più efficiente e conveniente.
Architettura del carico di lavoro: Usare l'utilità di scalabilità automatica orizzontale dei pod. Modificare il numero di pod in una distribuzione a seconda dell'utilizzo della CPU o di altre metriche selezionate, che supportano le operazioni di ridimensionamento del cluster.
Architettura del carico di lavoro: Usare la scalabilità automatica verticale dei pod (anteprima). Dirittizza i pod e imposta dinamicamente richieste e limiti in base all'utilizzo cronologico.
Architettura del carico di lavoro: Usare la scalabilità automatica basata su eventi (KEDA) di Kubernetes . Ridimensionare in base al numero di eventi elaborati. Scegli da un ricco catalogo di 50+ scaler KEDA.
Architetture di cluster e carichi di lavoro: Adottare una disciplina finanziaria e una pratica culturale cloud per promuovere la proprietà dell'utilizzo del cloud. La base dell'abilitazione dell'ottimizzazione dei costi è la diffusione di un cluster con risparmio sui costi. Un approccio alle operazioni finanziarie (FinOps) viene spesso usato per aiutare le organizzazioni a ridurre i costi del cloud. Si tratta di una pratica che coinvolge la collaborazione tra team finanziari, operativi e tecnici per favorire l'allineamento sugli obiettivi di risparmio sui costi e portare la trasparenza ai costi del cloud.
Architettura del cluster: Iscriversi alle prenotazioni di Azure o al piano di risparmio di Azure. Se la capacità è stata pianificata correttamente, il carico di lavoro è prevedibile ed esiste per un lungo periodo di tempo, iscriversi a una prenotazione di Azure o a un piano di risparmio per ridurre ulteriormente i costi delle risorse.
Architettura del cluster: Configurare il monitoraggio del cluster con Informazioni dettagliate sui contenitori. Informazioni dettagliate sui contenitori fornisce informazioni dettagliate interattive sulle risorse inattive e non allocate dei cluster. Informazioni dettagliate sui contenitori supporta anche la raccolta di metriche prometheus e si integra con Azure Managed Grafana per ottenere una visione olistica dell'applicazione e dell'infrastruttura.
Architettura del cluster: Configurare il componente aggiuntivo Analisi costi del servizio Azure Kubernetes. L'estensione del cluster di analisi dei costi consente di ottenere informazioni dettagliate sui costi associati a varie risorse Kubernetes nei cluster o negli spazi dei nomi.

Per altri suggerimenti, vedere Principi del pilastro dell'ottimizzazione dei costi e Ottimizzare i costi in servizio Azure Kubernetes.

Definizioni dei criteri

Anche se non sono presenti criteri predefiniti correlati all'ottimizzazione dei costi, è possibile creare criteri personalizzati sia per la risorsa del servizio Azure Kubernetes che per il componente aggiuntivo Criteri di Azure per Kubernetes. In questo modo è possibile aggiungere ulteriori vincoli di ottimizzazione dei costi da applicare nell'architettura del cluster e del carico di lavoro.

Efficienza del cloud

Rendere i carichi di lavoro più sostenibili e cloud efficienti, richiede la combinazione di sforzi per l'ottimizzazione dei costi, la riduzione delle emissioni di carbonio e l'ottimizzazione del consumo energetico. L'ottimizzazione dei costi dell'applicazione è il passaggio iniziale per rendere i carichi di lavoro più sostenibili.

Informazioni su come creare carichi di lavoro del servizio Azure Kubernetes sostenibili ed efficienti, in Principi di progettazione del software sostenibile in servizio Azure Kubernetes (servizio Azure Kubernetes).

Eccellenza operativa

Il monitoraggio e la diagnostica sono fondamentali. Non solo è possibile misurare le statistiche sulle prestazioni, ma anche usare le metriche per risolvere e correggere rapidamente i problemi. È consigliabile esaminare i principi di progettazione dell'eccellenza operativa e la guida operativa alle operazioni day-2.

Quando si discute dell'eccellenza operativa con servizio Azure Kubernetes, è importante distinguere tra l'eccellenza operativa del cluster e l'eccellenza operativa del carico di lavoro. Le operazioni del cluster sono responsabilità condivisa tra l'amministratore del cluster e il provider di risorse, mentre le operazioni del carico di lavoro sono il dominio di uno sviluppatore. servizio Azure Kubernetes ha considerazioni e raccomandazioni per entrambi questi ruoli.

Nell'elenco di controllo di progettazione e nell'elenco delle raccomandazioni riportate di seguito vengono effettuate chiamate per indicare se ogni scelta è applicabile all'architettura del cluster, all'architettura del carico di lavoro o a entrambi.

Elenco di controllo della progettazione

  • Architettura del cluster: Usare una distribuzione basata su modello usando Bicep, Terraform o altri. Assicurarsi che tutte le distribuzioni siano ripetibili, tracciabili e archiviate in un repository del codice sorgente.
  • Architettura del cluster: Creare un processo automatizzato per assicurarsi che i cluster vengano avviati con le configurazioni e le distribuzioni a livello di cluster necessarie. Questa operazione viene spesso eseguita usando GitOps.
  • Architettura del carico di lavoro: Usare processi di distribuzione ripetibili e automatizzati per il carico di lavoro all'interno del ciclo di vita dello sviluppo software.
  • Architettura del cluster: Abilitare le impostazioni di diagnostica per assicurarsi che vengano registrate le interazioni del piano di controllo o del server API principale.
  • Architetture di cluster e carichi di lavoro: Abilitare Informazioni dettagliate sui contenitori per raccogliere metriche, log e diagnostica per monitorare la disponibilità e le prestazioni del cluster e dei carichi di lavoro in esecuzione.
  • Architettura del carico di lavoro: Il carico di lavoro deve essere progettato per generare dati di telemetria che possono essere raccolti, che devono includere anche lo stato di disponibilità e conformità.
  • Architetture di cluster e carichi di lavoro: Usare le procedure di progettazione chaos destinate a Kubernetes per identificare i problemi di affidabilità dell'applicazione o della piattaforma.
  • Architettura del carico di lavoro: Ottimizzare il carico di lavoro per operare e distribuire in modo efficiente in un contenitore.
  • Architetture di cluster e carichi di lavoro: Applicare la governance del cluster e del carico di lavoro usando Criteri di Azure.

Consigli

Esplorare la tabella seguente di consigli per ottimizzare la configurazione del servizio Azure Kubernetes per le operazioni.

Recommendation Vantaggi
Architetture di cluster e carichi di lavoro: Vedere la documentazione sulle procedure consigliate del servizio Azure Kubernetes . Per compilare ed eseguire correttamente le applicazioni nel servizio Azure Kubernetes, è necessario comprendere e implementare le applicazioni. Queste aree includono le funzionalità multi-tenancy e pianificazione, sicurezza di cluster e pod o continuità aziendale e ripristino di emergenza.
Architetture di cluster e carichi di lavoro: Esaminare Azure Chaos Studio. Azure Chaos Studio consente di simulare errori e attivare situazioni di ripristino di emergenza.
Architetture di cluster e carichi di lavoro: Configurare il monitoraggio del cluster con Informazioni dettagliate sui contenitori. Informazioni dettagliate sui contenitori consentono di monitorare le prestazioni dei contenitori raccogliendo metriche di memoria e processore da controller, nodi e contenitori disponibili in Kubernetes tramite l'API Metriche e i log dei contenitori.
Architettura del carico di lavoro: Monitorare le prestazioni dell'applicazione con Monitoraggio di Azure. Configurare Application Insights per il monitoraggio basato sul codice delle applicazioni in esecuzione in un cluster del servizio Azure Kubernetes.
Architettura del carico di lavoro: Configurare lo scraping delle metriche di Prometheus con Informazioni dettagliate sui contenitori. Le informazioni dettagliate sui contenitori, che fanno parte di Monitoraggio di Azure, offrono un'esperienza di onboarding trasparente per raccogliere le metriche di Prometheus. Per altre informazioni, vedere Configurare lo scraping delle metriche prometheus .
Architettura del cluster: Adottare una strategia di multiregione distribuendo cluster del servizio Azure Kubernetes distribuiti in aree di Azure diverse per ottimizzare la disponibilità e garantire la continuità aziendale. I carichi di lavoro con connessione Internet devono sfruttare Frontdoor di Azure o Gestione traffico di Azure per instradare il traffico a livello globale tra i cluster del servizio Azure Kubernetes.
Architettura del cluster: Rendere operativi i cluster e gli standard di configurazione dei pod con Criteri di Azure. Criteri di Azure può essere utile per applicare l'applicazione e le misure di sicurezza su larga scala nei cluster in modo centralizzato e coerente. Può anche controllare quali funzioni vengono concesse ai pod e se sono in esecuzione componenti che non rispettano i criteri aziendali.
Architettura del carico di lavoro: Usare le funzionalità della piattaforma nel processo di progettazione del rilascio. I controller Kubernetes e in ingresso supportano molti modelli di distribuzione avanzati per l'inclusione nel processo di progettazione del rilascio. Prendere in considerazione modelli come distribuzioni blu-verde o versioni canary.
Architetture di cluster e carichi di lavoro: Per i carichi di lavoro cruciali, usare distribuzioni blu/verde a livello di timbro. Automatizzare le aree di progettazione cruciali, tra cui distribuzione e test.

Per altri suggerimenti, vedere Principi del pilastro dell'eccellenza operativa.

Azure Advisor fornisce anche raccomandazioni su un subset degli elementi elencati nella sezione dei criteri seguente, ad esempio le versioni del servizio Azure Kubernetes non supportate e le impostazioni di diagnostica non configurate. Analogamente, vengono fornite raccomandazioni per il carico di lavoro relative all'uso dello spazio dei nomi predefinito.

Definizioni dei criteri

Criteri di Azure offre varie definizioni di criteri predefinite che si applicano sia alla risorsa di Azure che al servizio Azure Kubernetes, come le definizioni di criteri standard, e l'uso del componente aggiuntivo Criteri di Azure per Kubernetes, anche all'interno del cluster. Molti dei criteri delle risorse di Azure sono disponibili sia in Audit/Deny, che in una variante Deploy If Not Exists (Distribuisci se non esiste).

Esistono numerosi criteri e i criteri chiave correlati a questo pilastro sono riepilogati qui. Per una visualizzazione più dettagliata, vedere Definizioni di criteri predefinite per Kubernetes.

Architettura del cluster

  • Criteri di Azure componente aggiuntivo per Kubernetes
  • Criteri di configurazione di GitOps
  • Criteri delle impostazioni di diagnostica
  • Restrizioni della versione del servizio Azure Kubernetes
  • Impedisci richiamo comandi

Architettura del cluster e del carico di lavoro

  • Restrizioni di distribuzione dello spazio dei nomi

Oltre ai criteri predefiniti, è possibile creare criteri personalizzati sia per la risorsa del servizio Azure Kubernetes che per il componente aggiuntivo Criteri di Azure per Kubernetes. In questo modo è possibile aggiungere altri vincoli di sicurezza da applicare nell'architettura del cluster e del carico di lavoro.

Efficienza delle prestazioni

L'efficienza delle prestazioni è la capacità di ridimensionare il carico di lavoro soddisfare in modo efficiente le richieste poste dagli utenti. È consigliabile esaminare i principi di efficienza delle prestazioni.

Quando si parla di prestazioni con servizio Azure Kubernetes, è importante distinguere tra prestazioni del cluster e prestazioni del carico di lavoro. Le prestazioni del cluster sono responsabilità condivisa tra l'amministratore del cluster e il provider di risorse, mentre le prestazioni del carico di lavoro sono il dominio di uno sviluppatore. servizio Azure Kubernetes ha considerazioni e raccomandazioni per entrambi questi ruoli.

Nell'elenco di controllo di progettazione e nell'elenco delle raccomandazioni riportate di seguito vengono effettuate chiamate per indicare se ogni scelta è applicabile all'architettura del cluster, all'architettura del carico di lavoro o a entrambi.

Elenco di controllo della progettazione

Quando si effettuano scelte di progettazione per servizio Azure Kubernetes, esaminare i principi di efficienza delle prestazioni.

  • Architetture di cluster e carichi di lavoro: Eseguire e scorrere un esercizio dettagliato del piano di capacità che include SKU, impostazioni di scalabilità automatica, indirizzamento IP e considerazioni sul failover.
  • Architettura del cluster: Abilitare la scalabilità automatica del cluster per regolare automaticamente il numero di nodi dell'agente nelle richieste del carico di lavoro di risposta.
  • Architettura del cluster: Usare il ridimensionamento automatico orizzontale dei pod per modificare il numero di pod in una distribuzione a seconda dell'utilizzo della CPU o di altre metriche selezionate.
  • Architetture di cluster e carichi di lavoro: Eseguire attività di test di carico in corso che esercitano sia il pod che il ridimensionamento automatico del cluster.
  • Architetture di cluster e carichi di lavoro: Separare i carichi di lavoro in pool di nodi diversi che consentono lo scalling indipendente.

Consigli

Esplorare la tabella seguente di consigli per ottimizzare la configurazione servizio Azure Kubernetes per le prestazioni.

Recommendation Vantaggi
Architetture del cluster e del carico di lavoro: Sviluppare un piano di capacità dettagliato e rivedere continuamente. Dopo aver formalizzato il piano di capacità, deve essere aggiornato spesso osservando continuamente l'utilizzo delle risorse del cluster.
Architettura del cluster: Abilitare la scalabilità automatica del cluster per modificare automaticamente il numero di nodi dell'agente in risposta ai vincoli delle risorse. La capacità di incrementare o ridurre il numero di nodi nel cluster del servizio Azure Kubernetes permette di gestire il cluster in modo efficace e conveniente.
Architetture del cluster e del carico di lavoro: Separare i carichi di lavoro in pool di nodi diversi e valutare la scalabilità dei pool di nodi utente. A differenza dei pool di nodi di sistema che richiedono sempre l'esecuzione di nodi, i pool di nodi utente consentono di aumentare o ridurre.
Architettura del carico di lavoro: Usare le funzionalità avanzate dell'utilità di pianificazione del servizio Azure Kubernetes. Consente di controllare il bilanciamento delle risorse per i carichi di lavoro che li richiedono.
Architettura del carico di lavoro: Usare metriche di scalabilità dei carichi di lavoro significative. Non tutte le decisioni di scalabilità possono essere derivate dalle metriche della CPU o della memoria. Spesso le considerazioni sulla scala provengono da punti dati più complessi o anche esterni. Usare KEDA per creare un set di regole di scalabilità automatica significativo in base ai segnali specifici del carico di lavoro.

Per altri suggerimenti, vedere Principi del pilastro dell'efficienza delle prestazioni.

Definizioni dei criteri

Criteri di Azure offre diverse definizioni di criteri predefinite che si applicano sia alla risorsa di Azure che al servizio Azure Kubernetes come definizioni di criteri standard e all'uso del componente aggiuntivo Criteri di Azure per Kubernetes, anche all'interno del cluster. Molti dei criteri di risorse di Azure sono disponibili sia In Audit/Deny, ma anche in una variante Deploy If Not Exists .

Esistono numerosi criteri e i criteri chiave correlati a questo pilastro sono riepilogati qui. Per una visualizzazione più dettagliata, vedere Definizioni di criteri predefinite per Kubernetes.

Architettura del cluster e del carico di lavoro

  • Limiti delle risorse cpu e memoria

Oltre ai criteri predefiniti, è possibile creare criteri personalizzati sia per la risorsa del servizio Azure Kubernetes che per il componente aggiuntivo Criteri di Azure per Kubernetes. Ciò consente di aggiungere vincoli di sicurezza aggiuntivi che si desidera applicare nell'architettura del cluster e del carico di lavoro.

Risorse aggiuntive

Linee guida del Centro architetture di Azure

Linee guida di Cloud Adoption Framework

Passaggi successivi