This message was deleted.

pulumi will honour your

$KUBECONFIG

but you can also set the `provider`: https://www.pulumi.com/docs/reference/pkg/nodejs/pulumi/kubernetes/#Provider This takes a providerArgs argument which you can use to specify your kubecontext. I don't think this has an example anywhere (that I can find) so I'll create an example for it

Cool, thank you @billowy-army-68599. I really want to just select my pulumi stack and have it talk to the correct kubernetes context. I’d prefer if it actually tweaked the kubectl config current-context so that other kubectl commands in different shells would talk to the right cluster and namespace

putting a pulumi config value that's the kubeconfig profile name could work easily to make this a per-stack config. however, be aware that the program won't be very portable if you're not committing the kubeconfig file into source control, or populating it automatically ...

Jesse, are you referring to

pulumi config set kubernetes:context <cluster_name>

? If so, that doesn’t seem to impact anything externally when I select the stack. Meaning, if I do a ‘kubectl config current-context’ I still see something else in a different shell

No, I mean, you can put your kubeconfig context name as a project-local config item, then pass it in to the provider: https://www.pulumi.com/docs/reference/pkg/nodejs/pulumi/kubernetes/#ProviderArgs-context

I see what you’re saying. I already have code for pulumi to understand what is in the kube context, I was hoping to go the other way, such that when I select a stack, the act of selecting the stack would change my kube context so that I could run kubectl commands in other shells relating to the stack I’ve selected

What about using

exec

or

execSync

? https://nodejs.org/api/child_process.html#child_process_child_process_execsync_command_options

kubectl config use-context {context}

?

I’ll have to consider that; for the moment, I wrote a script to select the stack, set the kube context and kube namespace for every environment we use, which gets around the issue. It just feels brittle, since the kube context and kube namespace for the context all live inside the pulumi stack

I believe by default it uses whatever context is current in your kubeconfig file. I think everything you pass into it overrides the values in the current context. I've been using it by providing a string-literal kubeconfig file, and generating it dynamically (since I'm on EKS, and this is fairly easy to do).

Ok, it appears that that’s how it has to work, meaning I can’t see a way to get the Provider class from an existing KUBE directory, or get a handle on what the pulumi program is using for the Provider. That’s what I’d like to start with, just getting handle on the Provider it’s using and query it

It isn't great on interrogating the state of the world, no. I think your best bet would be: - generate your kubeconfig from pulumi program as a custom resource; provision on the localhost - pass the generated kubeconfig file to pulumi k8s provider

Yeah, the only downside of that approach is that my other shells don’t really understand the environment that pulumi is using; that’s why I was hoping to have it set everything when I select the stack. I need to give more thought to your suggestion of having the program set the kube context and namespace as a side-effect of running, but that just feels a little odd. I’d rather have a hook do it when selecting the stack

You also might try playing around with multiple kubeconfig files that get merged together; the CLI supports this natively. As for merging stack select + kubeconfig select ... that seems really cool, but maybe best-suited for a shell alias. 🙂

Yes, I currently have a shell script to select the app and environment, which then selects the pulumi stack, sets the correct kube context and namespace. I just don’t like having all the duplicate settings 😄