No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

<@UJBNC99MF> I ultimately expected crd2pulumi for capi CRDs and rendering the custom resources inside pulumi...  :nerd_face: 

“exercise is left to the reader” :wink:

I did explore the use of `crd2pulumi`, but didn't have time to incorporate that into the session. <@UE1LN7A22> has hit the nail on the head precisely. :slightly_smiling_face:

But seriously, I’d be really interested to see that

I'll see about exploring that a bit further, it's definitely interesting to me as well

I think the first "next step" I'll be exploring is using the Automation API to drive the entire process---building the infrastructure stack, grabbing the values CAPI needs, and then applying the CAPI manifests.

At some point things are getting redundant when you are already working in pulumi and have all tools at hand for spinning up the cluster. I’m interested to see real use cases for capi...

Sounds like the perfect foundation for “kops 2.0”

`have all tools at hand for spinning up the cluster` &lt;- Are you talking about a managed K8s service here, like EKS or GKE? Or is there something else I'm missing for boostrapping self-managed clusters using Pulumi?

<@ULXSQT866> Thank you :slightly_smiling_face:

One of the main potential advantages I see for CAPI is that you could take advantage of upstream improvements while keeping the same API. It gives you lower-level control of the k8s cluster without necessarily having to manage all the cloud-specific infra yourself.

Yep, I was referring to managed k8s when I’m already running in a cloud environment. But there might be cases for CAPI-created clusters I don’t see at the moment. I’m somehow used to leverage the integrations the managed clusters come with (e.g. registry access, pod identities, integrated auth).

One off the top of my head would be running k8s versions closer to HEAD to preview changes

e.g. running your application against ephemeral test clusters on alpha/beta tags of k8s

Good point. Still a question if I’d want to run those in prod. Maybe ARM clusters could be one use case you don’t get as managed k8s.