Modifica

Architettura di microservizi nel servizio Azure Kubernetes

Gateway applicazione di Azure
Registro Azure Container
Servizio Azure Kubernetes
Rete virtuale di Azure

Questa architettura di riferimento illustra in dettaglio diverse configurazioni da considerare quando si eseguono microservizi in servizio Azure Kubernetes. Gli argomenti includono 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 baseline del servizio Azure Kubernetes, punto di partenza consigliato da Microsoft per l'infrastruttura del servizio Azure Kubernetes. La baseline del servizio Azure Kubernetes illustra in dettaglio le funzionalità structurali, ad esempio le ID dei carichi di lavoro di Microsoft Entra, le restrizioni in ingresso e in uscita, i limiti delle risorse e altre configurazioni dell'infrastruttura del servizio Azure Kubernetes sicure. Questi dettagli infrastrutturali non sono trattati in questo documento. È consigliabile acquisire familiarità con la baseline del servizio Azure Kubernetes prima di procedere con il contenuto dei microservizi.

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

Architettura

Network diagram showing the hub-spoke network with two peered virtual networks and the Azure resources this implementation uses.

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 messaggistica procede come segue:

  1. Viene inviata una richiesta HTTPS per pianificare un ritiro tramite drone. Le richieste passano attraverso app Azure lication Gateway nell'applicazione Web di inserimento, che viene eseguita come microservizio nel cluster nel servizio Azure Kubernetes.

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

  3. Il sistema back-end assegna un drone e invia una notifica all'utente. Flusso di lavoro:

    • Utilizza le informazioni sui messaggi dalla coda di messaggi bus di servizio.
    • Invia una richiesta HTTPS al microservizio Recapito, che passa i dati a cache di Azure per Redis'archiviazione dati esterna.
    • Invia una richiesta HTTPS al microservizio Dell'utilità di pianificazione drone.
    • Invia una richiesta HTTPS al microservizio Package, che passa i dati all'archiviazione dati esterna mongoDB.

  4. Una richiesta HTTPS GET viene usata per restituire lo stato di recapito. Questa richiesta passa attraverso il gateway applicazione nel microservizio Recapito.

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

Componenti

Questa architettura usa i componenti di Azure seguenti:

servizio Azure Kubernetes è un'offerta di Azure che fornisce un cluster Kubernetes gestito. Quando si usa il servizio Azure Kubernetes, il server API Kubernetes viene gestito da Azure. I nodi o i pool di nodi Kubernetes sono accessibili e possono essere gestiti dall'operatore del cluster.

Le funzionalità dell'infrastruttura del servizio Azure Kubernetes usate in questa architettura includono:

Le Rete virtuale di Azure sono ambienti isolati e altamente sicuri per l'esecuzione di macchine virtuali e applicazioni. Questa architettura di riferimento usa una topologia di rete virtuale hub-spoke con peering. La rete virtuale hub contiene il firewall di Azure e le subnet di Azure Bastion. La rete virtuale spoke contiene le subnet del sistema del servizio Azure Kubernetes e del pool di nodi utente e la subnet del gateway di app Azure lication.

collegamento privato di Azure alloca indirizzi IP privati specifici per accedere a Registro Azure Container e Key Vault da endpoint privati all'interno della subnet del sistema del servizio Azure Kubernetes e del pool di nodi utente.

gateway app Azure lication con web application firewall (WAF) espone le route HTTP(S) al cluster servizio Azure Kubernetes e bilancia il carico del traffico Web all'applicazione Web. Questa architettura usa app Azure lication Gateway Ingress Controller (AGIC) come controller di ingresso Kubernetes.

Azure Bastion fornisce l'accesso SECURE Remote Desktop Protocol (RDP) e secure shell (SSH) alle macchine virtuali nelle reti virtuali usando un ssl (Secure Socket Layer), senza la necessità di esporre le macchine virtuali tramite indirizzi IP pubblici.

Firewall di Azure è un servizio di sicurezza di rete che protegge tutte le risorse di Azure Rete virtuale. Il firewall consente solo servizi approvati e nomi di dominio completi (FQDN) come traffico in uscita.

Archiviazione esterna e altri componenti:

Azure Key Vault archivia e gestisce le chiavi di sicurezza per i servizi servizio Azure Kubernetes.

Registro Azure 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.

Azure Cosmos DB archivia i dati usando Azure Cosmos DB open source per MongoDB. I microservizi sono in genere senza stato e scrivono il proprio stato in archivi dati esterni. Azure Cosmos DB è un database NoSQL con API open source per MongoDB e Cassandra.

bus di servizio di Azure offre una messaggistica cloud affidabile come servizio e una semplice integrazione ibrida. bus di servizio supporta modelli di messaggistica asincroni comuni alle applicazioni di microservizi.

cache di Azure per Redis aggiunge un livello di memorizzazione nella cache all'architettura dell'applicazione per migliorare la velocità e le prestazioni per carichi di traffico pesanti.

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. È possibile usare questi dati per monitorare l'applicazione, configurare avvisi e dashboard ed eseguire l'analisi della causa radice degli errori.

Altri componenti del sistema di supporto operativo (OSS):

Helm, una gestione pacchetti per Kubernetes che aggrega gli oggetti Kubernetes in una singola unità che è possibile pubblicare, distribuire, versione e aggiornare.

Il provider CSI dell'archivio segreto di Azure Key Vault ottiene i segreti archiviati in Azure Key Vault e usa l'interfaccia del driver CSI dell'archivio segreti per montarli in pod Kubernetes.

Flux, una soluzione di recapito continuo aperta ed estendibile per Kubernetes, basata su GitOps Toolkit.

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 con un ETA aggiornato continuamente.

Potenziali casi d'uso

Questa soluzione è ideale per le industrie aeree, aerospaziali e aeree.

Consigli

Implementare questi consigli quando si distribuiscono architetture avanzate di microservizi del servizio Azure Kubernetes.

controller di ingresso (AGIC) gateway applicazione

Il routing del gateway API è un modello di progettazione di microservizi generale. Un gateway API funge da 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 tramite:

Il routing delle richieste client ai servizi back-end corretti fornisce un singolo endpoint per i client e consente di separare i client dai servizi.

  • Aggregazione di più richieste in una singola richiesta per ridurre il chatter tra il client e il back-end.
  • Offload di funzionalità come terminazione SSL, autenticazione, restrizioni IP e limitazione della frequenza client dai servizi back-end.

Lo stato del cluster del servizio Azure Kubernetes viene convertito in gateway applicazione configurazione specifica e applicata tramite Azure Resource Manager.

I controller di ingresso esterni semplificano l'inserimento del traffico nei cluster del servizio Azure Kubernetes, migliorano la sicurezza e le prestazioni e salvano le risorse. Questa architettura usa il controller di ingresso (AGIC) del gateway di app Azure per il controllo in ingresso. L'uso di gateway applicazione per gestire tutto il traffico elimina la necessità di un servizio di bilanciamento del carico aggiuntivo. Poiché i pod stabiliscono connessioni dirette a gateway applicazione, il numero di hop necessari viene ridotto, con prestazioni migliori.

gateway applicazione include funzionalità di scalabilità automatica predefinite, a differenza dei controller di ingresso in cluster che devono essere ridimensionati se utilizzano una quantità indesiderata di risorse di calcolo. gateway applicazione possibile eseguire il routing e la terminazione SSL di livello 7 e include TLS (Transport Layer Security) end-to-end integrato con un web application firewall (WAF) predefinito.

Per l'opzione ingresso AGIC, è necessario abilitare la rete CNI quando si configura il cluster del servizio Azure Kubernetes perché gateway applicazione viene distribuito in una subnet della rete virtuale del servizio Azure Kubernetes. I carichi di lavoro multi-tenant o un singolo cluster che supporta gli ambienti di sviluppo e test potrebbero richiedere più controller di ingresso.

Criteri di rete senza attendibilità

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 nell'implementazione di 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 'deny all policy' che verrebbe applicato a tutti i pod che si trovano nello spazio dei nomi back-end-dev.

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

Dopo aver definito 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 nomi back-end-dev con un'etichetta corrispondente a app.kubernetes.io/component: back-end. Il criterio nega il traffico a meno che non venga originato da un pod con un'etichetta corrispondente 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.

Quote di risorse

Le quote di risorse consentono agli amministratori di 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 i limiti per:

  • Risorse di calcolo, come CPU e memoria o le GPU.
  • Archiviazione risorse, 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.

Una volta che il totale cumulativo delle richieste di risorse o dei limiti supera la quota assegnata, nessun'altra distribuzione successiva ha esito positivo.

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ò starvezzare i servizi back-end per le risorse o viceversa.

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 mostra una specifica di 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 aumentare i nodi nel cluster per aumentare le risorse di calcolo totali disponibili. La scalabilità automatica è un sistema di feedback autonomo auto-corretto. Anche se è possibile ridimensionare manualmente pod e nodi, la scalabilità automatica riduce al minimo le probabilità che i servizi diventino a carico elevato. Una strategia di scalabilità automatica deve prendere in considerazione sia i pod che i nodi.

La scalabilità automatica del cluster

Il ridimensionamento automatico del cluster ridimensiona il numero di nodi. Si supponga che i pod non possano 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 di Resource Manager:

"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 di Resource Manager sono i nodi minimo e massimo per la CA:

"minCount": 2,
"maxCount": 5,

Scalabilità automatica 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 funzionano bene insieme, 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/v2beta2
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
        targetAverageUtilization: 60

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

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.

In Kubernetes un pod può esporre due tipi di probe di integrità:

  • Il probe di attività indica a Kubernetes se un pod è stato avviato correttamente ed è integro.
  • Il probe di idoneità indica a Kubernetes se un pod è pronto per accettare le richieste.

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 informa 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 ritardo e timeout personalizzati in modo specifico per i controlli eseguiti. Le chiavi della formula HPA quasi esclusivamente fuori dalla fase Ready in un pod, quindi è fondamentale che i probe di integrità esistano e siano accurati.

Monitoraggio

In un'applicazione di microservizi, il monitoraggio di Application Performance Management (APM) è fondamentale per rilevare anomalie, diagnosticare i problemi e comprendere rapidamente le dipendenze tra i servizi. Application Insights, che fa parte di Monitoraggio di Azure, fornisce il monitoraggio APM per le applicazioni live scritte in .NET Core, Node.js, Java e molti altri linguaggi applicativi.

Application Insights:

  • Registra le richieste HTTP, inclusa la latenza e il codice dei risultati.
  • Abilita la traccia distribuita per impostazione predefinita.
  • Include un ID operazione nelle tracce, in modo che sia possibile trovare tutte le tracce per una determinata operazione.
  • Spesso include informazioni contestuali aggiuntive nelle tracce.

Per contestualizzare i dati di telemetria dei servizi con il mondo Kubernetes, integrare i dati di telemetria di Monitoraggio di Azure con il servizio Azure Kubernetes per raccogliere metriche da controller, nodi e contenitori, nonché dai log dei contenitori e dei nodi. Se si usa .NET, la libreria di Application Insights per Kubernetes arricchisce i dati di telemetria di Application Insights con informazioni su immagine, contenitore, nodo, pod, etichetta e set di repliche.

Il diagramma seguente mostra un esempio della mappa delle dipendenze dell'applicazione generata da Application Insights per una traccia di telemetria dei microservizi del servizio Azure Kubernetes:

Example of an Application Insights dependency map for an AKS microservices application.

Per altre informazioni sulle opzioni per instrumentare linguaggi comuni per l'integrazione di Application Insights, vedere Monitoraggio delle applicazioni per Kubernetes.

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Framework ben progettato di Microsoft Azure.

Scalabilità

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 entrambi di modificare il numero di repliche possono 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 frequentemente, man mano che si verificano eventi di scalabilità orizzontale e scalabilità orizzontale. Per attenuare questi effetti:

    • 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.

  • Non è possibile modificare le dimensioni della macchina virtuale dopo la creazione di un cluster, quindi è possibile pianificare la capacità iniziale per scegliere le dimensioni della macchina virtuale appropriate per i nodi dell'agente quando si crea il cluster.

  • 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 sulla creazione di pool di nodi con subnet univoche, vedere Aggiungere un pool di nodi con una subnet univoca. Le organizzazioni hanno standard diversi per le implementazioni hub-spoke. Assicurarsi di seguire le linee guida dell'organizzazione.

Gestione

Quando si pianifica la gestibilità, tenere presenti i punti seguenti.

  • 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 durante la compilazione della 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 distinti relativi al ciclo di vita e alle operazioni.

  • Considerare 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 di parametro e input.

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per altre informazioni, vedere Panoramica del pilastro della sicurezza.

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

  • Un pod del servizio Azure Kubernetes si autentica usando un'identità del carico di lavoro archiviata nell'ID Microsoft Entra. L'uso di un'identità del carico di lavoro è preferibile perché non richiede un segreto client.

  • Con le identità gestite, il processo di esecuzione può ottenere rapidamente token OAuth 2.0 di Azure Resource Manager; non sono necessarie password o stringa di connessione. Nel servizio Azure Kubernetes è possibile assegnare identità a singoli pod usando ID dei carichi di lavoro di Microsoft Entra.

  • 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 sulla configurazione e la gestione dell'account del servizio Kubernetes, vedere Gestione degli account del servizio Kubernetes.

  • Non tutti i servizi di Azure supportano l'autenticazione del piano dati usando Microsoft Entra ID. Per archiviare le credenziali o i segreti dell'applicazione per tali servizi, per i servizi di terze parti o per le chiavi API, usare Azure Key Vault. Azure 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 il progetto secrets-store-csi-driver-provider-azure in GitHub.

Ottimizzazione dei costi

L'ottimizzazione dei costi riguarda l'analisi dei modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Panoramica del pilastro di ottimizzazione dei costi.

  • La sezione Costo in Microsoft Azure Well-Architected Framework descrive le considerazioni sui costi. Usare il calcolatore prezzi di Azure per stimare i costi per lo scenario specifico.

  • 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.

  • Per stimare il costo delle risorse necessarie, vedere il calcolatore di Servizi contenitore.

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

Passaggi successivi