The page on the Pulumi operator is quite light on justification of 'why this it is a good thing': https://www.pulumi.com/blog/pulumi-kubernetes-operator/ From https://github.com/pulumi/pulumi-kubernetes-operator it seems like it is purely CI/CD convenience - i.e. providing no additional functionality compared with deploying from say GitHub actions. Are there any specific advantages outside of CI integration that using the operator permits?

Speaking PURELY from a GitOps standpoint. This operator is conformant to the OpenGitOps Principles, which means, if you're in a NoOps situation; Developers can use whatever language they want for their source of truth. Opening up a world of possibilities where you don't have to teach Developers Infra in order to do GitOps I have an example here: https://github.com/christianh814/pulumi-k8s-operator-example

Thanks for response.

Developers can use whatever language they want for their source of truth.

What do you mean by this? Source of truth of what?

Without understanding how Kubernetes works with relation to GitOps, this will be hard to explain. “Source of truth” is where the configuration of the cluster is stored and is seen as the representation of the desired state of the Workload on the cluster. Traditionally (which seems weird to say because this is like still new but bear with me), this meant storing YAML in Git. Now there are GitOps controllers that read the “source of truth” (git) for the desired state (stored in YAML) and the controller reconciles the differences/drift. Think “My

deployment

is declared as 3 replicas in Git but there’s only 2 running. I’m going to scale it to match what you want”. NOW, Pulumi does this without YAML. Meaning a Developer writes the declarations in their language (I’m a Golang guy) rather than learn how the infra is laid out and learn how that relates/translates to YAML. HTH