Contribuisci a migliorare questa pagina

Per contribuire a questa guida per l’utente, seleziona il link Edit this page on GitHub che si trova nel riquadro destro di ogni pagina.

Ulteriori informazioni relative allo spostamento zonale in controller di ripristino delle applicazioni Amazon (ARC)

Kubernetes dispone di funzionalità native che consentono di rendere le applicazioni più resistenti a eventi come il deterioramento dello stato di integrità o il deterioramento di una zona di disponibilità (AZ). Quando esegui i carichi di lavoro in un cluster Amazon EKS, è possibile migliorare ulteriormente la tolleranza ai guasti e il ripristino delle applicazioni dell’ambiente applicativo utilizzando lo spostamento zonale o lo spostamento zonale automatico del controller di ripristino delle applicazioni Amazon (ARC). Lo spostamento zonale ARC è progettato per essere una misura temporanea che consente di spostare il traffico di una risorsa lontano da una AZ interessata fino alla scadenza dello spostamento zonale o all’annullamento dello stesso. È possibile estendere lo spostamento zonale, se necessario.

È possibile avviare uno spostamento zonale per un cluster EKS oppure consentire a AWS di spostare il traffico per te abilitando lo spostamento zonale automatico. Questo spostamento aggiorna il flusso di traffico di rete da est a ovest nel cluster per considerare solo gli endpoint di rete per i pod in esecuzione su nodi worker in AZ integre. Inoltre, qualsiasi ALB o NLB che gestisce il traffico in ingresso per le applicazioni nel cluster EKS indirizzerà automaticamente il traffico verso le destinazioni nelle AZ integre. Per i clienti che cercano gli obiettivi di disponibilità più elevati, nel caso in cui una zona AZ sia compromessa, può essere importante consentire di indirizzare tutto il traffico lontano dalla AZ compromessa fino a quando non si ripristina. Per questo, puoi anche abilitare ALB o NLB con spostamento zonale ARC.

Comprensione del flusso di traffico di rete est-ovest tra i pod

Il diagramma seguente illustra due esempi di carichi di lavoro, Ordini e Prodotti. Lo scopo di questo esempio è mostrare come comunicano carichi di lavoro e Pod in diverse AZ.

Comprensione dello spostamento zonale ARC in Amazon EKS

Se il tuo ambiente presenta un deterioramento di AZ, è possibile avviare uno spostamento zonale per l’ambiente del cluster EKS. In alternativa, è possibile consentire a AWS di gestire lo spostamento del traffico con lo spostamento zonale automatico. Con lo spostamento zonale automatico, AWS monitora l’integrità generale di AZ e risponde a un potenziale deterioramento di AZ spostando automaticamente il traffico dall’area AZ compromessa nell’ambiente del cluster.

Dopo che il cluster Amazon EKS ha abilitato lo spostamento zonale con ARC, è possibile avviare uno spostamento zonale o abilitare lo spostamento zonale automatico utilizzando console ARC, AWS CLI o API di spostamento zonale o di spostamento zonale automatico. Durante uno spostamento zonale EKS, è eseguito automaticamente quanto segue:

I seguenti diagrammi forniscono una panoramica di alto livello su come uno spostamento zonale EKS garantisce che solo gli endpoint dei pod integri siano presi di mira nell’ambiente del cluster.

Requisiti per lo spostamento zonale EKS

Affinché lo spostamento zonale funzioni correttamente con EKS, è necessario configurare in anticipo l’ambiente del cluster in modo che sia resiliente a una compromissione di AZ. Di seguito è riportato un elenco di opzioni di configurazione che aiutano a garantire la resilienza.

Esegui il provisioning dei nodi workerEKS in più zone di disponibilità

Le regioni AWS hanno più sedi separate con data center fisici, note come zone di disponibilità (AZ). Le AZ sono progettate per essere isolate fisicamente l’una dall’altra per evitare impatti simultanei che potrebbero interessare un’intera regione. Quando si effettua il provisioning di un cluster EKS, si consiglia di distribuire i nodi di lavoro su più AZ in una regione. Ciò contribuisce a rendere l’ambiente cluster più resiliente alla compromissione di una singola AZ e consente di mantenere un’elevata disponibilità per le applicazioni eseguite nelle altre AZ. Quando inizi uno spostamento zonale rispetto alla AZ interessata, la rete interna al cluster dell’ambiente EKS si aggiorna automaticamente per utilizzare solo AZ integre, per contribuire a mantenere un’elevata disponibilità per il cluster.

La garanzia di disporre di una configurazione multi-AZ per l’ambiente EKS migliora l’affidabilità complessiva del sistema. Tuttavia, gli ambienti multi-AZ influenzano il modo in cui i dati delle applicazioni sono trasferiti ed elaborati, il che a sua volta ha un impatto sui costi di rete dell’ambiente. In particolare, il traffico in uscita frequente tra le zone (traffico distribuito tra le AZ) può avere un impatto importante sui costi relativi alla rete. È possibile applicare diverse strategie per controllare la quantità di traffico tra le zone tra i pod nel cluster EKS e ridurre i costi associati. Per ulteriori informazioni su come ottimizzare i costi di rete durante l’esecuzione di ambienti EKS ad alta disponibilità, consulta queste best practice.

Il diagramma seguente illustra un ambiente EKS ad alta disponibilità con tre AZ integre.

Il diagramma seguente illustra come un ambiente EKS con tre AZ sia resiliente a una compromissione di AZ e rimanga altamente disponibile perché rimangono due AZ integre.

Consulta a una capacità di elaborazione sufficiente per resistere alla rimozione di una singola zona di disponibilità

Per ottimizzare l’utilizzo delle risorse e i costi per l’infrastruttura di elaborazione nel piano dati EKS, è consigliabile allineare la capacità di elaborazione ai requisiti del carico di lavoro. Tuttavia, se tutti i nodi worker sono a piena capacità, è necessario aggiungere nuovi nodi worker al piano dati EKS prima di poter pianificare nuovi pod. Quando si eseguono carichi di lavoro critici, in genere è buona norma impiegare una capacità ridondante online per gestire scenari quali aumenti improvvisi del carico e problemi di integrità dei nodi. Se prevedi di utilizzare lo spostamento zonale, intendi rimuovere un’intera AZ di capacità in caso di compromissione. Ciò significa che è necessario regolare la capacità di elaborazione ridondante in modo che sia sufficiente a gestire il carico anche con una delle AZ offline.

Quando si ridimensionano le risorse di elaborazione, il processo di aggiunta di nuovi nodi al piano dati EKS richiede del tempo. Ciò può avere implicazioni sulle prestazioni e sulla disponibilità in tempo reale delle applicazioni, soprattutto in caso di una compromissione zonale. Il tuo ambiente EKS dovrebbe essere in grado di assorbire il peso della perdita di una AZ senza compromettere l’esperienza degli utenti finali o dei clienti. Ciò significa ridurre al minimo o eliminare il ritardo tra il momento in cui è necessario un nuovo pod e quello in cui è effettivamente pianificato su un nodo worker.

Inoltre, in caso di compromissione zonale, dovresti cercare di mitigare il rischio di incorrere in un limite di capacità di elaborazione che impedirebbe l’aggiunta di nuovi nodi necessari al piano dati EKS nelle AZ integre.

Per ridurre il rischio di questi potenziali impatti negativi, consigliamo di fornire una capacità di elaborazione eccessiva in alcuni nodi di lavoro di ciascuna AZ. In questo modo, il sistema di pianificazione Kubernetes dispone di una capacità pre-esistente disponibile per il posizionamento di nuovi pod, il che è particolarmente importante quando si perde una delle AZ nel proprio ambiente.

Esegui e distribuisci più repliche di pod tra le zone di disponibilità

Kubernetes ti consente di pre-scalare i carichi di lavoro eseguendo più istanze (repliche di pod) di una singola applicazione. L’esecuzione di più repliche di pod per un’applicazione elimina i singoli punti di guasto e aumenta le prestazioni complessive riducendo il carico di sovraccarico su una singola replica. Tuttavia, per garantire un’elevata disponibilità e una migliore tolleranza ai guasti per le applicazioni, si consiglia di eseguire più repliche dell’applicazione e di distribuirle su diversi domini di guasto, noti anche come domini di topologia. I domini di guasto in questo scenario sono le zone di disponibilità. Utilizzando i vincoli di diffusione della topologia, è possibile configurare le applicazioni in modo che abbiano una stabilità statica pre-esistente. Quindi, in caso di una compromissione di AZ, l’ambiente disporrà di un numero sufficiente di repliche in AZ funzionanti per gestire immediatamente eventuali picchi o aumenti improvvisi di traffico.

Il diagramma seguente illustra un ambiente EKS con un flusso di traffico da est a ovest quando tutte le AZ sono integre.

Il diagramma seguente illustra un ambiente EKS con un flusso di traffico da est a ovest in cui una singola AZ ha subito un guasto ed è stato avviato uno spostamento zonale.

Il seguente frammento di codice è un esempio di come configurare il carico di lavoro con più repliche in Kubernetes.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: orders
spec:
  replicas: 9
  selector:
    matchLabels:
      app:orders
  template:
    metadata:
      labels:
        app: orders
        tier: backend
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: "topology.kubernetes.io/zone"
        whenUnsatisfiable: ScheduleAnyway
        labelSelector:
          matchLabels:
            app: orders

Soprattutto, è necessario eseguire più repliche del software del server DNS (CoreDNS/Kube-DNS) e applicare vincoli di diffusione della topologia simili, se non sono configurati per impostazione predefinita. Ciò aiuta a garantire che, in caso di una singola compromissione di AZ, si disponga di un numero sufficiente di pod DNS in AZ integre per continuare a gestire le richieste di rilevamento servizi per altri pod comunicanti nel cluster. Il componente aggiuntivo EKS CoreDNS dispone di impostazioni predefinite per i pod CoreDNS che assicurano che, se sono disponibili nodi in più AZ, siano distribuiti nelle zone di disponibilità del cluster. Se si desidera, è possibile sostituire queste impostazioni predefinite con le proprie configurazioni personalizzate.

Quando installi CoreDNS con Helm, è possibile aggiornare replicaCount nel file values.yaml per assicurarti di avere un numero sufficiente di repliche in ciascuna AZ. Inoltre, per garantire che queste repliche siano distribuite tra le diverse AZ nell’ambiente cluster, assicurati di aggiornare la proprietà topologySpreadConstraints nello stesso file values.yaml. Il seguente frammento di codice illustra come configurare CoreDNS per eseguire tale operazione.

values.yaml CoredNS Helm

replicaCount: 6
topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: ScheduleAnyway
    labelSelector:
      matchLabels:
        k8s-app: kube-dns

In caso di compromissione di AZ, è possibile assorbire l’aumento del carico sui pod CoreDNS, utilizzando un sistema di scalabilità automatica per CoreDNS. Il numero di istanze DNS necessarie dipende dal numero di carichi di lavoro in esecuzione nel cluster. CoreDNS è legato alla CPU, il che gli consente di scalare in base alla CPU utilizzando l’Horizontal Pod Autoscaler (HPA). Di seguito è riportato un esempio che è possibile modificare in base alle esigenze.

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: coredns
  namespace: default
spec:
  maxReplicas: 20
  minReplicas: 2
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: coredns
  targetCPUUtilizationPercentage: 50

In alternativa, EKS può gestire la scalabilità automatica dell’implementazione CoreDNS nella versione del componente aggiuntivo EKS di CoreDNS. Questo autoscaler di CoreDNS monitora continuamente lo stato del cluster, incluso il numero di nodi e core CPU. Sulla base di tali informazioni, il controller regola dinamicamente il numero di repliche dell’implementazione CoreDNS in un cluster EKS.

Per abilitare la configurazione di scalabilità automatica nel componente aggiuntivo CoredNS EKS, utilizzare la seguente impostazione di configurazione:

{
  "autoScaling": {
    "enabled": true
  }
}

È anche possibile utilizzare NodeLocal DNS o l’autoscaler proporzionale del cluster per scalare CoreDNS. Per ulteriori informazioni, consulta Scalare CoredNS orizzontalmente.

Co-locare i pod interdipendenti nella stessa zona di disponibilità

In genere, le applicazioni hanno carichi di lavoro distinti che devono comunicare tra loro per completare con successo un processo end-to-end. Se queste applicazioni distinte sono distribuite su diverse AZ e non sono co-locate nella stessa AZ, una singola violazione della AZ può influire sul processo end-to-end. Ad esempio, se l’applicazione A ha più repliche in AZ 1 e AZ 2, ma l’applicazione B ha tutte le repliche in AZ 3, la perdita di AZ 3 influirà sui processi end-to-end tra i due carichi di lavoro, l’applicazione A e l’applicazione B. Se combini i vincoli di diffusione della topologia con l’affinità dei pod, puoi migliorare la resilienza dell’applicazione distribuendo i pod su tutte le AZ. Inoltre, ciò configura una relazione tra determinati pod per garantire che siano co-locati.

Con le regole di affinità dei pod, è possibile definire le relazioni tra i carichi di lavoro per influenzare il comportamento del sistema di pianificazione Kubernetes in modo che collochi i pod sullo stesso nodo worker o nella stessa AZ. Inoltre, è possibile configurare la rigidità dei vincoli di pianificazione.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: products
  namespace: ecommerce
  labels:
    app.kubernetes.io/version: "0.1.6"

    spec:
      serviceAccountName: graphql-service-account
      affinity:
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - orders
            topologyKey: "kubernetes.io/hostname"

Il diagramma seguente mostra diversi pod che sono stati co-locati sullo stesso nodo utilizzando le regole di affinità dei pod.

Verifica che il tuo ambiente cluster sia in grado di gestire la perdita di una AZ

Dopo aver completato i requisiti descritti nelle sezioni precedenti, il passaggio successivo consiste nel verificare di disporre di una capacità di elaborazione e carico di lavoro sufficiente per gestire la perdita di una AZ. Per eseguire tale operazione è possibile avviare manualmente uno spostamento zonale in EKS. In alternativa, è possibile abilitare lo spostamento zonale automatico e configurare le sessioni pratiche, che consentono anche di verificare che le applicazioni funzionino come previsto con una AZ in meno nell’ambiente cluster.

Domande frequenti

Qual è il vantaggio di utilizzare questa funzionalità?

Utilizzando lo spostamento zonale ARC o lo spostamento zonale automatico nel cluster EKS, è possibile mantenere meglio la disponibilità delle applicazioni Kubernetes automatizzando il processo di ripristino rapido che consiste nello spostamento del traffico di rete interno al cluster da una zona AZ compromessa. Con ARC, è possibile evitare passaggi lunghi e complicati, che possono portare a un periodo di recupero prolungato in caso di eventi AZ compromessi.

In che modo questa funzionalità funziona con altri servizi AWS?

EKS si integra con ARC, che fornisce l’interfaccia principale in cui portare a termine le operazioni di ripristino in AWS. Per garantire che il traffico all’interno del cluster sia indirizzato in modo appropriato lontano da una zona di disponibilità compromessa, EKS apporta modifiche all’elenco degli endpoint di rete per i pod in esecuzione sul piano dati Kubernetes. Se utilizzi Elastic Load Balancing per instradare il traffico esterno verso il cluster, è possibile registrare i bilanciatori del carico con ARC e avviare uno spostamento zonale su di essi per impedire che il traffico fluisca verso la zona AZ deteriorata. Lo spostamento zonale funziona anche con i gruppi di Amazon EC2 Auto Scaling creati da gruppi di nodi gestiti da EKS. Per evitare che una AZ compromessa sia utilizzata per nuovi pod Kubernetes o avvii di nodi, EKS rimuove la AZ compromessa dai gruppi Auto Scaling.

In che modo questa funzionalità è diversa dalle protezioni Kubernetes predefinite?

Tale funzionalità funziona in combinazione con diverse protezioni integrate di Kubernetes che aiutano la resilienza delle applicazioni dei clienti. È possibile configurare le sonde readiness e liveness di pod che decidono quando un Pod deve ricevere traffico. Quando queste sonde si guastano, Kubernetes rimuove questi pod come obiettivi di un servizio e il traffico non è più inviato al pod. Sebbene ciò sia utile, non è semplice per i clienti configurare tali controlli dell’integrità in modo da garantire che abbiano esito negativo in caso di deterioramento di una AZ. La funzione di spostamento zonale ARC fornisce una rete di sicurezza aggiuntiva che ti aiuta a isolare completamente una AZ deteriorata quando le protezioni native di Kubernetes non erano sufficienti. Lo spostamento zonale offre anche un modo semplice per testare la prontezza operativa e la resilienza dell’architettura.

È possibile che AWS avvii uno spostamento zonale per mio conto?

Sì, se desideri un modo completamente automatizzato di utilizzare lo spostamento zonale ARC, puoi abilitare lo spostamento zonale automatico ARC. Con lo spostamento zonale automatico, puoi contare su AWS per il monitoraggio dell’integrità di AZ per il tuo cluster EKS e per avviare automaticamente uno spostamento zonale quando è rilevata una compromissione della AZ.

Cosa succede se utilizzo questa funzionalità e i miei nodi worker e i miei carichi di lavoro non sono predimensionati?

Se non si esegue una pre-scalabilità e si affida al provisioning di nodi o pod aggiuntivi durante uno spostamento zonale, si rischia un ripristino ritardato. Il processo di aggiunta di nuovi nodi al piano dati di Kubernetes richiede del tempo, il che può influire sulle prestazioni e sulla disponibilità in tempo reale delle applicazioni, soprattutto in caso di compromissione zonale. Inoltre, in caso di compromissione zonale, potresti riscontrare un potenziale limite di capacità di elaborazione che potrebbe impedire l’aggiunta dei nuovi nodi necessari alle AZ integre.

Se i carichi di lavoro non sono pre-scalati e distribuiti su tutte le AZ del cluster, una compromissione zonale potrebbe influire sulla disponibilità di un’applicazione che è eseguita solo sui nodi worker nelle AZ interessate. Per mitigare il rischio di un’interruzione completa della disponibilità dell’applicazione, EKS dispone di un sistema a prova di guasto per l’invio del traffico agli endpoint di pod in una zona compromessa se il carico di lavoro ha tutti i suoi endpoint in una AZ non integra. Tuttavia, consigliamo vivamente di pre-scalare e distribuire le applicazioni su tutte le AZ per mantenere la disponibilità in caso di problemi zonali.

Come funziona se sto eseguendo un’applicazione stateful?

Se stai eseguendo un’applicazione stateful, devi valutarne la tolleranza ai guasti, in base al tuo caso d’uso e all’architettura. Se disponi di un’architettura o di un modello attivo/standby, potrebbero esservi istanza in cui l’attivo si trova in una AZ compromessa. A livello di applicazione, se lo standby non è attivato, è possibile che si verifichino problemi con l’applicazione. Inoltre, potresti riscontrare problemi quando sono avviati nuovi pod Kubernetes in AZ integre, poiché non saranno in grado di collegarsi ai volumi persistenti limitati alla AZ compromessa.

Questa funzionalità funziona con Karpenter?

Il supporto di Karpenter non è attualmente disponibile con uno spostamento zonale ARC e uno spostamento zonale automatico in EKS. Se una AZ è compromessa, è possibile modificare la configurazione NodePool Karpenter pertinente rimuovendo la AZ non integra in modo che i nuovi nodi worker siano avviati solo nelle altre AZ.

Questa funzionalità funziona con EKS Fargate?

Questa funzionalità non funziona con EKS Fargate. Per impostazione predefinita, quando EKS Fargate riconosce un evento di integrità zonale, i pod preferiranno essere eseguiti nelle altre AZ.

Il piano di controllo Kubernetes gestito da EKS ne risentirà?

No, per impostazione predefinita Amazon EKS esegue ed effettua il dimensionamento di istanze del piano di controllo Kubernetes in molteplici AZ per garantire un’elevata disponibilità. Lo spostamento zonale ARC e lo spostamento zonale automatico agiscono solo sul piano dati Kubernetes.

Ci sono dei costi associati a questa nuova funzionalità?

È possibile utilizzare uno spostamento zonale ARC e uno spostamento zonale automatico nel cluster EKS senza costi aggiuntivi. Tuttavia, continuerai a pagare per le istanze assegnate e consigliamo vivamente di pre-scalare il tuo piano dati Kubernetes prima di utilizzare questa funzionalità. È necessario considerare un equilibrio tra costi e disponibilità delle applicazioni.

Risorse aggiuntive