由于授权失败，EKS 集群节点在大约 30 分钟后从“就绪”变为“未就绪”

Question 1

这些是我解决此问题所遵循的步骤...

通过 SSH 连接到失败的实例。
执行“aws sts get-caller-identity”
记下用户的 ARN，它可能是这样的 arn:aws:sts::999999999999:assumed-role/AmazonSSMRoleForInstancesQuickSetup/i-00000000000ffffff

请注意，这里的角色是 AmazonSSMRoleForInstancesQuickSetup，这对我来说似乎是错误的 - 但据我所知，我在创建集群时严格遵循了指南。

目前存在的问题：

a) 为什么此角色用于 AWS 身份？

b) 如果这是正确的角色，为什么它一开始就成功，但在集群创建 30 分钟后才失败？

c) 如果这是正确的角色，缺少哪些访问权限？

就我个人而言，我觉得这对我来说是错误的角色，但我通过解决要点 (c) 解决了我的问题。

继续步骤...

如果通过 AWS 控制台中的 IAM 服务检查此角色，则可以看到它没有所有必需的权限，默认情况下它具有：

AmazonSSMManagedInstanceCore

假设此角色是正确的角色，那么它至少需要添加以下策略：

AmazonEC2ContainerRegistryPowerUser

以通常的方式附加该策略，我承认这可能会授予比需要更多的权限，但那是另一回事了。

至此，AWS 安全配置应该是正确的，但这并不是故事的结束。

Kubernetes 通过 kubelet 进程有自己的安全角色映射需要考虑——即将 Kubernetes 用户映射到 IAM 用户或 AWS 上的角色。

通过编辑 Kubernetes 配置映射来维护此配置。

使用“kubectl edit -n kube-system configmap/aws-auth”编辑配置映射。

这是创建集群之后、进行任何更改之前的配置：

apiVersion: v1
data:
  mapRoles: |
    - groups:
      - system:bootstrappers
      - system:nodes
      rolearn: arn:aws:iam::999999999999:role/eksctl-my-demo-nodegroup-my-demo-NodeInstanceRole-AAAAAAAAAAAAA
      username: system:node:{{EC2PrivateDNSName}}
kind: ConfigMap
metadata:
  [...whatever...]

这里映射的唯一角色是节点实例角色 —— 该角色是在通过配置集群期间自动创建的eksctl。

更改配置图：

apiVersion: v1
data:
  mapRoles: |
    - rolearn: arn:aws:iam::999999999999:role/eksctl-my-demo-nodegroup-my-demo-NodeInstanceRole-AAAAAAAAAAAAA
      username: system:node:{{EC2PrivateDNSName}}
      groups:
      - system:bootstrappers
      - system:nodes
    - rolearn: arn:aws:iam::999999999999:role/AmazonSSMRoleForInstancesQuickSetup
      username: MyDemoEKSRole
      groups:
      - system:masters
    - rolearn: arn:aws:iam::999999999999:role/MyDemoEKSRole
      username: CodeBuild
      groups:
      - system:masters
      - system:bootstrappers
      - system:nodes
kind: ConfigMap
metadata:
  [...whatever...]

我已将 AmazonSSMRoleForInstancesQuickSetup 角色映射为 Kubernetes 主角色。

我还将MyDemoEKSRole先前为集群配置创建的集群安全角色映射到各种 Kubernetes 角色，以供 Kubernetes 被 CodeBuild 管道调用的情况。

保存此配置图，最终集群将自我修复并报告准备就绪。

结论：

执行完所有这些集群创建后步骤后，我的身份验证失败就消失了，集群再次开始报告成功状态，清除健康检查并将节点返回到状态Ready。

我坦率地承认这可能不是解决我的问题的“正确”方法，并且确实感觉我开放的安全方式比我应该开放的要多，但它确实有效并解决了我的问题。

正如此后不久提到的，我们转换到了 Azure 而不是 AWS，所以我没有再采取任何进一步的行动 - 但我最终得到了一个完全正常运行的集群，并且不再有任何过期的凭据。

我天真地以为这些工具能帮我创建一个工作集群。我发现的任何指南中都没有提到这个问题或这些步骤。

Answer