Team is new to K8. Wondering a couple things from the pros here. • Would Pulumi be a good start for a team writing Go to learn K8 without doing the normal yaml approach, or is there any opinion on starting with the yaml and maturing to Pulumi later? (I know the answer I expect here 😉 but still wanted to make sure). • Next I'm wrapping up some tasks with Mage (a Go based task runner) and setup some docker compose and goreleaser stuff recently. Next step is Minikube/Kind deployment locally. Most of the work I'm doing I want to produce locally first in a single cluster for development work. ◦ I've considered one approach with https://devspace.sh/ which seems to make this a nice smooth process. ◦ The other is to wrap up some pulumi commands. I'm not certain though if I can do most of my work with local development with pulumi and only store state in dashboard once I push to an actual environment. ◦ So in summary: I'm wondering if I can replace Docker compose file reasonably with a pulumi setup without it being too complicated, and can I replace any need for helm/k8 yaml for the local stage of testing with pulumi, or is it designed more for the shared environment deployments into a staging system? Cheers!

For your first bullet point, absolutely yes. The structure of your Pulumi k8s resources will be identical to the yaml files, so the knowledge you gain is directly transferrable to the yaml approach.

FYI this was proven to be very true. Intellisense and adding resources made this easy to translate from yaml to add new things. Only thing I'm super unclear on that i probably need to invest in learning is components concepts so I can begin making building blocks like helm would. Right now it's a little too messy and intertwined for my liking, not much better "in practice" than a helm chart for testing and such. Lots to learn!

There's Pulumi abstractions that are made for that like Components, but honestly I haven't used those (yet). I've found that simply wrapping related components in a function has been a very simple way to group resources. For example, you might have a function that accepts an object with key/value pairs as the equivalent of helm's

value.yaml

overrides, and the body of the function can just construct the deployment, configmaps, service, etc. and

return

them so they're accessible to the rest of the program.

I just noticed this and found out I did the same 🙂 Just broke them up (a bit overkill probably) each into an internal/name package to ensure I wasn't pulling anything between packages and then main has all the required pieces.