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

Are you creating an explicit provider, or using the default provider and config file settings?

<@U04E2D27NF5> I am using the default config (no explicit provider config), hence I am curious what exactly does the provider pick up

I tried to configure the provider explicitly, but to no avail. Same error.

<https://www.pulumi.com/registry/packages/kubernetes/installation-configuration/>

Set your pulumi config vars  `kubernetes:&lt;var&gt;` - possible options are listed here:

<https://www.pulumi.com/registry/packages/kubernetes/api-docs/provider/>

yes, I did all that. Without seeing what cluster/context gets used it is impossible to say what is going on

thank you, but I did try that.
As I said, for whatever reason the wrong context gets chosen. The question is how to check what context is picked up and why

what does including `--show-config` and `--debug` reveal when doing a *preview* ?

Also, are you running pulumi via a container ala docker-compose or locally?

pulumi binary is installed natively on the linux os

both flags reveal nothing that disclose what cluster connection details are used

I used -v 11 and trace options, but still nothing

found the issue
Apparently the clusters I deployed used the same default kubeadm name for a k8s admin — kubernetes-admin

when my automation merged several kubeconfig into one it made an interesting side effect on the authentication workflow.

Once I renamed the users it started to work well