¿Cómo puedo crear y solucionar problemas de aprovisionamiento de volúmenes con reconocimiento de topología que utiliza un controlador CSI de EBS en Amazon EKS?

8 minutos de lectura
0

Quiero aprovisionar volúmenes con reconocimiento de topología en un clúster de Amazon Elastic Kubernetes Service (Amazon EKS) que utilice componentes de Amazon Elastic Block Store (Amazon EBS).

Descripción breve

Para configurar y solucionar problemas de una topología de infraestructura de nube en Amazon EKS que utilice componentes de Amazon EBS, complete los siguientes pasos:

  1. Compruebe que el complemento CSI de EBS esté configurado correctamente.
  2. Configure la clase de almacenamiento con una implementación que tenga en cuenta la topología.
  3. Cree un pod y una carga de trabajo y, a continuación, pruebe un escenario con reconocimiento de topología.
  4. Solucione los errores del controlador CSI de EBS.

Resolución

Nota: Si recibe errores al ejecutar los comandos de la Interfaz de la línea de comandos de AWS (AWS CLI), asegúrese de utilizar la versión más reciente de la AWS CLI.

Compruebe que el complemento CSI de EBS esté configurado correctamente

Nota: Se recomienda utilizar el aprovisionador de CSI de EBS ebs.csi.aws.com para el aprovisionamiento de volúmenes de EBS. Además, utilice el aprovisionador de CSI de EBS al implementar volúmenes con reconocimiento de topología en lugar del aprovisionador de Kubernetes kubernetes.io/aws-ebs integrado en el árbol.

Para comprobar que el complemento CSI de EBS está configurado correctamente, siga estos pasos:

1.    Compruebe si el controlador CSI está instalado. Si no está instalado, consulte Controlador CSI de Amazon EBS para instalar el controlador CSI.

2.    Compruebe que el rol de AWS Identity and Access Management (IAM) de la cuenta de servicio tenga los permisos mínimos de acción de volumen de EBS.

Nota: Debe anotar en la cuenta de servicio los roles de IAM para cuentas de servicio (IRSA). Si no anota la cuenta de servicio con IRSA, el controlador CSI de Amazon EBS asume el rol de IAM en el nodo de trabajo de forma predeterminada. Si el controlador CSI establece de forma predeterminada el rol de IAM en el nodo de trabajo, configure los permisos de rol de IAM necesarios en la consola de administración de AWS.

Configure la clase de almacenamiento con una implementación con reconocimiento de topología

1.    Ejecute el siguiente comando para desplegar la clase de almacenamiento. Edite el manifiesto según sea necesario según sus requisitos de despliegue específicos.

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

Ejemplo de manifiesto:

Nota: Sustituya los atributos del manifiesto por otros que sean específicos de su caso de 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: Para una implementación con reconocimiento de topología, asegúrese de configurar la opción allowedTopologies. Al eliminar esta opción, se deduce la zona de disponibilidad correcta y el controlador CSI de Amazon EBS crea un volumen en el que se programa el pod.

2.    Use una de las siguientes opciones para crear un pv-claim:

(Opción 1) Cree un pv-claim que solicite un volumen con el tipo de perfil especificado en el manifiesto de la clase de almacenamiento desplegada:

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

(Opción 2) Cree un pv-claim que utilice un volumen de EBS disponible especificado en el manifiesto de volúmenes persistentes. Asegúrese de modificar la opción storageClassname: por una cadena vacía**, «»,** y modifique el bloque NodeAffinity según sea necesario.

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

Nota: Para la opción 1 o la opción 2, si los nodos no están disponibles en la zona de disponibilidad del volumen, se produce un error en el despliegue. Esto se debe a que el planificador no puede ajustarse dinámicamente a la restricción topológica.

Cree un pod y una carga de trabajo y pruebe un escenario con reconocimiento de topología

Crear un pod

1.    Cree un módulo de prueba que utilice la afirmación anterior de pv-claim:

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

Nota: Cuando usa topology.ebs.csi.aws.com/zone en allowedTopologogies dentro de una clase de almacenamiento o un volumen persistente, el pod se coloca en la zona de disponibilidad que se especifica en los manifiestos de configuración. Si no hay ningún nodo disponible en esa zona de disponibilidad, el pod queda atascado en el estado Pendiente.

2.    Ejecute los siguientes comandos de pod get y describe para comprobar el estado del despliegue:

kubectl get pod,pvc,pv
kubectl describe pod <EXAMPLE_POD_NAME>

Nota: Sustituya EXAMPLE_POD_NAME por el nombre del pod.

Crear una carga de trabajo

1.     Ejecute el siguiente comando para crear una carga de trabajo de statefulSet que utilice el pv-claim anterior:

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

2.    Ejecute el siguiente comando get y describe para comprobar el estado de la carga de trabajo destatefulSet:

kubectl get statefulset,pod,pvc,pv
kubectl describe pod <EXAMPLE_POD_NAME>

Nota: El controlador statefulSet crea algunas pv-claims para satisfacer las solicitudes de volumen de los pods para los volúmenes en las regiones us-east-2b y us-east-2c de AWS. No se garantiza que StatefulSets, al finalizar, limpie los volúmenes persistentes, lo que podría provocar que no se vuelvan a aprovisionar los volúmenes para los pods de statefulSet que se reprogramen en otra zona de disponibilidad.

Probar un escenario con reconocimiento de topología

(Opcional) Para probar cómo se gestiona el reemplazo de nodos en otra zona de disponibilidad, simule la reorganización de nodos reduciendo la escala de los nodos de la AZ especificada. A continuación, escale verticalmente los nodos nuevos en otra AZ. Cuando haya terminado, consulte las secciones Crear un pod y Crear una carga de trabajo.

Ejemplo de resultado sobre un problema de despliegue simulado:

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.

Para corregir el pod atascado, vuelva a escalar verticalmente un nodo de la zona de disponibilidad especificada para resolver el error de conflicto de afinidad del nodo de volumen.

Nota: Al escalar verticalmente un nuevo nodo en la zona de disponibilidad esperada, el despliegue puede fallar debido a errores en las ejecuciones del reconciliador. Para conocer los pasos de solución de problemas, consulte la siguiente sección, Solucionar errores en el controlador CSI de EBS.

Solucionar errores en el controlador CSI de EBS

Ejemplo de un error de CSI de EBS en el que se simuló la pérdida de nodos y el reciclaje de nodos:

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.    Para aislar el problema, describa el pod y revise las entradas del registro de errores del evento. En el error de ejemplo anterior, el mensaje muestra que cuatro de los cinco nodos no se pueden programar debido a los taints de los nodos y a la configuración de topología o afinidad. Además, el último nodo que se ejecutó en la zona de disponibilidad correcta no encontró ningún volumen persistente disponible para enlazarlo.

2.    Para aislar este problema, compruebe el estado del enlace pv-claim:

kubectl describe persistentvolumeclaim <PVC_NAME>

Nota: Los estados de pv-claim son waiting, bound, invalid o not found. En el siguiente ejemplo, el pv-claim espera a que el controlador cree un volumen. Mientras espera, el pv-claim no se enlaza a un nodo de destino.

`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.    Compruebe los registros del contenedor csi-provisioner en el pod ebs-csi-controller:

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

El siguiente resultado es un ejemplo de evento de error:

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: Si se producen eventos de error similares a los del mensaje anterior, el reconciliador de pv-claim no pudo encontrar la anotación del nodo de destino seleccionado. Elimine esta anotación para que pv-claim se pueda sincronizar correctamente.

4.    Para eliminar la anotación del nodo de destino seleccionado, ejecute el siguiente comando. Asegúrese de copiar y guardar el resultado en el manifiesto pv-claim para eliminar la anotación del nodo seleccionado.

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

Si los pasos de solución de problemas que se siguen no resuelven el problema, recopile los registros de la carga de trabajo del contenedor aislado y póngase en contacto con AWS Support. También puede buscar problemas relacionados en el repositorio de GitHub.

OFICIAL DE AWS
OFICIAL DE AWSActualizada hace un año