Piano dati EKS

Per utilizzare applicazioni ad alta disponibilità e resilienza, è necessario un piano dati ad alta disponibilità e resilienza. Un piano dati elastico garantisce che Kubernetes possa scalare e correggere automaticamente le tue applicazioni. Un piano dati resiliente è costituito da due o più nodi di lavoro, può crescere e ridursi con il carico di lavoro e ripristinarsi automaticamente in caso di guasti.

Hai diverse scelte per i nodi di lavoro con EKS: nodi gestiti in modalità automatica EKS, EC2 Istanze e Fargate.

EKS Auto Mode offre il percorso più semplice verso un piano dati resiliente. Auto Mode estende la gestione AWS dei cluster Kubernetes oltre il cluster stesso, per consentire ad AWS di configurare e gestire anche l'infrastruttura che consente il funzionamento regolare dei carichi di lavoro. La modalità automatica ridimensiona automaticamente il piano dati verso l'alto o verso il basso man mano che Kubernetes ridimensiona i pod e lavora per garantire continuamente che i nodi del cluster siano dimensionati in modo appropriato ed economico per i carichi di lavoro attualmente in esecuzione.

Se scegli le EC2 istanze, puoi gestire tu stesso i nodi di lavoro o utilizzare i gruppi di nodi gestiti da EKS. Puoi avere un cluster con una combinazione di modalità automatica, nodi di lavoro gestiti e autogestiti e Fargate.

Fargate esegue ogni Pod in un ambiente di elaborazione isolato. Ogni Pod in esecuzione su Fargate ha il proprio nodo di lavoro. Fargate ridimensiona automaticamente il piano dati come Kubernetes ridimensiona i pod. È possibile scalare sia il piano dati che il carico di lavoro utilizzando l'autoscaler a pod orizzontale.

Il modo preferito per scalare i EC2 nodi di lavoro (se non si utilizza la modalità Auto EKS, che viene eseguita automaticamente da AWS) è utilizzare i gruppi Karpenter, Kubernetes Cluster Autoscaler o Auto Scaling. EC2

Raccomandazioni

Distribuisci i nodi di lavoro e i carichi di lavoro tra più AZs

Puoi proteggere i tuoi carichi di lavoro dai guasti in una singola AZ eseguendo nodi di lavoro e Pods in più aree. AZs È possibile controllare l'AZ in cui vengono creati i nodi di lavoro utilizzando le sottoreti in cui vengono creati i nodi.

Il metodo consigliato per distribuire i pod AZs consiste nell'utilizzare Topology Spread Constraints for Pods. Le funzionalità di scalabilità automatica come EKS Auto Mode e Karpenter sono consapevoli dei vincoli di diffusione della topologia e avvieranno automaticamente i nodi nella posizione corretta per consentire il rispetto dei vincoli. AZs

La distribuzione riportata di seguito distribuisce i pod, se possibile, lasciando che funzionino comunque in caso contrario AZs :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-server
  template:
    metadata:
      labels:
        app: web-server
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          whenUnsatisfiable: ScheduleAnyway
          topologyKey: topology.kubernetes.io/zone
          labelSelector:
            matchLabels:
              app: web-server
      containers:
      - name: web-app
        image: nginx
        resources:
          requests:
            cpu: 1

Nota

kube-schedulerconosce solo i domini di topologia tramite nodi che esistono con tali etichette. Se la distribuzione di cui sopra viene distribuita in un cluster con nodi in una sola zona, tutti i pod verranno programmati su quei nodi poiché kube-scheduler non sono a conoscenza delle altre zone. Affinché questa distribuzione della topologia funzioni come previsto con lo scheduler, i nodi devono già esistere in tutte le zone. La minDomains proprietà dei vincoli di diffusione della topologia viene utilizzata per comunicare allo scheduler il numero di domini idonei, anche se è in esecuzione un nodo per evitare questo problema.

avvertimento

L'impostazione whenUnsatisfiable su DoNotSchedule farà sì che i pod non siano programmabili se il vincolo di diffusione della topologia non può essere soddisfatto. Dovrebbe essere impostato solo se è preferibile che i pod non vengano eseguiti invece di violare il vincolo di diffusione della topologia.

Nelle versioni precedenti di Kubernetes, puoi utilizzare le regole di antiaffinità dei pod per pianificare i pod su più pod. AZs Il manifesto riportato di seguito indica allo scheduler di Kubernetes di preferire la pianificazione dei pod in modo distinto. AZs

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server
  labels:
    app: web-server
spec:
  replicas: 4
  selector:
    matchLabels:
      app: web-server
  template:
    metadata:
      labels:
        app: web-server
    spec:
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: app
                  operator: In
                  values:
                  - web-server
              topologyKey: failure-domain.beta.kubernetes.io/zone
            weight: 100
      containers:
      - name: web-app
        image: nginx

avvertimento

Non è necessario che i pod siano pianificati in AZs modo distinto, altrimenti il numero di pod in una distribuzione non supererà mai il numero di. AZs

Garantisci la possibilità di avviare i nodi in ogni AZ quando usi i volumi EBS

Se utilizzi Amazon EBS per fornire volumi persistenti, devi assicurarti che i pod e il volume EBS associato si trovino nella stessa zona di disponibilità. Un pod non può accedere ai volumi persistenti supportati da EBS che si trovano in una AZ diversa. Lo scheduler Kubernetes sa in quale AZ si trova un nodo di lavoro dalle etichette che si trovano sul nodo e pianificherà sempre un Pod che richiede un volume EBS nella stessa AZ del volume. Tuttavia, se non ci sono nodi di lavoro disponibili nell'AZ in cui si trova il volume, il Pod non può essere pianificato.

Se utilizzi EKS Auto Mode o Karpenter, dovrai assicurarti di NodeClass selezionare le sottoreti in ogni AZ. Se si utilizzano gruppi di nodi gestiti, è necessario assicurarsi di disporre di un gruppo di nodi in ogni AZ.

Una funzionalità di storage EBS è integrata in EKS Auto Mode, ma se si utilizza Karpenter o Managed Node Groups, sarà necessario installare anche EBS CSI.

Usa EKS Auto Mode per gestire i nodi di lavoro

EKS Auto Mode semplifica la gestione EKS fornendo cluster pronti per la produzione con un sovraccarico operativo minimo. La modalità automatica è responsabile dell'aumento o della riduzione del numero di nodi a seconda dei pod in esecuzione nel cluster. I nodi vengono aggiornati automaticamente con patch e correzioni software, e gli aggiornamenti vengono eseguiti in base alle impostazioni di NodePoolinterruzione configurate e ai Pod Disruption Budgets.

Esegui il Node Monitoring Agent

Il Node Monitoring Agent monitora e reagisce ai problemi di integrità dei nodi pubblicando gli eventi Kubernetes e aggiornando le condizioni di stato sui nodi. Il Node Monitoring Agent è incluso nei nodi EKS Auto Mode e può essere installato come componente aggiuntivo EKS per i nodi che non sono gestiti da Auto Mode.

EKS Auto Mode, Managed Node Groups e Karpenter hanno tutti la capacità di rilevare le condizioni fatali dei nodi segnalate dall'agente di monitoraggio dei nodi e di ripararli automaticamente quando si verificano tali condizioni.

Implementa QoS

Per le applicazioni critiche, prendi in considerazione la definizione di requests = limits per il contenitore nel Pod. Ciò garantirà che il contenitore non venga ucciso se un altro Pod richiede risorse.

È consigliabile implementare limiti di CPU e memoria per tutti i contenitori in quanto impedisce che un contenitore consumi inavvertitamente risorse di sistema influendo sulla disponibilità di altri processi co-localizzati.

Configura e dimensiona le risorse per tutti i carichi di lavoro Requests/Limits

Alcune indicazioni generali possono essere applicate al dimensionamento delle richieste di risorse e ai limiti per i carichi di lavoro:

• Non specificare limiti di risorse sulla CPU. In assenza di limiti, la richiesta influisce sulla quantità di tempo relativo alla CPU ottenuta dai container. Ciò consente ai carichi di lavoro di utilizzare l'intera CPU senza limiti artificiali o carenze.

• Per le risorse diverse dalla CPU, configuring requests = limits fornisce il comportamento più prevedibile. Se! requests =limits, inoltre, il QOS del container è stato ridotto da Guaranteed a Burstable, il che rende più probabile lo sfratto in caso di pressione dei nodi.

• Per le risorse diverse dalla CPU, non specificare un limite molto più grande della richiesta. Quanto più grandi limits sono le dimensioni configurate rispetto arequests, tanto più è probabile che i nodi vengano sovraccaricati, con conseguenti alte probabilità di interruzione del carico di lavoro.

• Le richieste di dimensioni corrette sono particolarmente importanti quando si utilizza una soluzione di auto-scaling dei nodi come Karpenter o Cluster. AutoScaler Questi strumenti esaminano le richieste di carico di lavoro per determinare il numero e la dimensione dei nodi da fornire. Se le tue richieste sono troppo piccole e con limiti più elevati, potresti scoprire che i carichi di lavoro vengono eliminati o l'OOM bloccato se sono stati raggruppati in un nodo ristretto.

Determinare le richieste di risorse può essere difficile, ma strumenti come Vertical Pod Autoscaler possono aiutarvi a «dimensionare correttamente» le richieste osservando l'utilizzo delle risorse del contenitore in fase di esecuzione. Altri strumenti che possono essere utili per determinare le dimensioni delle richieste includono:

• Riccioli d'oro

• Parca

• Profiler

• rg

Configura le quote di risorse per i namespace

I namespace sono concepiti per l'uso negli ambienti con molti utenti distribuiti su più team o progetti. Forniscono un ambito per i nomi e sono un modo per dividere le risorse del cluster tra più team, progetti e carichi di lavoro. È possibile limitare il consumo aggregato di risorse in un namespace. L'ResourceQuotaoggetto può limitare la quantità di oggetti che possono essere creati in un namespace per tipo, nonché la quantità totale di risorse di elaborazione che possono essere consumate dalle risorse di quel progetto. È possibile limitare la somma totale di risorse di archiviazione and/or (CPU e memoria) che possono essere richieste in un determinato spazio dei nomi.

Se la quota di risorse è abilitata per uno spazio dei nomi per risorse di calcolo come CPU e memoria, gli utenti devono specificare le richieste o i limiti per ogni contenitore in tale spazio dei nomi.

Prendi in considerazione la possibilità di configurare le quote per ogni namespace. Prendi in considerazione l'utilizzo LimitRanges per applicare automaticamente limiti preconfigurati ai contenitori all'interno di un namespace.

Limita l'utilizzo delle risorse del contenitore all'interno di un namespace

Le quote di risorse aiutano a limitare la quantità di risorse che un namespace può utilizzare. L'LimitRangeoggetto può aiutarti a implementare le risorse minime e massime richieste da un contenitore. Utilizzando LimitRange you puoi impostare una richiesta e dei limiti predefiniti per i contenitori, il che è utile se l'impostazione dei limiti delle risorse di elaborazione non è una pratica standard nell'organizzazione. Come suggerisce il nome, LimitRange può imporre l'utilizzo minimo e massimo delle risorse di calcolo per Pod o Container in un namespace. Inoltre, applica la richiesta di archiviazione minima e massima per in un namespace. PersistentVolumeClaim

Valuta la possibilità di ResourceQuota utilizzarlo insieme LimitRange a per imporre limiti a livello di contenitore e namespace. L'impostazione di questi limiti garantirà che un contenitore o un namespace non influiscano sulle risorse utilizzate dagli altri tenant del cluster.

Usa NodeLocal DNSCache

È possibile migliorare le prestazioni del Cluster DNS NodeLocalDNSCacheeseguendo. Questa funzionalità esegue un agente di caching DNS sui nodi del cluster come. DaemonSet Tutti i pod utilizzano l'agente di caching DNS in esecuzione sul nodo per la risoluzione dei nomi anziché utilizzare Service. kube-dns Questa funzionalità è inclusa automaticamente in EKS Auto Mode.

Configurare CoredNS con scalabilità automatica

Un altro metodo per migliorare le prestazioni del Cluster DNS consiste nell'abilitare l'auto-scaling integrato dei CoredNS Pods.

Questa funzionalità monitora continuamente lo stato del cluster, incluso il numero di nodi e core della CPU. Sulla base di tali informazioni, il controller adatterà dinamicamente il numero di repliche dell'implementazione CoredNS in un cluster EKS.