Complete a 3 Question Survey and Earn a re:Post Badge
Help improve AWS Support Official channel in re:Post and share your experience - complete a quick three-question survey to earn a re:Post badge!
Como soluciono problemas ao integrar o Secrets Manager com o Amazon EKS?
Quando tento integrar o AWS Secrets Manager com o Amazon Elastic Kubernetes Service (Amazon EKS), recebo um erro.
Breve descrição
Se seus pods não entrarem no estado de Em execução, você receberá um erro ao integrar o Secrets Manager ao Amazon EKS. Para resolver esse problema, verifique os logs dos pods do driver Container Storage Interface (CSI) do Secrets Store para determinar os pods que não estão funcionando.
Resolução
Para exibir os pods do driver CSI do Secrets Store, execute o seguinte comando:
kubectl --namespace=kube-system get pods -l "app=secrets-store-csi-driver"
Para exibir os logs dos pods CSI do Secrets Store, execute o seguinte comando:
kubectl --namespace=kube-system logs -f -l "app=secrets-store-csi-driver"
Os logs a seguir mostram que cada pod está funcionando bem:
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
**Observação:**Os pods que realizam as mesmas ações aparecem como entradas duplicadas.
Se a SecretProviderClass no **volumeMount ** não existir no mesmo namespace do pod, você receberá o seguinte erro:
“Aviso FailedMount 3s (x4 over 6s) kubelet, kind-control-plane MountVolume.Falha na configuração do volume “secrets-store-inline”: erro rpc: code = Unknown desc = falha ao obter secretproviderclass default/aws, erro: secretproviderclasses.secrets-store.csi.x-k8s.io “aws” não encontrado”
A classe SecretProviderClass deve existir no mesmo namespace do pod.
O driver CSI do Secrets Store é implantado como um daemonset. Se os pods do Driver CSI não estiverem em execução no nó, você receberá o seguinte erro:
“Aviso FailedMount 1s (x4 over 4s) kubelet, kind-control-plane MountVolume.A configuração falhou para o volume “secrets-store-inline”: kubernetes.io/csi: Mounter.setupAT falhou ao obter o cliente CSI: o nome do driver secrets-store.csi.k8s.io não foi encontrado na lista de drivers CSI registrados”
Se o nó estiver no com taints, adicione uma tolerância para o taint no daemonset do Driver CSI Driver do Secrets Store.
Verifique se há algum seletor de nó que não permita que os pods do Driver CSI do Secrets Store sejam executados no nó:
kubectl --namespace=kube-system describe pods -l "app=secrets-store-csi-driver" | grep Node-Selectors*
Obtenha os rótulos associados aos nós de processamento em seu pod:
kubectl get node --selector=kubernetes.io/os=linux
Compare as saídas dos comandos anteriores. Certifique-se de que os rótulos correspondam aos valores do seletor de nós.
Verifique se o driver CSI foi implantado no cluster e se todos os pods estão no estado de Execução:
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
Exemplo de saída:
kubectl get csidriver NAME ATTACHREQUIRED PODINFOONMOUNT MODES AGE secrets-store.csi.k8s.io false true Ephemeral 110m
A saída anterior mostra que o driver foi implantado no cluster. Se você não encontrar secrets-store.csi.k8s.io, então reinstale o driver.
O pod secrets-store-csi-driver-provider-aws é implantado como um daemonset. Se o pod não estiver sendo executado no nó de processamento em que o pod da sua aplicação está tentando iniciar, você receberá o seguinte erro:
“Falha de MountVolume.setup para o volume “volumename”: erro rpc: código = Unknown desc = falha ao montar segredos, armazenar objetos para o namespace/pod do pod, err: erro ao conectar-se ao provedor “aws”: provedor não encontrado: provedor “aws"”
Para verificar o número de pods secrets-store-csi-driver-provider-aws em execução no cluster e o número de nós, execute os dois comandos a seguir:
kubectl get ds csi-secrets-store-provider-aws -n kube-system
kubectl get nodes
Se o parâmetro desiredNumberScheduled do daemonset for menor do que o número de nós no cluster, verifique o parâmetro Tolerations do daemonset:
kubectl get ds csi-secrets-store-provider-aws -n kube-system -o yaml
Na saída do comando, em tolerations:, procure pelo operador: Existe. Se não encontrar o operador: Existe, talvez seja por isso que o pod do daemonset secrets-store-csi-driver-provider-aws não foi executado nesse nó. Isso ocorre porque o daemonset secrets-store-csi-driver-provider-aws não tolera taints por padrão. Para resolver esse problema, adicione a tolerância. Para obter mais informações, consulte Taints e tolerâncias no site do Kubernetes.
Se os arquivos que a SecretProviderClass extraiu forem maiores que 4 mebibytes (MiB), você poderá receber avisos de FailedMount. A mensagem de erro inclui grpc: mensagem recebida maior do que o máximo. Para aceitar respostas maiores do que 4 MiB, especifique --max-call-recv-msg-size=tamanho em bytes para o contêiner Secrets Store no daemonset csi-secrets-store.
**Observação:**Substitua o tamanho em bytes pelo tamanho que você deseja que o driver aceite. Como respostas maiores podem aumentar o consumo de recursos de memória do contêiner secrets-store, talvez seja necessário aumentar seu limite de memória. Se ainda tiver problemas, revise os eventos de log em ordem cronológica para ver se ocorreu alguma outra falha:
kubectl get events -n kube-system --sort-by='.metadata.creationTimestamp'

Conteúdo relevante
- feita há 2 meseslg...
- feita há 2 meseslg...
- feita há 4 meseslg...
- feita há 3 meseslg...
- AWS OFICIALAtualizada há 4 meses