In che modo posso creare e risolvere i problemi di provisioning dei volumi in base alla topologia che utilizza un driver EBS CSI in Amazon EKS?

Breve descrizione

Per configurare e risolvere i problemi di una topologia dell'infrastruttura cloud in Amazon EKS che utilizza componenti Amazon EBS, completa i seguenti passaggi:

1. Verificare che il componente aggiuntivo EBS CSI sia configurato correttamente.
2. Configura la classe di archiviazione con un'implementazione consapevole della topologia.
3. Crea un pod e un carico di lavoro, quindi testa uno scenario compatibile con la topologia.
4. Risolvi gli errori del controller EBS CSI.

Risoluzione

Nota: Se ricevi errori durante l'esecuzione dei comandi AWS Command Line Interface (AWS CLI), assicurati di utilizzare la versione più recente dell'interfaccia a riga di comando di AWS.

Verifica che il componente aggiuntivo EBS CSI sia configurato correttamente

Nota: È consigliabile utilizzare il provider EBS CSI ebs.csi.aws.com per l'approvvigionamento di volumi EBS. Inoltre, utilizza il provisioner EBS CSI quando implementi volumi sensibili alla topologia anziché il provisioner Kubernetes integrato nell'albero kubernetes.io/aws-ebs.

Per verificare che il componente aggiuntivo EBS CSI sia configurato correttamente, completa i seguenti passaggi:

1.    Controlla se il driver CSI è installato. Se non è installato, consulta il driver CSI di Amazon EBS per installare il driver CSI.

2.    Verifica che il ruolo AWS Identity and Access Management (IAM) sull'account del servizio disponga delle autorizzazioni di azione di volume EBS minime.

Nota: È necessario annotare l'account del servizio con i ruoli IAM per gli account di servizio (IRSA). Se non annoti l'account del servizio con IRSA, il driver CSI di Amazon EBS assume il ruolo IAM sul nodo di lavoro per impostazione predefinita. Se il driver CSI è impostato per impostazione predefinita sul ruolo IAM sul nodo di lavoro, configura le autorizzazioni del ruolo IAM richieste nella Console di gestione AWS.

Configurazione della classe di storage con un'implementazione sensibile alla topologia

1.    Esegui il comando seguente per implementare la classe di archiviazione. Modifica il manifesto secondo necessità in base ai tuoi requisiti di distribuzione specifici.

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-ebs-csi-driver/master/examples/kubernetes/storageclass/manifests/storageclass.yaml

Manifesto di esempio:

Nota: Sostituisci gli attributi nel manifest con altri specifici per il tuo caso d'uso.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ebs-sc
provisioner: ebs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
  csi.storage.k8s.io/fstype: xfs
  type: io1
  iopsPerGB: "50"
  encrypted: "true"
allowedTopologies:
- matchLabelExpressions:
  - key: topology.ebs.csi.aws.com/zone
    values:
    - us-east-2c

Nota: Per un'implementazione consapevole della topologia, assicurati di configurare l'opzione allowedTopologies. L'eliminazione di questa opzione fa sì che venga dedotta la zona di disponibilità corretta e il controller CSI di Amazon EBS crei un volume in cui è pianificato il pod.

2.    Utilizza una delle seguenti opzioni per creare un pv-claim:

(Opzione 1) Crea un pv-claim che richieda un volume con il tipo di profilo specificato nel manifesto della classe di storage distribuita:

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-ebs-csi-driver/master/examples/kubernetes/storageclass/manifests/claim.yaml

(Opzione 2) Crea un pv-claim che utilizza un volume EBS disponibile specificato nel manifesto del volume persistente. Assicurati di modificare l'opzione storageClassName: in una stringa vuota**, "", ** e modifica il blocco NodeAffinity come richiesto.

kubectl apply -f https://github.com/kubernetes-sigs/aws-ebs-csi-driver/tree/master/examples/kubernetes/static-provisioning/manifests

Nota: Per l'opzione 1 o l'opzione 2, se i nodi non sono disponibili nella zona di disponibilità del volume, la distribuzione non riesce. Questo perché lo scheduler non può adattarsi dinamicamente alla restrizione della topologia.

Crea un pod e un carico di lavoro e testa uno scenario compatibile con la topologia

Crea un contenitore

1.    Crea un contenitore di test che utilizzi il precedente pv-claim:

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-ebs-csi-driver/master/examples/kubernetes/storageclass/manifests/pod.yaml

Nota: Quando usi topology.ebs.csi.aws.com/zone in AllowedTopologies all'interno di una classe di archiviazione o di un volume persistente, il pod viene inserito nella zona di disponibilità specificata nei manifesti di configurazione. Se non è disponibile alcun nodo in quella zona di disponibilità, il contenitore si blocca nello stato In sospeso.

2.    Esegui i seguenti comandi pod get e describe per verificare lo stato della distribuzione:

kubectl get pod,pvc,pv

kubectl describe pod <EXAMPLE_POD_NAME>

Nota: Sostituisci EXAMPLE_POD_NAME con il nome del tuo pod.

Crea un carico di lavoro

1.     Esegui il comando seguente per creare un carico di lavoro StatefulSet che utilizza il precedente pv-claim:

kubectl apply -f https://gist.githubusercontent.com/AbeOwlu/b8641d2f58810789986ab775f00c7780/raw/9144ae5385dfd98d4739e99983346fbdd28eaa2d/statefulset.yaml

2.    Esegui il seguente comando get e describe per verificare lo stato del carico di lavoro StatefulSet:

kubectl get statefulset,pod,pvc,pv

kubectl describe pod <EXAMPLE_POD_NAME>

Nota: Il controller StatefulSet crea alcuni pv claim per soddisfare la richiesta di volumi dei pod nelle regioni AWS us-east-2b e us-east-2c. Non è garantito che StatefulSets alla terminazione pulisca i volumi persistenti, il che potrebbe impedire il riprovisioning dei volumi per i pod StatefulSet che vengono riprogrammati in un'altra zona di disponibilità.

Testa uno scenario compatibile con la topologia

(Facoltativo) Per verificare come viene gestita la sostituzione dei nodi in un'altra zona di disponibilità, simula il rimpasto dei nodi ridimensionando i nodi nella AZ specificata. Quindi, ridimensiona i nuovi nodi in un'altra AZ. Al termine, consulta le sezioni Crea un contenitore e Crea un carico di lavoro.

Esempio di output su un problema di distribuzione simulata:

from: default-scheduler : message: 0/4 nodes are available: 1 node(s) had volume node affinity conflict, 3 node(s) had taint {eks.amazonaws.com/compute-type: fargate}, that the pod didn't tolerate.

Per correggere il contenitore bloccato, ridimensiona nuovamente un nodo nella zona di disponibilità specificata per risolvere l'errore di conflitto di affinità tra i nodi di volume.

Nota: Quando si esegue la scalabilità di un nuovo nodo nella zona di disponibilità prevista, la distribuzione può fallire a causa di esecuzioni del riconciliatore non riuscite. Per la procedura di risoluzione dei problemi, consulta la sezione seguente, Risoluzione degli errori del controller EBS CSI.

Risoluzione degli errori del controller EBS CSI

Esempio di errore EBS CSI in cui sono stati simulati l'abbandono dei pod e il riciclo dei nodi:

from: default-scheduler : message: 0/5 nodes are available: 1 node(s) didn't find available persistent volumes to bind, 1 node(s) didn't match Pod's node affinity/selector, 3 node(s) had taint {eks.amazonaws.com/compute-type: fargate}, that the pod didn't tolerate

1.    Per isolare il problema, descrivi il pod e rivedi le voci del registro degli errori nell'evento. Nell'errore di esempio precedente, il messaggio mostra che quattro nodi su cinque non possono essere pianificati a causa di difetti dei nodi e della configurazione della topologia o dell'affinità. Inoltre, l'ultimo nodo in esecuzione nella zona di disponibilità corretta non ha trovato un volume persistente disponibile da associare.

2.    Per isolare questo problema, controlla lo stato del pv-claim bind:

kubectl describe persistentvolumeclaim <PVC_NAME>

Nota: Gli stati di pv-claim sono in attesa, vincolato, non valido o non trovato. Nell'esempio seguente, pv-claim è in attesa che il driver crei un volume. Durante l'attesa, il pv-claim non si collega a un nodo di destinazione.

`from: ebs.csi.aws.com_ebs-csi-controller- : message:  failed to get target node: node "ip-10-0-60-85.ec2.internal" not found`  
`waiting for a volume to be created, either by external provisioner "ebs.csi.aws.com" or manually created by system administrator`

3.    Controlla i log del contenitore csi-provisioner nel pod ebs-csi-controller.

kubectl logs ebs-csi-controller-<RANDOM_HASH> -c csi-provisioner -n kube-system

L'output seguente è un esempio di evento di errore:

Retrying syncing claim "claim-id", failure 343 error syncing claim "claim-id": failed to get target node: node "ip-10-0-60-85.ec2.internal" not found

Nota: Se si verificano eventi di errore simili al messaggio precedente, il riconciliatore pv-claim non è riuscito a trovare un'annotazione del nodo di destinazione selezionato. Rimuovi questa annotazione in modo che pv-claim possa essere sincronizzato correttamente.

4.    Per rimuovere l'annotazione del nodo di destinazione selezionato, esegui il comando seguente. Assicurati di copiare e salvare l'output nel manifesto pv-claim per rimuovere l'annotazione del nodo selezionato.

kubectl edit  persistentvolumeclaims ebs-claim | grep -v "volume.kubernetes.io/selected-node:"

Se la procedura di risoluzione dei problemi non risolve il problema, raccogli i log dal carico di lavoro isolato del container e contatta AWS Support. Puoi anche cercare problemi correlati nel repository GitHub.