This message was deleted.

Generally, folks will separate infrastructure from applications using separate stacks. Then, you can use a StackReference (details depend on what you’re using to store your state) to pull in the necessary infrastructure details when deploying applications. This provides separation of concerns, smaller fault/failure domains, and more flexibility.

Do you have depends clauses in the opts that reference the eks cluster? We have them in separate projects, but it usually seem to wait properly when we use depends correctly. Hacky way would be to run a sleep 600 command and depend on that, or poll the cluster state....but yeah eks is slooow to provision.

In my experience you need to wait for the api server via its healthz endpoint. I do that by weaving this wait into the creation of the kubeconfig output; e.g. (dotnet/c#): https://github.com/gitfool/Pulumi.Dungeon/blob/55d54512f18d28c9447a243cf71c25be6cffe2d6/Aws/EksStack.cs#L106 https://github.com/gitfool/Pulumi.Dungeon/blob/55d54512f18d28c9447a243cf71c25be6cffe2d6/K8s/ApiServer.cs#L24

if you want to bring up an EKS cluster and some k8s reosurces in the same stack you should reference the

eksCluster.provider

in the k8s resources'

provider

opts property

I guess you're referring to pulumi-eks which also waits for the api server (That's probably where I got the idea from since I couldn't use it from dotnet at the time)

Thanks for the links. Relatively new to Pulumi, I still have a LOT to learn… Any examples of the depends clause? Part of the choice in Pulumi is the ability to use TypeScript. That’s another learning point on my part.

Awesome… Appreciate the assist.. I found myself mired in documentation overload.. This is extremely helpful.