Wie behebe ich Probleme, wenn ich Secrets Manager mit Amazon EKS integriere?

Kurzbeschreibung

Wenn Ihre Pods nicht in den Status Wird ausgeführt wechseln, erhalten Sie eine Fehlermeldung, wenn Sie Secrets Manager in Amazon EKS integrieren. Um dieses Problem zu beheben, überprüfen Sie die Protokolle der Secrets Store Container Storage Interface (CSI)-Treiber-Pods, um festzustellen, ob die Pods nicht funktionieren.

Lösung

Führen Sie den folgenden Befehl aus, um die Secrets Store CSI-Treiber-Pods anzuzeigen:

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

Führen Sie den folgenden Befehl aus, um die Protokolle der Secrets Store CSI-Pods anzuzeigen:

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

Die folgenden Protokolle zeigen, dass jeder Pod eine gute Leistung erbringt:

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

Hinweis: Pods, die dieselben Aktionen ausführen, werden als doppelte Einträge angezeigt.

Wenn die SecretProviderClass im VolumeMount nicht im selben Namespace wie der Pod existiert, erhalten Sie die folgende Fehlermeldung:

„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“

Die SecretProviderClass muss im selben Namespace wie der Pod existieren.

Der Secrets Store CSI-Treiber wird als Daemonset bereitgestellt. Wenn die CSI-Treiber-Pods nicht auf dem Knoten ausgeführt werden, erhalten Sie die folgende Fehlermeldung:

„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“

Wenn der Knoten getaintet ist, fügen Sie dem Secrets Store CSI-Driver-Daemonset eine Toleranz für die Verunsicherung hinzu.

Prüfen Sie, ob es Knotenselektoren gibt, die nicht zulassen, dass die Secrets Store CSI-Treiber-Pods auf dem Knoten ausgeführt werden:

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

Rufen Sie die Labels ab, die den Worker-Knoten in Ihrem Pod zugeordnet sind:

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

Vergleichen Sie die Ausgaben der vorherigen Befehle. Stellen Sie sicher, dass die Beschriftungen mit den Knotenselektorwerten übereinstimmen.

Prüfen Sie, ob der CSI-Treiber auf dem Cluster bereitgestellt wurde und ob sich alle Pods im Status Aktiv befinden:

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

-oder-

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

Beispielausgabe:

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

Die vorherige Ausgabe zeigt, dass der Treiber im Cluster bereitgestellt wurde. Wenn Sie secrets-store.csi.k8s.io nicht finden, installieren Sie den Treiber erneut.

Der Pod secrets-store-csi-driver-provider-aws wird als DaemonSet bereitgestellt. Wenn der Pod nicht auf dem Worker-Knoten ausgeführt wird, auf dem der Anwendungs-Pod zu starten versucht, erhalten Sie die folgende Fehlermeldung:

„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"“

Führen Sie die folgenden beiden Befehle aus, um die Anzahl der secrets-store-csi-driver-provider-aws-Pods, die im Cluster ausgeführt werden, und die Anzahl der Knoten zu überprüfen:

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

kubectl get nodes

Wenn der Parameter desiredNumberScheduled des DaemonSets kleiner ist als die Anzahl der Knoten im Cluster, überprüfen Sie den Parameter Tolerations (Toleranzen) des DaemonSets:

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

Suchen Sie in der Befehlsausgabe unter tolerations: (Toleranzen) nach operator: Exists (Operator vorhanden). Wenn Sie operator: Exists (Operator vorhanden) nicht finden, dann könnte das der Grund sein, warum der DaemonSet-Pod secrets-store-csi-driver-provider-aws auf diesem Knoten nicht ausgeführt wurde. Das liegt daran, dass das DaemonSet secrets-store-csi-driver-provider-aws standardmäßig keine Taints toleriert. Um dieses Problem zu beheben, fügen Sie die Toleranz hinzu. Weitere Informationen finden Sie unter Taints and Tolerations auf der Kubernetes-Website.

Wenn die Dateien, die die SecretProviderClass abgerufen hat, größer als 4 Mebibyte (MiB) sind, erhalten Sie möglicherweise FailedMount-Warnungen. Die Fehlermeldung beinhaltet grpc: received message larger than max. Um Antworten zu akzeptieren, die größer als 4 MiB sind, geben Sie --max-call-recv-msg-size=size in bytes für den Secrets Store Container im DaemonSet csi-secrets-store an.

**Hinweis:**Ersetzen Sie die Größe in Byte durch die Größe, die der Treiber akzeptieren soll. Da größere Antworten den Speicherressourcenverbrauch des secrets-store-Containers erhöhen können, müssen Sie möglicherweise Ihr Speicherlimit erhöhen. Wenn Sie immer noch Probleme haben, überprüfen Sie die Protokollereignisse in chronologischer Reihenfolge, um festzustellen, ob es weitere Fehler gab:

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