i'm trying to install a helm chart where one of th...
# aws
q
i'm trying to install a helm chart where one of the values depends on the current eks cluster's k8s version. the helm chart provider mentions running
kubectl version
and grabbing the version from there and based on that providing the value to the helm chart. i'm trying to figure out how i can do that with pulumi. i have the
eks*.Cluster*
available within the program. how i can run an authenticated kubectl command against it?
v
Tbh you probably don’t want your cluster / Kubectl auto updating. I’d have that in a config file somewhere and then you can be in control of you’re updgrades when they come. Hopefully this solves your issue
q
the cluster version won't change
from the pulumi program
it will be done via aws console at some point
i need this helm chart to be aware of the version and update accordingly whenever run
v
Why don’t you just hard code the kubectl version? Surely that wil differ between your local dev and CI runners etc
Would be easier for you to be in control and keep it consistent
What’s the problem you’re trying to solve and what’s been the biggest issue so far?
b
The cluster version is an output property on the cluster object, just pass it that. It doesn’t need to be the kubectl version
q
i guess you mean
eksCluster*.*version
on
eks.Cluster
that can work. this is not the first time i've needed something like this, though. for example, i recently wanted to configure a k8s deployment where the image for it should be either a new one defined on an environment variable, else just use the current deployment's one. so i used kubectl for that inside the pulumi program, but this meant grabbing the kubeconfig json, saving that, running a shell command to obtain the current image within the program, etc.
i suppose i was wondering if there was a pattern for this sort of thing
v
Sounds like you’re doing stuff that’s not best practise to determine this stuff, the way we handle versions is having them controlled in outputs from a config stack or having them hard coded and then gradually rolling out change by bumping them and release it to test clusters etc
If aws decide to update the eks cluster and there’s not a matching version for downstream applications that’s going to cause issues
q
yeah, perhaps you're right. not sure about setting the image id in the stack config, since the pulumi program might be running in a CI env, but also in local environments during the development of the program. it would mean i'd need to keep the config file updated locally, no? or how would you handle that situation?
v
Yeah exactly, you either need to keep it configured locally in files or it could introduce inconsistencies in CI
q
i ended up refactoring stuff to do what you recommended and keep the version tracked in the stack config. it really simplified doing things. thanks!