Comment puis-je résoudre les problèmes liés à l'intégration de Secrets Manager à Amazon EKS ?

Brève description

Si vos pods ne passent pas à l'état En cours d’exécution, une erreur s'affiche lorsque vous intégrez Secrets Manager à Amazon EKS. Pour résoudre ce problème, consultez les journaux des pods du pilote CSI (Container Storage Interface) Secrets Store pour déterminer si certains pods ne fonctionnent pas.

Résolution

Pour afficher les pods du pilote CSI Secrets Store, exécutez la commande suivante :

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

Pour afficher les journaux des pods CSI Secrets Store, exécutez la commande suivante :

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

Les journaux suivants indiquent que chaque pod fonctionne correctement :

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

Remarque : les pods qui effectuent les mêmes actions apparaissent sous forme d'entrées dupliquées.

Si la variable SecretProviderClass de VolumeMount n'existe pas dans le même espace de noms que le pod, le message d'erreur suivant s'affiche :

« 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 »

La variable SecretProviderClass doit exister dans le même espace de noms que le pod.

Le pilote CSI Secrets Store est déployé en tant que daemonset. Si les pods du pilote CSI ne s'exécutent pas sur le nœud, le message d'erreur suivant s'affiche :

« 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 le nœud est rejeté, ajoutez une tolérance de rejet dans le daemonset du pilote CSI Secrets Store.

Vérifiez s'il existe des sélecteurs de nœuds qui n'autorisent pas les pods du pilot CSI Secrets Store à s'exécuter sur le nœud :

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

Identifiez les étiquettes associées aux composants master de votre pod :

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

Comparez les sorties des commandes précédentes. Assurez-vous que les étiquettes correspondent bien aux valeurs du sélecteur de nœuds.

Vérifiez que le pilote CSI a bien été déployé sur le cluster et que tous les pods sont à l'état En cours d'exécution :

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

-ou-

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

Exemple de sortie :

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

La sortie précédente indique que le pilote a été déployé sur le cluster. Si vous ne trouvez pas secrets-store.csi.k8s.io, réinstallez le pilote.

Le pod secrets-store-csi-driver-provider-aws est déployé en tant que daemonset. Si le pod ne s'exécute pas dans le nœud de travail sur lequel votre module d'application tente de démarrer, l’erreur suivante s'affiche :

« 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" »

Pour vérifier le nombre de pods secrets-store-csi-driver-provider-aws qui s'exécutent dans le cluster et le nombre de nœuds, exécutez les deux commandes suivantes :

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

kubectl get nodes

Si le paramètre desiredNumberScheduled du daemonset est inférieur au nombre de nœuds du cluster, vérifiez le paramètre Tolérances du daemonset :

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

Dans la sortie de la commande, sous tolérances :, recherchez l’opérateur : Existe. Si vous ne trouvez pas d'opérateur : Existe, c'est peut-être la raison pour laquelle le pod daemonset secrets-store-csi-driver-provider-aws ne s'est pas exécuté sur ce nœud. Cela est dû au fait que le daemonset secrets-store-csi-driver-provider-aws ne tolère pas les rejets par défaut. Pour résoudre ce problème, ajoutez la tolérance. Pour plus d'informations, consultez la page Rejets et tolérances sur le site Web de Kubernetes.

Si la taille des fichiers extraits par SecretProviderClass dépasse 4 mébioctets (Mio), des avertissements FailedMount peuvent s’afficher. Le message d'erreur inclut grpc: received message larger than max. Pour accepter des réponses supérieures à 4 Mo, spécifiez --max-call-recv-msg-size=size en octets au conteneur Secrets Store du daemonset csi-secrets-store.

Remarque : remplacez taille en octets par la taille que vous souhaitez que le pilote accepte. Étant donné que des réponses plus importantes peuvent augmenter la consommation de ressources mémoire du conteneur secrets-store, il peut être nécessaire d’augmenter votre limite de mémoire. Si les problèmes persistent, examinez les événements de journaux dans l'ordre chronologique pour voir si d'autres échecs se sont produits :

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