On Terraform 0.14, our configuration works fine, until we upgrade the Azurerm provider from version 1.44 to version 2.88, and add the features {} in the provider block.
Then the plan fails with Error: Get “http://localhost/api/v1/namespaces/…”: dial tcp [::1]:80: connect: connection refused
We use Terraform to build AKS clusters in Azure.
The Kubernetes provider is upgraded to the latest release.
Any advise for a workaround would be really appreciated.
2 Likes
Hi @framigni,
It sounds like the provider has planned to replace your AKS cluster for some reason, and so when planning reaches the kubernetes provider there’s no known AKS cluster endpoint and so that provider is defaulting to connecting to localhost.
I think my next step here would be to create a plan with the -target=... specifying your AKS cluster resource address, which should then let you see the plan to replace that cluster and thus hopefully see what you’d need to change in the configuration in order to avoid replacing the cluster.
1 Like
Thanks, your help is really appreciated.
I’ve done as you suggested, the plan reports that the cluster must be replaced (as you expected), plus just a warning about a deprecated argument (which I quickly fixed), than nothing else.
We would really like to avoid any cluster re-building (which would cause a long outage and possibly extra headaches) and especially we don’t want to separate Azure and kubernetes into different states, as recommended in https://registry.terraform.io/providers/hashicorp/kubernetes/latest/docs#stacking-with-managed-kubernetes-cluster-resources (it seems a terrible limitation…)
1 Like
I think we are out of the woods. The tip of running terraform plan -target *nameofthecluster* was a good one: reading more carefully the plan output, the cluster replacement was forced by a change in the sku from Basic to Standard (which probably is the default setting requested by the new provider version) . So we’ve modified the configuration, explicitly declaring that we want a Basic sku and now the Plan doesn’t ask to replace the entire cluster, just a change on the config_map (hopefully no disruptive, still investigating)
Great outcome. Thanks again for the tip !
I’ve faced the same problem using another cloud provider and spent several hours debugging this issue.
I believe this use case needs better error handling.