如何解決 Secrets Manager 與 Amazon EKS 整合時的問題？

簡短說明

如果您的 Pod 沒有進入執行中狀態，則當您使用 Amazon EKS 整合 Secrets Manager 時會收到錯誤。若要解決此問題，請檢查 Secrets Store Container Storage Interface (CSI) Driver Pod 中的日誌檔，以決定是否有任何 Pod 無法執行。

解決方法

若要顯示 Secrets Store CSI Driver Pod，請執行下列命令：

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

若要顯示 Secrets Store CSI Pod 中的日誌檔，請執行下列命令：

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

下列日誌顯示每個 Pod 表現良好：

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

**注意：**執行相同動作的 Pod 會顯示為重複項目。

如果 VolumeMount 中的 SecretProviderClass 在與 Pod 相同的命名空間中不存在，則會收到下列錯誤：

"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 必須存在於與 Pod 相同的命名空間中。

Secrets Store CSI Driver 部署為 daemonset。如果節點上未執行 CSI Driver Pod，則會收到下列錯誤：

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

如果節點受到污染，則在 Secrets Store CSI Driver daemonset 中為污點新增容忍。

檢查是否有任何節點選擇器不允許 Secrets Store CSI Driver Pod 在節點上執行：

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

取得與 Pod 中的工作節點相關聯的標籤：

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

比較上述命令的輸出。確定標籤與節點選取器值相符。

檢查 CSI Driver 是否已部署到叢集，以及所有 Pod 是否處於執行中狀態：

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

-或-

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

範例輸出：

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

上述輸出顯示驅動程式已部署到叢集。如果找不到 secrets-store.csi.k8s.io，請重新安裝驅動程式。

secrets-store-csi-driver-provider-aws Pod 部署為常駐程式。如果當您的應用程式 Pod 嘗試啟動時，工作節點的 Pod 未在執行中，則您會收到下列錯誤：

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

若要檢查叢集中正在執行的secrets-store-csi-driver-provider-aws Pod 以及節點數量，請執行下列兩個命令：

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

kubectl get nodes

如果常駐程式 desiredNumberScheduled 參數小於叢集中的節點數目，請檢查常駐程式的容差參數：

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

在命令的輸出中，在容差下：，查找運算子： 存在。如果找不到運算子： 存在，那麼這可能是為什麼secrets-store-csi-driver-provider-aws 常駐程式 Pod 無法在該節點執行的原因。這是因為預設情況下，secrets-store-csi-driver-provider-aws 常駐程式不容差污點。若要解決此問題，請新增容差。如需詳細資訊，請參閱 Kubernetes 網站上的污點和容差。

如果 SecretProviderClass 提取的檔案大於 4 兆位元組 (MiB)，則可能會收到 FailedMount 警告。錯誤訊息包括 **grpc：收到的訊息大於最大值。**若要接受大於 4 MiB 的回應，請指定 --max-call-recv-msg-size=size in bytes 至 csi-secrets-store 常駐程式中的私密儲存容器。

**注意：**使用您希望驅動程式接受的大小取代 size in bytes。由於較大的回應可能會增加 secrets-store 容器的記憶體資源消耗，因此您可能需要增加記憶體限制。如果仍然存在問題，請按時間順序檢閱日誌事件，以查看是否有任何其他失敗：

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