Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kubernetes provider gives error on first 'terraform apply' #382

Closed
mukesh-panigrahi opened this issue Apr 1, 2019 · 6 comments
Closed

Comments

@mukesh-panigrahi
Copy link

mukesh-panigrahi commented Apr 1, 2019

Hello,

Stuck with a issue on kubernetes provider.
Getting below error on first 'terraform apply'.
Everything do works perfectly fine on subsequent tf apply.
Can anyone help me to find out the reason for this.
I am working on something where I need to automate everything in my pipeline and should not fail in between like this.

*kubernetes_service.memcache: Post http://localhost/api/v1/namespaces/default/services: dial tcp 127.0.0.1:80: connect: connection refused

* kubernetes_deployment.memcached: Failed to create deployment: Post http://localhost/apis/apps/v1/namespaces/default/deployments: dial tcp 127.0.0.1:80: connect: connection refused

Terraform Version

Terraform v0.11.11

  • provider.google v2.0.0
  • provider.kubernetes v1.5.2

Affected Resource(s)

Any GKE resource I try to create using the provider.

Terraform Configuration Files

provider "kubernetes" {
  config_path = "${path.root}/generated/kubeconfig"
  config_context_auth_info = "target-cluster"
}

Expected Behavior

It should worked on the very first time itself, instead of me manually doing a 'terraform apply' again.

More info to my case:

I am creating the kubeconfig file to a specified path using local_file resource and referring the same in my provider.

@alexsomesan
Copy link
Member

alexsomesan commented Apr 3, 2019

This looks like wrong / missing credentials.
How are you configuring credentials for the provider?
Is there any $HOME/.kube/config file present?

@mukesh-panigrahi
Copy link
Author

Well i am providing it using a generated local-file resource.
I had to giveup with the config file method as their were to many dependency and default options to be taken care of.
I used the token method, which worked fine.

@paultyng
Copy link
Contributor

paultyng commented Aug 5, 2019

This seems like the upstream progressive apply issue: hashicorp/terraform#4149

You cannot currently chain together a provider's config with the output of a resource.

@paultyng paultyng closed this as completed Aug 5, 2019
@HanBingfeng
Copy link

could you describe token method more specific, what should i do if i choose to use token method to cert the provider

@ddska
Copy link

ddska commented Oct 10, 2019

@HanBingfeng
Here is the example of using token auth:

data "google_client_config" "default" {}

data "google_container_cluster" "mycluster" {
  name = "mycluster"
  location = var.region
}

provider "kubernetes" {
  load_config_file = false
  host = google_container_cluster.mycluster.endpoint
  token = data.google_client_config.default.access_token

  client_certificate = base64decode(google_container_cluster.mycluster.master_auth[0].client_certificate)
  client_key = base64decode(google_container_cluster.mycluster.master_auth[0].client_key)
  cluster_ca_certificate = base64decode(google_container_cluster.mycluster.master_auth[0].cluster_ca_certificate)
}

@HanBingfeng
Copy link

@ddska thank you for your reply : )

MartinPetkov added a commit to GoogleCloudPlatform/fda-mystudies that referenced this issue Apr 20, 2020
For the SA, from https://www.terraform.io/docs/providers/google/r/google_service_account_key.html:
"This can be a string in the format {ACCOUNT} or projects/{PROJECT_ID}/serviceAccounts/{ACCOUNT}, where {ACCOUNT} is the email address or unique id of the service account."

Since it's using a unique_id, it should use the full name.

For the token, I got the suggestion from here: hashicorp/terraform-provider-kubernetes#382 (comment)

Co-authored-by: Martin Petkov <mpetkov@google.com>
@ghost ghost locked and limited conversation to collaborators Apr 21, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants