Condividi tramite

Architettura di microservizi nel servizio Azure Kubernetes

Gateway applicazione di Azure
Registro Azure Container
Servizio Azure Kubernetes (AKS)
Rete virtuale di Azure

Questa architettura di riferimento descrive diverse configurazioni da considerare quando si eseguono microservizi nel servizio Azure Kubernetes. Questo articolo illustra la configurazione dei criteri di rete, la scalabilità automatica dei pod e la traccia distribuita in un'applicazione basata su microservizi.

Questa architettura si basa sull'architettura di base del servizio Azure Kubernetes, consigliata da Microsoft come punto di partenza per l'infrastruttura del servizio Azure Kubernetes. La baseline del servizio Azure Kubernetes descrive le funzionalità infrastrutturali, ad esempio ID carico di lavoro Microsoft Entra, restrizioni in ingresso e in uscita, limiti delle risorse e altre configurazioni dell'infrastruttura del servizio Azure Kubernetes sicure. Queste funzionalità non sono descritte in questo articolo. È consigliabile acquisire familiarità con l'architettura di base del servizio Azure Kubernetes prima di procedere con il contenuto dei microservizi.

Logo di GitHub Un'implementazione di riferimento di questa architettura è disponibile in GitHub.

Architettura

Diagramma di rete che mostra una rete hub-spoke con due reti virtuali con peering e le risorse di Azure usate da questa implementazione.

Scaricare un file di Visio di questa architettura.

Se si preferisce iniziare con un esempio di microservizi più di base nel servizio Azure Kubernetes, vedere Architettura di microservizi nel servizio Azure Kubernetes.

Flusso di lavoro

Questo flusso di richiesta implementa i modelli di progettazione cloud Publisher-Subscriber, Consumer concorrenti e Routing del gateway. Il flusso di lavoro seguente corrisponde al diagramma precedente:

  1. Viene inviata una richiesta HTTPS per pianificare un ritiro tramite drone. La richiesta passa attraverso il gateway applicazione di Azure nell'applicazione Web di inserimento, che viene eseguita come microservizio in cluster nel servizio Azure Kubernetes.

  2. L'applicazione Web di inserimento genera un messaggio e lo invia alla coda dei messaggi del bus di servizio di Azure.

  3. Il sistema back-end assegna un drone e invia una notifica all'utente. Il microservizio flusso di lavoro esegue le attività seguenti:

    • Utilizza le informazioni sui messaggi dalla coda dei messaggi del bus di servizio
    • Invia una richiesta HTTPS al microservizio di recapito, che passa i dati all'archiviazione dati esterna di Cache Redis di Azure
    • Invia una richiesta HTTPS al microservizio dell'utilità di pianificazione drone
    • Invia una richiesta HTTPS al microservizio del pacchetto, che passa i dati all'archiviazione dati esterna mongoDB

  4. L'architettura usa una richiesta HTTPS GET per restituire lo stato di recapito. Questa richiesta passa attraverso il gateway applicazione nel microservizio di recapito.

  5. Il microservizio di recapito legge i dati da cache di Azure per Redis.

Componenti

Archiviazione esterna e altri componenti

  • Key Vault archivia e gestisce chiavi di sicurezza, valori segreti e certificati per i servizi di Azure. In questa architettura gli insiemi di credenziali delle chiavi di Azure archiviano le credenziali per Azure Cosmos DB e Cache Redis di Azure.

  • Registro Container archivia immagini di contenitori private che possono essere eseguite nel cluster del servizio Azure Kubernetes. Il servizio Azure Kubernetes esegue l'autenticazione con registro contenitori usando l'identità gestita di Microsoft Entra. È anche possibile usare altri registri contenitori, ad esempio Docker Hub. In questa architettura Registro Container archivia le immagini del contenitore per i microservizi.

  • Azure Cosmos DB è un database NoSQL, relazionale e vettoriale completamente gestito. I microservizi sono in genere senza stato e scrivono il proprio stato in archivi dati esterni. Azure Cosmos DB include API open source per MongoDB, PostgreSQL e Cassandra. In questa architettura, Azure Cosmos DB e Azure Cosmos DB per MongoDB fungono da archivi dati per ogni microservizio.

  • Il bus di servizio offre una messaggistica cloud affidabile come servizio e una semplice integrazione ibrida. Il bus di servizio supporta modelli di messaggistica asincroni comuni nelle applicazioni di microservizi. In questa architettura il bus di servizio funge da livello di accodamento asincrono tra i microservizi di inserimento e flusso di lavoro.

  • Cache Redis di Azure aggiunge un livello di memorizzazione nella cache all'architettura dell'applicazione per migliorare la velocità e le prestazioni per carichi di traffico elevato. In questa architettura, il microservizio di recapito usa Cache Redis di Azure come archivio stati e cache laterale.

  • Monitoraggio di Azure raccoglie e archivia metriche e log, inclusi i dati di telemetria dell'applicazione e le metriche della piattaforma e del servizio di Azure. In questa architettura è possibile usare questi dati per monitorare l'applicazione, configurare avvisi e dashboard ed eseguire l'analisi della causa radice degli errori.

Altre operazioni supportano i componenti di sistema

  • Helm è uno strumento di gestione pacchetti per Kubernetes che aggrega gli oggetti Kubernetes in una singola unità che è possibile pubblicare, distribuire, versione e aggiornare. In questa architettura usare i comandi Helm per creare un pacchetto e distribuire microservizi nel cluster del servizio Azure Kubernetes.

  • Provider di driver CSI dell'archivio segreti dell'insieme di credenziali delle chiavi Il provider di Key Vault per il driver CSI dell'archivio segreti consente l'integrazione di un insieme di credenziali delle chiavi come archivio segreto con un cluster del servizio Azure Kubernetes tramite un volume CSI. In questa architettura, i segreti dell'insieme di credenziali delle chiavi vengono montati come volume in contenitori di microservizi in modo che i microservizi possano recuperare le credenziali per Azure Cosmos DB, Cache Di Azure per Redis e bus di servizio.

  • Flux è una soluzione di recapito continuo aperta ed estendibile per Kubernetes che abilita GitOps nel servizio Azure Kubernetes.

Le alternative

Invece di usare un componente aggiuntivo di routing delle applicazioni, è possibile usare alternative come il gateway applicazione per contenitori e il componente aggiuntivo gateway Istio. Per un confronto delle opzioni di ingresso nel servizio Azure Kubernetes, vedere Ingresso nel servizio Azure Kubernetes. Il gateway applicazione per contenitori è un'evoluzione del controller di ingresso del gateway applicazione e offre funzionalità aggiuntive, ad esempio la suddivisione del traffico e il bilanciamento del carico round robin ponderato.

È possibile usare ArgoCD come strumento GitOps anziché Flux v2. Sia Flux v2 che ArgoCD sono disponibili come estensioni del cluster.

Anziché archiviare le credenziali per Azure Cosmos DB e Cache Redis di Azure negli insiemi di credenziali delle chiavi, è consigliabile usare le identità gestite per l'autenticazione perché i meccanismi di autenticazione senza password sono più sicuri. Per altre informazioni, vedere Usare le identità gestite per connettersi ad Azure Cosmos DB da una macchina virtuale di Azure e Autenticare un'identità gestita usando Microsoft Entra ID per accedere alle risorse del bus di servizio. Cache Redis di Azure supporta anche l'autenticazione usando identità gestite.

Dettagli dello scenario

L'esempio Fabrikam Drone Delivery Shipping App illustrato nel diagramma precedente implementa i componenti e le procedure architetturali descritti in questo articolo. In questo esempio Fabrikam, Inc., una società fittizia, gestisce una flotta di aerei da drone. Le aziende possono registrarsi per usare il servizio e gli utenti possono richiedere un drone per prelevare merci da consegnare. Quando un cliente pianifica un ritiro, il sistema back-end assegna un drone e invia una notifica all'utente con un tempo di consegna stimato. Mentre la consegna è in corso, il cliente può tenere traccia della posizione del drone e vedere un tempo stimato di arrivo costantemente aggiornato.

Consigli

È possibile applicare le raccomandazioni seguenti alla maggior parte degli scenari. Seguire queste indicazioni, a meno che non si disponga di un requisito specifico che le escluda.

Ingresso NGINX gestito con componente aggiuntivo di routing delle applicazioni

Il routing del gateway API è un modello di progettazione di microservizi generale. Un gateway API funziona come proxy inverso che instrada le richieste dai client ai microservizi. La risorsa di ingresso Kubernetes e il controller di ingresso gestiscono la maggior parte delle funzionalità del gateway API eseguendo le azioni seguenti:

  • Instradare le richieste client ai servizi back-end corretti per fornire un singolo endpoint per i client e separare i client dai servizi

  • Aggregazione di più richieste in una singola richiesta per ridurre il chatter tra il client e il back-end

  • Funzionalità di offload come la terminazione SSL (Secure Sockets Layer), l'autenticazione, le restrizioni degli indirizzi IP e la limitazione o la limitazione della frequenza client dai servizi back-end

I controller di ingresso semplificano l'inserimento del traffico nei cluster del servizio Azure Kubernetes, migliorano la sicurezza e le prestazioni e salvano le risorse. Questa architettura usa l'ingresso NGINX gestito con il componente aggiuntivo di routing dell'applicazione per il controllo in ingresso.

È consigliabile usare il controller di ingresso con un indirizzo IP interno (privato) e un servizio di bilanciamento del carico interno e integrarsi nelle zone del sistema dei nomi di dominio privato di Azure per la risoluzione dei nomi host dei microservizi. Configurare l'indirizzo IP privato o il nome host del controller di ingresso come indirizzo del pool back-end nel gateway applicazione. Il gateway applicazione riceve il traffico sull'endpoint pubblico, esegue ispezioni WAF e indirizza il traffico all'indirizzo IP privato in ingresso.

È necessario configurare il controller di ingresso con un nome di dominio personalizzato e un certificato SSL in modo che il traffico sia crittografato end-to-end. Il gateway applicazione riceve traffico nel listener HTTPS. Dopo le ispezioni waf, il gateway applicazione instrada il traffico all'endpoint HTTPS del controller di ingresso. Tutti i microservizi devono essere configurati con nomi di dominio personalizzati e certificati SSL in modo che la comunicazione tra microservizi all'interno del cluster servizio Azure Kubernetes sia protetta anche tramite SSL.

I carichi di lavoro multi-tenant o un singolo cluster che supporta gli ambienti di sviluppo e test potrebbero richiedere più controller di ingresso. Il componente aggiuntivo di routing delle applicazioni supporta configurazioni e personalizzazioni avanzate, inclusi più controller di ingresso all'interno dello stesso cluster del servizio Azure Kubernetes e l'uso di annotazioni per configurare le risorse di ingresso.

Criteri di rete Zero Trust

I criteri di rete specificano il modo in cui i pod del servizio Azure Kubernetes possono comunicare tra loro e con altri endpoint di rete. Per impostazione predefinita, tutto il traffico in ingresso e in uscita è consentito da e verso i pod. Quando si progetta il modo in cui i microservizi comunicano tra loro e con altri endpoint, è consigliabile seguire un principio Zero Trust, in cui l'accesso a qualsiasi servizio, dispositivo, applicazione o repository di dati richiede una configurazione esplicita.

Una strategia per implementare un criterio Zero Trust consiste nel creare criteri di rete che negano tutto il traffico in ingresso e in uscita a tutti i pod all'interno dello spazio dei nomi di destinazione. Nell'esempio seguente viene illustrato un criterio di negazione di tutti i criteri che si applicano a tutti i pod che si trovano nello spazio dei backend-dev nomi .

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: backend-dev
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Dopo che sono stati applicati criteri restrittivi, iniziare a definire regole di rete specifiche per consentire il traffico in ingresso e in uscita da ogni pod nel microservizio. Nell'esempio seguente i criteri di rete vengono applicati a qualsiasi pod nello spazio dei backend-dev nomi con un'etichetta corrispondente app.kubernetes.io/component: backenda . Il criterio nega il traffico a meno che non venga originato da un pod con un'etichetta corrispondente a app.kubernetes.io/part-of: dronedelivery.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: package-v010-dev-np-allow-ingress-traffic
  namespace: backend-dev
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/component: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app.kubernetes.io/part-of: dronedelivery
    ports:
    - port: 80
      protocol: TCP

Per altre informazioni sui criteri di rete kubernetes e altri esempi di potenziali criteri predefiniti, vedere Criteri di rete nella documentazione di Kubernetes.

Azure offre tre motori di criteri di rete per l'applicazione dei criteri di rete:

È consigliabile usare Cilium come motore dei criteri di rete.

Quote di risorse

Gli amministratori usano le quote di risorse per riservare e limitare le risorse in un team di sviluppo o in un progetto. È possibile impostare le quote di risorse in uno spazio dei nomi e usarle per impostare limiti sulle risorse seguenti:

  • Risorse di calcolo, ad esempio CPU e memoria, o GPU
  • Risorse di archiviazione, incluso il numero di volumi o la quantità di spazio su disco per una determinata classe di archiviazione
  • Numero di oggetti, ad esempio il numero massimo di segreti, servizi o processi che è possibile creare

Dopo che il totale cumulativo delle richieste o dei limiti delle risorse supera la quota assegnata, non vengono eseguite altre distribuzioni.

Le quote di risorse assicurano che il set totale di pod assegnati allo spazio dei nomi non possa superare la quota di risorse dello spazio dei nomi. Il front-end non può usare tutte le risorse per i servizi back-end e il back-end non può usare tutte le risorse per i servizi front-end.

Quando si definiscono le quote di risorse, tutti i pod creati nello spazio dei nomi devono fornire limiti o richieste nelle relative specifiche dei pod. Se non forniscono questi valori, la distribuzione viene rifiutata.

L'esempio seguente illustra una specifica del pod che imposta le richieste e i limiti delle quote delle risorse:

requests:
  cpu: 100m
  memory: 350Mi
limits:
  cpu: 200m
  memory: 500Mi

Per altre informazioni sulle quote delle risorse, vedere:

Scalabilità automatica

Kubernetes supporta la scalabilità automatica per aumentare il numero di pod allocati a una distribuzione o per aumentare i nodi nel cluster per aumentare il totale delle risorse di calcolo disponibili. La scalabilità automatica è un sistema di feedback autonomo auto-corretto. È possibile ridimensionare manualmente pod e nodi, ma la scalabilità automatica riduce al minimo le probabilità che i servizi raggiungano i limiti delle risorse a carichi elevati. Una strategia di scalabilità automatica deve tenere conto sia dei pod che dei nodi.

La scalabilità automatica del cluster

La scalabilità automatica del cluster (CA) ridimensiona il numero di nodi. Se i pod non possono essere pianificati a causa di vincoli di risorse, il ridimensionamento automatico del cluster effettua il provisioning di più nodi. Si definisce un numero minimo di nodi per mantenere operativo il cluster del servizio Azure Kubernetes e i carichi di lavoro e un numero massimo di nodi per il traffico elevato. La CA controlla ogni pochi secondi la presenza di pod in sospeso o nodi vuoti e ridimensiona il cluster del servizio Azure Kubernetes in modo appropriato.

L'esempio seguente illustra la configurazione della CA dal modello Bicep:

autoScalerProfile: {
  'scan-interval': '10s'
  'scale-down-delay-after-add': '10m'
  'scale-down-delay-after-delete': '20s'
  'scale-down-delay-after-failure': '3m'
  'scale-down-unneeded-time': '10m'
  'scale-down-unready-time': '20m'
  'scale-down-utilization-threshold': '0.5'
  'max-graceful-termination-sec': '600'
  'balance-similar-node-groups': 'false'
  expander: 'random'
  'skip-nodes-with-local-storage': 'true'
  'skip-nodes-with-system-pods': 'true'
  'max-empty-bulk-delete': '10'
  'max-total-unready-percentage': '45'
  'ok-total-unready-count': '3'
}

Le righe seguenti nel set di modelli Bicep esempio di nodi minimo e massimo per il ridimensionamento automatico del cluster:

minCount: 2
maxCount: 5

Scalabilità automatica orizzontale dei pod

Horizontal Pod Autoscaler (HPA) ridimensiona i pod in base a CPU, memoria o metriche personalizzate osservate. Per configurare il ridimensionamento orizzontale dei pod, specificare le metriche di destinazione e il numero minimo e massimo di repliche nella specifica del pod di distribuzione Kubernetes. Testare il carico dei servizi per determinare questi numeri.

Ca e HPA interagiscono, quindi abilitare entrambe le opzioni di scalabilità automatica nel cluster del servizio Azure Kubernetes. HPA ridimensiona l'applicazione, mentre la CA ridimensiona l'infrastruttura.

L'esempio seguente imposta le metriche delle risorse per HPA:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: delivery-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: delivery
  minReplicas: 2
  maxReplicas: 5
  metrics:
  - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

HPA esamina le risorse effettive utilizzate o altre metriche dall'esecuzione di pod. La CA effettua il provisioning dei nodi per i pod non ancora pianificati. Di conseguenza, la CA esamina le risorse richieste, come specificato nella specifica del pod. Usare i test di carico per ottimizzare questi valori.

Per altre informazioni, vedere Opzioni di ridimensionamento per le applicazioni nel servizio Azure Kubernetes.

Ridimensionamento automatico verticale dei pod

Vertical Pod Autoscaler (VPA) regola automaticamente le richieste di CPU e memoria per i pod in modo che corrispondano ai modelli di utilizzo dei carichi di lavoro. Quando è configurata, la vpa imposta automaticamente le richieste di risorse e i limiti per i contenitori per ogni carico di lavoro in base all'utilizzo passato. La VPA rende disponibile CPU e memoria per altri pod e garantisce un utilizzo efficace dei cluster del servizio Azure Kubernetes.

In questa architettura, vpa aumenta le richieste di CPU e memoria e i limiti per i microservizi in base al passato utilizzo. Ad esempio, se il microservizio del flusso di lavoro usa più CPU rispetto ad altri microservizi, la vpa può monitorare questo utilizzo e aumentare i limiti di CPU per il microservizio del flusso di lavoro.

Scalabilità automatica guidata dagli eventi Kubernetes

Il componente aggiuntivo Kubernetes Event Driven Autoscaler (KEDA) consente la scalabilità automatica basata su eventi per ridimensionare il microservizio in modo da soddisfare la domanda in modo sostenibile e conveniente. Ad esempio, KEDA può aumentare le prestazioni dei microservizi quando il numero di messaggi nella coda del bus di servizio supera soglie specifiche.

Nell'esempio di recapito tramite drone Fabrikam KEDA aumenta il numero di istanze del microservizio del flusso di lavoro a seconda della profondità della coda del bus di servizio e in base all'output del microservizio di inserimento. Per un elenco dei scaler KEDA per i servizi di Azure, vedere Integrazioni con KEDA nel servizio Azure Kubernetes.

Probe di integrità

Kubernetes bilancia il carico del traffico verso i pod che corrispondono a un selettore di etichette per un servizio. Ricevono il traffico solo i pod avviati correttamente e integri. Se un contenitore si arresta in modo anomalo, Kubernetes rimuove il pod e pianifica una sostituzione.

Kubernetes definisce tre tipi di probe di integrità che un pod può esporre:

  • Il probe di idoneità indica a Kubernetes se il pod è pronto per accettare le richieste.

  • Il probe di attività indica a Kubernetes se rimuovere un pod e avviare una nuova istanza.

  • Il probe di avvio indica a Kubernetes se il pod è stato avviato.

I probe di attività gestiscono i pod ancora in esecuzione, ma non integri e devono essere riciclati. Ad esempio, se un contenitore che gestisce le richieste HTTP si blocca, il contenitore non si arresta in modo anomalo, ma smette di gestire le richieste. Il probe di attività HTTP smette di rispondere, che avvisa Kubernetes di riavviare il pod.

In alcuni casi, un pod potrebbe non essere pronto per ricevere traffico, anche se il pod è stato avviato correttamente. Ad esempio, l'applicazione in esecuzione nel contenitore potrebbe eseguire attività di inizializzazione. Il probe di idoneità indica se il pod è pronto per ricevere traffico.

I microservizi devono esporre gli endpoint nel codice che facilitano i probe di integrità, con timeout e ritardo personalizzati in modo specifico per i controlli eseguiti. La formula HPA si basa sulla fase pronta del pod, quindi è fondamentale che i probe di integrità esistano e siano accurati.

Monitoraggio

In un'applicazione di microservizi, il monitoraggio della gestione delle prestazioni delle applicazioni è fondamentale per rilevare anomalie, diagnosticare i problemi e comprendere rapidamente le dipendenze tra i servizi. Application Insights, una funzionalità di Monitoraggio di Azure, fornisce il monitoraggio APM per le applicazioni live scritte in .NET Core, Node.js, Java e molti altri linguaggi applicativi.

Azure offre vari meccanismi per il monitoraggio dei carichi di lavoro dei microservizi:

  • Prometheus gestito per la raccolta di metriche. Usare Prometheus per monitorare e avvisare le prestazioni dell'infrastruttura e dei carichi di lavoro.

  • Il servizio gestito di Monitoraggio di Azure per Prometheus e le informazioni dettagliate sui contenitori interagiscono per il monitoraggio completo dell'ambiente Kubernetes.

  • Grafana gestita per la visualizzazione di cluster e microservizi.

Per contestualizzare i dati di telemetria del servizio in Kubernetes, integrare i dati di telemetria di Monitoraggio di Azure con il servizio Azure Kubernetes per raccogliere metriche da controller, nodi, contenitori e log di contenitori e nodi. È possibile integrare Application Insights con il servizio Azure Kubernetes senza modifiche al codice.

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di set di principi guida che è possibile usare per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Well-Architected Framework.

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'uso improprio dei dati e dei sistemi preziosi. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per Security.

Quando si pianifica la sicurezza, tenere presenti i punti seguenti.

  • Usare le misure di sicurezza della distribuzione nel cluster del servizio Azure Kubernetes. Le protezioni di distribuzione applicano le procedure consigliate di Kubernetes nel cluster del servizio Azure Kubernetes tramite i controlli di Criteri di Azure.

  • Integrare l'analisi della sicurezza nelle pipeline di compilazione e distribuzione di microservizi. Gestire l'ambiente DevOps usando la sicurezza di Microsoft Defender for Cloud DevOps. Usare l'analisi del codice senza agente ed eseguire strumenti di analisi del codice statico come parte delle pipeline di integrazione continua e distribuzione continua (CI/CD) in modo da poter identificare e risolvere le vulnerabilità del codice del microservizio come parte dei processi di compilazione e distribuzione.

  • Un pod del servizio Azure Kubernetes viene autenticato usando un'identità del carico di lavoro archiviata nell'ID Microsoft Entra. È consigliabile usare un'identità del carico di lavoro perché non richiede un segreto client.

  • Quando si usano identità gestite, l'applicazione può ottenere rapidamente i token OAuth 2.0 di Azure Resource Manager durante l'esecuzione. Non sono necessarie password o stringhe di connessione. Nel servizio Azure Kubernetes è possibile assegnare identità a singoli pod usando l'ID del carico di lavoro.

  • A ogni servizio nell'applicazione di microservizio deve essere assegnata un'identità univoca del carico di lavoro per facilitare le assegnazioni di controllo degli accessi in base al ruolo con privilegi minimi. È consigliabile assegnare identità solo ai servizi che li richiedono.

  • Nei casi in cui un componente dell'applicazione richiede l'accesso all'API Kubernetes, assicurarsi che i pod dell'applicazione siano configurati per l'uso di un account del servizio con accesso api con ambito appropriato. Per altre informazioni, vedere Gestire gli account del servizio Kubernetes.

  • Non tutti i servizi di Azure supportano l'uso dell'ID Microsoft Entra per l'autenticazione del piano dati. Per archiviare le credenziali o i segreti dell'applicazione per tali servizi, per i servizi non Microsoft o per le chiavi API, usare Key Vault. Key Vault offre gestione centralizzata, controllo di accesso, crittografia dei dati inattivi e controllo di tutte le chiavi e i segreti.

  • Nel servizio Azure Kubernetes, è possibile montare uno o più segreti da Key Vault come volume. Il pod può quindi leggere i segreti di Key Vault esattamente come un volume normale. Per altre informazioni, vedere Usare il provider di Key Vault per il driver CSI dell'archivio segreti in un cluster del servizio Azure Kubernetes. È consigliabile mantenere insiemi di credenziali delle chiavi separati per ogni microservizio. L'implementazione di riferimento usa insiemi di credenziali delle chiavi separati per ogni microservizio.

  • Se il microservizio deve comunicare con risorse, ad esempio URL esterni, all'esterno del cluster, controllare l'accesso tramite Firewall di Azure. Se il microservizio non deve effettuare chiamate in uscita, usare cluster isolati di rete.

  • Abilitare Microsoft Defender per contenitori per fornire la gestione del comportamento di sicurezza, la valutazione delle vulnerabilità per i microservizi, la protezione dalle minacce in fase di esecuzione e altre funzionalità di sicurezza.

Ottimizzazione costi

L'ottimizzazione dei costi è incentrata sui modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'ottimizzazione dei costi.

  • La sezione Ottimizzazione costi in Well-Architected Framework descrive le considerazioni sui costi.

  • Usare il calcolatore prezzi di Azure per stimare i costi per lo scenario specifico.

  • Nel livello Gratuito il servizio Azure Kubernetes non prevede costi associati alla distribuzione, alla gestione e alle operazioni del cluster Kubernetes. Si paga solo per le istanze di macchina virtuale, l'archiviazione e le risorse di rete usate dal cluster. La scalabilità automatica del cluster può ridurre significativamente il costo del cluster rimuovendo nodi vuoti o inutilizzati.

  • Prendere in considerazione l'uso del livello Gratuito del servizio Azure Kubernetes per i carichi di lavoro di sviluppo e usare i livelli Standard e Premium per i carichi di lavoro di produzione.

  • Valutare la possibilità di abilitare l'analisi dei costi di AKS per l'allocazione granulare dei costi dell'infrastruttura del cluster da costrutti specifici di Kubernetes.

Eccellenza operativa

L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e lo mantengono in esecuzione nell'ambiente di produzione. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'eccellenza operativa.

Quando si pianifica la gestibilità, tenere presente quanto segue.

  • Gestire l'infrastruttura del cluster del servizio Azure Kubernetes tramite una pipeline di distribuzione automatizzata. L'implementazione di riferimento per questa architettura fornisce un flusso di lavoro di GitHub Actions a cui è possibile fare riferimento quando si compila la pipeline.

  • Il file del flusso di lavoro distribuisce l'infrastruttura solo, non il carico di lavoro, nella rete virtuale già esistente e nella configurazione di Microsoft Entra. La distribuzione dell'infrastruttura e del carico di lavoro separatamente consente di risolvere problemi di ciclo di vita e operativi distinti.

  • Prendere in considerazione il flusso di lavoro come meccanismo per la distribuzione in un'altra area in caso di errore a livello di area. Compilare la pipeline in modo che sia possibile distribuire un nuovo cluster in una nuova area con modifiche ai parametri e all'input.

Efficienza delle prestazioni

L'efficienza delle prestazioni si riferisce alla capacità del carico di lavoro di ridimensionarsi per soddisfare in modo efficiente le esigenze degli utenti. Per altre informazioni, vedere Elenco di controllo per l'efficienza delle prestazioni.

Quando si pianifica la scalabilità, tenere presente quanto segue.

  • Non combinare la scalabilità automatica e la gestione imperativa o dichiarativa del numero di repliche. Gli utenti e un'utilità di scalabilità automatica tentano di modificare il numero di repliche potrebbero causare un comportamento imprevisto. Quando HPA è abilitato, ridurre il numero di repliche al numero minimo da distribuire.

  • Un effetto collaterale della scalabilità automatica dei pod è che i pod possono essere creati o rimossi spesso quando l'applicazione aumenta o aumenta il numero di istanze. Per attenuare questi effetti, eseguire le azioni seguenti:

    • Usare probe di idoneità per consentire a Kubernetes di sapere quando un nuovo pod è pronto per accettare il traffico.
    • Usare i budget di interruzioni di pod per limitare il numero di pod che possono essere eliminati da un servizio alla volta.

  • Se è presente un numero elevato di flussi in uscita dal microservizio, prendere in considerazione l'uso dei gateway network Address Translation per evitare l'esaurimento delle porte di Source Network Address Translation.

  • I carichi di lavoro multi-tenant o altri carichi di lavoro avanzati potrebbero avere requisiti di isolamento del pool di nodi che richiedono più subnet e probabilmente più piccole. Per altre informazioni, vedere Aggiungere pool di nodi con subnet univoche. Le organizzazioni hanno standard diversi per le implementazioni hub-spoke. Assicurarsi di seguire le linee guida dell'organizzazione.

  • Prendere in considerazione l'uso di CNI con la rete sovrapposta per risparmiare spazio indirizzi di rete.

Passaggi successivi