¿Cómo soluciono los problemas al integrar Secrets Manager con Amazon EKS?

Descripción breve

Si los pods no entran en el estado EN EJECUCIÓN, aparecerá un error al integrar Secrets Manager con Amazon EKS. Para resolver este problema, comprueba los registros de los pods de controladores de la interfaz de almacenamiento de contenedores (CSI) de Secrets Store para determinar los pods que no funcionan.

Resolución

Para mostrar los pods de controladores de CSI de Secrets Store, ejecute el siguiente comando:

kubectl --namespace=kube-system get pods -l "app=secrets-store-csi-driver"

Para mostrar los registros de los pods de CSI de Secrets Store, ejecuta el siguiente comando:

kubectl --namespace=kube-system logs -f -l "app=secrets-store-csi-driver"

Los siguientes registros muestran que cada pod funciona bien:

I1120 20:21:19.135834       1 secrets-store.go:74] Driver: secrets-store.csi.k8s.io
I1120 20:21:19.135857       1 secrets-store.go:75] Version: v0.2.0, BuildTime: 2021-08-12-18:55
I1120 20:21:19.135868       1 secrets-store.go:76] Provider Volume Path: /etc/kubernetes/secrets-store-csi-providers
I1120 20:21:19.135874       1 secrets-store.go:77] GRPC supported providers will be dynamically created
I1120 20:21:19.135895       1 driver.go:80] "Enabling controller service capability" capability="CREATE_DELETE_VOLUME"
I1120 20:21:19.135912       1 driver.go:90] "Enabling volume access mode" mode="SINGLE_NODE_READER_ONLY"
I1120 20:21:19.135922       1 driver.go:90] "Enabling volume access mode" mode="MULTI_NODE_READER_ONLY"
I1120 20:21:19.135938       1 main.go:172] starting manager
I1120 20:21:19.136210       1 server.go:111] Listening for connections on address: //csi/csi.sock
I1120 20:21:18.956092       1 exporter.go:33] metrics backend: prometheus

Nota: Los pods que llevan a cabo las mismas acciones aparecen como entradas duplicadas.

Si SecretProviderClass no existe en el mismo espacio de nombres que el pod en VolumeMount, se mostrará el siguiente error:

«Warning FailedMount 3s (x4 over 6s) kubelet, kind-control-plane MountVolume.SetUp failed for volume "secrets-store-inline" : rpc error: code = Unknown desc = failed to get secretproviderclass default/aws, error: secretproviderclasses.secrets-store.csi.x-k8s.io "aws" not found»

SecretProviderClass debe existir en el mismo espacio de nombres que el pod.

El controlador de CSI de Secrets Store se implementa como un daemonset. Si los pods del controlador de CSI no se están ejecutando en el nodo, se muestra el siguiente error:

«Warning FailedMount 1s (x4 over 4s) kubelet, kind-control-plane MountVolume.SetUp failed for volume "secrets-store-inline" : kubernetes.io/csi: mounter.SetUpAt failed to get CSI client: driver name secrets-store.csi.k8s.io not found in the list of registered CSI drivers»

Si el nodo tiene la propiedad taint, añada una tolerancia para taint en el daemonset del controlador de CSI de Secrets Store.

Compruebe si hay algún selector de nodos que no permita que los pods de controladores de CSI de Secrets Store se ejecuten en el nodo:

kubectl --namespace=kube-system describe pods -l "app=secrets-store-csi-driver" | grep Node-Selectors*

Obtenga las etiquetas asociadas a los nodos de trabajo de su pod:

kubectl get node --selector=kubernetes.io/os=linux

Compare los resultados de los comandos anteriores. Asegúrese de que las etiquetas coincidan con los valores del selector de nodos.

Compruebe si el controlador de CSI se desplegó en el clúster y si todos los pods están en estado En ejecución:

kubectl get pods -l app=secrets-store-csi-driver -n kube-system

-o-

kubectl get daemonset csi-secrets-store-secrets-store-csi-driver -n kube-system

Resultado del ejemplo:

kubectl get csidriver
NAME                       ATTACHREQUIRED   PODINFOONMOUNT   MODES       AGE
secrets-store.csi.k8s.io   false            true             Ephemeral   110m

El resultado anterior muestra que el controlador se desplegó en el clúster. Si no encuentras secrets-store.csi.k8s.io, vuelve a instalar el controlador.

El pod secrets-store-csi-driver-provider-aws se despliega como un daemonset. Si el pod no se ejecuta en el nodo de trabajo en el que se intenta iniciar el pod de la aplicación, aparecerá el siguiente error:

“MountVolume.SetUp failed for volume "volumename" : rpc error: code = Unknown desc = failed to mount secrets store objects for pod namespace/pod, err: error connecting to provider "aws": provider not found: provider "aws"”

Para comprobar la cantidad de pods de secrets-store-csi-driver-provider-aws que se están ejecutando en el clúster y la cantidad de nodos, ejecuta los dos comandos siguientes:

kubectl get ds csi-secrets-store-provider-aws -n kube-system

kubectl get nodes

Si el parámetro desiredNumberScheduled del daemonset es inferior al número de nodos del clúster, comprueba el parámetro Tolerations del daemonset:

kubectl get ds csi-secrets-store-provider-aws -n kube-system -o yaml

En el resultado del comando, en tolerations:, busca operator: Exists. Si no encuentras operator: Exists, entonces esa podría ser la razón por la que el pod del daemonset secrets-store-csi-driver-provider-aws no se ejecutó en ese nodo. Esto se debe a que el daemonset secrets-store-csi-driver-provider-aws no tolera taints de forma predeterminada. Para resolver este problema, añade la tolerancia. Para obtener más información, consulta Taints and tolerations (Taints y tolerancias) en el sitio web de Kubernetes.

Si los archivos que ha extraído SecretProviderClass superan los 4 mebibytes (MiB), es posible que se muestren advertencias de FailedMount. El mensaje de error incluye grpc: received message larger than max. Para aceptar respuestas de más de 4 MiB, especifica --max-call-recv-msg-size=size en bytes en el contenedor de Secrets Store del daemonset csi-secrets-store.

**Nota:**Sustituya el tamaño en bytes por el tamaño que quiera que acepte el controlador. Dado que las respuestas más grandes pueden aumentar el consumo de recursos de memoria del contenedor secrets-store, es posible que tengas que aumentar el límite de memoria. Si sigues teniendo problemas, consulta los eventos de registro en orden cronológico para ver si se ha producido algún otro error:

kubectl get events -n kube-system --sort-by='.metadata.creationTimestamp'