配置映射"aws-auth"已经存在

Question

我正在使用这个模块创建三个EKS集群。一切都很好，只是当我尝试使用map_roles将configmap添加到集群时，我遇到了一个问题。

我的配置看起来像这样，我在所有三个集群中都有它

map_roles = [{
rolearn   = "arn:aws:iam::${var.account_no}:role/argo-${var.environment}-${var.aws_region}"
username  = "system:node:{{EC2PrivateDNSName}}"
groups    = ["system:bootstrappers","system:nodes"]
},
{
rolearn   = "arn:aws:sts::${var.account_no}:assumed-role/${var.assumed_role_1}"
username  = "admin"
groups    = ["system:masters","system:nodes","system:bootstrappers"]
},
{
rolearn  = "arn:aws:sts::${var.account_no}:assumed-role/${var.assumed_role_2}"
username  = "admin"
groups    = ["system:masters","system:nodes","system:bootstrappers"]
}
]

应用模板时出现问题。上面写着

configmaps "aws-auth" already exists

当我进一步研究这个错误时，我意识到在应用模板时，该模块会创建三个同名的配置映射资源，如

resource "kubernetes_config_map" "aws_auth" {
# ...
}
resource "kubernetes_config_map" "aws_auth" {
# ...
}
resource "kubernetes_config_map" "aws_auth" {
# ...
}

这显然是个问题。如何解决此问题？

Answer 1

创建托管节点池时，aws-auth-configmap由EKS创建。它具有节点向控制平面注册所需的配置。如果你想用Terraform控制configmap的内容，你有两个选项。

请确保在托管节点池资源之前创建配置映射。或者手动将现有的配置映射导入Terraform状态。

Answer 2

我知道已经太晚了。但分享一个我发现的解决方案。

我们应该使用kubernete_config_map_v1_data而不是Kubernete_configu_map_v1。该资源允许Terraform在预先存在的ConfigMap中管理数据。

示例，

resource "kubernetes_config_map_v1_data" "aws_auth" {
metadata {
name      = "aws-auth"
namespace = "kube-system"
}
data = {
"mapRoles" = data.template_file.aws_auth_template.rendered
}
force = true
}

data "template_file" "aws_auth_template" {
template = "${file("${path.module}/aws-auth-template.yml")}"
vars = {
cluster_admin_arn = "${local.accounts["${var.env}"].cluster_admin_arn}"
}
}

Answer 3

我现在已经测试了我的解决方案，它扩展到@pst的"import-aws auth"；答案如下：将主eks项目中的terraform apply操作分解为3个步骤，将eks资源与k8s资源完全隔离，这样您就可以从terraform工作流中管理aws-authConfigMap。

1. terraform apply -target=module.eks
   • 这只创建eks集群和模块创建的任何其他集群
   • eks模块的设计现在保证这将不包括来自kubernetes提供者的任何内容
2. terraform import kubernetes_config_map.aws-auth kube-system/aws-auth
   • 这将使上一步中创建eks集群生成的aws-auth-map进入远程地形状态
   • 只有当地图还没有处于状态时，这才是必要的，所以我们首先检查，如下所示：

if terraform state show kubernetes_config_map.aws-auth ; then
echo "aws-auth ConfigMap already exists in Remote Terraform State."
else
echo "aws-auth ConfigMap does not exist in Remote Terraform State. Importing..."
terraform import -var-file="${TFVARS_FILE}" kubernetes_config_map.aws-auth kube-system/aws-auth
fi

3. terraform apply
   • 这是一个"；正常的"；应用程序，其行为与以前完全相同，但与module.eks无关。最重要的是，这通电话不会遇到"aws-auth-ConfigMap已经存在"；错误，因为地形意识到它的存在，而建议的计划将更新aws-auth

NB:

1. 使用Makefile包装地形工作流使其易于实现
2. 使用带有-target的单片根模块有点难看，而且随着对kubernetes提供程序的使用增加，将所有kubernetesterraform对象分解为一个单独的项目是有意义的。但以上内容完成了任务
3. 无论如何，eks/k8s资源的分离是最佳实践，并且建议防止aws和k8s提供者之间的已知竞争条件。从这里开始追踪详细信息