问题标签 [amazon-eks]

我正在尝试使用位于https://github.com/kubernetes/charts/tree/master/stable/prometheus的默认 prometheus helm 图表将 Prometheus 安装到我的 EKS 集群。它部署成功，但在 Kubernetes 仪表板中，AlertManager 和服务器部署显示：

pod 有未绑定的 PersistentVolumeClaims（重复 3 次）

我试过修改values.yaml文件无济于事。

我知道这没什么好做的，但是我不确定在日志记录方面我还能查到什么。

这是运行的输出helm install stable/prometheus --name prometheus --namespace prometheus

我正在寻找这些日志：

在 EKS 中，用户无权访问控制平面，也无法直接查看这些文件。

我知道 AWS 宣布的CloudTrail集成。但它显示的事件不是来自 k8s API，而是 AWS EKS API 之类的CreateCluster事件。还有一个悬而未决的问题是如何获取调度程序和控制器管理器日志。

pod 列表中没有 api 和控制器的 pod。

节点列表中没有主节点

当我尝试测试 kubectl 的配置时

我得到这个

错误：服务器没有资源类型“svc”

当我尝试这个命令时

我收到错误：

与服务器 localhost:8080 的连接被拒绝 - 您是否指定了正确的主机或端口？

我正在按照这个用户指南在我的 Mac 上部署一个 kubernetes 应用程序

https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html#eks-create-cluster

我已按照说明使用 Terraform 在 AWS 中创建 EKS 集群。

https://www.terraform.io/docs/providers/aws/guides/eks-getting-started.html

我还将连接到集群的输出复制到 ~/.kube/config-eks。我已经验证这可以成功，因为我已经能够连接到集群并手动部署容器。但是，现在我正在尝试使用 Terraform Kubernetes 提供程序连接到集群，但似乎无法正确配置提供程序。

我已将提供程序配置为使用我的 kubectl 配置，但是在尝试推送简单的 configmap 时，我收到一条错误消息，说明如下：

禁止配置映射：用户“system:anonymous”无法在命名空间“kube-system”中创建配置映射

我知道提供商正在获取部分配置，但我似乎无法对其进行身份验证。我怀疑这是因为 EKS 使用 heptio 进行身份验证，我不确定 Terraform 使用的 K8s Go 客户端是否支持 heptio。但是，鉴于 Terraform 在 EKS 正式发布时发布了他们的 AWS EKS 支持，我怀疑他们不会更新他们的 Terraform 提供商以使用它。

现在甚至有可能做到这一点吗？有替代品吗？

EKS 文档说

“当您创建 Amazon EKS 集群时，会自动授予 IAM 实体（用户或角色）在集群的 RBAC 配置中的 system:master 权限”。

但是在 EKS 集群创建之后，如果您检查 aws-auth 配置映射，它没有 ARN 映射到system:masters组。但我可以通过 kubectl 访问集群。因此，如果 aws-auth（heptio 配置映射）没有将我的 ARN（我是创建 EKS 集群的人）映射到system:masters组，那么 heptio aws 身份验证器如何对我进行身份验证？

在 AWS EKS 上启动并运行我的集群后，我发现运行helm init时出现以下错误：

kubectlheptio-authenticator-aws正常工作（对象检索、创建和集群管理），通过在连接时运行（exec在 kubectl 配置中的一个部分）正确地进行身份验证和授权。

为了为 helm 准备集群，我创建了 helm docs中指定的服务帐户和角色绑定。

我听说有人在 EKS 上运行 helm，我猜他们exec通过硬编码令牌来跳过 kubectl 配置的部分......我想避免这种情况！

有想法该怎么解决这个吗？我的猜测是它与 helm 无法heptio-authenticator-aws正常执行有关

我构建了一个 docker 映像以helm在容器中运行。

我已经设置kubeconfig了默认路径~/.kube/config，我可以在本地运行 helm 命令

但是在容器中运行 helm 命令时，出现以下错误：

$ docker run -ti --rm -v ~/.kube:/root/.kube -v $(pwd):/apps helm list

错误：获取https://xxxx.yl4.us-west-2.eks.amazonaws.com/api/v1/namespaces/kube-system/pods?labelSelector=app%3Dhelm%2Cname%3Dtiller：拨打 tcp 10.xxx .7.xxx:443: i/o 超时

有什么我可以检查的吗？

更新

第二天试了，没有任何变化。

我们正在使用与 Vault 集成的 EKS，使用 Kubernetes 作为 Vault 的“身份验证后端”。我们看到的一个安全漏洞是，如果有人可以访问 kubelet 证书，他们可以冒充 kubelet，因此可以获得 pod 已映射到的服务帐户的机密（根据Vault 角色定义）并使用 Vault 验证自身并从 Vault 获取数据库凭据。有没有办法缓解这种情况。基本上我们如何才能降低有人冒充 kubelet 的风险。

我正在尝试在 Terraform 中配置 kubernetes 提供程序，但是到目前为止我一直无法做到。EKS 使用 heptio 身份验证器，因此我没有可以提供给 Kubernetes 提供商的证书路径。实现这一目标的正确方法是什么？

我已经尝试过这样的事情：

结果得到：

我有一个 ~/.kube/config ，我会丢失什么？

我正在尝试使用 v1alpha3 路由打开到 Istio 服务网格的 TCP 连接。我可以成功打开与外部负载均衡器的连接。该流量按预期进入默认 IngressGateway；我已经tcpdump在 IngressGateway pod 上验证了这一点。

不幸的是，流量永远不会转发到服务网格中；它似乎死在了 IngressGateway 中。

以下是我的配置示例：

我已经验证 IngressGateway 可以通过netcat指定端口访问服务。使用 envoy 在 Service pod 上运行tcpdump表明永远不会尝试与 pod 或代理进行通信。

我已经多次阅读文档，但我不知道如何继续。文档中的这一行对我来说是可疑的：

虽然 Istio 将配置代理以侦听这些端口，但用户有责任确保允许到这些端口的外部流量进入网格。

有什么想法吗？