hey folks.. I have a very newbie question , but ma...
# getting-started
a
hey folks.. I have a very newbie question , but maybe a complex scenario
I am building an example which involves two Kubernetes Clusters, one that is dynamically created using VCluster
I am using go, and the credentials for the dynamically created cluster are stored inside a Kubernetes Secret
I can get the secret.. but I wonder how to use these new credentials to for example install a new Helm Chart into the newly created cluster
I am looking in go at
Copy code
helm.NewRelease()
and I am guessing that I will need to mess up with the
ctx *pulumi.Context
I am pretty sure that @quiet-wolf-18467 and @broad-dog-22463 can point me in the right direction (async) of course
q
If you have the secret, you can create a new provider
a
yeah
q
new kubernetes.Provider(“vcluster”, { kubeconfig: secret.value});
Then when working with resources for that cluster, ensure you pass the ResourceOption provider in the last arg bundle
a
and then how do I use that provider with helm.Release? is that possible?
q
Hope that helps 😀
a
@quiet-wolf-18467 now the crazy question haha
q
Uh oh
a
(blog post is coming)
because I am doing this in local.. I should automate a port-forward to access the new API server 🙂
and while that is not a pulumi specific thing
I thought that some crazy person might have created something to help to automate that
in code
also for situations where you don’t want to expose services outside and just want to run a couple of interactions while running the pulumi app
because doing something like this: https://gianarb.it/blog/programmatically-kube-port-forward-in-go sounds like I will need to end up doing something like that for every language and a helper would totally help 🙂
q
You can use the Kubernetes client (the real one) to handle the port forward
But if you need this to work across multiple languages it gets tricky
But if you wrap this in a provider, you can write it purely in Go
Depends if you're aiming for a reusable component
a
I am trying to figure out how can I reuse and what I can’t ..
Using client-go might be the best alternative here
because I am guessing that the official java kube-client will provide similar features
the whole point of the blog post is to show what pulumi gives as part of the SDKs and what is language specific
Thanks a lot for the pointers @quiet-wolf-18467
very helpful
q
Glad I could help
🙌 1
a
I am getting back to this.. and a more generic question that I have is how to do get the KubeConfig from the pulumi Context.. I will be trying to figure that out.. but if someone has a pointer that will be great
context (go sdk)
nice.. this is kinda working in a way
🙂
@quiet-wolf-18467 this is funny..
I managed to wire stuff together
but now I am really wondering if this will work with pulumi as it is
as I am creating a Helm Release inside a VCluster, which has a different provider
pulumi keeps track of this release.. but that release is never going to be reachable again for pulumi to destroy on
pulumi destroy
I wonder if there is a way to make sure that
pulumi destroy
just destroy all the things it needs
to destroy without stopping if it finds an issue
q
@acoustic-apple-75209 Why won't the VCluster be accessible again?
You can add
retainOnDelete: true
as a resource option to the
helm.Release
, but any calls to refresh would cause another failure.
a
@quiet-wolf-18467 because of the port-forwarding..
q
Then I'd probably use just enough Pulumi to deploy the Operator, then have a stack run inside the cluster to manage the VCluster
a
I can share the code.. which is super dirty now.. but the idea was.. 1) Create VCluster 2) Port-forward to the VCluster API Server 3) install helm release to this new provider 4) shut down the port-forwarding (because if not the pulumi app will hang in there)
yeah.. so I thought about that as well..
you mean.. that the instalation of the chart inside the VCluster can be done from inside the cluster itself
q
Yep
a
Can you point me to that Operator?
q
a
oh.. the kube operator
ok
I know that one
@quiet-wolf-18467 but still even if it is done from inside the cluster.. the Pulumi operator will need to interact with the VCluster API server.. to manage the internal helm release.. I am not sure that the operator is ready to support those use cases
q
Is the VCluster API server available in the host cluster as a service endpoint?
a
yes it is
but the operator needs to understand that for example installing the Vcluster helm chart happens in the host .. and the application happens in the vcluster
but I need to do my homework there.. I will check the operator internals to see if I can make that happen
I am currently happy with the port-forward.. because, that’s just a thing for running locally.. in a real cluster I would have that service exposed, so I can connect from outside