Piano dati EKS

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

Sono disponibili diverse scelte per i nodi di lavoro con EKS: nodi gestiti EKS Auto Mode, istanze EC2 e Fargate. https://docs.aws.amazon.com/eks/latest/userguide/fargate.html

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 corretto funzionamento 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 istanze EC2, puoi gestire tu stesso i nodi di lavoro o utilizzare i gruppi di nodi gestiti da EKS. https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html Puoi avere un cluster con una combinazione di nodi di lavoro in modalità automatica, 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 man mano che Kubernetes ridimensiona i pod. Puoi scalare sia il piano dati che il carico di lavoro utilizzando il pod https://docs.aws.amazon.com/eks/latest/userguide/horizontal-pod-autoscaler.html autoscaler orizzontale.

Il modo preferito per scalare i nodi di lavoro EC2 (se non si utilizza EKS Auto Mode, dove questa operazione viene eseguita automaticamente da AWS) è utilizzare i gruppi Karpenter, Kubernetes Cluster Autoscaler o EC2 Auto Scaling. https://docs.aws.amazon.com/autoscaling/ec2/userguide/AutoScalingGroup.html

Raccomandazioni

Distribuisci i nodi di lavoro e i carichi di lavoro su più AZ

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

Il metodo consigliato per distribuire i pod tra gli AZ consiste nell'utilizzare Topology Spread Constraints for Pods. Auto-scaling funzionalità come EKS Auto Mode e Karpenter sono consapevoli dei vincoli di diffusione della topologia e avvieranno automaticamente i nodi negli AZ corretti per consentire il rispetto dei vincoli.

La distribuzione seguente distribuisce i pod tra gli AZ, se possibile, lasciandoli comunque funzionare in caso contrario:


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-schedulerè a conoscenza dei domini di topologia solo tramite nodi che esistono con tali etichette. Se la distribuzione di cui sopra viene distribuita in un cluster con nodi solo in una singola zona, tutti i pod verranno pianificati su quei nodi poiché kube-scheduler non sono a conoscenza delle altre zone. Affinché questa topologia diffusa 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 informare lo scheduler del numero di domini idonei, anche se è presente un nodo in esecuzione 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. Deve 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 anti-affinità dei pod per pianificare i pod su più AZ. Il seguente manifesto indica allo scheduler di Kubernetes di preferire la pianificazione dei pod in AZ distinti.


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 programmati su AZ distinti, altrimenti il numero di pod in una distribuzione non supererà mai il numero di AZ.

Garantite la capacità di lanciare nodi in ogni AZ quando utilizzate 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 AZ. Un pod non può accedere a volumi EBS-backed permanenti che si trovano in una AZ diversa. Lo scheduler Kubernetes sa in quale AZ si trova un nodo di lavoro grazie alle etichette presenti 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 utilizzi Managed Node Groups, devi assicurarti di avere un Node Group 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 del ridimensionamento del numero di nodi verso l'alto o verso il basso a seconda dei pod in esecuzione nel cluster. I nodi vengono aggiornati automaticamente con le patch e le correzioni del software, con gli aggiornamenti eseguiti in base alle impostazioni di NodePool interruzione configurate e ai budget di interruzione dei Pod.

Esegui il Node Monitoring Agent

Il Node Monitoring Agent monitora e reagisce ai problemi di salute del nodo pubblicando eventi Kubernetes e aggiornando la condizione 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 irreversibili dei nodi segnalate dal Node Monitoring Agent e di ripararli automaticamente quando si verificano tali condizioni.

Implementa QoS

Per le applicazioni critiche, valuta la possibilità di definire requests = limits per il contenitore nel Pod. Ciò assicurerà che il contenitore non venga interrotto se un altro Pod richiede risorse.

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

Configurazione e dimensionamento delle risorse per tutti i carichi di lavoro Requests/Limits

Alcune linee guida generali possono essere applicate al dimensionamento delle richieste di risorse e dei limiti per i carichi di lavoro:

Non specificare limiti di risorse sulla CPU. In assenza di limiti, la richiesta agisce come un peso sul tempo di CPU relativo ottenuto dai contenitori. Ciò consente ai carichi di lavoro di utilizzare l'intera CPU senza limiti artificiali o esaurimenti.
Per le risorse non basate sulla CPU, la configurazione 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 sui nodi. https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction/
Per le risorse non basate sulla CPU, non specificare un limite molto superiore alla richiesta. Maggiore è la dimensione limits della configurazione rispetto arequests, maggiore è la probabilità che i nodi subiscano un sovraccarico, con conseguente elevata probabilità di interruzione del carico di lavoro.
Le richieste di dimensioni corrette sono particolarmente importanti quando si utilizza una soluzione di scalabilità automatica dei nodi come Karpenter o Cluster. https://aws.github.io/aws-eks-best-practices/karpenter/ AutoScaler Questi strumenti esaminano le richieste di carico di lavoro per determinare il numero e la dimensione dei nodi di cui eseguire il provisioning. Se le richieste sono troppo piccole con limiti maggiori, è possibile che i carichi di lavoro vengano eliminati o che OOM venga interrotto se sono stati raggruppati in modo compatto su un nodo.

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

Configura le quote delle 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 calcolo 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 namespace.

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

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

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

Le quote delle risorse aiutano a limitare la quantità di risorse che un namespace può utilizzare. L'LimitRangeoggetto può aiutarti a implementare le risorse minime e massime che un contenitore può richiedere. L'utilizzo è LimitRange possibile impostare una richiesta e dei limiti predefiniti per i contenitori, il che è utile se l'impostazione dei limiti delle risorse di calcolo 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

Prendi in considerazione l'utilizzo LimitRange in combinazione con ResourceQuota per applicare i limiti a livello di contenitore e di namespace. L'impostazione di questi limiti garantirà che un contenitore o un namespace non influisca sulle risorse utilizzate da altri tenant del cluster.

Usa DNSCache NodeLocal

È possibile migliorare le prestazioni del Cluster DNS eseguendo DNSCache. NodeLocal 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 invece di utilizzare Service. kube-dns Questa funzionalità è inclusa automaticamente nella modalità EKS Auto.

Configurare il ridimensionamento automatico di CoreDNS

Un altro metodo per migliorare le prestazioni del Cluster DNS consiste nell'abilitare il ridimensionamento automatico integrato dei pod CoreDNS.

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.

Avvertimento JavaScript è disabilitato o non è disponibile nel tuo browser.

Per usare la documentazione AWS, JavaScript deve essere abilitato. Consulta le pagine della guida del browser per le istruzioni.

Convenzioni dei documenti

Piano di controllo

Rete