No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

Ok, I’ve finally found the problem. I didn’t switch the `kubectl` config..

This is really error prone to have to change so many things in order to switch from one stack/cluster/project to another

I think pulumi should be in charge of that at one point

In the meantime I will write a tool to automate all of this, else I will begin to be crazy soon enough. I’ll keep you posted :wink:

We have a work item (<https://github.com/pulumi/pulumi/issues/1181>) to make it clearer in the display output when we're picking up ambient config for your deployment target, to help to avoid pitfalls like this. cc <@UB9JVTW07> on that

It *is* possible to specify your kubeconfig in code, however, unless I'm missing something this isn't as smooth as it could be. For example, you can do this

```
const config = new pulumi.Config();
const kubeconfig = config.require("kubeconfig");
const provider = new k8s.Provider("k8s", { kubeconfig });
const service = new k8s.v1.core.Service(..., { provider });
```

This configures an explicit Kubernetes provider that uses kubeconfig supplied via the Pulumi configuration system. All resources that use it (note the `..., { provider }` bit) will then target your kubeconfig, not the ambient `kubectl` one. You can similarly specify `cluster` or `context`.

I'm not sure if there's a way to set the stack-wide config in the same manner, however, e.g.

```
$ cat kubeconfig.json | \
    pulumi config set kubernetes:kubeconfig --
```

(or `cluster`, or `context`...)

<@UBAJ7TD53> <@UE1LN7A22> Is this currently possible?

Yeah, that's an annoying issue that frequently bites people using the k8s provider. I think you can set the parent object to automatically use the same provider, but it's not super convenient. We plan to address that more cleanly in the near future.

Thing is, to configure k8s, I generate a kubeconfig after having provisioned my cluster like the example you provide for gcp, which actually relies on the account currently selected by the `gcloud` tool.

I’ll come up with something :slightly_smiling_face: