Architettura di base per un cluster del servizio Azure Kubernetes (AKS)

Questa architettura di riferimento fornisce un'architettura di infrastruttura di base consigliata per distribuire un cluster del servizio Azure Kubernetes (servizio Azure Kubernetes) in Azure. Usa i principi di progettazione e si basa sulle procedure consigliate per l'architettura di Azure Well-Architected Framework per guidare un team multidisciplinare o più team distinti, ad esempio rete, sicurezza e identità, attraverso l'implementazione di questa infrastruttura per utilizzo generico.

Questa architettura non è incentrata su un carico di lavoro, ma si concentra sul cluster del servizio Azure Kubernetes stesso. Le informazioni riportate di seguito sono la baseline minima consigliata per la maggior parte dei cluster del servizio Azure Kubernetes. Si integra con i servizi di Azure che offrono osservabilità, una topologia di rete che supporta la crescita a più aree e protegge il traffico in cluster.

L'architettura di destinazione è influenzata dai requisiti aziendali e di conseguenza può variare tra contesti di applicazione diversi. Deve essere considerato il punto di partenza per le fasi di pre-produzione e produzione.

Un'implementazione di questa architettura è disponibile anche in GitHub: implementazione di riferimento della baseline di servizio Azure Kubernetes (servizio Azure Kubernetes). È possibile usarlo come punto di partenza alternativo e configurarlo in base alle proprie esigenze.

Configurazione della rete

Topologia di rete
Pianificare gli indirizzi IP
Distribuire le risorse in ingresso

Calcolo del cluster

Calcolo per il cluster di base
Informazioni di riferimento sulle immagini del contenitore
Gestione dei criteri

Gestione delle identità

Integrare l'ID Microsoft Entra per il cluster
Integrare l'ID Microsoft Entra per il carico di lavoro

Proteggere il flusso di dati

Proteggere il flusso di rete
Aggiungere la gestione dei segreti

Continuità aziendale

Scalabilità
Disponibilità di cluster e nodi
Supporto per disponibilità e più aree

Operazioni

Pipeline CI/CD del cluster e del carico di lavoro
Integrità e metriche del cluster
Gestione dei costi e creazione di report

Topologia di rete

Questa architettura usa una topologia di rete hub-spoke. Gli hub e gli spoke vengono distribuiti in reti virtuali separate connesse tramite peering. Ecco alcuni vantaggi di questa topologia:

• Gestione separata. Consente di applicare la governance e di rispettare il principio dei privilegi minimi. Supporta anche il concetto di zona di destinazione di Azure con separazione dei compiti.

• Riduce al minimo l'esposizione diretta delle risorse di Azure alla rete Internet pubblica.

• Le organizzazioni spesso operano con topologie hub-spoke a livello di area. Le topologie di rete hub-spoke possono essere espanse in futuro e forniscono l'isolamento del carico di lavoro.

• Tutte le applicazioni Web devono richiedere un servizio di Web Application Firewall (WAF) per gestire il flusso del traffico HTTP.

• Questa è una scelta naturale per i carichi di lavoro che si estendono su più sottoscrizioni.

• Rende estendibile l'architettura. Per supportare nuove funzionalità o carichi di lavoro, è possibile aggiungere nuovi spoke anziché riprogettare la topologia di rete.

• Alcune risorse, ad esempio un firewall e un DNS, possono essere condivise tra reti.

• Allinea alle zone di destinazione su scala aziendale di Azure.

Scaricare un file di Visio di questa architettura.

Per altre informazioni, vedere Topologia di rete hub-spoke in Azure.

Per esaminare le modifiche alla progettazione di rete incluse nei contenitori di Windows nell'architettura di riferimento di base del servizio Azure Kubernetes, vedere l'articolo complementare.

Hub

La rete virtuale hub è il punto centrale di connettività e osservabilità. Un hub contiene sempre un Firewall di Azure con criteri firewall globali definiti dai team IT centrali per applicare criteri firewall a livello di organizzazione, Azure Bastion, una subnet del gateway per la connettività VPN e Monitoraggio di Azure per l'osservabilità della rete.

All'interno della rete vengono distribuite tre subnet.

Subnet per ospitare Firewall di Azure

Firewall di Azure è firewall come servizio. L'istanza del firewall protegge il traffico di rete in uscita. Senza questo livello di sicurezza, questo traffico potrebbe comunicare con un servizio dannoso di terze parti che potrebbe sottrarre i dati aziendali sensibili. Firewall di Azure Manager consente di distribuire e configurare centralmente più istanze di Firewall di Azure e gestire i criteri di Firewall di Azure per questo tipo di architettura di rete virtuale hub.

Subnet per ospitare un gateway

Questa subnet è un segnaposto per un gateway VPN o ExpressRoute. Il gateway fornisce la connettività tra i router nella rete locale e la rete virtuale.

Subnet per ospitare Azure Bastion

Questa subnet è un segnaposto per Azure Bastion. È possibile usare Bastion per accedere in modo sicuro alle risorse di Azure senza esporre le risorse a Internet. Questa subnet viene usata solo per la gestione e le operazioni.

Spoke

La rete virtuale spoke contiene il cluster del servizio Azure Kubernetes e altre risorse correlate. Lo spoke ha quattro subnet:

Subnet per ospitare il gateway applicazione di Azure

Il gateway applicazione di Azure è un servizio di bilanciamento del carico del traffico Web che opera al livello 7. L'implementazione di riferimento usa lo SKU gateway applicazione v2 che abilita Web Application Firewall (WAF). WAF protegge il traffico in ingresso da attacchi comuni al traffico Web, inclusi i bot. L'istanza ha una configurazione IP front-end pubblica che riceve le richieste utente. Per impostazione predefinita, il gateway applicazione richiede una subnet dedicata.

Subnet per ospitare le risorse di ingresso

Per instradare e distribuire il traffico, Traefik è il controller di ingresso che soddisfa le risorse in ingresso di Kubernetes. I servizi di bilanciamento del carico interno di Azure sono presenti in questa subnet. Per altre informazioni, vedere Usare un servizio di bilanciamento del carico interno con servizio Azure Kubernetes (servizio Azure Kubernetes).

Subnet per ospitare i nodi del cluster

Il servizio Azure Kubernetes gestisce due gruppi separati di nodi (o pool di nodi). Il pool di nodi di sistema ospita i pod che eseguono i servizi cluster di base. Il pool di nodi utente esegue il carico di lavoro e il controller di ingresso per abilitare la comunicazione in ingresso al carico di lavoro.

Subnet per ospitare endpoint di collegamento privato

collegamento privato di Azure vengono create connessioni per il Registro Azure Container e Azure Key Vault, quindi è possibile accedere a questi servizi usando un endpoint privato all'interno della rete virtuale spoke. Gli endpoint privati non richiedono una subnet dedicata e possono anche essere inseriti nella rete virtuale hub. Nell'implementazione di base, vengono distribuite in una subnet dedicata all'interno della rete virtuale spoke. Questo approccio riduce il traffico passando la connessione di rete con peering, mantiene le risorse appartenenti al cluster nella stessa rete virtuale e consente di applicare regole di sicurezza granulari a livello di subnet usando i gruppi di sicurezza di rete.

Per altre informazioni, vedere collegamento privato opzioni di distribuzione.

pianificazione degli indirizzi IP

Scaricare un file di Visio di questa architettura.

Lo spazio degli indirizzi della rete virtuale deve essere sufficientemente grande da contenere tutte le subnet. Tenere conto di tutte le entità che riceveranno il traffico. Gli indirizzi IP per tali entità verranno allocati dallo spazio indirizzi della subnet. Si considerino questi punti.

• Aggiornamento

  Il servizio Azure Kubernetes aggiorna regolarmente i nodi per assicurarsi che le macchine virtuali sottostanti siano aggiornate sulle funzionalità di sicurezza e su altre patch di sistema. Durante un processo di aggiornamento, il servizio Azure Kubernetes crea un nodo che ospita temporaneamente i pod, mentre il nodo di aggiornamento viene isolato e svuotato. A tale nodo temporaneo viene assegnato un indirizzo IP dalla subnet del cluster.

  Per i pod, potrebbero essere necessari indirizzi aggiuntivi a seconda della strategia. Per gli aggiornamenti in sequenza, sono necessari indirizzi per i pod temporanei che eseguono il carico di lavoro mentre i pod effettivi vengono aggiornati. Se si usa la strategia di sostituzione, i pod vengono rimossi e quelli nuovi vengono creati. Gli indirizzi associati ai pod precedenti vengono quindi riutilizzati.

• Scalabilità

  Prendere in considerazione il numero di nodi di tutti i nodi di sistema e utente e il relativo limite massimo di scalabilità. Si supponga di voler aumentare il numero di istanze del 400%. Saranno necessari quattro volte il numero di indirizzi per tutti i nodi con scalabilità orizzontale.

  In questa architettura, ogni pod può essere contattato direttamente. Quindi, ogni pod necessita di un singolo indirizzo. La scalabilità dei pod influirà sul calcolo degli indirizzi. Questa decisione dipenderà dalla scelta relativa al numero di pod che si desidera aumentare.

• Indirizzi di Collegamento privato di Azure

  Prendere in considerazione gli indirizzi necessari per la comunicazione con altri servizi di Azure tramite Collegamento privato. In questa architettura sono stati assegnati due indirizzi per i collegamenti a Registro Azure Container e a Key Vault.

• Alcuni indirizzi sono riservati per l'uso da parte di Azure. Non possono essere assegnati.

L'elenco precedente non è esaustivo. Se la progettazione ha altre risorse che influiranno sul numero di indirizzi IP disponibili, supportare tali indirizzi.

Questa architettura è progettata per un singolo carico di lavoro. Per più carichi di lavoro, è possibile isolare i pool di nodi utente l'uno dall'altro e dal pool di nodi di sistema. Questa scelta si traduce in un numero maggiore di subnet di dimensioni più piccole. Inoltre, la risorsa di ingresso potrebbe essere più complessa e, di conseguenza, potrebbero essere necessari più controller di ingresso che richiedono indirizzi IP aggiuntivi.

Per il set completo di considerazioni per questa architettura, vedere Topologia di rete di base del servizio Azure Kubernetes.

Per informazioni relative alla pianificazione dell'indirizzo IP per un cluster del servizio Azure Kubernetes, vedere Pianificare l'indirizzamento IP per il cluster.

Per esaminare le considerazioni sulla pianificazione degli indirizzi IP incluse nei contenitori di Windows nell'architettura di riferimento della baseline del servizio Azure Kubernetes, vedere l'articolo complementare.

Componenti aggiuntivi e funzionalità di anteprima

Kubernetes e servizio Azure Kubernetes sono prodotti in continua evoluzione, con cicli di rilascio più veloci rispetto al software per gli ambienti locali. Questa architettura di base dipende dalle funzionalità di anteprima del servizio Azure Kubernetes e dai componenti aggiuntivi del servizio Azure Kubernetes. La differenza tra i due è la seguente:

• Il team del servizio Azure Kubernetes descrive le funzionalità di anteprima fornite e migliorando. Il motivo è che molte delle funzionalità di anteprima rimangono in questo stato solo per alcuni mesi prima di passare alla fase di rilascio generale (GA).
• I componenti aggiuntivi e le estensioni del servizio Azure Kubernetes offrono funzionalità aggiuntive supportate. L'installazione, la configurazione e il ciclo di vita vengono gestiti dal servizio Azure Kubernetes.

Questa architettura di base non include tutte le funzionalità di anteprima o i componenti aggiuntivi, ma solo quelli che aggiungono valore significativo a un cluster per utilizzo generico sono inclusi. Man mano che queste funzionalità escono dall'anteprima, questa architettura di base verrà modificata di conseguenza. Esistono alcune funzionalità di anteprima aggiuntive o componenti aggiuntivi del servizio Azure Kubernetes che è possibile valutare nei cluster di pre-produzione che aumentano la sicurezza, la gestibilità o altri requisiti. Con i componenti aggiuntivi di terze parti, è necessario installarli e gestirli, inclusi il rilevamento delle versioni disponibili e l'installazione degli aggiornamenti dopo l'aggiornamento della versione kubernetes di un cluster.

Informazioni di riferimento sulle immagini del contenitore

Oltre al carico di lavoro, il cluster potrebbe contenere diverse altre immagini, ad esempio il controller di ingresso. Alcune di queste immagini potrebbero risiedere nei registri pubblici. Prendere in considerazione questi punti durante il pull nel cluster.

• Il cluster viene autenticato per eseguire il pull dell'immagine.

• Se si usa un'immagine pubblica, è consigliabile importarla nel registro contenitori in linea con lo SLO. In caso contrario, l'immagine potrebbe essere soggetta a problemi di disponibilità imprevisti. Questi problemi possono causare problemi operativi se l'immagine non è disponibile quando necessario. Ecco alcuni vantaggi dell'uso del registro contenitori anziché di un registro pubblico:

  • È possibile bloccare l'accesso non autorizzato alle immagini.
  • Non si avranno dipendenze pubbliche.
  • È possibile accedere ai log pull delle immagini per monitorare le attività e valutare i problemi di connettività.
  • Sfruttare i vantaggi dell'analisi integrata dei contenitori e della conformità delle immagini.

  Un'opzione è Registro Azure Container (ACR).

• Eseguire il pull delle immagini dai registri autorizzati. È possibile applicare questa restrizione tramite Criteri di Azure. In questa implementazione di riferimento, il cluster esegue il pull solo di immagini da Registro Azure Container distribuite come parte dell'architettura.

Configurare il calcolo per il cluster di base

Nel servizio Azure Kubernetes ogni pool di nodi corrisponde a un set di scalabilità di macchine virtuali. I nodi sono le macchine virtuali in ogni pool di nodi. Prendere in considerazione l'uso di una dimensione di macchina virtuale inferiore per il pool di nodi di sistema per ridurre al minimo i costi. Questa implementazione di riferimento distribuisce il pool di nodi di sistema con tre nodi DS2_v2. Tale dimensione è sufficiente per soddisfare il carico previsto dei pod di sistema. Le dimensioni del disco del sistema operativo sono di 512 GB.

Ecco alcune considerazioni per il pool di nodi utente:

• Scegliere dimensioni del nodo maggiori per accogliere il numero massimo di pod impostati in un nodo. Riduce al minimo il footprint dei servizi eseguiti in tutti i nodi, ad esempio il monitoraggio e la registrazione.

• Distribuire almeno due nodi. In questo modo, il carico di lavoro avrà un modello di disponibilità elevata con due repliche. Con il servizio Azure Kubernetes è possibile modificare il numero di nodi senza ricreare il cluster.

• Le dimensioni effettive dei nodi per il carico di lavoro dipendono dai requisiti determinati dal team di progettazione. In base ai requisiti aziendali, è stata scelta la dimensione DS4_v2 per il carico di lavoro di produzione. Per contenere i costi, è possibile ridurre la dimensione a DS3_v2, ovvero la raccomandazione minima.

• Quando si pianifica la capacità per il cluster, supporre che il carico di lavoro possa consumare fino all'80% di ogni nodo. Il rimanente 20% è riservato per i servizi del servizio Azure Kubernetes.

• Impostare il numero massimo di pod per nodo in base alla pianificazione della capacità. Se si sta tentando di stabilire una baseline di capacità, iniziare con un valore pari a 30. Regolare tale valore in base ai requisiti del carico di lavoro, alle dimensioni del nodo e ai vincoli IP.

Integrare Microsoft Entra ID per il cluster

La protezione dell'accesso da e verso il cluster è fondamentale. Tenere presente il punto di vista del cluster quando si effettuano scelte di sicurezza:

• Accesso dall'interno all'esterno. Accesso del servizio Azure Kubernetes ai componenti di Azure, ad esempio infrastruttura di rete, Registro Azure Container e Azure Key Vault. Autorizzare solo le risorse a cui il cluster è autorizzato ad accedere.
• Accesso dall'esterno all'interno. Fornire alle identità l'accesso al cluster Kubernetes. Autorizzare solo le entità esterne a cui è consentito l'accesso al server API Kubernetes e ad Azure Resource Manager.

Accesso del servizio Azure Kubernetes ad Azure

Esistono due modi per gestire l'accesso del servizio Azure Kubernetes ad Azure tramite Microsoft Entra ID: entità servizio o identità gestite per le risorse di Azure.

È consigliabile usare le identità gestite in due modi. Con le entità servizio, l'utente è responsabile della gestione e della rotazione dei segreti, manualmente o a livello di codice. Con le identità gestite, Microsoft Entra ID gestisce ed esegue automaticamente l'autenticazione e la rotazione tempestiva dei segreti.

È consigliabile abilitare le identità gestite in modo che il cluster possa interagire con le risorse esterne di Azure tramite Microsoft Entra ID. È possibile abilitare questa impostazione solo durante la creazione del cluster. Anche se Microsoft Entra ID non viene usato immediatamente, è possibile incorporarlo in un secondo momento.

Per impostazione predefinita, esistono due identità primarie usate dal cluster, l'identità del cluster e l'identità kubelet. L'identità del cluster viene usata dai componenti del piano di controllo del servizio Azure Kubernetes per gestire le risorse del cluster, inclusi i servizi di bilanciamento del carico in ingresso, gli indirizzi IP pubblici gestiti dal servizio Azure Kubernetes e così via. L'identità kubelet viene usata per eseguire l'autenticazione con Registro Azure Container. Anche alcuni componenti aggiuntivi supportano l'autenticazione con un'identità gestita.

Come esempio per lo scenario dall'interno all'esterno, si esaminerà l'uso delle identità gestite quando il cluster deve eseguire il pull delle immagini da un registro contenitori. Questa azione richiede al cluster di ottenere le credenziali del registro. Un modo consiste nell'archiviare tali informazioni sotto forma di oggetto Segreti Kubernetes e usare imagePullSecrets per recuperare il segreto. Questo approccio non è consigliato a causa delle complessità della sicurezza. Non solo è necessaria una conoscenza precedente del segreto, ma occorre anche eseguire la divulgazione di tale segreto tramite la pipeline DevOps. Si ottiene inoltre il sovraccarico operativo della gestione della rotazione del segreto. Concedere invece acrPull l'accesso all'identità gestita kubelet del cluster al registro. Questo approccio risolve tali problemi.

In questa architettura il cluster accede alle risorse di Azure protette dall'ID Microsoft Entra ed eseguono operazioni che supportano le identità gestite. Assegnare il controllo degli accessi in base al ruolo di Azure e le autorizzazioni alle identità gestite del cluster, a seconda delle operazioni che il cluster intende eseguire. Il cluster esegue l'autenticazione a Microsoft Entra ID e quindi è consentito o negato l'accesso in base ai ruoli assegnati. Ecco alcuni esempi di questa implementazione di riferimento in cui i ruoli predefiniti di Azure sono stati assegnati al cluster:

• Collaboratore Rete. Capacità del cluster di controllare la rete virtuale spoke. Questa assegnazione di ruolo consente all'identità assegnata dal sistema del cluster del servizio Azure Kubernetes di usare la subnet dedicata per i servizi controller di ingresso interni.
• Autore metriche di monitoraggio. Capacità del cluster di inviare metriche a Monitoraggio di Azure.
• AcrPull. Capacità del cluster di eseguire il pull delle immagini dai registri contenitori di Azure specificati.

Accesso al cluster

L'integrazione con Microsoft Entra semplifica anche la sicurezza per l'accesso dall'esterno all'interno. Si supponga che un utente voglia usare kubectl. Come passaggio iniziale, esegue il az aks get-credentials comando per ottenere le credenziali del cluster. Microsoft Entra ID autentica l'identità dell'utente rispetto ai ruoli di Azure autorizzati a ottenere le credenziali del cluster. Per altre informazioni, vedere Autorizzazioni dei ruoli del cluster disponibili.

Il servizio Azure Kubernetes consente l'accesso a Kubernetes usando Microsoft Entra ID in due modi. Il primo consiste nell'usare Microsoft Entra ID come provider di identità integrato con il sistema di controllo degli accessi in base al ruolo kubernetes nativo. L'altro consiste nell'usare il controllo degli accessi in base al ruolo nativo di Azure per controllare l'accesso al cluster. Entrambi sono descritti in dettaglio di seguito.

Associare il controllo degli accessi in base al ruolo di Kubernetes a Microsoft Entra ID

Kubernetes supporta il controllo degli accessi in base al ruolo tramite:

• Set di autorizzazioni. Definito da un Role oggetto o ClusterRole per le autorizzazioni a livello di cluster.

• Associazioni che assegnano utenti e gruppi autorizzati a eseguire le azioni. Definito da un RoleBinding oggetto o ClusterRoleBinding .

Kubernetes include alcuni ruoli predefiniti, ad esempio cluster-admin, modifica, visualizzazione e così via. Associare tali ruoli a utenti e gruppi di Microsoft Entra per usare la directory aziendale per gestire l'accesso. Per altre informazioni, vedere Usare il controllo degli accessi in base al ruolo di Kubernetes con l'integrazione di Microsoft Entra.

Assicurarsi che i gruppi di Microsoft Entra usati per l'accesso al cluster e allo spazio dei nomi siano inclusi nelle verifiche di accesso di Microsoft Entra.

Usare il controllo degli accessi in base al ruolo di Azure per l'autorizzazione con Kubernetes

Anziché usare il controllo degli accessi in base al ruolo nativo di Kubernetes (ClusterRoleBindings e RoleBindings) per l'autorizzazione con l'autenticazione integrata di Microsoft Entra, un'altra opzione consigliata, consiste nell'usare il controllo degli accessi in base al ruolo di Azure e le assegnazioni di ruolo di Azure per applicare i controlli di autorizzazione nel cluster. Queste assegnazioni di ruolo possono anche essere aggiunte negli ambiti della sottoscrizione o del gruppo di risorse in modo che tutti i cluster nell'ambito ereditino un set coerente di assegnazioni di ruolo rispetto a chi dispone delle autorizzazioni per accedere agli oggetti nel cluster Kubernetes.

Per altre informazioni, vedere Controllo degli accessi in base al ruolo di Azure per l'autorizzazione Kubernetes.

Account locali

Il servizio Azure Kubernetes supporta l'autenticazione utente nativa di Kubernetes. L'accesso utente ai cluster che usano questo metodo non è consigliato. Si tratta di un certificato basato su certificato e viene eseguito esternamente al provider di identità primario; rendendo difficile il controllo e la governance centralizzati degli accessi utente. Gestire sempre l'accesso al cluster usando Microsoft Entra ID e configurare il cluster per disabilitare in modo esplicito l'accesso all'account locale.

In questa implementazione di riferimento, l'accesso tramite account cluster locali viene disabilitato in modo esplicito quando il cluster viene distribuito.

Integrare l'ID Microsoft Entra per il carico di lavoro

Analogamente alla presenza di un'identità gestita assegnata dal sistema di Azure per l'intero cluster, è possibile assegnare identità gestite a livello di pod. Un'identità del carico di lavoro consente al carico di lavoro ospitato di accedere alle risorse tramite Microsoft Entra ID. Ad esempio, il carico di lavoro archivia i file in Archiviazione di Azure. Quando deve accedere a tali file, il pod si autentica sulla risorsa come identità gestita di Azure.

In questa implementazione di riferimento, le identità gestite per i pod vengono fornite tramite ID dei carichi di lavoro di Microsoft Entra nel servizio Azure Kubernetes. Questa funzionalità si integra con le funzionalità native di Kubernetes per la federazione con provider di identità esterni. Per altre informazioni sulla federazione ID dei carichi di lavoro di Microsoft Entra, vedere la panoramica seguente.

Distribuire le risorse in ingresso

Le risorse di ingresso Kubernetes instradano e distribuiscono il traffico in ingresso al cluster. Esistono due parti delle risorse in ingresso:

• Servizio di bilanciamento del carico interno. Gestito dal servizio Azure Kubernetes. Questo servizio di bilanciamento del carico espone il controller di ingresso tramite un indirizzo IP statico privato. Funge da singolo punto di contatto che riceve flussi in ingresso.

  In questa architettura viene usato Azure Load Balancer. Viene posizionato all'esterno del cluster in una subnet dedicata per le risorse in ingresso. Riceve il traffico dal gateway di app Azure lication e tale comunicazione è tramite TLS. Per informazioni sulla crittografia TLS per il traffico in ingresso, vedere Flusso del traffico in ingresso.

• Controller di ingresso. Abbiamo scelto Traefik. Viene eseguito nel pool di nodi utente nel cluster. Riceve il traffico dal servizio di bilanciamento del carico interno, termina TLS e lo inoltra ai pod del carico di lavoro tramite HTTP.

Il controller di ingresso è un componente critico del cluster. Prendere in considerazione questi punti durante la configurazione di questo componente.

• Come parte delle decisioni di progettazione, scegliere un ambito in cui sarà consentito il funzionamento del controller di ingresso. Ad esempio, è possibile consentire al controller di interagire solo con i pod che eseguono un carico di lavoro specifico.

• Evitare di posizionare le repliche nello stesso nodo per distribuire il carico e garantire la continuità aziendale in caso di interruzione di un nodo. Usare podAntiAffinity a questo scopo.

• Vincolare i pod per essere pianificati solo nel pool di nodi utente tramite nodeSelectors. Questa impostazione isola il carico di lavoro e i pod di sistema.

• Aprire porte e protocolli che consentono a entità specifiche di inviare traffico al controller di ingresso. In questa architettura Traefik riceve solo il traffico dal gateway di app Azure lication.

• Il controller di ingresso deve inviare segnali che indicano l'integrità dei pod. Configurare readinessProbe e livenessProbe impostazioni che monitoreranno l'integrità dei pod all'intervallo specificato.

• È consigliabile limitare l'accesso del controller in ingresso a risorse specifiche e la possibilità di eseguire determinate azioni. Questa restrizione può essere implementata tramite le autorizzazioni di controllo degli accessi in base al ruolo di Kubernetes. In questa architettura, ad esempio, a Traefik sono state concesse le autorizzazioni per controllare, ottenere ed elencare i servizi e gli endpoint usando regole nell'oggetto Kubernetes ClusterRole .

Per esaminare la progettazione in ingresso usata nei contenitori di Windows nell'architettura di riferimento della baseline del servizio Azure Kubernetes, vedere l'articolo complementare.

Impostazioni router

Il controller di ingresso usa route per determinare dove inviare il traffico. Le route specificano la porta di origine in cui viene ricevuto il traffico e le informazioni sulle porte e i protocolli di destinazione.

Ecco un esempio di questa architettura:

Traefik usa il provider Kubernetes per configurare le route. , annotationstlse entrypoints indicano che le route verranno gestite tramite HTTPS. middlewares Specifica che è consentito solo il traffico proveniente dalla subnet del gateway di app Azure lication. Le risposte useranno la codifica gzip se il client accetta. Poiché Traefik esegue la terminazione TLS, la comunicazione con i servizi back-end è tramite HTTP.

apiVersion:networking.k8s.io/v1
kind: Ingress
metadata:
  name: aspnetapp-ingress
  namespace: a0008
  annotations:
    kubernetes.io/ingress.allow-http: "false"
    kubernetes.io/ingress.class: traefik-internal
    traefik.ingress.kubernetes.io/router.entrypoints: websecure
    traefik.ingress.kubernetes.io/router.tls: "true"
    traefik.ingress.kubernetes.io/router.tls.options: default
    traefik.ingress.kubernetes.io/router.middlewares: app-gateway-snet@file, gzip-compress@file
spec:
  tls:
  - hosts:
      - bu0001a0008-00.aks-ingress.contoso.com
  rules:
  - host: bu0001a0008-00.aks-ingress.contoso.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: aspnetapp-service
            port: 
              number: 80

protezione del flusso di rete

Il flusso di rete, in questo contesto, può essere classificato come:

• Traffico in ingresso. Dal client al carico di lavoro in esecuzione nel cluster.

• Traffico in uscita. Da un pod o un nodo nel cluster a un servizio esterno.

• Traffico da pod a pod. Comunicazione tra pod. Questo traffico include la comunicazione tra il controller di ingresso e il carico di lavoro. Inoltre, se il carico di lavoro è costituito da più applicazioni distribuite nel cluster, la comunicazione tra tali applicazioni rientra in questa categoria.

• Traffico di gestione. Traffico che passa tra il client e il server API Kubernetes.

Scaricare un file di Visio di questa architettura.

Questa architettura offre diversi livelli di sicurezza per proteggere tutti i tipi di traffico.

Flusso del traffico in ingresso

L'architettura accetta dal client solo richieste crittografate TLS. TLS v1.2 è la versione minima consentita con un set limitato di crittografie. L'indicazione nome server (SNI) è abilitata. Il TLS end-to-end viene configurato tramite il gateway applicazione usando due diversi certificati TLS, come illustrato in questa immagine.

Scaricare un file di Visio di questa architettura.

1. Il client invia una richiesta HTTPS al nome di dominio: bicycle.contoso.com. Tale nome è associato tramite un record DNS A all'indirizzo IP pubblico del gateway applicazione di Azure. Questo traffico viene crittografato per assicurarsi che il traffico tra il browser client e il gateway non possa essere controllato o modificato.

2. gateway applicazione dispone di un web application firewall integrato (WAF) e negozia l'handshake TLS per bicycle.contoso.com, consentendo solo crittografie sicure. Il gateway applicazione è un punto di terminazione TLS, perché è necessario elaborare le regole di ispezione WAF ed eseguire regole di routing che inoltrano il traffico al back-end configurato. Il certificato TLS viene archiviato in Azure Key Vault. Si accede usando un'identità gestita assegnata dall'utente integrata con il gateway applicazione. Per informazioni su questa funzionalità, vedere Terminazione TLS con certificati di Key Vault.

3. Quando il traffico passa dal gateway applicazione al back-end, viene crittografato di nuovo con un altro certificato TLS (carattere jolly per *.aks-ingress.contoso.com), mentre viene inoltrato al servizio di bilanciamento del carico interno. Questa ricrittografazione garantisce che il traffico non sicuro non entri nella subnet del cluster.

4. Il controller di ingresso riceve il traffico crittografato tramite il servizio di bilanciamento del carico. Il controller è un altro punto di terminazione TLS per *.aks-ingress.contoso.com e inoltra il traffico ai pod del carico di lavoro su HTTP. I certificati vengono archiviati in Azure Key Vault e montati nel cluster usando il driver CSI (Container Storage Interface). Per altre informazioni, vedere Aggiungere la gestione dei segreti.

È possibile implementare l'intero traffico TLS end-to-end a ogni hop attraverso il pod del carico di lavoro. Assicurarsi di misurare le prestazioni, la latenza e l'impatto operativo quando si decide di proteggere il traffico da pod a pod. Per la maggior parte dei cluster a tenant singolo, con il controllo degli accessi in base al ruolo appropriato e le procedure mature del ciclo di vita dello sviluppo software, è sufficiente crittografare TLS fino al controller di ingresso e proteggere con Web Application Firewall (WAF). Ciò ridurrà al minimo il sovraccarico nella gestione del carico di lavoro e negli effetti sulle prestazioni di rete. I requisiti di conformità e carico di lavoro determinano dove si esegue la terminazione TLS.

Flusso del traffico in uscita

In questa architettura è consigliabile tutto il traffico in uscita dal cluster che comunica tramite Firewall di Azure o un'appliance virtuale di rete simile, su altre opzioni, ad esempio gateway NAT o proxy HTTP. Per il controllo zero-trust e la possibilità di controllare il traffico, tutto il traffico in uscita dal cluster passa attraverso Firewall di Azure. È possibile implementare tale scelta usando route definite dall'utente . L'hop successivo della route è l'indirizzo IP privato del Firewall di Azure. In questo caso, Firewall di Azure decide se bloccare o consentire il traffico in uscita. Tale decisione si basa sulle regole specifiche definite nella Firewall di Azure o sulle regole di intelligence sulle minacce predefinite.

Un'alternativa all'uso di Firewall di Azure consiste nell'usare la funzionalità proxy HTTP del servizio Azure Kubernetes. Tutto il traffico in uscita del cluster viene impostato prima sull'indirizzo IP del proxy HTTP, che decide di inoltrare il traffico o eliminarlo.

Con entrambi i metodi, esaminare le regole di rete in uscita necessarie per il servizio Azure Kubernetes.

Un'eccezione al controllo zero-trust è quando il cluster deve comunicare con altre risorse di Azure. Ad esempio, il cluster deve eseguire il pull di un'immagine aggiornata dal registro contenitori o dai segreti di Azure Key Vault. L'approccio consigliato consiste nell'usare collegamento privato di Azure. Il vantaggio è che le subnet specifiche raggiungono direttamente il servizio anziché il traffico tra il cluster e i servizi che passano tramite Internet. Uno svantaggio è che collegamento privato richiede una configurazione aggiuntiva anziché usare il servizio di destinazione sull'endpoint pubblico. Inoltre, non tutti i servizi o gli SKU di Azure supportano collegamento privato. Per questi casi, è consigliabile abilitare un endpoint di servizio Rete virtuale nella subnet per accedere al servizio.

Se collegamento privato o gli endpoint di servizio non sono un'opzione, è possibile raggiungere altri servizi tramite gli endpoint pubblici e controllare l'accesso tramite Firewall di Azure regole e il firewall integrato nel servizio di destinazione. Poiché questo traffico passa attraverso gli indirizzi IP statici del firewall, questi indirizzi possono essere aggiunti all'elenco indirizzi IP consentiti del servizio. Uno svantaggio è che Firewall di Azure deve avere regole aggiuntive per assicurarsi che sia consentito solo il traffico da una subnet specifica. Tenere conto di questi indirizzi quando si pianificano più indirizzi IP per il traffico in uscita con Firewall di Azure; in caso contrario, è possibile raggiungere l'esaurimento delle porte. Per altre informazioni sulla pianificazione di più indirizzi IP, vedere Limitare e controllare il traffico in uscita.

Per esaminare le considerazioni sull'uscita specifiche di Windows usate nei contenitori windows nell'architettura di riferimento della baseline del servizio Azure Kubernetes, vedere l'articolo complementare.

Traffico da pod a pod

Per impostazione predefinita, un pod può accettare il traffico da qualsiasi altro pod nel cluster. Kubernetes NetworkPolicy viene usato per limitare il traffico di rete tra i pod. Applicare i criteri in modo succoso, altrimenti potrebbe verificarsi una situazione in cui viene bloccato un flusso di rete critico. Consentire solo percorsi di comunicazione specifici, in base alle esigenze, ad esempio il traffico tra il controller di ingresso e il carico di lavoro. Per altre informazioni, vedere Criteri di rete.

Abilitare i criteri di rete quando viene effettuato il provisioning del cluster perché non può essere aggiunto in un secondo momento. Esistono alcune opzioni per le tecnologie che implementano NetworkPolicy. È consigliabile usare Criteri di rete di Azure, che richiede l'interfaccia di rete di Azure Container( CNI), vedere la nota seguente. Altre opzioni includono Calico Network Policy, un'opzione open source nota. Prendere in considerazione Calico se è necessario gestire i criteri di rete a livello di cluster. Calico non è coperto da supporto tecnico di Azure standard.

Per altre informazioni, vedere Differenze tra i criteri di rete di Azure e i criteri Calico e le relative funzionalità.

Traffico di gestione

Nell'ambito dell'esecuzione del cluster, il server API Kubernetes riceverà traffico dalle risorse che vogliono eseguire operazioni di gestione nel cluster, ad esempio le richieste di creare risorse o ridimensionare il cluster. Esempi di queste risorse includono il pool di agenti di compilazione in una pipeline DevOps, una subnet Bastion e i pool di nodi stessi. Anziché accettare questo traffico di gestione da tutti gli indirizzi IP, usare la funzionalità Intervalli IP autorizzati del servizio Azure Kubernetes per consentire solo il traffico dagli intervalli IP autorizzati al server API.

Per altre informazioni, vedere Definire intervalli IP autorizzati del server API.

Per un livello di controllo aggiuntivo, a costo di complessità aggiuntiva, è possibile effettuare il provisioning di un cluster del servizio Azure Kubernetes privato. Usando un cluster privato, è possibile garantire che il traffico di rete tra il server API e i pool di nodi rimanga solo nella rete privata, non sia esposto a Internet. Per altre informazioni, vedere Cluster privati del servizio Azure Kubernetes.

Aggiungi la gestione dei segreti

Archiviare i segreti in un archivio chiavi gestito, ad esempio Azure Key Vault. Il vantaggio è che l'archivio gestito gestisce la rotazione dei segreti, offre una crittografia avanzata, fornisce un log di controllo di accesso e mantiene i segreti principali dalla pipeline di distribuzione. In questa architettura il firewall di Azure Key Vault è abilitato e configurato con connessioni di collegamento privato alle risorse in Azure che devono accedere a segreti e certificati.

Azure Key Vault è ben integrato con altri servizi di Azure. Usare la funzionalità predefinita di tali servizi per accedere ai segreti. Per un esempio su come app Azure lication Gateway accede ai certificati TLS per il flusso di ingresso, vedere la sezione Flusso del traffico in ingresso.

Il modello di autorizzazione controllo degli accessi in base al ruolo di Azure per Key Vault consente di assegnare le identità del carico di lavoro all'utente dei segreti dell'insieme di credenziali delle chiavi o all'assegnazione del ruolo lettore dell'insieme di credenziali delle chiavi e di accedere ai segreti. Per altre informazioni, vedere Accedere ad Azure Key Vault usando il controllo degli accessi in base al ruolo.

Accesso ai segreti del cluster

È necessario usare le identità del carico di lavoro per consentire a un pod di accedere ai segreti da un archivio specifico. Per facilitare il processo di recupero, usare un driver CSI dell'archivio segreti. Quando il pod richiede un segreto, il driver si connette all'archivio specificato, recupera il segreto in un volume e monta tale volume nel cluster. Il pod può quindi ottenere il segreto dal file system del volume.

Il driver CSI include molti provider per supportare vari archivi gestiti. In questa implementazione è stato scelto azure Key Vault con il driver CSI dell'archivio segreti usando il componente aggiuntivo per recuperare il certificato TLS da Azure Key Vault e caricarlo nel pod che esegue il controller di ingresso. Viene eseguita durante la creazione del pod e il volume archivia sia le chiavi pubbliche che le chiavi private.

Archiviazione del carico di lavoro

Il carico di lavoro usato in questa architettura è senza stato. Se è necessario archiviare lo stato, è consigliabile salvarlo in modo permanente all'esterno del cluster. Le linee guida per lo stato del carico di lavoro non rientrano nell'ambito di questo articolo.

Per altre informazioni sulle opzioni di archiviazione, vedere Archiviazione opzioni per le applicazioni in servizio Azure Kubernetes (servizio Azure Kubernetes).

Gestione dei criteri

Un modo efficace per gestire un cluster del servizio Azure Kubernetes consiste nell'applicare la governance tramite i criteri. Kubernetes implementa i criteri tramite OPA Gatekeeper. Per il servizio Azure Kubernetes, i criteri vengono distribuiti tramite Criteri di Azure. Ogni criterio viene applicato a tutti i cluster nel relativo ambito. Criteri di Azure'imposizione viene gestita in definitiva da OPA Gatekeeper nel cluster e vengono registrati tutti i controlli dei criteri. Le modifiche ai criteri non vengono riflesse immediatamente nel cluster, si prevede di vedere alcuni ritardi.

Esistono due scenari diversi che Criteri di Azure offrono per la gestione dei cluster del servizio Azure Kubernetes:

• Impedire o limitare la distribuzione di cluster del servizio Azure Kubernetes in un gruppo di risorse o in una sottoscrizione valutando gli standard dell'organizzazione. Ad esempio, seguire una convenzione di denominazione, specificare un tag e così via.
• Proteggere il cluster del servizio Azure Kubernetes tramite Criteri di Azure per Kubernetes.

Quando si impostano i criteri, applicarli in base ai requisiti del carico di lavoro. Tenere presente questi fattori:

• Si vuole impostare una raccolta di criteri (denominate iniziative) o scegliere singoli criteri? Criteri di Azure offre due iniziative predefinite: di base e limitate. Ogni iniziativa è una raccolta di criteri predefiniti applicabili a un cluster del servizio Azure Kubernetes. È consigliabile selezionare un'iniziativa e scegliere e scegliere criteri aggiuntivi per il cluster e le risorse (Registro Azure Container, gateway applicazione, Key Vault e altri) che interagiscono con il cluster in base ai requisiti dell'organizzazione.

• Controllare o negare l'azione? In modalità di controllo , l'azione è consentita, ma è contrassegnata come non conforme. Disporre di processi per controllare gli stati non conformi a cadenza regolare e intraprendere le azioni necessarie. In modalità Nega l'azione viene bloccata perché viola i criteri. Prestare attenzione a scegliere questa modalità perché può essere troppo restrittiva per il funzionamento del carico di lavoro.

• Sono presenti aree nel carico di lavoro che non devono essere conformi in base alla progettazione? Criteri di Azure ha la possibilità di specificare spazi dei nomi Kubernetes esenti dall'imposizione dei criteri. È consigliabile applicare ancora i criteri in modalità di controllo in modo che siano a conoscenza di tali istanze.

• Sono previsti requisiti non coperti dai criteri predefiniti? È possibile creare una definizione di Criteri di Azure personalizzata che applica i criteri personalizzati di OPA Gatekeeper. Non applicare criteri personalizzati direttamente al cluster. Per altre informazioni sulla creazione di criteri personalizzati, vedere Creare e assegnare definizioni di criteri personalizzati.

• Sono previsti requisiti a livello di organizzazione? In tal caso, aggiungere tali criteri a livello di gruppo di gestione. Il cluster deve anche assegnare criteri specifici del carico di lavoro, anche se l'organizzazione dispone di criteri generici.

• I criteri di Azure vengono assegnati a ambiti specifici. Assicurarsi che i criteri di produzione vengano convalidati anche nell'ambiente di pre-produzione . In caso contrario, quando si esegue la distribuzione nell'ambiente di produzione, è possibile che si verifichino restrizioni aggiuntive impreviste che non sono state prese in considerazione in fase di pre-produzione.

In questa implementazione di riferimento, Criteri di Azure è abilitata quando viene creato il cluster del servizio Azure Kubernetes e assegna l'iniziativa restrittiva in modalità di controllo per ottenere visibilità sulla mancata conformità.

L'implementazione imposta anche criteri aggiuntivi che non fanno parte di alcuna iniziativa predefinita. Questi criteri vengono impostati in modalità Nega . È ad esempio disponibile un criterio per assicurarsi che le immagini vengano estratte solo dal Registro Azure Container distribuito. Prendere in considerazione la creazione di iniziative personalizzate. Combinare i criteri applicabili per il carico di lavoro in una singola assegnazione.

Per osservare il funzionamento di Criteri di Azure dall'interno del cluster, è possibile accedere ai log dei pod per tutti i pod nello gatekeeper-system spazio dei nomi, nonché i log per i azure-policy pod e azure-policy-webhook nello spazio dei kube-system nomi .

Per esaminare le considerazioni sulle Criteri di Azure specifiche di Windows incluse nei contenitori windows nell'architettura di riferimento della baseline del servizio Azure Kubernetes, vedere l'articolo complementare.

Scalabilità di nodi e pod

Con l'aumento della domanda, Kubernetes può aumentare istanze aggiungendo altri pod ai nodi esistenti, tramite la scalabilità aumentare orizzontale dei pod (HPA). Quando non è più possibile pianificare altri pod, il numero di nodi deve essere aumentato tramite la scalabilità automatica del cluster del servizio Azure Kubernetes. Una soluzione di scalabilità completa deve avere la possibilità di ridimensionare sia le repliche dei pod che il numero di nodi del cluster.

Esistono due approcci: il ridimensionamento automatico o il ridimensionamento manuale.

Il metodo manuale o programmatico richiede il monitoraggio e l'impostazione di avvisi sull'utilizzo della CPU o sulle metriche personalizzate. Per il ridimensionamento dei pod, l'operatore dell'applicazione può aumentare o diminuire il numero di repliche pod modificando le ReplicaSet API kubernetes. Per il ridimensionamento del cluster, un modo consiste nel ricevere una notifica quando l’utilità di pianificazione Kubernetes ha esito negativo. Un altro modo consiste nell’osservare i pod in sospeso nel tempo. È possibile modificare il numero di nodi tramite l’interfaccia della riga di comando di Azure o il portale.

La scalabilità automatica è l'approccio consigliato perché alcuni di questi meccanismi manuali sono integrati nel ridimensionamento automatico.

Come approccio generale, iniziare dal test delle prestazioni con un numero minimo di pod e nodi. Usare questi valori per stabilire le aspettative di base. Usare quindi una combinazione di metriche delle prestazioni e ridimensionamento manuale per individuare colli di bottiglia e comprendere la risposta dell'applicazione al ridimensionamento. Usare infine questi dati per impostare i parametri per la scalabilità automatica. Per informazioni su uno scenario di ottimizzazione delle prestazioni con il servizio Azure Kubernetes, vedere Scenario di ottimizzazione delle prestazioni: transazioni aziendali distribuite.

Utilità di scalabilità automatica orizzontale dei pod

Horizontal Pod Autoscaler (HPA) è una risorsa Kubernetes che ridimensiona il numero di pod.

Nella risorsa HPA, è consigliabile impostare il numero minimo e massimo di repliche. Questi valori vincolano i limiti di scalabilità automatica.

HPA può ridimensionare in base all'utilizzo della CPU, della memoria e alle metriche personalizzate. Viene fornito solo l'utilizzo della CPU. La definizione di HorizontalPodAutoscaler specifica i valori di destinazione per tali metriche. Ad esempio, la specifica imposta un utilizzo della CPU di destinazione. Mentre i pod sono in esecuzione, il controller HPA usa l’API metriche Kubernetes per controllare l'utilizzo della CPU di ogni pod. Confronta questo valore con l'utilizzo di destinazione e calcola un rapporto. Usa quindi il rapporto per determinare se i pod sono sovrassegnati o sottoallocati. Si affida all’Utilità di pianificazione Kubernetes per assegnare nuovi pod ai nodi o rimuovere pod dai nodi.

Potrebbe esserci una race condition in cui (HPA) controlla prima del completamento di un'operazione di ridimensionamento. Il risultato potrebbe essere un calcolo del rapporto non corretto. Per informazioni dettagliate, vedere Cooldown degli eventi di ridimensionamento.

Se il carico di lavoro è basato su eventi, un'opzione open source comune è KEDA. Prendere in considerazione KEDA se il carico di lavoro è basato su un'origine evento, ad esempio una coda di messaggi, anziché essere associata alla CPU o alla memoria. KEDA supporta molte origini eventi (o scaler). L'elenco dei scaler KEDA supportati è disponibile qui , incluso il scaler di Monitoraggio di Azure, un modo pratico per ridimensionare i carichi di lavoro KEDA in base alle metriche di Monitoraggio di Azure.

Ridimensionamento automatico del cluster

Il componente di scalabilità automatica del cluster è un componente aggiuntivo del servizio Azure Kubernetes che ridimensiona il numero di nodi in un pool di nodi. Deve essere aggiunto durante il provisioning del cluster. È necessario un componente di scalabilità automatica del cluster separato per ogni pool di nodi utente.

Il ridimensionamento automatico del cluster viene attivato dall'utilità di pianificazione kubernetes. Quando l’Utilità di pianificazione Kubernetes non riesce a pianificare un pod a causa di vincoli di risorse, il ridimensionamento automatico effettua automaticamente il provisioning di un nuovo nodo nel pool di nodi. Viceversa, il ridimensionamento automatico del cluster controlla la capacità inutilizzata dei nodi. Se il nodo non è in esecuzione con una capacità prevista, i pod vengono spostati in un altro nodo e il nodo inutilizzato viene rimosso.

Quando si abilita la scalabilità automatica, impostare il numero massimo e minimo di nodi. I valori consigliati dipendono dalle prestazioni attese dal carico di lavoro, dalla crescita del cluster e dalle implicazioni economiche. Il numero minimo è la capacità riservata per tale pool di nodi. In questa implementazione di riferimento, il valore minimo è impostato su 2 a causa della natura semplice del carico di lavoro.

Per il pool di nodi di sistema, il valore minimo consigliato è 3.

Per esaminare le considerazioni sulla scalabilità incluse nei contenitori di Windows nell'architettura di riferimento della baseline del servizio Azure Kubernetes, vedere l'articolo complementare.

Decisioni di continuità aziendale

Per mantenere la continuità aziendale, definire il Contratto di servizio per l'infrastruttura e l'applicazione. Per informazioni sul calcolo del tempo di attività mensile, vedere Contratto di servizio per servizio Azure Kubernetes (servizio Azure Kubernetes).

Nodi del cluster

Per soddisfare il livello minimo di disponibilità per i carichi di lavoro, sono necessari più nodi in un pool di nodi. Se un nodo diventa inattivo, un altro nodo nel pool di nodi nello stesso cluster può continuare a eseguire l'applicazione. Per l'affidabilità, sono consigliati tre nodi per il pool di nodi di sistema. Per il pool di nodi utente, iniziare con almeno due nodi. Se è necessaria una maggiore disponibilità, effettuare il provisioning di più nodi.

Isolare le applicazioni dai servizi di sistema inserendola in un pool di nodi separato, detto pool di nodi utente. In questo modo, i servizi Kubernetes vengono eseguiti in nodi dedicati e non competono con il carico di lavoro. È consigliabile usare tag, etichette e taints per identificare il pool di nodi per pianificare il carico di lavoro e assicurarsi che il pool di nodi di sistema sia tainonsOnly [taint] (/azure/aks/use-system-pools#system-and-user-node-pools).

La manutenzione regolare del cluster, ad esempio aggiornamenti tempestivi, è fondamentale per l'affidabilità. È inoltre consigliabile monitorare l'integrità dei pod tramite probe.

Disponibilità dei pod

Verificare le risorse dei pod. È consigliabile che le distribuzioni specifichino i requisiti per le risorse dei pod. L'utilità di pianificazione può quindi pianificare in modo appropriato il pod. L'affidabilità deprecherà significativamente se i pod non possono essere pianificati.

Impostare i budget di interruzione dei pod. Questa impostazione determina il numero di repliche in una distribuzione durante un evento di aggiornamento o aggiornamento. Per altre informazioni, vedere Budget di interruzione dei pod.

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

Impostare le quote di risorse negli spazi dei nomi del carico di lavoro. La quota di risorse in uno spazio dei nomi garantisce che le richieste e i limiti dei pod siano impostati correttamente in una distribuzione. Per altre informazioni, vedere Applicare le quote di risorse.

Impostare le richieste e i limiti dei pod. L'impostazione di questi limiti consente a Kubernetes di allocare in modo efficiente le risorse di CPU e/o memoria ai pod e di avere una densità di contenitore superiore in un nodo. I limiti possono anche aumentare l'affidabilità con costi ridotti a causa di un utilizzo migliore dell'hardware.

Per stimare i limiti, testare e stabilire una linea di base. Iniziare con valori uguali per le richieste e i limiti. Quindi, ottimizzare gradualmente tali valori fino a quando non è stata stabilita una soglia che può causare instabilità nel cluster.

Questi limiti possono essere specificati nei manifesti della distribuzione. Per altre informazioni, vedere Impostare richieste e limiti dei pod.

Zone di disponibilità e supporto per più aree

Se il contratto di servizio richiede un tempo di attività più elevato, proteggersi dalle interruzioni usando le zone di disponibilità. È possibile usare le zone di disponibilità se l'area le supporta. I componenti del piano di controllo e i nodi nei pool di nodi possono quindi essere distribuiti tra le zone. Se un'intera zona non è disponibile, è ancora disponibile un nodo in un'altra zona all'interno dell'area. Ogni pool di nodi esegue il mapping a un set di scalabilità di macchine virtuali separato, che gestisce le istanze del nodo e la scalabilità. Le operazioni e la configurazione dei set di scalabilità vengono gestite dal servizio Servizio Azure Kubernetes. Di seguito sono riportate alcune considerazioni per l'abilitazione di più zone:

• Intera infrastruttura. Scegliere un'area che supporta le zone di disponibilità. Per altre informazioni, vedere Limitazioni e disponibilità dell'area. Se si vuole acquistare un contratto di servizio per il tempo di attività, scegliere un'area che supporti tale opzione. Il contratto di servizio tempo di attività è maggiore quando si usano le zone di disponibilità.

• Cluster. Le zone di disponibilità possono essere impostate solo quando viene creato il pool di nodi e non possono essere modificate in un secondo momento. Le dimensioni del nodo devono essere supportate in tutte le zone in modo che sia possibile eseguire la distribuzione prevista. Il set di scalabilità di macchine virtuali sottostante fornisce la stessa configurazione hardware tra le zone.

  Il supporto per più zone non si applica solo ai pool di nodi, ma anche al piano di controllo. Il piano di controllo del servizio Azure Kubernetes si estenderà sulle zone richieste, ad esempio i pool di nodi. Se non si usa il supporto della zona nel cluster, i componenti del piano di controllo non sono garantiti per la distribuzione tra le zone di disponibilità.

• Risorse dipendenti. Per ottenere un vantaggio completo dalle zone, anche tutte le dipendenze del servizio devono supportare le zone. Se un servizio dipendente non supporta le zone, è possibile che un errore di zona possa causare un errore del servizio.

Ad esempio, un disco gestito è disponibile nella zona in cui viene effettuato il provisioning. In caso di errore, il nodo potrebbe spostarsi in un'altra zona, ma il disco gestito non verrà spostato con il nodo in tale zona.

Per semplicità, in questa architettura il servizio Azure Kubernetes viene distribuito in una singola area con pool di nodi che si estendono su zone di disponibilità 1, 2 e 3. Altre risorse dell'infrastruttura, ad esempio Firewall di Azure e gateway applicazione vengono distribuite nella stessa area anche con supporto per più zone. La replica geografica è abilitata per Registro Azure Container.

Più aree geografiche

L'abilitazione delle zone di disponibilità non sarà sufficiente se l'intera area diventa inattiva. Per ottenere una disponibilità più elevata, eseguire più cluster del servizio Azure Kubernetes in aree diverse.

• Usare le aree abbinate. Prendere in considerazione l'uso di una pipeline CI/CD configurata per l'uso di un'area abbinata per il ripristino da errori di area. Un vantaggio dell'uso delle aree abbinate è l'affidabilità durante gli aggiornamenti. Azure assicura che solo un'area nella coppia venga aggiornata alla volta. Alcuni strumenti DevOps, ad esempio Flux, possono semplificare le distribuzioni in più aree.

• Se una risorsa di Azure supporta la ridondanza geografica, specificare la posizione in cui il servizio ridondante avrà il relativo database secondario. Ad esempio, l'abilitazione della replica geografica per Registro Azure Container replicherà automaticamente le immagini nelle aree di Azure selezionate e fornirà accesso continuo alle immagini anche in caso di interruzione di un'area.

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

Ripristino di emergenza

In caso di errore nell'area primaria, dovrebbe essere possibile creare rapidamente una nuova istanza in un'altra area. Di seguito sono elencati alcuni suggerimenti:

• Usare le aree abbinate.

• Un carico di lavoro non con stato può essere replicato in modo efficiente. Se è necessario archiviare lo stato nel cluster (non consigliato), assicurarsi di eseguire spesso il backup dei dati nell'area abbinata.

• Integrare la strategia di ripristino, ad esempio la replica in un'altra area, come parte della pipeline DevOps per soddisfare gli obiettivi del livello di servizio .

• Durante il provisioning di ogni servizio di Azure, scegliere le funzionalità che supportano il ripristino di emergenza. In questa architettura, ad esempio, Registro Azure Container è abilitata per la replica geografica. Se un'area diventa non disponibile, è comunque possibile eseguire il pull delle immagini dall'area replicata.

Backup del cluster

Per molte architetture, è possibile effettuare il provisioning di un nuovo cluster e restituirlo allo stato operativo tramite GitOps [bootstrapping cluster}(#cluster-bootstrapping) e seguito dalla distribuzione dell'applicazione. Tuttavia, se lo stato critico delle risorse, ad esempio mappe di configurazione, processi e segreti potenzialmente non possono essere acquisiti all'interno del processo di bootstrap, prendere in considerazione la strategia di ripristino. È in genere consigliabile eseguire carichi di lavoro senza stato in Kubernetes, ma se l'architettura prevede lo stato basato su disco, è necessario considerare anche la strategia di ripristino per tale contenuto.

Quando il backup del cluster deve far parte della strategia di ripristino, è necessario installare una soluzione che soddisfi i requisiti aziendali all'interno del cluster. Questo agente sarà responsabile del push dello stato delle risorse del cluster in una destinazione scelta e del coordinamento degli snapshot del volume persistente basati su disco di Azure.

Il Velero di VMware è un esempio di una soluzione di backup Kubernetes comune che è possibile installare e gestire direttamente. In alternativa, l'estensione di backup del servizio Azure Kubernetes può essere usata per fornire un'implementazione gestita di Velero. L'estensione di backup del servizio Azure Kubernetes supporta il backup di risorse Kubernetes e volumi permanenti, con pianificazioni e ambito di backup esternizzati come configurazione dell'insieme di credenziali in Backup di Azure.

L'implementazione di riferimento non implementa il backup, che implica risorse di Azure aggiuntive nell'architettura per gestire, monitorare, pagare e proteggere; ad esempio un account Archiviazione di Azure, Backup di Azure insieme di credenziali e configurazione e accesso attendibile. GitOps combinato con la finalità di eseguire un carico di lavoro senza stato è la soluzione di ripristino implementata.

Scegliere e convalidare una soluzione che soddisfi l'obiettivo aziendale, incluso l'obiettivo del punto di ripristino (RPO) definito e l'obiettivo del tempo di ripristino (RTO). Definire questo processo di ripristino in un runbook del team e praticarlo per tutti i carichi di lavoro critici per l'azienda.

Contratto di servizio del server API Kubernetes

Il servizio Azure Kubernetes può essere usato come servizio gratuito, ma tale livello non offre un contratto di servizio con copertura finanziaria. Per ottenere tale contratto di servizio, è necessario scegliere il livello Standard. È consigliabile che tutti i cluster di produzione usino il livello Standard. Riservare cluster di livello gratuito per i cluster di pre-produzione. In combinazione con Azure zone di disponibilità, il contratto di servizio del server API Kubernetes è aumentato al 99,95%. I pool di nodi e altre risorse sono coperti dal proprio contratto di servizio.

Compromesso

Esiste un compromesso tra costi e disponibilità per la distribuzione dell'architettura tra zone e soprattutto aree. Alcune funzionalità di replica, ad esempio la replica geografica in Registro Azure Container, sono disponibili negli SKU Premium, che sono più costosi. Il costo aumenterà anche perché i costi di larghezza di banda applicati quando il traffico si sposta tra zone e aree.

Inoltre, prevedere una latenza di rete aggiuntiva nella comunicazione tra zone o aree. Misurare l'impatto di questa decisione architetturale sul carico di lavoro.

Eseguire test con simulazioni e failover forzati

Garantire l'affidabilità tramite test di failover forzato con interruzioni simulate, ad esempio l'arresto di un nodo, l'arresto di tutte le risorse del servizio Azure Kubernetes in una zona specifica per simulare un errore di zona o richiamare un errore di dipendenza esterna. Azure Chaos Studio può anche essere usato per simulare vari tipi di interruzioni in Azure e nel cluster.

Per altre informazioni, vedere Azure Chaos Studio.

Monitorare e raccogliere le metriche

Informazioni dettagliate sui contenitori di Monitoraggio di Azure è lo strumento consigliato per monitorare le prestazioni dei carichi di lavoro dei contenitori perché è possibile visualizzare gli eventi in tempo reale. Acquisisce i log dei contenitori dai pod in esecuzione e li aggrega per la visualizzazione. Raccoglie anche informazioni dall'API Metriche sull'utilizzo della memoria e della CPU per monitorare l'integrità delle risorse e dei carichi di lavoro in esecuzione. È anche possibile usarlo per monitorare le prestazioni durante la scalabilità dei pod. Include la raccolta di dati di telemetria critici per il monitoraggio, l'analisi e la visualizzazione dei dati raccolti per identificare le tendenze e configurare gli avvisi per ricevere una notifica proattiva dei problemi critici.

La maggior parte dei carichi di lavoro ospitati nei pod genera metriche prometheus. Informazioni dettagliate sui contenitori è in grado di eseguire l'integrazione con Prometheus per visualizzare le metriche dell'applicazione e del carico di lavoro raccolte dai nodi e da Kubernetes.

Esistono alcune soluzioni di terze parti che si integrano con Kubernetes, ad esempio Datadog, Grafana o New Relic, se l'organizzazione li usa già.

Con il servizio Azure Kubernetes, Azure gestisce alcuni servizi Kubernetes di base e i log per i componenti del piano di controllo del servizio Azure Kubernetes vengono implementati in Azure come log delle risorse. È consigliabile che la maggior parte dei cluster abbia sempre abilitato quanto segue, perché consente di risolvere i problemi del cluster e di avere una densità di log relativamente bassa:

• Accedere a ClusterAutoscaler per ottenere l'osservabilità nelle operazioni di ridimensionamento. Per altre informazioni, vedere Recuperare i log e lo stato del ridimensionamento automatico del cluster.
• KubeControllerManager per avere l'osservabilità nell'interazione tra Kubernetes e il piano di controllo di Azure.
• KubeAudit Amministrazione per avere osservabilità nelle attività che modificano il cluster. Non esiste alcun motivo per cui KubeAudit e KubeAudit Amministrazione entrambi abilitati, poiché KubeAudit è un superset di KubeAudit Amministrazione che include anche operazioni non di modifica (lettura).
• Guard acquisisce i controlli microsoft Entra ID e Controllo degli accessi in base al ruolo di Azure.

Altre categorie di log, ad esempio KubeScheduler o KubeAudit, possono essere molto utili per abilitare durante lo sviluppo iniziale del cluster o del ciclo di vita del carico di lavoro, in cui è stata aggiunta la scalabilità automatica del cluster, il posizionamento e la pianificazione dei pod e dati simili potrebbero aiutare a risolvere i problemi relativi alle operazioni del cluster o del carico di lavoro. Mantenere i log di risoluzione dei problemi estesi a tempo pieno, una volta superate le esigenze di risoluzione dei problemi, potrebbe essere considerato un costo non necessario per l'inserimento e l'archiviazione in Monitoraggio di Azure.

Anche se Monitoraggio di Azure include un set di query di log esistenti da iniziare, è anche possibile usarle come base per creare query personalizzate. Man mano che la libreria cresce, è possibile salvare e riutilizzare le query di log usando uno o più Query Pack. La libreria personalizzata di query consente di abilitare un'osservabilità aggiuntiva nell'integrità e nelle prestazioni dei cluster del servizio Azure Kubernetes e supportare gli obiettivi del livello di servizio.

Per altre informazioni sulle procedure consigliate di monitoraggio per il servizio Azure Kubernetes, vedere Monitoraggio servizio Azure Kubernetes con Monitoraggio di Azure.

Per esaminare le considerazioni sul monitoraggio specifiche di Windows incluse nei contenitori windows nell'architettura di riferimento della baseline del servizio Azure Kubernetes, vedere l'articolo complementare.

Abilitare la riparazione automatica

Monitorare l'integrità dei pod impostando probe di Liveness e Readiness. Se viene rilevato un pod che non risponde, Kubernetes riavvia il pod. Il probe di attività determina se il pod è integro. Se non risponde, Kubernetes riavvierà il pod. Il probe di idoneità determina se il pod è pronto per ricevere richieste/traffico.

Aggiornamenti del cluster del servizio Azure Kubernetes

Definire una strategia di aggiornamento coerente con i requisiti aziendali è fondamentale. Comprendere il livello di prevedibilità per la data e l'ora in cui la versione del cluster del servizio Azure Kubernetes o i relativi nodi vengono aggiornati e il grado di controllo desiderato su quali immagini o file binari specifici vengono installati sono aspetti fondamentali che delineano il progetto di aggiornamento del cluster del servizio Azure Kubernetes. La prevedibilità è associata a due principali proprietà di aggiornamento del cluster del servizio Azure Kubernetes che sono la frequenza di aggiornamento e la finestra di manutenzione. Il controllo indica se gli aggiornamenti vengono installati manualmente o automaticamente. Le organizzazioni con cluster del servizio Azure Kubernetes che non sono conformi a una rigida normativa sulla sicurezza possono prendere in considerazione aggiornamenti settimanali o persino mensili, mentre il resto deve aggiornare le patch con etichetta di sicurezza non appena disponibili (giornaliere). Le organizzazioni che gestiscono cluster del servizio Azure Kubernetes come infrastruttura non modificabile non li aggiornano. Significa che non vengono eseguiti aggiornamenti automatici o manuali. Al contrario, quando un aggiornamento desiderato diventa disponibile, viene distribuito un timbro di replica e solo quando la nuova istanza dell'infrastruttura è pronta, quella precedente viene svuotata offrendo loro il massimo livello di controllo.

Dopo aver determinato il progetto di aggiornamento del cluster del servizio Azure Kubernetes, è possibile eseguire facilmente il mapping nelle opzioni di aggiornamento disponibili per i nodi del servizio Azure Kubernetes e la versione del cluster del servizio Azure Kubernetes:

• Nodi del servizio Azure Kubernetes:

  1. Aggiornamenti none/manuali: si tratta di un'infrastruttura non modificabile o quando gli aggiornamenti manuali sono le preferenze. In questo modo si ottiene la prevedibilità e il controllo di livello maggiore sugli aggiornamenti dei nodi del servizio Azure Kubernetes.
  2. Aggiornamenti automatici automatici: il servizio Azure Kubernetes esegue gli aggiornamenti nativi del sistema operativo. Ciò garantisce la prevedibilità configurando finestre di manutenzione allineate a ciò che è utile per l'azienda. Potrebbe essere basato sulle ore di punta e sulle migliori operazioni. Il livello di controllo è basso perché non è possibile sapere in anticipo cosa verrà installato specificamente all'interno del nodo del servizio Azure Kubernetes.
  3. Aggiornamenti automatici delle immagini del nodo: è consigliabile aggiornare automaticamente le immagini dei nodi del servizio Azure Kubernetes quando diventano disponibili nuovi dischi rigidi virtuali (VHD). Progettare finestre di manutenzione da allineare il più possibile alle esigenze aziendali. Per gli aggiornamenti del disco rigido virtuale con etichetta di sicurezza, è consigliabile configurare una finestra di manutenzione giornaliera che offre la prevedibilità più bassa. Gli aggiornamenti regolari del disco rigido virtuale possono essere configurati con una finestra di manutenzione settimanale, ogni due settimane o anche mensilmente. A seconda che la necessità sia per i dischi rigidi virtuali con etichetta di sicurezza rispetto ai normali dischi rigidi virtuali combinati con la finestra di manutenzione pianificata, la prevedibilità varia offrendo maggiore o meno flessibilità da allineare ai requisiti aziendali. Lasciando questo sempre fino ai requisiti aziendali sarebbe ideale, la realtà impone alle organizzazioni di trovare il punto di puntamento. Il livello di controllo è basso perché non è possibile sapere in anticipo quali file binari specifici sono stati inclusi in un nuovo disco rigido virtuale e ancora questo tipo di aggiornamenti automatici è l'opzione consigliata poiché le immagini vengono controllate prima di diventare disponibili.

  Nota

  Per altre informazioni su come configurare gli aggiornamenti automatici dei nodi del servizio Azure Kubernetes, vedere Immagini del sistema operativo del nodo di aggiornamento automatico.

• Versione del cluster del servizio Azure Kubernetes:

  1. Aggiornamenti none/manuali: si tratta di un'infrastruttura non modificabile o quando gli aggiornamenti manuali sono le preferenze. In questo modo si ottiene la prevedibilità e il controllo di livello maggiore sugli aggiornamenti delle versioni del cluster del servizio Azure Kubernetes. È consigliabile acconsentire esplicitamente a questo problema, poiché questo lascia il controllo completo, dando la possibilità di testare una nuova versione del cluster del servizio Azure Kubernetes (ad esempio 1.14.x a 1.15.x) in ambienti inferiori prima di raggiungere la produzione.
  2. Aggiornamenti automatici: non è consigliabile applicare automaticamente patch o aggiornare un cluster di produzione in qualsiasi modo (ad esempio da 1.16.x a 1.16.y) alla nuova versione del cluster del servizio Azure Kubernetes disponibile senza essere testata correttamente negli ambienti inferiori. Anche se le versioni upstream di Kubernetes e gli aggiornamenti delle versioni del cluster del servizio Azure Kubernetes sono coordinati fornendo una cadenza regolare, la raccomandazione è ancora di essere difensiva con i cluster del servizio Azure Kubernetes nell'ambiente di produzione, aumentando la prevedibilità e il controllo sul processo di aggiornamento. Per considerare questa configurazione per gli ambienti inferiori come parte dell'eccellenza operativa, consentendo esecuzioni proattive di test di routine per rilevare potenziali problemi il prima possibile.

Mantenere aggiornata la versione di Kubernetes con le versioni N-2 supportate. L'aggiornamento alla versione più recente di Kubernetes è fondamentale perché le nuove versioni vengono rilasciate di frequente.

Per altre informazioni, vedere Aggiornare regolarmente la versione più recente di Kubernetes e aggiornare un cluster del servizio Azure Kubernetes .For more information, see Regularly update to the latest version of Kubernetes and Upgrade an servizio Azure Kubernetes cluster (AKS).

La notifica degli eventi generati dal cluster, ad esempio la disponibilità della nuova versione del servizio Azure Kubernetes per il cluster, può essere ottenuta tramite l'argomento di sistema del servizio Azure Kubernetes per Griglia di eventi di Azure. L'implementazione di riferimento distribuisce questo argomento di sistema di Griglia di eventi in modo che sia possibile sottoscrivere l'evento dalla soluzione di notifica del Microsoft.ContainerService.NewKubernetesVersionAvailable flusso di eventi.

Aggiornamenti settimanali

Il servizio Azure Kubernetes fornisce nuove immagini del nodo con gli aggiornamenti più recenti del sistema operativo e del runtime. Queste nuove immagini non vengono applicate automaticamente. L'utente è responsabile della scelta della frequenza con cui le immagini devono essere aggiornate. È consigliabile eseguire un processo per aggiornare settimanalmente l'immagine di base dei pool di nodi. Per altre informazioni, vedere Servizio Azure Kubernetes (AKS) node image upgrade the AKS Release Notes (Note sulla versione del servizio Azure Kubernetes).

Aggiornamenti giornalieri

Tra gli aggiornamenti delle immagini, i nodi del servizio Azure Kubernetes scaricano e installano singolarmente le patch del sistema operativo e del runtime. Un'installazione potrebbe richiedere il riavvio delle macchine virtuali del nodo. Il servizio Azure Kubernetes non riavvia i nodi a causa di aggiornamenti in sospeso. Disporre di un processo che monitora i nodi per gli aggiornamenti applicati che richiedono un riavvio ed esegue il riavvio di tali nodi in modo controllato. Un'opzione open source è Kured (daemon di riavvio di Kubernetes).

Mantenere sincronizzate le immagini del nodo con la versione settimanale più recente riduce al minimo queste occasionali richieste di riavvio mantenendo al tempo stesso un comportamento di sicurezza avanzato. L'aggiornamento delle immagini del nodo garantisce la compatibilità del servizio Azure Kubernetes e l'applicazione settimanale di patch alla sicurezza. Mentre l'applicazione degli aggiornamenti giornalieri risolverà più rapidamente i problemi di sicurezza, non sono necessariamente stati testati nel servizio Azure Kubernetes. Se possibile, usare l'aggiornamento dell'immagine del nodo come strategia di applicazione di patch alla sicurezza settimanale principale.

Monitoraggio della sicurezza

Monitorare l'infrastruttura contenitore sia per le minacce attive che per i potenziali rischi per la sicurezza:

• Abilitare Microsoft Defender per contenitori per identificare e correggere Defender per il cloud raccomandazioni per le immagini del contenitore.
• Microsoft Defender per contenitori analizza regolarmente le immagini del contenitore per individuare le vulnerabilità.
• Microsoft Defender per contenitori genera anche avvisi di sicurezza in tempo reale per attività sospette.
• Per informazioni sulla protezione avanzata applicata agli host delle macchine virtuali del servizio Azure Kubernetes, vedere Protezione avanzata nel sistema operativo host.

Operazioni del cluster e del carico di lavoro (DevOps)

Ecco alcune considerazioni. Per altre informazioni, vedere il pilastro Dell'eccellenza operativa.

Bootstrap del cluster

Al termine del provisioning, è disponibile un cluster funzionante, ma potrebbero essere necessari passaggi prima della distribuzione dei carichi di lavoro. Il processo di preparazione del cluster è denominato bootstrapping e può essere costituito da azioni come la distribuzione di immagini dei prerequisiti nei nodi del cluster, la creazione di spazi dei nomi e qualsiasi altro elemento che soddisfi i requisiti del caso d'uso o dell'organizzazione.

Per ridurre il divario tra un cluster con provisioning e un cluster configurato correttamente, gli operatori del cluster devono considerare l'aspetto del processo di bootstrap univoco e preparare in anticipo gli asset pertinenti. Ad esempio, se Kured è in esecuzione in ogni nodo prima della distribuzione dei carichi di lavoro dell'applicazione è importante, l'operatore del cluster vuole assicurarsi che un Registro Azure Container contenente l'immagine Kured di destinazione esista già prima del provisioning del cluster.

Il processo di bootstrap può essere configurato usando uno dei metodi seguenti:

• Autoconfigurazione con qualcosa come Flux o Argo CD
• Pipeline
• Estensione del cluster GitOps Flux v2

Uno dei principali vantaggi dell'uso dell'estensione del cluster GitOps Flux v2 per il servizio Azure Kubernetes è che non esiste un divario tra un cluster con provisioning e un cluster di avvio automatico. Imposta l'ambiente con una solida base di gestione in futuro e supporta anche l'inclusione di tale bootstrap come modelli di risorse per allinearsi alla strategia IaC.

Infine, quando si usa l'estensione, kubectl non è necessario per nessuna parte del processo di bootstrap e l'utilizzo dell'accesso kubectlbasato su può essere riservato per situazioni di correzione di emergenza. Tra i modelli per le definizioni delle risorse di Azure e il bootstrap dei manifesti tramite l'estensione GitOps, tutte le normali attività di configurazione possono essere eseguite senza la necessità di usare kubectl.

Isolare le responsabilità del carico di lavoro

Dividere il carico di lavoro per team e tipi di risorse per gestire singolarmente ogni parte.

Iniziare con un carico di lavoro di base che contiene i componenti fondamentali e compilarlo. Un'attività iniziale sarebbe quella di configurare la rete. Effettuare il provisioning di reti virtuali per hub e spoke e subnet all'interno di tali reti. Ad esempio, lo spoke ha subnet separate per i pool di nodi di sistema e utente e le risorse di ingresso. Una subnet per Firewall di Azure nell'hub.

Un'altra parte potrebbe essere quella di integrare il carico di lavoro di base con Microsoft Entra ID.

Usare Infrastructure as Code (IaC)

Scegliere un metodo dichiarativo idempotente su un approccio imperativo, laddove possibile. Anziché scrivere una sequenza di comandi che specificano le opzioni di configurazione, usare la sintassi dichiarativa che descrive le risorse e le relative proprietà. Un'opzione è un modello di Azure Resource Manager (ARM ). Un altro è Terraform.

Assicurarsi di effettuare il provisioning delle risorse in base ai criteri di governance. Ad esempio, quando si selezionano le dimensioni corrette delle macchine virtuali, rimanere entro i vincoli di costo, le opzioni della zona di disponibilità per soddisfare i requisiti dell'applicazione.

Se è necessario scrivere una sequenza di comandi, usare l'interfaccia della riga di comando di Azure. Questi comandi coprono una gamma di servizi di Azure e possono essere automatizzati tramite scripting. L'interfaccia della riga di comando di Azure è supportata in Windows e Linux. Un'altra opzione multipiattaforma è Azure PowerShell. La scelta dipenderà dal set di competenze preferito.

Archiviare script e versioni e file modello nel sistema di controllo del codice sorgente.

CI/CD del carico di lavoro

Le pipeline per il flusso di lavoro e la distribuzione devono avere la possibilità di compilare e distribuire le applicazioni in modo continuo. Aggiornamenti deve essere distribuito in modo sicuro e rapido ed eseguito il rollback in caso di problemi.

La strategia di distribuzione deve includere una pipeline di recapito continuo (CD) affidabile e automatizzata. Le modifiche apportate alle immagini del contenitore del carico di lavoro devono essere distribuite automaticamente nel cluster.

In questa architettura è stato scelto GitHub Actions per la gestione del flusso di lavoro e della distribuzione. Altre opzioni comuni includono Azure DevOps Services e Jenkins.

Integrazione continua/distribuzione continua del cluster

Scaricare un file di Visio di questa architettura.

Anziché usare un approccio imperativo come kubectl, usare strumenti che sincronizzano automaticamente le modifiche del cluster e del repository. Per gestire il flusso di lavoro, ad esempio il rilascio di una nuova versione e la convalida di tale versione prima della distribuzione nell'ambiente di produzione, prendere in considerazione un flusso GitOps.

Una parte essenziale del flusso CI/CD è il bootstrap di un cluster appena sottoposto a provisioning. Un approccio GitOps è utile verso questo fine, consentendo agli operatori di definire in modo dichiarativo il processo di bootstrap come parte della strategia IaC e vedere la configurazione riflessa automaticamente nel cluster.

Quando si usa GitOps, un agente viene distribuito nel cluster per assicurarsi che lo stato del cluster sia coordinato con la configurazione archiviata nel repository Git privato. Uno di questi agenti è flux, che usa uno o più operatori nel cluster per attivare le distribuzioni all'interno di Kubernetes. Flux esegue queste attività:

• Esegue il monitoraggio di tutti i repository configurati.
• Rileva le nuove modifiche di configurazione.
• Attiva le distribuzioni.
• Aggiornamenti la configurazione in esecuzione desiderata in base a tali modifiche.

È anche possibile impostare criteri che regolano la modalità di distribuzione di tali modifiche.

Di seguito è riportato un esempio che illustra come automatizzare la configurazione del cluster con GitOps e flux:

Scaricare un file di Visio di questa architettura.

1. Uno sviluppatore esegue il commit delle modifiche al codice sorgente, ad esempio i file YAML di configurazione, archiviati in un repository Git. Le modifiche vengono quindi inoltrate a un server Git.

2. Flux viene eseguito nel pod insieme al carico di lavoro. Flux ha accesso in sola lettura al repository Git per assicurarsi che Flux applichi solo le modifiche richieste dagli sviluppatori.

3. Flux riconosce le modifiche nella configurazione e applica tali modifiche usando i comandi kubectl.

4. Gli sviluppatori non hanno accesso diretto all'API Kubernetes tramite kubectl.

5. Disporre di criteri di ramo nel server Git. In questo modo, più sviluppatori possono approvare una modifica tramite una richiesta pull prima che venga applicata all'ambiente di produzione.

Anche se GitOps e Flux possono essere configurati manualmente, è consigliabile usare l'estensione del cluster GitOps con Flux v2 per il servizio Azure Kubernetes .

Strategie di distribuzione del carico di lavoro e del cluster

Distribuire qualsiasi modifica (componenti dell'architettura, carico di lavoro, configurazione del cluster) in almeno un cluster del servizio Azure Kubernetes di pre-produzione. In questo modo, la modifica potrebbe sbloccare i problemi prima della distribuzione nell'ambiente di produzione.

Eseguire test/convalide in ogni fase prima di passare alla successiva per assicurarsi di poter eseguire il push degli aggiornamenti nell'ambiente di produzione in modo altamente controllato e ridurre al minimo le interruzioni dai problemi di distribuzione imprevisti. Questa distribuzione deve seguire un modello simile a quello di produzione, usando la stessa pipeline di GitHub Actions o gli operatori Flux.

Le tecniche di distribuzione avanzate, ad esempio la distribuzione blu-verde, i test A/B e le versioni Canary, richiedono processi aggiuntivi e strumenti potenzialmente. Flagger è una soluzione open source comune per risolvere gli scenari di distribuzione avanzati.

Gestione costi

Per iniziare, esaminare l'elenco di controllo per la progettazione dell'ottimizzazione dei costi e l'elenco di raccomandazioni descritte in Well Architected Framework per il servizio Azure Kubernetes. Usare il calcolatore prezzi di Azure per stimare i costi per i servizi usati nell'architettura. Altre procedure consigliate sono descritte nella sezione Ottimizzazione costi in Microsoft Azure Well-Architected Framework.

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.

Per esaminare le considerazioni sulla gestione dei costi specifiche per i carichi di lavoro basati su Windows inclusi nei contenitori di Windows nell'architettura di riferimento della baseline del servizio Azure Kubernetes, vedere l'articolo complementare.

Provisioning di

• Non sono previsti costi associati al servizio Azure Kubernetes nella distribuzione, nella gestione e nelle operazioni del cluster Kubernetes. Ciò che influisce sui costi sono le istanze della macchina virtuale, l'archiviazione, i dati di log e le risorse di rete utilizzate dal cluster. Valutare la possibilità di scegliere macchine virtuali più economiche per i pool di nodi di sistema. Lo SKU DS2_v2 è un tipo di macchina virtuale tipico per il pool di nodi di sistema.

• Non avere la stessa configurazione per ambienti di sviluppo/test e produzione. I carichi di lavoro di produzione hanno requisiti aggiuntivi per la disponibilità elevata e sono in genere più costosi. Questa configurazione non è necessaria nell'ambiente di sviluppo/test.

• Per i carichi di lavoro di produzione, aggiungere un contratto di servizio tempo di attività. Tuttavia, esistono risparmi per i cluster progettati per carichi di lavoro di sviluppo/test o sperimentali in cui la disponibilità non è necessaria per essere garantita. Ad esempio, lo SLO è sufficiente. Inoltre, se il carico di lavoro lo supporta, prendere in considerazione l'uso di pool di nodi spot dedicati che eseguono macchine virtuali spot.

  Per i carichi di lavoro non di produzione che includono database SQL di Azure o app Azure Servizio come parte dell'architettura del carico di lavoro del servizio Azure Kubernetes, valutare se si è idonei a usare le sottoscrizioni di Sviluppo/test di Azure per ricevere sconti sul servizio.

• Anziché iniziare con un cluster sovradimensionato per soddisfare le esigenze di ridimensionamento, effettuare il provisioning di un cluster con un numero minimo di nodi e consentire al ridimensionamento automatico del cluster di monitorare e prendere decisioni di ridimensionamento.

• Impostare le richieste e i limiti dei pod per consentire a Kubernetes di allocare le risorse del nodo con una densità più elevata in modo che l'hardware venga usato per la capacità.

• L'abilitazione della diagnostica nel cluster può aumentare il costo.

• Se il carico di lavoro è previsto per un lungo periodo, è possibile eseguire il commit in istanze di macchina virtuale riservate di uno o tre anni per ridurre i costi del nodo. Per altre informazioni, vedere Macchine virtuali riservate.

• Usare i tag quando si creano pool di nodi. I tag sono utili per creare report personalizzati per tenere traccia dei costi sostenuti. I tag consentono di tenere traccia del totale delle spese ed eseguire il mapping di qualsiasi costo a una risorsa o a un team specifico. Inoltre, se il cluster viene condiviso tra i team, creare report di chargeback per consumer per identificare i costi a consumo per i servizi cloud condivisi. Per altre informazioni, vedere Specificare un taint, un'etichetta o un tag per un pool di nodi.

• I trasferimenti di dati tra zone di disponibilità in un'area non sono gratuiti. Se il carico di lavoro è in più aree o sono presenti trasferimenti tra zone di disponibilità, prevedere costi aggiuntivi per la larghezza di banda. Per altre informazioni, vedere Traffico tra zone e aree di fatturazione.

• Creare budget per rimanere entro i vincoli di costo identificati dall'organizzazione. Un modo consiste nel creare budget tramite Gestione costi di Azure. È anche possibile creare avvisi per ricevere notifiche quando vengono superate determinate soglie. Per altre informazioni, vedere Creare un budget usando un modello.

Monitoraggio

Per monitorare i costi dell'intero cluster, oltre ai costi di calcolo, raccogliere anche informazioni sui costi relativi all'archiviazione, alla larghezza di banda, al firewall e ai log. Azure offre vari dashboard per monitorare e analizzare i costi:

• Azure Advisor

• Gestione costi di Azure

Idealmente, monitorare i costi in tempo reale o almeno una cadenza regolare per intervenire prima della fine del mese quando i costi sono già calcolati. Monitorare anche la tendenza mensile nel tempo per rimanere nel budget.

Per prendere decisioni basate sui dati, individuare la risorsa (livello granulare) che comporta il maggior costo. Avere anche una buona conoscenza dei contatori usati per calcolare l'utilizzo di ogni risorsa. Analizzando le metriche, è possibile determinare se la piattaforma è sovradimensionato, ad esempio. È possibile visualizzare i contatori di utilizzo nelle metriche di Monitoraggio di Azure.

Ottimizzazione

Agire sulle raccomandazioni fornite da Azure Advisor. Esistono altri modi per ottimizzare:

• Abilitare il ridimensionamento automatico del cluster per rilevare e rimuovere nodi sottoutilizzati nel pool di nodi.

• Scegliere uno SKU inferiore per i pool di nodi, se il carico di lavoro lo supporta.

• Se l'applicazione non richiede il ridimensionamento burst, valutare la possibilità di ridimensionare il cluster in base alle dimensioni corrette analizzando le metriche delle prestazioni nel tempo.

• Se il carico di lavoro lo supporta, ridimensionare i pool di nodi utente a 0 nodi quando non è previsto che siano in esecuzione. Inoltre, se non sono stati pianificati carichi di lavoro che devono essere eseguiti nel cluster, è consigliabile usare la funzionalità Avvio/Arresto del servizio Azure Kubernetes per arrestare tutte le risorse di calcolo, che includono il pool di nodi di sistema e il piano di controllo del servizio Azure Kubernetes.

Per altre informazioni sui costi, vedere Prezzi del servizio Azure Kubernetes.

Passaggi successivi

Continuare a conoscere l'architettura di base del servizio Azure Kubernetes:

• Per informazioni sull'hosting di microservizi nella baseline del servizio Azure Kubernetes, vedere Architettura avanzata dei microservizi servizio Azure Kubernetes del servizio Azure Kubernetes.
• Per la distribuzione della baseline del servizio Azure Kubernetes in più aree, vedere Baseline del servizio Azure Kubernetes per cluster con più aree.
• Per la distribuzione della baseline del servizio Azure Kubernetes in un ambiente PCI-DSS 3.2.1, vedere Cluster regolamentato del servizio Azure Kubernetes per PCI-DSS 3.2.1.
• Per informazioni sulle considerazioni sull'aggiunta di contenitori Windows all'architettura di riferimento, vedere l'articolo complementare: Contenitori Windows nell'architettura di riferimento della baseline del servizio Azure Kubernetes

Scopri di più sul servizio Azure Kubernetes

• Esaminare la roadmap del prodotto del servizio Azure Kubernetes, vedere servizio Azure Kubernetes Roadmap su GitHub.
• Se è necessario un aggiornamento in Kubernetes, completare l'introduzione a Kubernetes e sviluppare e distribuire applicazioni nei percorsi di apprendimento kubernetes .

Risorse correlate

Vedere le guide correlate seguenti:

• Revisione di Azure Well-Architected Framework per servizio Azure Kubernetes (AKS)
• Acceleratore di zona di destinazione del servizio Azure Kubernetes, che è un'implementazione su scala aziendale basata su questa architettura. L'acceleratore consente di configurare l'ambiente di Azure in modo coerente e ripetibile usando Infrastructure-As-Code (IaC) per una distribuzione del servizio Azure Kubernetes (Servizio Azure Kubernetes).
• Guida alle operazioni di manutenzione ordinaria del servizio Azure Kubernetes

Vedere le architetture correlate seguenti:

• Architettura di microservizi nel servizio Azure Kubernetes
• Usare Firewall di Azure per proteggere un cluster servizio Azure Kubernetes (servizio Azure Kubernetes)
• GitOps per servizio Azure Kubernetes
• Streaming dei dati con il servizio Azure Kubernetes