can anyone explain this pattern to me please? https://github.com/pulumi/pulumi-eks/blob/0658ec1989192efee4302607aac0f116e1c51ee1/nodejs/eks/cluster/cluster.ts#L2220-L2255

Which part?

If it's the highlighted bit from 2220 to 2255, that's not really a pattern. It's just detected that the resource already exists in state (urn is not undefined) so it doesn't go through the resource creation work. Normally this isn't done in component resources, only normal resources. I don't know why it's done this way in this provider.

Interesting, I though the same and I also do not understand the reasoning behind that. I’ve seen this pattern all over the place of pulumi provided components, namely AWSX. We are currently debating with my team whether we should drop

@pulumi/eks

due to past awsX pains which are still haunting our codebase.

Unfortunately not a comfort, but I recommend against anything AWSX-based for experienced users. I feel that a few design decisions make is awkward enough to use that it's generally better to roll your own components. Even if AWSX didn't have the features that irk me, I think that these sorts of strongly-opinionated-but-caters-to-(almost)-all-cases libraries are bad ideas. Either something is strongly opinionated and doesn't allow the "wrong" way of doing things, or is just the base components and you can do your own thing. The prime example of this is the logic in awsx.ec2.Vpc for creating public, private and isolated subnets from a simple array of counts. This is great for beginners but when you're a year into your project and looking to make optimizations, it bites hard.

We've been thinking about ways to like 'eject' from awsx. Take the state that awsx is currently setting and write out the resource declarations to match it. This would let you start with awsx but easily get out of it when you cross that complexity barrier.