Revisione di Azure Well-Architected Framework - servizio Azure Kubernetes (AKS)
Questo articolo fornisce le 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 prestazionale
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 della revisione di Azure Well-Architected Framework.
Per il contesto, è consigliabile 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 della zona di destinazione per un cluster di servizio Azure Kubernetes 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 di 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. Il servizio Azure Kubernetes include considerazioni e consigli per entrambi i ruoli.
Nell'elenco di controllo di progettazione e nell'elenco di raccomandazioni seguenti vengono eseguiti callout 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 degli 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: esaminare le procedure consigliate per il monitoraggio di Kubernetes con Monitoraggio di Azure per determinare la strategia di monitoraggio migliore per i carichi di lavoro.
- 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 del cluster e dei carichi di lavoro: assicurarsi 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à.
| Elemento consigliato | Vantaggio |
|---|---|
| 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 alle risorse inutilizzate nei nodi di utilizzare, ma assegna la priorità ai pod che definiscono il selettore del 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 la selezione corretta del 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%disponibilità dell'endpoint server dell'API Kubernetes per i cluster del servizio Azure Kubernetes che usano Azure zone di disponibilità o- 99.9% di disponibilità per i cluster che non usano zone di disponibilità di Azure. |
| Architetture di cluster e carichi di lavoro: esaminare le procedure consigliate per il monitoraggio di Kubernetes con Monitoraggio di Azure per determinare la strategia di monitoraggio migliore per i carichi di lavoro. | N/D |
| 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 è stata disattivata. Se esistono requisiti di colocalità, è possibile usare una normale distribuzione del servizio Azure Kubernetes basata su set di scalabilità di macchine virtuali in una singola zona o in gruppi di posizionamento di prossimità per ridurre al minimo la latenza internade. |
| 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 dei pod nei manifesti della distribuzione dell'applicazione e applicare 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 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 i criteri di Azure tipici che, usando il componente aggiuntivo Criteri di Azure per Kubernetes, anche all'interno del cluster. Esistono numerosi criteri chiave correlati a questo pilastro 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 altri 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ò migliorare 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), vedere Cluster regolamentato del servizio Azure Kubernetes per PCI-DSS 3.2.1.
Per informazioni sul supporto e sui requisiti di DoD Impact Level 5 (IL5) con il servizio Azure Kubernetes, vedere Azure per enti pubblici requisiti di isolamento IL5.
Quando si discute di 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. Il servizio Azure Kubernetes include considerazioni e consigli per entrambi i ruoli.
Nell'elenco di controllo di progettazione e nell'elenco di raccomandazioni seguenti 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 contenitori con Azure Sentinel per rilevare e rispondere rapidamente alle minacce nel cluster e nei carichi di lavoro in esecuzione su di essi.
- 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: assicurarsi che la pipeline CI/CID sia avanzata con l'analisi compatibile con i contenitori.
Consigli
Esplorare la tabella seguente di raccomandazioni per ottimizzare la configurazione del servizio Azure Kubernetes per la sicurezza.
| Elemento consigliato | Vantaggio |
|---|---|
| Architettura del cluster: usare l'integrazione di Microsoft Entra. | L'uso di Microsoft Entra AD consente di centralizzare 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 dei 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 attraversa 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 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à dell'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 Controllo degli accessi in base al ruolo di Microsoft Entra. | 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 ID Microsoft Entra. |
| 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'imposizione 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 Web application firewall (WAF) di Azure in un gateway di app Azure lication o in 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 stringa 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 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 subset 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 elementi dell'iniziativa di sicurezza dei pod. Esaminare le raccomandazioni.
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 delle risorse di Azure sono disponibili sia in Audit/Deny, sia in una variante Deploy If Not Exists .
Esistono numerosi criteri chiave correlati a questo pilastro riepilogati qui. Per una visualizzazione più dettagliata, vedere Definizioni di criteri predefinite per Kubernetes.
Architettura del cluster
- criteri basati su Microsoft Defender per il 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, caps di sicurezza, SELinux, seccomp, contenitori con privilegi, credenziali API del cluster di montaggio automatico
- Criteri di montaggio, driver di volume e file system
- Criteri di rete dei pod/contenitori, ad esempio rete host, porta, indirizzi IP esterni consentiti, indirizzi IP di protezione hardware e servizi di bilanciamento del carico interni
servizio Azure Kubernetes distribuzioni spesso usano anche Registro Azure Container per grafici Helm e immagini del contenitore. 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 il cloud, che integra un'architettura del servizio Azure Kubernetes sicura.
Oltre ai criteri predefiniti, è 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 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 sulla protezione avanzata in base al benchmark kubernetes CIS.
Ottimizzazione dei costi
L'ottimizzazione dei costi riguarda la comprensione delle diverse opzioni di configurazione e le procedure consigliate per ridurre le spese non necessarie e migliorare l'efficienza operativa. Prima di seguire le indicazioni contenute in questo articolo, è consigliabile esaminare le risorse seguenti:
- Principi di progettazione dell'ottimizzazione dei costi.
- Funzionamento della gestione dei prezzi e dei costi in servizio Azure Kubernetes (servizio Azure Kubernetes) rispetto ad Amazon Elastic Kubernetes Service (Amazon EKS).
- Se si esegue il servizio Azure Kubernetes in locale o perimetrale, è anche possibile usare Vantaggio Azure Hybrid per ridurre ulteriormente i costi durante l'esecuzione di applicazioni in contenitori in tali scenari.
Quando si discute dell'ottimizzazione dei costi con il servizio Azure Kubernetes, è importante distinguere tra costo delle risorse del cluster e costo delle risorse del carico di lavoro. Le risorse del cluster sono una responsabilità condivisa tra l'amministratore del cluster e il provider di risorse, mentre le risorse del carico di lavoro sono di dominio dello sviluppatore. Il servizio Azure Kubernetes include considerazioni e consigli per entrambi i 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 prezzi di Azure e selezionare servizio Azure Kubernetes dai prodotti disponibili. È possibile testare piani di configurazione e pagamento diversi nel calcolatore.
Elenco di controllo della progettazione
- Architettura del cluster: usare lo SKU di macchina virtuale appropriato per 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 di raccomandazioni seguente per ottimizzare la configurazione del servizio Azure Kubernetes in termini di costi.
| Elemento consigliato | Vantaggio |
|---|---|
| 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 si paghino risorse non necessarie. |
| Architettura del cluster: selezionare il tipo di istanza della 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 ad alte prestazioni senza un utilizzo appropriato può comportare una spesa dispendiosa, mentre la scelta di un'istanza meno potente può causare problemi di prestazioni e tempi di inattività maggiori. Per determinare il tipo di istanza della 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 Macchine virtuali spot di Azure. | 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à, 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: gestire immagini di piccole dimensioni 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 dell'utente durante l'avvio dell'applicazione, causando potenzialmente l'overprovisioning. |
| 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 in caso di restituzione della domanda. |
| Architettura del cluster: abilitare il provisioning automatico del nodo 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). | Diritti per i pod e impostare dinamicamente richieste e limiti in base all'utilizzo cronologico. |
| Architettura del carico di lavoro: usare la scalabilità automatica basata su eventi di Kubernetes (KEDA). | Ridimensionare in base al numero di eventi elaborati. Scegli tra un ricco catalogo di 50+ scaler KEDA. |
| Architetture di cluster e carichi di lavoro: adottare una disciplina finanziaria cloud e una pratica culturale per guidare la proprietà dell'utilizzo del cloud. | La base dell'abilitazione dell'ottimizzazione dei costi è la distribuzione di un cluster che consente di risparmiare 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 i team di finanza, operazioni e ingegneria per favorire l'allineamento sugli obiettivi di risparmio sui costi e portare trasparenza ai costi del cloud. |
| Architettura del cluster: iscriversi alle prenotazioni di Azure o al piano di risparmio di Azure. | Se si pianifica correttamente la capacità, 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: esaminare le procedure consigliate per il monitoraggio di Kubernetes con Monitoraggio di Azure per determinare la strategia di monitoraggio migliore per i carichi di lavoro. | N/D |
| 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 esistono 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 risolvere rapidamente i problemi. È consigliabile esaminare i principi di progettazione dell'eccellenza operativa e la guida operativa al giorno 2.
Quando si discute di eccellenza operativa con servizio Azure Kubernetes, è importante distinguere tra eccellenza operativa del cluster ed eccellenza operativa del carico di lavoro. Le operazioni del cluster sono una 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. Il servizio Azure Kubernetes include considerazioni e consigli per entrambi i ruoli.
Nell'elenco di controllo di progettazione e nell'elenco di raccomandazioni seguenti 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 necessarie a livello di cluster. 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 garantire la registrazione delle interazioni del piano di controllo o del server API principale.
- Architetture di cluster e carichi di lavoro: esaminare le procedure consigliate per il monitoraggio di Kubernetes con Monitoraggio di Azure per determinare la strategia di monitoraggio migliore per i carichi di lavoro.
- 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 stati di disponibilità e conformità.
- Architetture di cluster e carichi di lavoro: usare 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 di raccomandazioni seguente per ottimizzare la configurazione del servizio Azure Kubernetes per le operazioni.
| Elemento consigliato | Vantaggio |
|---|---|
| Architetture di cluster e carichi di lavoro: vedere la documentazione sulle procedure consigliate del servizio Azure Kubernetes . | Per compilare ed eseguire correttamente applicazioni nel servizio Azure Kubernetes, è necessario comprendere e implementare alcune considerazioni chiave. 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 gli errori e attivare situazioni di ripristino di emergenza. |
| Architetture di cluster e carichi di lavoro: esaminare le procedure consigliate per il monitoraggio di Kubernetes con Monitoraggio di Azure per determinare la strategia di monitoraggio migliore per i carichi di lavoro. | N/D |
| 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'imposizione 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 delle versioni. | I controller kubernetes e in ingresso supportano molti modelli di distribuzione avanzati per l'inclusione nel processo di progettazione delle versioni. 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 stamp. | 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, offre raccomandazioni per il carico di lavoro relative all'uso dello spazio dei nomi predefinito.
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 delle risorse di Azure sono disponibili sia in Audit/Deny, sia in una variante Deploy If Not Exists .
Esistono numerosi criteri chiave correlati a questo pilastro 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 richiamare 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 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 prestazionale
L'efficienza delle prestazioni è la capacità di dimensionare il carico di lavoro per 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 una 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. Il servizio Azure Kubernetes include considerazioni e consigli per entrambi i ruoli.
Nell'elenco di controllo di progettazione e nell'elenco di raccomandazioni seguenti 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 in un esercizio dettagliato del piano di capacità che include SKU, impostazioni di scalabilità automatica, indirizzamento IP e considerazioni sul failover.
- Architettura del cluster: abilitare il ridimensionamento automatico del cluster per regolare automaticamente il numero di nodi dell'agente nelle richieste del carico di lavoro di risposta.
- Architettura del cluster: usare l'utilità di scalabilità automatica orizzontale dei pod per regolare 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 di raccomandazioni seguente per ottimizzare la configurazione servizio Azure Kubernetes per le prestazioni.
| Elemento consigliato | Vantaggio |
|---|---|
| Architetture di cluster e carichi di lavoro: sviluppare un piano di capacità dettagliato e rivedere continuamente. | Dopo aver formalizzato il piano di capacità, deve essere aggiornato di frequente osservando continuamente l'utilizzo delle risorse del cluster. |
| Architettura del cluster: abilitare il ridimensionamento automatico del cluster per regolare 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 di cluster e carichi di lavoro: separare i carichi di lavoro in pool di nodi diversi e valutare la possibilità di ridimensionare i pool di nodi utente. | A differenza dei pool di nodi di sistema che richiedono sempre nodi in esecuzione, i pool di nodi utente consentono di aumentare o ridurre le prestazioni. |
| 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 ridimensionamento significative del carico di lavoro. | 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 delle risorse di Azure sono disponibili sia in Audit/Deny, sia in una variante Deploy If Not Exists .
Esistono numerosi criteri chiave correlati a questo pilastro 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 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.
Risorse aggiuntive
Linee guida del Centro architetture di Azure
- Architettura di base del servizio Azure Kubernetes
- Architettura avanzata dei microservizi AKS
- Cluster del servizio Azure Kubernetes per un carico di lavoro PCI-DSS
- Baseline di AKS per cluster multiarea
Linee guida di Cloud Adoption Framework
Passaggi successivi
- Distribuire un cluster servizio Azure Kubernetes usando l'interfaccia della riga di comando di Azure Avvio rapido: Distribuire un cluster servizio Azure Kubernetes del servizio Azure Kubernetes usando l'interfaccia della riga di comando di Azure