Architettura di base per un cluster del servizio Azure Kubernetes

Azure Active Directory
Gateway applicazione
Bastion
Registro contenitori
Firewall
Key Vault
Servizio Kubernetes
Load Balancer
Monitoraggio
Criteri
Collegamento privato
Controllo degli accessi in base al ruolo di Azure

In questa architettura di riferimento verrà compilata un'infrastruttura di base che distribuisce un cluster servizio Azure Kubernetes (AKS). Questo articolo include raccomandazioni per la rete, la sicurezza, l'identità, la gestione e il monitoraggio del cluster in base ai requisiti aziendali di un'organizzazione.

Logo gitHub Un'implementazione di questa architettura è disponibile in GitHub: servizio Azure Kubernetes (AKS) Secure Baseline Reference Implementation. È possibile usarlo come punto di partenza e configurarlo in base alle proprie esigenze.

Nota

Questa architettura di riferimento richiede una conoscenza di Kubernetes e dei relativi concetti. Se è necessario un aggiornamento, vedere la sezione Articoli correlati per le risorse.

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 isolata. Consente di applicare la governance e controllare il raggio del raggio. Supporta anche il concetto di zona di destinazione 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 regione. Le topologie di rete hub-spoke possono essere espanse in futuro e fornire l'isolamento del carico di lavoro.

  • Tutte le applicazioni Web devono richiedere un web application firewall web (WAF) per gestire i flussi di traffico HTTP.

  • Scelta naturale per i carichi di lavoro che si estendono su più sottoscrizioni.

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

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

Topologia di rete hub-spoke

Hub

La rete virtuale hub è il punto centrale di connettività e osservabilità. All'interno della rete vengono distribuite tre subnet.

Subnet in cui ospitare Firewall di Azure

Firewall di Azure è un firewall come servizio. L'istanza del firewall protegge il traffico di rete in uscita. Senza questo livello di sicurezza, il flusso potrebbe comunicare con un servizio di terze parti dannoso che potrebbe esfiltrare dati aziendali sensibili.

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 in cui 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.

Parlato

La rete virtuale spoke conterrà il cluster del servizio Web Diaks e altre risorse correlate. Lo spoke ha tre subnet:

Subnet in cui ospitare 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 v2 del gateway applicazione che abilita Web Application Firewall (WAF). WAF protegge il traffico in ingresso da attacchi comuni al traffico Web. L'istanza ha una configurazione IP front-end pubblica che riceve le richieste dell'utente. Per impostazione predefinita, il gateway applicazione richiede una subnet dedicata.

Subnet in cui ospitare le risorse in ingresso

Per instradare e distribuire il traffico, Traefik è il controller di ingresso che sta per soddisfare le risorse in ingresso di Kubernetes. I servizi di bilanciamento del carico interni di Azure sono presenti in questa subnet.

Subnet in cui ospitare i nodi del cluster

Il servizio AKS gestisce due gruppi separati di nodi (o pool di nodi). Il pool di nodi di sistema ospita i pod che eseguono i servizi cluster principali. Il pool di nodi utente esegue il carico di lavoro contoso e il controller di ingresso per facilitare la comunicazione in ingresso con il carico di lavoro. Il carico di lavoro è un'ASP.NET semplice.

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

Pianificare gli indirizzi IP

Topologia di rete del cluster del servizio Web Diaks

Lo spazio indirizzi della rete virtuale deve essere sufficientemente grande da contenere tutte le subnet. Account per 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

    AKS 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 AKS crea un nodo che ospita temporaneamente i pod, mentre il nodo di aggiornamento viene svuotato. Al 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 ne vengono creati di nuovi. Pertanto, gli indirizzi associati ai pod vecchi vengono riutilizzati.

  • Scalabilità

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

    In questa architettura ogni pod può essere contattato direttamente. Ogni pod necessita quindi di un singolo indirizzo. La scalabilità dei pod inciderà sul calcolo dell'indirizzo. Tale decisione dipenderà dalla scelta del numero di pod da aumentare.

  • collegamento privato di Azure indirizzi

    Fattori degli indirizzi necessari per la comunicazione con altri servizi di Azure tramite collegamento privato. In questa architettura sono stati assegnati due indirizzi per i collegamenti Registro Azure Container e 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 incideranno sul numero di indirizzi IP disponibili, inserire 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 può comportare più subnet di dimensioni inferiori. Inoltre, la risorsa in ingresso potrebbe essere più complessa. Potrebbero essere necessari più controller di ingresso che richiedono indirizzi aggiuntivi.

Per il set completo di considerazioni per questa architettura, vedere Topologia di rete di base del servizio Web Del servizio Web Di seguito.

Per informazioni sulla pianificazione dell'indirizzo IP per un cluster del servizio Web Diaks, vedere Pianificare l'indirizzamento IP per il cluster.

Informazioni di riferimento sull'immagine del contenitore

Oltre al carico di lavoro, il cluster potrebbe contenere diverse altre immagini, ad esempio il controller di ingresso. Alcune di queste immagini possono risiedere in registri pubblici. Prendere in considerazione questi punti quando si esegue 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 l'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 è necessaria. Ecco alcuni vantaggi dell'uso del registro contenitori anziché di un registro pubblico:

    • È possibile bloccare l'accesso non autorizzato alle immagini.
    • Non si hanno dipendenze pubbliche.
    • È possibile accedere ai log di pull delle immagini per monitorare le attività e verificare 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 di immagini da registri autorizzati. È possibile applicare questa restrizione tramite Criteri di Azure. In questa implementazione di riferimento, il cluster estrae solo le immagini da Registro Controllo di accesso distribuito come parte dell'architettura.

Configurare il calcolo per il cluster di base

Nel servizio Diaks ogni pool di nodi esegue il mapping a un set di scalabilità di macchine virtuali. I nodi sono macchine virtuali in ogni pool di nodi. Prendere in considerazione l'uso di una macchina virtuale di dimensioni inferiori 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 DS2_v2 nodi. Tale dimensione è sufficiente per soddisfare il carico previsto dei pod di sistema. Il disco del sistema operativo è di 512 GB.

Per il pool di nodi utente, di seguito sono riportate alcune considerazioni:

  • Scegliere dimensioni di nodo maggiori per creare un pacchetto del numero massimo di pod impostati in un nodo. Ridurrà al minimo il footprint dei servizi in esecuzione 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 Diaks è possibile modificare il numero di nodi senza ricreare il cluster.

  • Le dimensioni effettive dei nodi per il carico di lavoro dipenderanno dai requisiti determinati dal team di progettazione. In base ai requisiti aziendali, è stato scelto di DS4_v2 per il carico di lavoro di produzione. Per ridurre i costi, è possibile ridurre le dimensioni DS3_v2, che è la raccomandazione minima.

  • Quando si pianifica la capacità per il cluster, si supponga che il carico di lavoro possa utilizzare fino all'80% di ogni nodo. il restante 20% è riservato per i servizi del servizio Web Diaks.

  • 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. Modificare tale valore in base ai requisiti del carico di lavoro, alle dimensioni del nodo e ai vincoli IP.

Integrare Azure Active Directory per il cluster

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

  • Accesso esterno a. Autorizzare solo le entità esterne a cui è consentito l'accesso al server API Kubernetes Azure Resource Manager.

  • Accesso interno all'interno di. Autorizzare solo le risorse a cui è consentito l'accesso al cluster.

Esistono due modi per gestire l'accesso tramite Azure Active Directory (Azure AD): entità servizio o identità gestite per le risorse di Azure.

Tra i due modi, è consigliabile utilizzare le identità gestite. Con le entità servizio, l'utente è responsabile della gestione e della rotazione dei segreti, manualmente o a livello di codice. Con le identità gestite, Azure AD gestisce ed esegue automaticamente l'autenticazione e la rotazione dei segreti.

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

Come esempio per il caso inside-out, si esamini 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 di sistema. Un modo è archiviare le informazioni sotto forma di oggetto Segreti Kubernetes e usare imagePullSecrets per recuperare il segreto. Questo approccio non è consigliato a causa di complessità della sicurezza. Non solo è necessaria una conoscenza preliminare del segreto, ma anche la divulgazione di tale segreto tramite la pipeline DevOps. Un altro motivo è il sovraccarico operativo della gestione della rotazione del segreto. Concedere invece acrPull l'accesso all'identità gestita del cluster al registro. Questo approccio risolve questi problemi.

In questa architettura, il cluster accede alle risorse di Azure protette da Azure AD ed esegue 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 eseguirà l'autenticazione Azure AD e quindi verrà consentito o negato l'accesso in base ai ruoli assegnati. Di seguito sono riportati 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 Web Del servizio Gestione licenze di funzionare con la subnet dedicata per i servizi controller di ingresso interni.

  • Server di pubblicazione delle 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.

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

Associare il controllo degli accessi in base al ruolo di Kubernetes Azure Active Directory

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

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

  • Associazioni che assegnano utenti e gruppi a cui è consentito eseguire le azioni. Definito da un RoleBinding oggetto CluserRoleBinding o .

Kubernetes ha alcuni ruoli predefiniti, ad esempio amministratore del cluster, modifica, visualizzazione e così via. Associare tali ruoli a Azure Active Directory utenti e gruppi per usare la directory aziendale per gestire l'accesso. Per altre informazioni, vedere Use Kubernetes RBAC with Azure AD integration(Usare il controllo degli accessi in base al ruolo di Kubernetes Azure AD integrazione).

È anche possibile usare i ruoli di Azure anziché i ruoli predefiniti di Kubernetes. Per altre informazioni, vedere Ruoli di Azure.

Integrare Azure Active Directory per il carico di lavoro

Analogamente alla presenza di identità gestite di Azure per l'intero cluster, è possibile assegnare identità gestite a livello di pod. Un'identità gestita di pod consente al carico di lavoro ospitato di accedere alle risorse tramite Azure Active Directory. Ad esempio, il carico di lavoro archivia i file nel Archiviazione di Azure. Quando deve accedere a tali file, il pod eseguirà l'autenticazione in base alla risorsa.

In questa implementazione di riferimento, le identità del pod gestito vengono semplificate tramite aad-pod-identity.

Distribuire le risorse in ingresso

Le risorse in ingresso kubernetes instradare e distribuire il traffico in ingresso al cluster. Esistono due parti delle risorse in ingresso:

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

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

  • Controller di ingresso. È stato 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 entro il quale il controller di ingresso sarà autorizzato a operare. 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 inattività di un nodo. Usare podAntiAffinity a questo scopo.

  • Vincolare i pod da programmare solo nel pool di nodi utente usando nodeSelectors . Questa impostazione isola i pod di carico di lavoro e 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 da gateway applicazione di Azure.

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

  • Valutare la possibilità di limitare l'accesso del controller di ingresso a risorse specifiche e la possibilità di eseguire determinate azioni. Tale restrizione può essere implementata tramite le autorizzazioni per il 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 servizi ed endpoint usando regole nell'oggetto ClusterRole Kubernetes.

Nota

La scelta del controller di ingresso appropriato è basata sui requisiti del carico di lavoro, sul set di competenze dell'operatore e sulla supportabilità delle opzioni tecnologiche. Soprattutto, la possibilità di soddisfare le aspettative di SLO.

Traefik è un'opzione open source diffusa per un cluster Kubernetes ed è stata scelta in questa architettura a scopo illustrativo. Mostra l'integrazione di prodotti di terze parti con i servizi di Azure. Ad esempio, l'implementazione mostra come integrare Traefik con Azure AD pod managed identity e Azure Key Vault.

Un'altra scelta è gateway applicazione di Azure controller in ingresso ed è ben integrato con il servizio AKS. Oltre alle funzionalità di controller in ingresso, offre altri vantaggi. Ad esempio, il gateway applicazione facilita il punto di ingresso della rete virtuale del cluster. Può osservare il traffico che entra nel cluster. Se si dispone di un'applicazione che richiede WAF, il gateway applicazione è una scelta ottimale perché è integrato con WAF. Offre anche la possibilità di eseguire la terminazione TLS.

Impostazioni del router

Il controller di ingresso usa le 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 sui protocolli di destinazione.

Ecco un esempio di questa architettura:

Traefik usa il provider Kubernetes per configurare le route. , annotations tls e entrypoints indicano che le route verranno servite tramite HTTPS. specifica middlewares che è consentito solo il traffico gateway applicazione di Azure subnet. 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/v1beta1
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: /
        backend:
          serviceName: aspnetapp-service
          servicePort: http

Proteggere il flusso di rete

Il flusso di rete, in questo contesto, può essere categorizzato 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.

  • Gestione del traffico. Traffico che passa tra il client e il server API Kubernetes.

Flusso di traffico del cluster

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

Flusso del traffico in ingresso

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

Terminazione TLS

  1. Il client invia una richiesta HTTPS al nome di dominio: bicycle.contoso.com. Tale nome è associato a tramite un record DNS A all'indirizzo IP pubblico di 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. Il gateway applicazione ha un web application firewall (WAF) integrato e negozia l'handshake TLS per bicycle.contoso.com, consentendo solo la crittografia sicura. 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. È possibile accedervi usando un'identità gestita assegnata dall'utente integrata con il gateway applicazione. Per informazioni su tale funzionalità, vedere Terminazione TLS con Key Vault certificati.

  3. Il traffico viene spostato dal gateway applicazione al back-end, il traffico viene crittografato nuovamente con un altro certificato TLS (con caratteri jolly per .aks-ingress.contoso.com) mentre viene inoltrato al servizio di bilanciamento del carico * interno. Questa crittografia assicura che il traffico non sicuro non fluirà 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 inoltra il traffico ai pod del carico * di lavoro tramite HTTP. I certificati vengono archiviati in Azure Key Vault e montati nel cluster usando il driver Container Storage Interface (CSI). Per altre informazioni, vedere Aggiungere la gestione dei segreti.

È possibile implementare il traffico TLS end-to-end a ogni hop fino al 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 del piano di controllo appropriato e le procedure mature del ciclo di vita dello sviluppo software, è sufficiente eseguire la crittografia TLS fino al controller di ingresso e la protezione con Web Application Firewall (WAF). Ciò ridurrà al minimo l'overhead nella gestione dei carichi di lavoro e negli effetti sulle prestazioni di rete. I requisiti di carico di lavoro e conformità determinano dove eseguire la terminazione TLS.

Flusso del traffico in uscita

Per il controllo dell'attendibilità zero 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 (UDT). L'hop successivo della route è l'indirizzo IP privato del Firewall di Azure. In questo Firewall di Azure decide se bloccare o consentire il traffico in uscita. Tale decisione si basa sulle regole specifiche definite nel Firewall di Azure o sulle regole di intelligence per le minacce predefinite.

Nota

Se si usa un servizio di bilanciamento del carico pubblico come punto pubblico per il traffico in ingresso e in uscita tramite Firewall di Azure tramite UDT, potrebbe verificarsi una situazione di routing asimmetrico. Questa architettura usa servizi di bilanciamento del carico interni in una subnet in ingresso dedicata dietro il gateway applicazione. Questa scelta di progettazione non solo migliora la sicurezza, ma elimina anche i problemi di routing asimmetrico. In alternativa, è possibile instradare il traffico in ingresso Firewall di Azure prima o dopo il gateway applicazione. Questo approccio non è necessario o consigliato per la maggior parte delle situazioni. Per altre informazioni sul routing asimmetrico, vedere Integrare Firewall di Azure con Azure Load Balancer Standard.

Un'eccezione al controllo dell'attendibilità zero è 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. L'approccio consigliato consiste nell'collegamento privato di Azure. Il vantaggio è che subnet specifiche raggiungono direttamente il servizio. Inoltre, il traffico tra il cluster e il servizio non viene esposto a Internet pubblico. 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 il collegamento privato. In questi casi, è consigliabile abilitare un endpoint di servizio nella subnet per accedere al servizio.

Se il collegamento privato o gli endpoint di servizio non sono un'opzione, è possibile raggiungere altri servizi tramite i relativi endpoint pubblici e controllare l'accesso tramite regole Firewall di Azure e il firewall integrato nel servizio di destinazione. Poiché questo traffico passa attraverso l'indirizzo IP statico del firewall, tale indirizzo può essere aggiunto all'elenco indirizzi IP consentiti del servizio. Uno svantaggio è che Firewall di Azure avere regole aggiuntive per assicurarsi che sia consentito solo il traffico da una subnet specifica.

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 pod. Applicare i criteri in modo giudizioso, in caso contrario si potrebbe avere una situazione in cui un flusso di rete critico è bloccato. 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 possono essere aggiunti in un secondo momento. Esistono alcune opzioni per le tecnologie che implementano NetworkPolicy . È consigliabile utilizzare Criteri di rete di Azure, che richiede Azure Container Networking Interface (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 standard supporto tecnico di Azure.

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

Nota

Il servizio AKS supporta questi modelli di rete: kubenet e Azure Container Networking Interface (CNI). CNI è più avanzato dei due modelli ed è necessario per abilitare Criteri di rete di Azure. In questo modello, ogni pod ottiene un indirizzo IP dallo spazio indirizzi della subnet. Le risorse all'interno della stessa rete (o risorse con peered) possono accedere ai pod direttamente tramite il relativo indirizzo IP. NAT non è necessario per il routing del traffico.CNI è quindi performante perché non sono presenti sovrapposizioni di rete aggiuntive. Offre anche un controllo di sicurezza migliore perché consente l'uso di Criteri di rete di Azure. In generale, è consigliabile utilizzare CNI. CNI offre un controllo granulare da parte dei team e delle risorse che controllano. CNI consente inoltre pod più scalati rispetto a kubenet. Considerare attentamente questa scelta in caso contrario, sarà necessario ridistribuire il cluster. Per informazioni sui modelli, vedere Confrontare i modelli di rete.

Traffico di gestione

Come parte dell'esecuzione del cluster, il server API Kubernetes riceverà il traffico dalle risorse che vogliono eseguire operazioni di gestione nel cluster, ad esempio le richieste di creazione di risorse o la scalabilità del 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. Invece di accettare questo traffico di gestione da tutti gli indirizzi IP, usare la funzionalità Intervalli IP autorizzati del servizio AKS per consentire solo il traffico dagli intervalli IP autorizzati al server API.

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

Aggiungere 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 fuori dalla pipeline di distribuzione.

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

Accesso ai segreti del cluster

È necessario usare le identità gestite del pod 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 necessita di 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 volume file system.

Il driver CSI dispone di molti provider per supportare vari archivi gestiti. In questa implementazione è stato scelto il Azure Key Vault con secrets store CSI Driver per recuperare il certificato TLS dal Azure Key Vault e caricarlo nel pod che esegue il controller di ingresso. Questa operazione 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 conservarlo all'esterno del cluster. Le linee guida per lo stato del carico di lavoro non sono nell'ambito di questo articolo.

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

Gestione dei criteri

Un modo efficace per gestire un cluster del servizio AKS è l'applicazione della governance tramite criteri. Kubernetes implementa i criteri tramite OPA Gatekeeper. Per il codice AKS, i criteri vengono recapitati tramite Criteri di Azure. Ogni criterio viene applicato a tutti i cluster nel relativo ambito. Criteri di Azure l'imposizione dei criteri viene infine gestita da OPA Gatekeeper nel cluster e vengono registrati tutti i controlli dei criteri. Le modifiche ai criteri non vengono riflesse immediatamente nel cluster. Si prevedono alcuni ritardi.

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 (detti iniziative) o scegliere singoli criteri. Criteri di Azure offre due iniziative incorporate: basic e restricted. Ogni iniziativa è una raccolta di criteri predefiniti applicabili a un cluster del servizio AppKs. È consigliabile selezionare un'iniziativa e scegliere criteri aggiuntivi per il cluster e le risorse (ACR, gateway applicazione, Key Vault e altri) che interagiscono con il cluster, in base ai requisiti dell'organizzazione.

  • Si vuole 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 una cadenza regolare e intraprendere le azioni necessarie. In modalità Nega l'azione viene bloccata perché viola i criteri. Prestare attenzione nella scelta di questa modalità perché può essere troppo restrittiva per il funzionamento del carico di lavoro.

  • Nel carico di lavoro sono presenti aree che non devono essere conformi in base alla progettazione? Criteri di Azure può specificare spazi dei nomi Kubernetes esenti dall'applicazione dei criteri. È consigliabile applicare comunque i criteri in modalità di controllo in modo da essere a conoscenza di tali istanze.

  • Sono presenti requisiti non coperti dai criteri predefiniti? In questi rari casi, creare una definizione di Criteri di Azure personalizzata che applica i criteri OPA Gatekeeper personalizzati. Non applicare i criteri direttamente al cluster.

  • Sono necessari requisiti a livello di organizzazione? In tal caso, aggiungere tali criteri a livello di gruppo di gestione. Il cluster deve anche assegnare i propri 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 siano convalidati anche rispetto all'ambiente di pre-produzione. In caso contrario, quando si esegue la distribuzione nell'ambiente di produzione, potrebbero verificarsi restrizioni aggiuntive impreviste che non sono state prese in considerazione in pre-produzione.

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

L'implementazione imposta anche criteri aggiuntivi che non fanno parte di iniziative incorporate. Questi criteri vengono impostati in modalità Nega. Ad esempio, è disponibile un criterio per assicurarsi che le immagini siano estrasse solo dal controllo di accesso distribuito. Valutare la possibilità di creare iniziative personalizzate. Combinare i criteri applicabili per il carico di lavoro in un'unica assegnazione.

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

Scalabilità di nodi e pod

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

Esistono due approcci: scalabilità automatica o scalabilità manuale.

Il modo manuale o programmatico richiede di monitorare e impostare avvisi sull'utilizzo della CPU o sulle metriche personalizzate. Per il ridimensionamento dei pod, l'operatore dell'applicazione può aumentare o ridurre il numero di repliche di pod regolando tramite le ReplicaSet API Kubernetes. Per il ridimensionamento del cluster, un modo è ricevere una notifica quando l'utilità di pianificazione di Kubernetes ha esito negativo. Un altro modo è quello di controllare 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 perché alcuni di questi meccanismi manuali sono incorporati nella scalabilità automatica.

Come approccio generale, iniziare dai test delle prestazioni con un numero minimo di pod e nodi. Usare questi valori per stabilire l'aspettativa di base. Usare quindi una combinazione di metriche delle prestazioni e scalabilità manuale per individuare i 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 tramite il servizio AKS, 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ò essere ridimensionato in base all'utilizzo della CPU, all'utilizzo della memoria e alle metriche personalizzate. Viene fornito solo l'utilizzo della CPU. La definizione 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 tale valore con l'utilizzo di destinazione e calcola un rapporto. Usa quindi il rapporto per determinare se i pod sono sovraallocati o sottoallocati. Si basa sull'utilità di pianificazione di Kubernetes per assegnare nuovi pod ai nodi o rimuovere i pod dai nodi.

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

Se il carico di lavoro è basato su eventi, un'opzione open source comune è KEDA. Considerare KEDA se il carico di lavoro è gestito da un'origine eventi, ad esempio una coda di messaggi, anziché essere associato alla CPU o alla memoria. KEDA supporta molte origini eventi (o scaler). È possibile trovare l'elenco dei scaler KEDA supportati qui, incluso il Monitoraggio di Azure scaler. un modo pratico per ridimensionare i carichi di lavoro KEDA in base Monitoraggio di Azure metriche.

Scalabilità automatica cluster

La scalabilità automatica del cluster è un componente aggiuntivo del servizio Web Del servizio Web di Microsoft Windows che ridimensiona il numero di nodi in un pool di nodi. Deve essere aggiunto durante il provisioning del cluster. È necessario un ridimensionamento automatico del cluster separato per ogni pool di nodi utente.

Il ridimensionamento automatico del cluster viene attivato dall'utilità di pianificazione di Kubernetes. Quando l'utilità di pianificazione di 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. Al contrario, 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 il ridimensionamento automatico, impostare il numero massimo e minimo di nodi. I valori consigliati dipendono dalle aspettative in termini di prestazioni del carico di lavoro, dalla quantità di crescita del cluster e dalle implicazioni in termini di costi. Il numero minimo è la capacità riservata per il 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.

Decisioni relative alla 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 (AKS).

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 si insedia, 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 non meno di due nodi. Se è necessaria una maggiore disponibilità, effettuare il provisioning di più nodi.

Isolare l'applicazione dai servizi di sistema inserendola in un pool di nodi separato. 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.

La manutenzione regolare del cluster, ad esempio gli aggiornamenti in tempo reale, è fondamentale per l'affidabilità. È anche consigliabile monitorare l'integrità dei pod tramite probe.

Disponibilità dei pod

Assicurarsi che le risorse del pod siano . È consigliabile che le distribuzioni specificano i requisiti delle risorse del pod. L'utilità di pianificazione può quindi pianificare in modo appropriato il pod. L'affidabilità deprecerà 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 che possono verificarsi 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 gli eventi pianificati, ad esempio aggiornamenti e aggiornamenti, un budget di interruzione può garantire che esista il numero necessario di repliche di pod per gestire il carico previsto dell'applicazione.

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

Nota

L'impostazione delle quote delle risorse a livello di cluster può causare problemi durante la distribuzione di carichi di lavoro di terze parti che non hanno richieste e limiti adeguati.

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 memoria ai pod e di avere una densità di contenitore più elevata in un nodo. I limiti possono anche aumentare l'affidabilità con costi ridotti grazie a un migliore utilizzo dell'hardware.

Per stimare i limiti, testare e stabilire una baseline. Iniziare con valori uguali per richieste e limiti. Quindi, ottimizzare gradualmente tali valori fino a stabilire una soglia che può causare instabilità nel cluster.

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

Zone di disponibilità e supporto per più aree

Se il contratto di servizio richiede un tempo di attività più elevato, proteggersi dalla perdita in una zona. È possibile usare le zone di disponibilità se l'area le supporta. Sia i componenti del piano di controllo che i nodi nei pool di nodi possono quindi essere distribuiti tra le zone. Se un'intera zona non è disponibile, un nodo in un'altra zona all'interno dell'area è ancora disponibile. 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 Web Disatteso. Di seguito sono riportate alcune considerazioni sull'abilitazione della multizone:

  • Intera infrastruttura. Scegliere un'area che supporti le zone di disponibilità. Per altre informazioni, vedere Limitazioni e disponibilità dell'area. Se si vuole acquistare un contratto di servizio 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 dei nodi devono essere supportate in tutte le zone in modo che sia possibile la distribuzione prevista. Il set di scalabilità di macchine virtuali sottostante fornisce la stessa configurazione hardware tra le zone.

    Il supporto multizone non si applica solo ai pool di nodi, ma anche al piano di controllo. Il piano di controllo del servizio AKS si estenderà per le zone richieste, ad esempio i pool di nodi. Se non si usa il supporto della zona nel cluster, non è garantito che i componenti del piano di controllo si diffondono tra le zone di disponibilità.

  • Risorse dipendenti. Per il vantaggio zonale completo, 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 si sposterà con il nodo in tale zona.

Per semplicità, in questa architettura il servizio AKS 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 il gateway applicazione, vengono distribuite nella stessa area anche con supporto multizone. La replica geografica è abilitata per Registro Azure Container.

Più aree geografiche

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

  • Usare 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 dell'area. Un vantaggio dell'uso di aree abbinate è l'affidabilità durante gli aggiornamenti. Azure garantisce l'aggiornamento di una sola area alla volta nella coppia. 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à l'accesso continuo alle immagini anche in caso di interruzione di un'area.

  • Scegliere un router di 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, Frontdoor di Azure essere considerati. Per altre considerazioni, vedere Scegliere un servizio di bilanciamento del carico.

Ripristino di emergenza

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

  • Usare aree abbinate.

  • Un carico di lavoro non con stato può essere replicato in modo efficiente. Se è necessario archiviare lo stato nel cluster (scelta non consigliata), 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( SLO).

  • Quando si esegue 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 non è più in grado di eseguire il pull delle immagini dall'area replicata.

Contratto di servizio per il tempo di attività del server API Kubernetes

Il servizio AKS può essere usato come servizio gratuito, ma tale livello non offre un contratto di servizio con supporto finanziario. Per ottenere tale contratto di servizio, è necessario scegliere di aggiungere un contratto di servizio per il tempo di attività all'acquisto. È consigliabile usare questa opzione per tutti i cluster di produzione. Riservare cluster senza questa opzione per i cluster di pre-produzione. In combinazione con zone di disponibilità di Azure, il contratto di servizio del server API Kubernetes viene 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 in particolare aree. Alcune funzionalità di replica, ad esempio la replica geografica in Registro Azure Container, sono disponibili negli SKU Premium, che è più costoso. Il costo aumenterà anche a causa degli addebiti per la larghezza di banda applicati quando il traffico si sposta tra zone e aree.

Prevedere anche una latenza di rete aggiuntiva nella comunicazione tra nodi 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 forzati con interruzioni simulate, ad esempio l'interruzione di un nodo, l'interruzione di tutte le risorse del servizio AKS in una determinata zona per simulare un errore di zona o l'interruzione di una dipendenza esterna.

Monitorare e raccogliere metriche

La Monitoraggio di Azure per i contenitori è lo strumento consigliato per il monitoraggio e la registrazione 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. È possibile usarlo per monitorare le prestazioni con la scalabilità dei pod. Un altro vantaggio è che è possibile usare facilmente portale di Azure per configurare grafici e dashboard. È in grado di creare avvisi che attivano runbook di Automazione, Funzioni di Azure e altri.

La maggior parte dei carichi di lavoro ospitati nei pod genera metriche di Prometheus. Monitoraggio di Azure è in grado di raschiare le metriche di Prometheus e di visualizzarle.

Sono disponibili alcune utilità di terze parti integrate con Kubernetes. Sfruttare le piattaforme di log e metriche, ad esempio Grafana o Datadog, se già utilizzate dall'organizzazione.

Con il servizio Azure Kubernetes, Azure gestisce alcuni servizi Kubernetes di base. I log di tali servizi devono essere abilitati solo per ogni richiesta del supporto tecnico. Tuttavia, è consigliabile abilitare queste origini di log perché consentono di risolvere i problemi del cluster:

  • Registrazione di 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 l'osservabilità nell'utilità di pianificazione dei pod.
  • KubeAuditAdmin per avere l'osservabilità nelle attività che modificano il cluster.

Abilitare la correzione automatica

Monitorare l'integrità dei pod impostando Liveness and Readiness probes. Se viene rilevato un pod che non risponde, Kubernetes riavvia il pod. Il probe di liveness 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.

Nota

Il servizio AKS offre l'auto-correzione automatica incorporata dei nodi dell'infrastruttura tramite il ripristino automatico dei nodi.

Aggiornamenti della sicurezza

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 Eseguire regolarmente l'aggiornamento alla versione più recente di Kubernetes e Aggiornare un cluster servizio Azure Kubernetes (AKS).

Aggiornamenti settimanali

AKS offre 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 di aggiornamento delle immagini. È consigliabile avere un processo per aggiornare settimanalmente l'immagine di base dei pool di nodi. Per altre informazioni, vedere le note sulla versione servizio Azure Kubernetes aggiornamento dell'immagine del nodo del servizio Web del servizio AKS.

Aggiornamenti giornalieri

Tra un aggiornamento dell'immagine e l'altro, i nodi del servizio Web AKS scaricano e installano il sistema operativo e le patch di runtime singolarmente. Un'installazione potrebbe richiedere il riavvio delle macchine virtuali del nodo. AKS non riavvierà 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 dei nodi con la versione settimanale più recente ridurrà al minimo queste richieste di riavvio occasionali mantenendo al tempo stesso un'impostazione di sicurezza avanzata. Basandosi solo sugli aggiornamenti dell'immagine del nodo, si garantisce la compatibilità del servizio Web Disattesa e l'applicazione di patch di sicurezza settimanali. Mentre l'applicazione degli aggiornamenti giornalieri consente di risolvere più rapidamente i problemi di sicurezza, non sono stati necessariamente testati nel server del piano di gestione del sito Web. Laddove possibile, usare l'aggiornamento dell'immagine del nodo come strategia di applicazione delle patch di sicurezza settimanale principale.

Monitoraggio della protezione

Monitorare l'infrastruttura dei contenitori per le minacce attive e i potenziali rischi per la sicurezza:

Operazioni su cluster e carichi di lavoro (DevOps)

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

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 basarsi su di esso. Un'attività iniziale è la configurazione della rete. Effettuare il provisioning delle reti virtuali per l'hub e lo spoke e le subnet all'interno di tali reti. Ad esempio, lo spoke ha subnet separate per i pool di nodi utente e di sistema e le risorse in ingresso. Una subnet per Firewall di Azure nell'hub.

Un'altra parte potrebbe essere l'integrazione del carico di lavoro di base con Azure Active Directory.

Usare l'infrastruttura come codice (IaC)

Scegliere un metodo dichiarativo idempotente rispetto a 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 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 di macchina virtuale giuste, rimanere entro i vincoli di costo e le opzioni della zona di disponibilità in base ai 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 script. 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 applicazioni in modo continuo. È necessario distribuire gli aggiornamenti in modo sicuro e rapido ed eseguire il rollback in caso di problemi.

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

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

Cluster CI/CD

CI/CD del carico di lavoro

Invece di 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. Un agente viene distribuito nel cluster per assicurarsi che lo stato del cluster sia coordinato con la configurazione archiviata nel repository Git privato. Kubernetes e il servizio Kubernetes non supportano questa esperienza in modo nativo. Un'opzione consigliata è flux. Usa uno o più operatori nel cluster per attivare le distribuzioni all'interno di Kubernetes. Flux esegue queste attività:

  • Monitora tutti i repository configurati.
  • Rileva le nuove modifiche di configurazione.
  • Attiva le distribuzioni.
  • Aggiorna la configurazione di 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 dell'implementazione di riferimento che illustra come automatizzare la configurazione del cluster con GitOps e Flux.

GitOps Flow

  1. Uno sviluppatore esegue il commit delle modifiche al codice sorgente, ad esempio i file YAML di configurazione, archiviati in un repository Git. Viene quindi inserito il push delle modifiche in un server Git.

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

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

  4. Gli sviluppatori non hanno accesso diretto all'API Kubernetes tramite kubectl. Avere criteri di ramo nel server Git. In questo modo, più sviluppatori possono approvare una modifica prima che venga applicata all'ambiente di produzione.

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 Web di pre-produzione. In questo modo si simula che la modifica potrebbe annullare 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 a causa di problemi di distribuzione imprevisti. Questa distribuzione deve seguire un modello simile a quello di produzione, usando gli stessi operatori GitHub Actions pipeline o Flux.

Le tecniche di distribuzione avanzate, ad esempio la distribuzione blu-verde,i test A/B e le versioni canary,richiedono un processo aggiuntivo e potenzialmente strumenti. Flagger è una soluzione open source diffusa che consente di risolvere gli scenari di distribuzione avanzata.

Gestione dei costi

Usare il calcolatore dei prezzi di Azure per stimare i costi per i servizi usati nell'architettura. Altre procedure consigliate sono descritte nella sezione Ottimizzazione dei costi in Microsoft Azure Well-Architected Framework.

Provisioning

  • Non sono previsti costi associati per il servizio Kubernetes nella distribuzione, nella gestione e nelle operazioni del cluster Kubernetes. Il principale driver di costo sono le istanze di macchina virtuale, le risorse di archiviazione e di rete utilizzate dal cluster. Valutare la possibilità di scegliere macchine virtuali più convenienti per i pool di nodi di sistema. Lo SKU consigliato è DS2_v2.

  • Non avere la stessa configurazione per gli ambienti di sviluppo/test e produzione. I carichi di lavoro di produzione hanno requisiti aggiuntivi per la disponibilità elevata e saranno più costosi. Potrebbe non essere necessario nell'ambiente di sviluppo/test.

  • Per i carichi di lavoro di produzione, aggiungere un contratto di servizio relativo al tempo di attività. Esistono tuttavia risparmi per i cluster progettati per carichi di lavoro di sviluppo/test o sperimentali in cui non è necessario garantire la disponibilità. Ad esempio, l'SLO è sufficiente. Inoltre, se il carico di lavoro lo supporta, è consigliabile usare 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 Servizio app di Azure come parte dell'architettura del carico di lavoro del servizio AzureKs, valutare se si è idonei a usare sottoscrizioni di sviluppo/test di Azure per ricevere sconti per il servizio.

  • Invece di iniziare con un cluster di dimensioni troppo grande per soddisfare le esigenze di ridimensionamento, effettuare il provisioning di un cluster con un numero minimo di nodi e abilitare il ridimensionamento automatico del cluster per monitorare e prendere decisioni relative al ridimensionamento.

  • Impostare le richieste e i limiti dei pod per consentire a Kubernetes di allocare le risorse del nodo con densità più elevata in modo che l'hardware sia utilizzato 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 nella creazione di report personalizzati per tenere traccia dei costi sostenuti. I tag offrono la possibilità 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 è condiviso tra i team, creare report di chargeback per ogni 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 all'interno delle zone di disponibilità di un'area non sono gratuiti. Se il carico di lavoro è in più aree o sono presenti trasferimenti tra zone di fatturazione, prevedere costi aggiuntivi per la larghezza di banda. Per altre informazioni, vedere Traffico tra aree e aree di fatturazione.

  • Creare budget per rimanere entro i vincoli di costo identificati dall'organizzazione. Un modo è 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, insieme ai costi di calcolo, raccogliere anche informazioni sui costi relativi ad archiviazione, larghezza di banda, firewall e log. Azure offre vari dashboard per monitorare e analizzare i costi:

In una situazione ideale, monitorare i costi in tempo reale o almeno con 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 guidate sui dati, individuare la risorsa (livello granulare) che comporta la maggior parte dei costi. Avere anche una buona conoscenza dei contatori usati per calcolare l'utilizzo di ogni risorsa. Analizzando le metriche, ad esempio, è possibile determinare se la piattaforma è sovra dimensionata. È possibile visualizzare i contatori di utilizzo nelle Monitoraggio di Azure metriche.

Ottimizzazione

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

  • Abilitare il ridimensionamento automatico del cluster per rilevare e rimuovere i 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 alle dimensioni giuste 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 ancora presenti carichi di lavoro pianificati per l'esecuzione nel cluster, è consigliabile usare la funzionalità di avvio/arresto del servizio AKS per arrestare tutte le risorse di calcolo, tra cui il pool di nodi di sistema e il piano di controllo del servizio Web AKS.

Per altre informazioni sui costi, vedere Prezzi del servizio Web Diaks.

Passaggi successivi

Se è necessario un aggiornamento in Kubernetes, completare i percorsi di apprendimento Introduzione a Kubernetes e Sviluppare e distribuire applicazioni nei percorsi di apprendimento di Kubernetes Microsoft Learn.