This message was deleted.

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

kubectl

config..

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 @lemon-spoon-91807 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

...) @creamy-potato-29402 @gorgeous-egg-16927 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.