Open dm-sumup opened 2 years ago
Same here
Hi @dm-sumup,
This issue doesn't seem to be related to the provider itself, but the community module that uses this provider. It looks like there is a big discussion in the module issue tracker. Please follow up with the discussion to address the issue.
Thank you.
Same here
(Seems it tries to create aws-auth
which already exists )
Dirty override that works for me:
1) Create EKS with manage_aws_auth_configmap = false
and create_aws_auth_configmap = false
2) Then, after creation, change manage_aws_auth_configmap
to true
and set what you want.
I get the same error.
Edit:
It's a race condition issue, we managed to fix it by completely managing our own aws-auth
config map and setting manage_aws_auth_configmap
and create_aws_auth_configmap
to false.
Same
I get the same error.
IMO, this bug will be pretty hard to fix. The default cluster is created with aws-auth. At the same moment, the appropriate object for aws-auth should appear in the terraform state. (That is, as if an implicit terraform import has been executed). But terraform does not support such things as well as changing the plan on the fly.
For anyone landing here - this issue is not related to the Kubernetes provider
terraform-aws-eks
module we have provided both the manage_aws_auth_configmap
and create_aws_auth_configmap
because of this (and for backwards compatibility support). If you are creating a new cluster, you should be ok with setting both of these to true. HOWEVER - please understand that it is not foolproof and there is a race condition. If the EKS managed node group or Fargate profile create the configmap before Terraform, it will fail with the error message that the configmap already exists. Conversely, if you only have manage_aws_auth_configmap
and are relying on EKS managed node group or Fargate profiles to create the configmap, you most likely will see the error message about the congifmap not existing yetIn short:
manage_aws_auth_configmap = true
and create_aws_auth_configmap = true
manage_aws_auth_configmap = true
and create_aws_auth_configmap = true
because one will NOT be automatically created for you manage_aws_auth_configmap
- There isn't anything else that can be done at this time to resolve these issues unfortunately. We are all waiting for the next iteration of cluster role management which will alleviate these race conditions and ownership issues
Looking at the Kubernetes APIs, if force = true
on kubernetes_config_map_v1_data
resource, shouldn't the provider first be trying to do a GET /api/v1/namespaces/{namespace}/configmaps/{name}
then if a 404
do a POST /api/v1/namespaces/{namespace}/configmaps/{name}
. If the GET
is a 200
it should then do a PUT /api/v1/namespaces/{namespace}/configmaps/{name}
?
Isn't that the whole point of the force = true
on kubernetes_config_map_v1_data
?
For anyone landing here - this issue is not related to the Kubernetes provider
- EKS Managed node groups and Fargate profiles will automatically create an aws-auth configmap in the cluster if one does not exist which can lead to race conditions. In the
terraform-aws-eks
module we have provided both themanage_aws_auth_configmap
andcreate_aws_auth_configmap
because of this (and for backwards compatibility support). If you are creating a new cluster, you should be ok with setting both of these to true. HOWEVER - please understand that it is not foolproof and there is a race condition. If the EKS managed node group or Fargate profile create the configmap before Terraform, it will fail with the error message that the configmap already exists. Conversely, if you only havemanage_aws_auth_configmap
and are relying on EKS managed node group or Fargate profiles to create the configmap, you most likely will see the error message about the congifmap not existing yet- There isn't anything else that can be done at this time to resolve these issues unfortunately. We are all waiting for the next iteration of cluster role management which will alleviate these race conditions and ownership issues
In short:
- If you are creating a net new cluster, you should be safe with setting
manage_aws_auth_configmap = true
andcreate_aws_auth_configmap = true
- If you are creating a cluster with only self-managed node groups, you MUST set
manage_aws_auth_configmap = true
andcreate_aws_auth_configmap = true
because one will NOT be automatically created for you- If you know that you have an existing configmap already in the cluster, only use
manage_aws_auth_configmap
Tried this route and still came up with the same error on creating a net new EKS cluster 😭
set both manage_aws_auth_configmap
and create_aws_auth_configmap
to false during EKS creation, after creation successful, set manage_aws_auth_configmap
to true, still same issue, and check the EKS cluster, the aws_auth already exist
For anyone landing here - this issue is not related to the Kubernetes provider
- EKS Managed node groups and Fargate profiles will automatically create an aws-auth configmap in the cluster if one does not exist which can lead to race conditions. In the
terraform-aws-eks
module we have provided both themanage_aws_auth_configmap
andcreate_aws_auth_configmap
because of this (and for backwards compatibility support). If you are creating a new cluster, you should be ok with setting both of these to true. HOWEVER - please understand that it is not foolproof and there is a race condition. If the EKS managed node group or Fargate profile create the configmap before Terraform, it will fail with the error message that the configmap already exists. Conversely, if you only havemanage_aws_auth_configmap
and are relying on EKS managed node group or Fargate profiles to create the configmap, you most likely will see the error message about the congifmap not existing yet- There isn't anything else that can be done at this time to resolve these issues unfortunately. We are all waiting for the next iteration of cluster role management which will alleviate these race conditions and ownership issues
In short:
- If you are creating a net new cluster, you should be safe with setting
manage_aws_auth_configmap = true
andcreate_aws_auth_configmap = true
- If you are creating a cluster with only self-managed node groups, you MUST set
manage_aws_auth_configmap = true
andcreate_aws_auth_configmap = true
because one will NOT be automatically created for you- If you know that you have an existing configmap already in the cluster, only use
manage_aws_auth_configmap
This isn't working on an existing cluster (with existing configmap) with EKS managed node groups.
same problem.
New fresh cluster create with docker image terraform:light and option:
create_aws_auth_configmap = true
manage_aws_auth_configmap = true
crash with error:
module.infrastructure.module.eks.kubernetes_config_map.aws_auth[0]: Creating...
╷
│ Error: configmaps "aws-auth" already exists
│
│ with module.infrastructure.module.eks.kubernetes_config_map.aws_auth[0],
│ on .terraform/modules/infrastructure.eks/main.tf line 536, in resource "kubernetes_config_map" "aws_auth":
│ 536: resource "kubernetes_config_map" "aws_auth" {
New fresh cluster create with terraform installed on local workstation (no docker) and I dont have any problem.
It's crazy
just to re-iterate: https://github.com/hashicorp/terraform-provider-kubernetes/issues/1720#issuecomment-1266937679
https://github.com/aws/containers-roadmap/issues/185 is the solution that will properly address the issues listed on this thread
Hey guys! I think it looks like a lot of work to do here. terraform module has to do the following:
terraform output
aws_auth could not be created when : create_aws_auth_configmap = true manage_aws_auth_configmap = true
I'm using hashicorp/kubernetes ~> 2.26.0 alekc/kubectl ~> 2.0.4 aws ~> 5.0 terraform version : 1.6.4 / 1.5.3 both
Terraform Version, Provider Version and Kubernetes Version
Affected Resource(s)
Terraform Configuration Files
This is my .tf file:
Debug Output
Panic Output
Steps to Reproduce
Expected Behavior
EKS Cluster and nodegroup deployment
Actual Behavior
Cluster deploys, but nodegroups are not created nor registered to the cluster
Important Factoids
Deploying to AWS EKS
References
Community Note