https://pulumi.com logo
#kubernetes
Title
# kubernetes
b

breezy-gold-44713

03/26/2020, 6:48 PM
Greetings! I may be missing the obvious, but is there a mechanism when selecting my pulumi stack that it can set the kubectl config context and namespace? Or an easy way to create some hooks to do that for me?
b

billowy-army-68599

03/26/2020, 7:14 PM
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
b

breezy-gold-44713

03/26/2020, 7:19 PM
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
b

brave-ambulance-98491

03/29/2020, 9:59 PM
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 ...
b

breezy-gold-44713

03/30/2020, 3:51 PM
Jesse, are you referring to
Copy code
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
b

brave-ambulance-98491

03/30/2020, 3:58 PM
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
b

breezy-gold-44713

03/30/2020, 4:03 PM
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
Since the pulumi stack has all the environment settings properly set up, it seems the perfect source for driving the context kube should be using
Unless I’m missing something as a side-effect of what you’re suggesting?
b

brave-ambulance-98491

03/30/2020, 4:13 PM
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}
?
b

breezy-gold-44713

03/30/2020, 4:15 PM
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
Jesse, do you have an example of the best way to get a handle on the Kubernetes Provider class, and/or construct one?
b

brave-ambulance-98491

03/30/2020, 4:32 PM
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).
b

breezy-gold-44713

03/30/2020, 4:38 PM
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 seems like it’s more suited to constructing the entire Provider from scratch
b

brave-ambulance-98491

03/30/2020, 4:45 PM
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
that way, you get a consistent provider string, and you localize all your k8s config into one place.
b

breezy-gold-44713

03/30/2020, 4:50 PM
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
b

brave-ambulance-98491

03/30/2020, 4:52 PM
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. 🙂
b

breezy-gold-44713

03/30/2020, 4:55 PM
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 😄
I’d rather have a built-in way for pulumi to invoke a program/script when the stack is selected to allow me to do custom stuff like that once the stack is chosen
4 Views