Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

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 due scelte per i nodi di lavoro con EKS: EC2istanze e Fargate. Se scegli EC2 le 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 nodi di lavoro gestiti e autogestiti e Fargate.

EKS on Fargate offre il percorso più semplice verso un piano dati resiliente. 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 è utilizzare Kubernetes Cluster Autoscaler, gruppi EC2Auto Scaling o progetti comunitari come Escalator di Atlassian.

Raccomandazioni

Usa EC2 Auto Scaling Groups per creare nodi di lavoro

È consigliabile creare nodi di lavoro utilizzando gruppi di EC2 Auto Scaling anziché creare singole EC2 istanze e unirle al cluster. I gruppi di Auto Scaling sostituiranno automaticamente tutti i nodi terminati o guasti assicurando che il cluster abbia sempre la capacità di eseguire il carico di lavoro.

Usa Kubernetes Cluster Autoscaler per scalare i nodi

Cluster Autoscaler regola la dimensione del piano dati quando ci sono pod che non possono essere eseguiti perché il cluster dispone di risorse insufficienti e l'aggiunta di un altro nodo di lavoro sarebbe utile. Sebbene Cluster Autoscaler sia un processo reattivo, attende che i pod diventino in sospeso a causa della capacità insufficiente del cluster. Quando si verifica un evento di questo tipo, aggiunge istanze al cluster. EC2 Ogni volta che la capacità del cluster esaurisce, nuove repliche o nuovi pod non saranno disponibili (in stato Pending) finché non verranno aggiunti nodi di lavoro. Questo ritardo può influire sull'affidabilità delle applicazioni se il piano dati non è in grado di scalare abbastanza velocemente da soddisfare le esigenze del carico di lavoro. Se un nodo di lavoro viene costantemente sottoutilizzato e tutti i relativi pod possono essere programmati su altri nodi di lavoro, Cluster Autoscaler lo interrompe.

Configura l'over-provisioning con Cluster Autoscaler

Cluster Autoscaler attiva una scalabilità verticale del piano dati quando i Pod nel cluster sono già in sospeso. Pertanto, potrebbe verificarsi un ritardo tra il momento in cui l'applicazione necessita di più repliche e il momento in cui, di fatto, riceve più repliche. Un'opzione per tenere conto di questo possibile ritardo consiste nell'aggiungere più repliche del necessario, aumentando così il numero di repliche per l'applicazione.

Un altro schema consigliato da Cluster Autoscaler utilizza pause Pods e la funzione Priority Preemption. Il pause Pod esegue un contenitore di pausa che, come suggerisce il nome, non fa altro che fungere da segnaposto per la capacità di elaborazione che può essere utilizzata da altri Pod del cluster. Poiché viene eseguito con una priorità assegnata molto bassa, il pause Pod viene rimosso dal nodo quando è necessario creare un altro Pod e il cluster non ha capacità disponibile. Kubernetes Scheduler rileva lo sfratto del Pod di pausa e tenta di riprogrammarlo. Ma poiché il cluster sta funzionando a pieno regime, il Pod di pausa rimane in sospeso, a cui Cluster Autoscaler reagisce aggiungendo nodi.

Utilizzo di Cluster Autoscaler con più gruppi di Auto Scaling

Esegui Cluster Autoscaler con il flag abilitato. --node-group-auto-discovery In questo modo, Cluster Autoscaler sarà in grado di trovare tutti i gruppi di scalabilità automatica che includono un particolare tag definito ed eviterà la necessità di definire e gestire ogni gruppo di scalabilità automatica nel manifesto.

Utilizzo di Cluster Autoscaler con archiviazione locale

Per impostazione predefinita, Cluster Autoscaler non riduce la scalabilità dei nodi su cui sono distribuiti pod con storage locale collegato. Imposta il --skip-nodes-with-local-storage flag su false per consentire a Cluster Autoscaler di ridimensionare questi nodi.

Distribuisci i nodi di lavoro e il carico di lavoro su più AZs

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

Se utilizzi Kubernetes 1.18+, il metodo consigliato per distribuire i pod AZs è utilizzare Topology Spread Constraints for Pods.

La distribuzione seguente distribuisce i pod, se possibile, su tutti i pod, 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

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

Garantisci la capacità 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à. Al momento della stesura, i volumi EBS sono disponibili solo all'interno di una singola AZ. 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. Kubernetes 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.

Crea un gruppo di Auto Scaling per ogni AZ con una capacità sufficiente a garantire che il cluster abbia sempre la capacità di pianificare i pod nella stessa zona dei volumi EBS di cui hanno bisogno. Inoltre, è necessario abilitare la --balance-similar-node-groups funzionalità in Cluster Autoscaler.

Se stai eseguendo un'applicazione che utilizza il volume EBS ma non ha requisiti per la disponibilità elevata, puoi limitare la distribuzione dell'applicazione a una singola AZ. In EKS, ai nodi di lavoro viene aggiunta automaticamente failure-domain.beta.kubernetes.io/zone l'etichetta, che contiene il nome della AZ. Puoi vedere le etichette allegate ai tuoi nodi eseguendokubectl get nodes --show-labels. Ulteriori informazioni sulle etichette integrate dei nodi sono disponibili qui. Puoi usare i selettori di nodi per pianificare un pod in una particolare AZ.

Nell'esempio seguente, il pod sarà programmato solo in us-west-2c AZ:

apiVersion: v1
kind: Pod
metadata:
  name: single-az-pod
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: failure-domain.beta.kubernetes.io/zone
            operator: In
            values:
            - us-west-2c
  containers:
  - name: single-az-container
    image: kubernetes/pause

I volumi persistenti (supportati da EBS) sono inoltre etichettati automaticamente con il nome AZ; puoi vedere a quale AZ appartiene il tuo volume persistente eseguendolo. kubectl get pv -L topology.ebs.csi.aws.com/zone Quando viene creato un pod e richiede un volume, Kubernetes pianifica il Pod su un nodo nella stessa AZ del volume.

Considerate questo scenario: avete un cluster EKS con un gruppo di nodi. Questo gruppo di nodi ha tre nodi di lavoro distribuiti su tre AZs. Hai un'applicazione che utilizza un volume persistente supportato da EBS. Quando crei questa applicazione e il volume corrispondente, il relativo Pod viene creato nella prima delle tre. AZs Quindi, il nodo di lavoro che esegue questo Pod diventa malsano e successivamente non disponibile per l'uso. Cluster Autoscaler sostituirà il nodo non funzionante con un nuovo nodo di lavoro; tuttavia, poiché il gruppo di scalabilità automatica si estende su tre AZs, il nuovo nodo di lavoro potrebbe essere lanciato nella seconda o nella terza AZ, ma non nella prima AZ, come richiesto dalla situazione. Poiché il volume EBS vincolato da AZ esiste solo nella prima AZ, ma non ci sono nodi di lavoro disponibili in quella zona, il Pod non può essere pianificato. Pertanto, è necessario creare un gruppo di nodi in ogni AZ, in modo che sia sempre disponibile una capacità sufficiente per eseguire pod che non possono essere pianificati in altre aree. AZs

In alternativa, EFS può semplificare la scalabilità automatica dei cluster durante l'esecuzione di applicazioni che richiedono uno storage persistente. I client possono accedere contemporaneamente ai file system EFS da tutta la AZs regione. Anche se un Pod che utilizza un volume persistente supportato da EFS viene terminato e pianificato in diverse AZ, sarà in grado di montare il volume.

Rileva i problemi dei nodi con l'agente di monitoraggio dei nodi

I guasti nei nodi di lavoro possono influire sulla disponibilità delle applicazioni. È possibile utilizzare l'agente di monitoraggio del nodo per rilevare e mostrare problemi di salute. Puoi anche abilitare la riparazione automatica dei nodi per sostituire automaticamente i nodi quando vengono rilevati problemi.

L'agente di monitoraggio dei nodi è incluso come funzionalità per tutti i cluster Amazon EKS Auto Mode. Per altri tipi di cluster, puoi aggiungere l'agente di monitoraggio come componente aggiuntivo di Amazon EKS. Per ulteriori informazioni, consulta Abilita la riparazione automatica dei nodi e analizza i problemi di integrità dei nodi nella Guida per l'utente di Amazon EKS.

Riserva le risorse per il sistema e i daemon Kubernetes

Puoi migliorare la stabilità dei nodi di lavoro riservando la capacità di calcolo per il sistema operativo e i daemon Kubernetes. I pod, in particolare quelli senza limits dichiarazione, possono saturare le risorse di sistema mettendo i nodi in una situazione in cui i processi del sistema operativo e i daemon Kubernetes (, il runtime dei container, ecc.) competono con i pod per le risorse di sistema. kubelet Puoi utilizzare kubelet i flag --system-reserved e riservare risorse rispettivamente --kube-reserved per i processi di sistema (udev, sshd ecc.) e i daemon Kubernetes.

Se utilizzi l'AMI Linux ottimizzata per EKS, la CPU, la memoria e lo storage sono riservati al sistema e ai daemon Kubernetes per impostazione predefinita. Quando vengono avviati i nodi di lavoro basati su questa AMI, EC2 i dati utente vengono configurati per attivare lo bootstrap.shscript. Questo script calcola le prenotazioni di CPU e memoria in base al numero di core della CPU e alla memoria totale disponibile sull'istanza. EC2 I valori calcolati vengono scritti nel KubeletConfiguration file che si trova in. /etc/kubernetes/kubelet/kubelet-config.json

Potrebbe essere necessario aumentare la prenotazione delle risorse di sistema se si eseguono demoni personalizzati sul nodo e la quantità di CPU e memoria riservate per impostazione predefinita è insufficiente.

eksctloffre il modo più semplice per personalizzare la prenotazione delle risorse per i daemon di sistema e Kubernetes.

Implementazione del 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 ridimensiona le richieste/i limiti di risorse per tutti i carichi di lavoro

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

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:

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 e/o elaborazione (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 quel namespace.

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.

CoreDNS

CoredNS soddisfa le funzioni di risoluzione dei nomi e individuazione dei servizi in Kubernetes. È installato per impostazione predefinita sui cluster EKS. Per quanto riguarda l'interoperabilità, il servizio Kubernetes per CoredNS è ancora denominato kube-dns. I CoredNS Pods vengono eseguiti come parte di una distribuzione kube-system nello spazio dei nomi e in EKS, per impostazione predefinita, esegue due repliche con richieste e limiti dichiarati. Le query DNS vengono inviate al servizio che viene eseguito nel Namespace. kube-dns kube-system

Raccomandazioni

Monitora le metriche CoredNS

CoredNS ha integrato il supporto per Prometheus. In particolare, dovresti considerare il monitoraggio della latenza di CoreDNS coredns_dns_request_duration_seconds_sum (prima della versione 1.7.0 veniva core_dns_response_rcode_count_total chiamata la metrica), degli errori coredns_dns_responses_total (, NXDOMAIN, SERVFAIL) e del consumo di memoria di CoredNS Pod. FormErr

Per scopi di risoluzione dei problemi, puoi usare kubectl per visualizzare i log di CoredNS:

for p in $(kubectl get pods -n kube-system -l k8s-app=kube-dns -o jsonpath='{.items[*].metadata.name}'); do kubectl logs $p -n kube-system; done

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

Configurazione cluster-proportional-scaler per CoredNS

Un altro metodo per migliorare le prestazioni del Cluster DNS consiste nel ridimensionare automaticamente in orizzontale l'implementazione CoreDNS in base al numero di nodi e core CPU nel cluster. Horizontal cluster-proportional-autoscaler è un contenitore che ridimensiona il numero di repliche di una distribuzione in base alla dimensione del piano dati pianificabile.

I nodi e l'aggregato dei core della CPU nei nodi sono le due metriche con cui è possibile scalare CoredNS. È possibile utilizzare entrambe le metriche contemporaneamente. Se si utilizzano nodi più grandi, il ridimensionamento di CoredNS si basa sul numero di core della CPU. Se invece si utilizzano nodi più piccoli, il numero di repliche CoredNS dipende dai core della CPU nel piano dati. La configurazione proporzionale dell'autoscaler si presenta così:

linear: '{"coresPerReplica":256,"min":1,"nodesPerReplica":16}'

Scelta di un AMI con Node Group

EKS fornisce soluzioni ottimizzate EC2 AMIs che vengono utilizzate dai clienti per creare gruppi di nodi gestiti e autogestiti. Questi AMIs sono pubblicati in ogni regione per ogni versione di Kubernetes supportata. EKS li contrassegna AMIs come obsoleti quando vengono rilevati dei bug. CVEs Pertanto, la raccomandazione è di non consumare dati obsoleti AMIs durante la scelta di un'AMI per il gruppo di nodi.

I dati obsoleti AMIs possono essere filtrati utilizzando l'API Ec2 describe-images utilizzando il comando seguente:

aws ec2 describe-images --image-id ami-0d551c4f633e7679c --no-include-deprecated

Puoi anche riconoscere un'AMI obsoleta verificando se l'output describe-image contiene un campo as a. DeprecationTime Ad esempio:

aws ec2 describe-images --image-id ami-xxx --no-include-deprecated
{
    "Images": [
        {
            "Architecture": "x86_64",
            "CreationDate": "2022-07-13T15:54:06.000Z",
            "ImageId": "ami-xxx",
            "ImageLocation": "123456789012/eks_xxx",
            "ImageType": "machine",
            "Public": false,
            "OwnerId": "123456789012",
            "PlatformDetails": "Linux/UNIX",
            "UsageOperation": "RunInstances",
            "State": "available",
            "BlockDeviceMappings": [
                {
                    "DeviceName": "/dev/xvda",
                    "Ebs": {
                        "DeleteOnTermination": true,
                        "SnapshotId": "snap-0993a2fc4bbf4f7f4",
                        "VolumeSize": 20,
                        "VolumeType": "gp2",
                        "Encrypted": false
                    }
                }
            ],
            "Description": "EKS Kubernetes Worker AMI with AmazonLinux2 image, (k8s: 1.19.15, docker: 20.10.13-2.amzn2, containerd: 1.4.13-3.amzn2)",
            "EnaSupport": true,
            "Hypervisor": "xen",
            "Name": "aws_eks_optimized_xxx",
            "RootDeviceName": "/dev/xvda",
            "RootDeviceType": "ebs",
            "SriovNetSupport": "simple",
            "VirtualizationType": "hvm",
            "DeprecationTime": "2023-02-09T19:41:00.000Z"
        }
    ]
}